https://wiki.archlinux.org/api.php?action=feedcontributions&user=Jelly&feedformat=atomArchWiki - User contributions [en]2024-03-29T08:48:43ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=DeveloperWiki:How_to_be_a_packager&diff=780555DeveloperWiki:How to be a packager2023-06-07T10:38:00Z<p>Jelly: /* Checkout/update a local package repository */ copied over from the ABS page</p>
<hr />
<div>[[Category:DeveloperWiki]]<br />
== Follow package guidelines ==<br />
<br />
Package guidelines can be found in the Arch Linux documentation, follow them closely.<br />
<br />
[[Arch packaging standards]]<br />
<br />
== Preparation and setup ==<br />
<br />
=== Installing the packages ===<br />
<br />
Make sure you have the packages {{pkg|devtools}} and {{pkg|namcap}} installed.<br />
<br />
=== SSH configuration ===<br />
<br />
If you have multiple SSH keys in your SSH Agent, you will need to make sure that the correct key is being used to contact the Arch servers.<br />
Also, when your local username differs from the one being used on the Arch servers, you need to take care of that too.<br />
<br />
Example {{ic|~/.ssh/config}} excerpt:<br />
<br />
{{bc|<br />
Host repos.archlinux.org<br />
Hostname repos.archlinux.org<br />
User archie<br />
IdentityFile ~/.ssh/id_arch<br />
IdentitiesOnly yes<br />
}}<br />
<br />
Also make sure to [https://gitlab.archlinux.org/-/profile/keys set your ssh key] in Gitlab: <br />
<br />
{{bc|<br />
Host gitlab.archlinux.org<br />
Hostname gitlab.archlinux.org<br />
User archie<br />
IdentityFile ~/.ssh/id_arch<br />
IdentitiesOnly yes<br />
}}<br />
<br />
{{Tip|While you are at it you can also add your packager GPG key to show the "verified" tag on your signatures on Gitlab. For more information about this see [https://gitlab.archlinux.org/help/user/project/repository/gpg_signed_commits/index.md#add-a-gpg-key-to-your-account].}}<br />
<br />
=== makepkg configuration ===<br />
<br />
Make sure to configure your {{ic|~/.makepkg.conf}} with the correct {{ic|PACKAGER}} and {{ic|GPGKEY}} variables.<br />
Wrong signatures or missing {{ic|PACKAGER}} will prevent your packages from entering the repository.<br />
<br />
{{bc|1=<br />
PACKAGER="Archie <archie@archlinux.org>"<br />
GPGKEY="0x0123456789abcdef"<br />
}}<br />
<br />
=== Helper scripts (optional) ===<br />
<br />
The packaged helper scripts below can be installed from the {{Grp|archlinux-tools}} group. <br />
<br />
* {{pkg|arch-rebuild-order}} — List the rebuild order of packages using the local pacman syncdb's.<br />
* {{pkg|arch-signoff}} — Signoff packages from [[testing]] interactively in your terminal.<br />
* {{pkg|arch-repro-status}} — List the reproducible status of your packages interactively in your terminal with the ability to see the build logs and diffoscope output per un-reproducible package.<br />
* {{pkg|archlinux-contrib}} — Collection of contrib scripts used in Arch Linux.<br />
<br />
== The workflow ==<br />
<br />
=== Checkout/update a local package repository ===<br />
<br />
Checkout an existing package:<br />
<br />
$ pkgctl repo clone ''packagename''<br />
<br />
{{Tip|This clones over SSH by default so if you do not have a GitLab account you need to clone over HTTPS by specifying the {{ic|--protocol}} argument: {{ic|pkgctl repo clone --protocol{{=}}https}}.}}<br />
<br />
Update an existing, previously checked out, package:<br />
<br />
$ cd ''packagename''<br />
$ git pull<br />
<br />
=== Adding a new package ===<br />
<br />
This step is only required when adding a new package to the repository for the first time.<br />
<br />
$ pkgctl repo create --clone ''new-package''<br />
$ cd ''new-package''<br />
$ cp /usr/share/pacman/PKGBUILD.proto PKGBUILD<br />
$ $EDITOR PKGBUILD<br />
$ git add .<br />
$ git commit<br />
<br />
{{Warning|dbscripts does not support packages with a different split package architecture.}}<br />
<br />
=== Change and build ===<br />
<br />
It is '''mandatory''' to build your package using a [[DeveloperWiki:Building in a clean chroot|clean chroot]].<br />
{{ic|pkgctl build}} does this automatically.<br />
<br />
$ cd ''some-package''<br />
$ $EDITOR PKGBUILD<br />
$ pkgctl build<br />
<br />
=== Run namcap on both PKGBUILD and package ===<br />
<br />
{{Note|When using {{ic|pkgctl build}}, this is done automatically.}}<br />
<br />
$ namcap PKGBUILD<br />
$ namcap ''some-package''-1.0-1-x86_64.pkg.tar.zst<br />
<br />
=== Run checkpkg on the package ===<br />
<br />
{{Note|When using {{ic|pkgctl build}}, this is done automatically.}}<br />
<br />
Run in the directory with your freshly built package to get a file list diff compared with the package version currently in the repositories.<br />
<br />
$ checkpkg<br />
<br />
{{Note|This can be skipped when adding a new package to the repository for the first time (e.g. by importing it from [[AUR]] to [[extra]]).}}<br />
<br />
=== Run sogrep on identified soname change ===<br />
<br />
{{Note|When using {{ic|pkgctl build}}, this is done automatically.}}<br />
<br />
If [[#Run checkpkg on the package|checkpkg]] identified a shared object name (aka. soname) change in {{ic|''package''}}'s library {{ic|''package''.so}}, it is '''required''' to rebuild packages directly depending on it.<br />
<br />
To identify which packages rely on a given library in {{ic|''package''}} in a repository (e.g. ''extra'', use sogrep (see {{man|1|sogrep}}).<br />
<br />
$ sogrep ''repository'' ''package''.so<br />
<br />
Build {{ic|''package''}} for its respective [[Official repositories#Staging repositories|staging]] environment (by following the remaining steps in [[#The workflow|the workflow]]) and create a [https://archlinux.org/todo/ TODO] with the identified dependants, so their maintainers can rebuild them against the new version of {{ic|''package''}}.<br />
<br />
{{Note|First sync with [https://archlinux.org/people/trusted-users/ trusted users] and/or [https://archlinux.org/people/developers/ developers], if any packages currently in the [[staging]] environment block the rebuilds against {{ic|''package''}}.}}<br />
<br />
=== Use devtools to sign, upload and commit ===<br />
<br />
Once you are satisfied with the package, you need to make sure all your changes are tracked in the repository.<br />
Run:<br />
<br />
$ git status<br />
<br />
in the {{ic|''some-package''}} directory and check the output carefully.<br />
If, for example, you have added a new {{ic|''some-package''.install}} file, you need to tell git to track that file, e.g.:<br />
<br />
$ git add ''some-package''.install<br />
<br />
Make sure to '''never''' add the binary packages, makepkg logs, etc. to the repository!<br />
<br />
When you are ready to proceed, you can run the devtools scripts to sign, upload and commit your work:<br />
<br />
$ pkgctl release --message "update to 1.2.3, add post_upgrade hook to fix permissions"<br />
<br />
Please try to write concise commit messages.<br />
If the package is simply an upstream change, that is fine, but if anything more complex changes, please inform us by writing an appropriate commit message.<br />
<br />
{{Warning|Make sure to also specify {{ic|--testing}} when releasing if you built against ''testing''. Otherwise the package could be linked against dependencies that are not present on the target system.}}<br />
<br />
This will upload the package and its signature to their repository specific location in your user's {{ic|~/staging}} directory on {{ic|repos.archlinux.org}} aswell as creating a signed tag for the version on the packages git repository.<br />
<br />
=== Update the repository ===<br />
<br />
Using {{ic|db-update}} will find new packages for a set of repositories, depending on which is being called.<br />
<br />
To release uploaded packages to [[core]], [[extra]], [[gnome-unstable]], [[kde-unstable]], [[staging]], or [[core-testing]] and [[extra-testing]] use:<br />
<br />
$ pkgctl db update<br />
<br />
== Other operations ==<br />
<br />
=== Removing a package ===<br />
<br />
Using {{ic|db-remove}} will remove a package from a specific binary repository.<br />
<br />
To remove a package from [[core]], [[extra]], [[gnome-unstable]], [[kde-unstable]], [[staging]], or [[core-testing]] and [[extra-testing]] use:<br />
<br />
$ pkgctl db remove core-testing ''libfoo''<br />
<br />
If removing the package from the repositories altogether, it is encouraged to archive it on Gitlab aswell.<br />
Just go to the GitLab page with {{ic|pkgctl repo web}} and archive it there.<br />
<br />
=== Moving a package between repositories ===<br />
<br />
Using {{ic|db-move}} will move a package between two binary repositories.<br />
<br />
To move packages of the same {{ic|pkgbase}} between [[core]], [[extra]], [[gnome-unstable]], [[kde-unstable]], [[staging]], or [[core-testing]] and [[extra-testing]], use:<br />
<br />
$ pkgctl db move ''source_repository target_repository pkgbase''...<br />
<br />
Under the hood it calls: <br />
<br />
$ ssh repos.archlinux.org "/packages/db-move ''from_repository to_repository packages''"<br />
<br />
e.g. to move packages of the {{ic|pkgbases}} {{ic|''foo''}} and {{ic|''bar''}} from [[core-testing]] to [[core]]:<br />
<br />
$ pkgctl db move core-testing core ''foo bar''<br />
<br />
== Miscellaneous stuff ==<br />
<br />
=== Avoid having to enter your password all the time ===<br />
<br />
When working with {{ic|extrapkg}} and the other devtools, quite a few ssh connections are established, even when using ssh keys and the ssh agent.<br />
You can work around that.<br />
<br />
Add this to your {{ic|~/.ssh/config}}:<br />
<br />
Host gitlab.archlinux.org<br />
ControlMaster auto<br />
ControlPath /run/user/%i/ssh-%r@%h:%p<br />
ControlPersist 15m<br />
<br />
Enter your password and leave that session open until you are finished.<br />
All ssh sessions to Gitlab will now be tunneled through this connection.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Pushing to the wrong repository ===<br />
<br />
If you find yourself accidentally having pushed a package to the wrong repository (e.g. running {{ic|pkgctl release}} with {{ic|--repo extra}} instead of {{ic|--repo core}} against {{ic|''example''-1.0.0-any.pkg.tar.zst}}) you can undo it.<br />
<br />
{{Note|This only applies to cases where the [[#Update the repository|repository update]] has not been done yet. If the repository has been updated already, refer to [[#Moving a package between repositories]].}}<br />
<br />
Remove the package from the staging location on the repositories server:<br />
<br />
$ ssh repos.archlinux.org "rm staging/extra/example-1.0.0-any.pkg.tar.zst*"<br />
<br />
Afterwards, proceed again with [[#Use devtools to sign, upload and commit|signing, uploading and committing]].</div>Jellyhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:How_to_be_a_packager&diff=780533DeveloperWiki:How to be a packager2023-06-07T07:00:44Z<p>Jelly: /* Checkout/update a local package repository */ Explain that we clone over ssh by default.</p>
<hr />
<div>[[Category:DeveloperWiki]]<br />
== Follow package guidelines ==<br />
<br />
Package guidelines can be found in the Arch Linux documentation, follow them closely.<br />
<br />
[[Arch packaging standards]]<br />
<br />
== Preparation and setup ==<br />
<br />
=== Installing the packages ===<br />
<br />
Make sure you have the packages {{pkg|devtools}} and {{pkg|namcap}} installed.<br />
<br />
=== SSH configuration ===<br />
<br />
If you have multiple SSH keys in your SSH Agent, you will need to make sure that the correct key is being used to contact the Arch servers.<br />
Also, when your local username differs from the one being used on the Arch servers, you need to take care of that too.<br />
<br />
Example {{ic|~/.ssh/config}} excerpt:<br />
<br />
{{bc|<br />
Host repos.archlinux.org<br />
Hostname repos.archlinux.org<br />
User archie<br />
IdentityFile ~/.ssh/id_arch<br />
IdentitiesOnly yes<br />
}}<br />
<br />
Also make sure to [https://gitlab.archlinux.org/-/profile/keys set your ssh key] in Gitlab: <br />
<br />
{{bc|<br />
Host gitlab.archlinux.org<br />
Hostname gitlab.archlinux.org<br />
User archie<br />
IdentityFile ~/.ssh/id_arch<br />
IdentitiesOnly yes<br />
}}<br />
<br />
{{Tip|While you are at it you can also add your packager GPG key to show the "verified" tag on your signatures on Gitlab. For more information about this see [https://gitlab.archlinux.org/help/user/project/repository/gpg_signed_commits/index.md#add-a-gpg-key-to-your-account].}}<br />
<br />
=== makepkg configuration ===<br />
<br />
Make sure to configure your {{ic|~/.makepkg.conf}} with the correct {{ic|PACKAGER}} and {{ic|GPGKEY}} variables.<br />
Wrong signatures or missing {{ic|PACKAGER}} will prevent your packages from entering the repository.<br />
<br />
{{bc|1=<br />
PACKAGER="Archie <archie@archlinux.org>"<br />
GPGKEY="0x0123456789abcdef"<br />
}}<br />
<br />
=== Helper scripts (optional) ===<br />
<br />
The packaged helper scripts below can be installed from the {{Grp|archlinux-tools}} group. <br />
<br />
* {{pkg|arch-rebuild-order}} — List the rebuild order of packages using the local pacman syncdb's.<br />
* {{pkg|arch-signoff}} — Signoff packages from [[testing]] interactively in your terminal.<br />
* {{pkg|arch-repro-status}} — List the reproducible status of your packages interactively in your terminal with the ability to see the build logs and diffoscope output per un-reproducible package.<br />
* {{pkg|archlinux-contrib}} — Collection of contrib scripts used in Arch Linux.<br />
<br />
== The workflow ==<br />
<br />
=== Checkout/update a local package repository ===<br />
<br />
Checkout an existing package:<br />
<br />
$ pkgctl repo clone ''packagename''<br />
<br />
{{Tip|This clones over ssh by default so if you don't have a Gitlab account you need to clone over https by passing {{ic|--protocol{{=}}https''}} }}<br />
<br />
Update an existing, previously checked out, package:<br />
<br />
$ cd ''packagename''<br />
$ git pull<br />
<br />
=== Adding a new package ===<br />
<br />
This step is only required when adding a new package to the repository for the first time.<br />
<br />
$ pkgctl repo create --clone ''new-package''<br />
$ cd ''new-package''<br />
$ cp /usr/share/pacman/PKGBUILD.proto PKGBUILD<br />
$ $EDITOR PKGBUILD<br />
$ git add .<br />
$ git commit<br />
<br />
{{Warning|dbscripts does not support packages with a different split package architecture.}}<br />
<br />
=== Change and build ===<br />
<br />
It is '''mandatory''' to build your package using a [[DeveloperWiki:Building in a clean chroot|clean chroot]].<br />
{{ic|pkgctl build}} does this automatically.<br />
<br />
$ cd ''some-package''<br />
$ $EDITOR PKGBUILD<br />
$ pkgctl build<br />
<br />
=== Run namcap on both PKGBUILD and package ===<br />
<br />
{{Note|When using {{ic|pkgctl build}}, this is done automatically.}}<br />
<br />
$ namcap PKGBUILD<br />
$ namcap ''some-package''-1.0-1-x86_64.pkg.tar.zst<br />
<br />
=== Run checkpkg on the package ===<br />
<br />
{{Note|When using {{ic|pkgctl build}}, this is done automatically.}}<br />
<br />
Run in the directory with your freshly built package to get a file list diff compared with the package version currently in the repositories.<br />
<br />
$ checkpkg<br />
<br />
{{Note|This can be skipped when adding a new package to the repository for the first time (e.g. by importing it from [[AUR]] to [[extra]]).}}<br />
<br />
=== Run sogrep on identified soname change ===<br />
<br />
{{Note|When using {{ic|pkgctl build}}, this is done automatically.}}<br />
<br />
If [[#Run checkpkg on the package|checkpkg]] identified a shared object name (aka. soname) change in {{ic|''package''}}'s library {{ic|''package''.so}}, it is '''required''' to rebuild packages directly depending on it.<br />
<br />
To identify which packages rely on a given library in {{ic|''package''}} in a repository (e.g. ''extra'', use sogrep (see {{man|1|sogrep}}).<br />
<br />
$ sogrep ''repository'' ''package''.so<br />
<br />
Build {{ic|''package''}} for its respective [[Official repositories#Staging repositories|staging]] environment (by following the remaining steps in [[#The workflow|the workflow]]) and create a [https://archlinux.org/todo/ TODO] with the identified dependants, so their maintainers can rebuild them against the new version of {{ic|''package''}}.<br />
<br />
{{Note|First sync with [https://archlinux.org/people/trusted-users/ trusted users] and/or [https://archlinux.org/people/developers/ developers], if any packages currently in the [[staging]] environment block the rebuilds against {{ic|''package''}}.}}<br />
<br />
=== Use devtools to sign, upload and commit ===<br />
<br />
Once you are satisfied with the package, you need to make sure all your changes are tracked in the repository.<br />
Run:<br />
<br />
$ git status<br />
<br />
in the {{ic|''some-package''}} directory and check the output carefully.<br />
If, for example, you have added a new {{ic|''some-package''.install}} file, you need to tell git to track that file, e.g.:<br />
<br />
$ git add ''some-package''.install<br />
<br />
Make sure to '''never''' add the binary packages, makepkg logs, etc. to the repository!<br />
<br />
When you are ready to proceed, you can run the devtools scripts to sign, upload and commit your work:<br />
<br />
$ pkgctl release --message "update to 1.2.3, add post_upgrade hook to fix permissions"<br />
<br />
Please try to write concise commit messages.<br />
If the package is simply an upstream change, that is fine, but if anything more complex changes, please inform us by writing an appropriate commit message.<br />
<br />
{{Warning|Make sure to also specify {{ic|--testing}} when releasing if you built against ''testing''. Otherwise the package could be linked against dependencies that are not present on the target system.}}<br />
<br />
This will upload the package and its signature to their repository specific location in your user's {{ic|~/staging}} directory on {{ic|repos.archlinux.org}} aswell as creating a signed tag for the version on the packages git repository.<br />
<br />
=== Update the repository ===<br />
<br />
Using {{ic|db-update}} will find new packages for a set of repositories, depending on which is being called.<br />
<br />
To release uploaded packages to [[core]], [[extra]], [[gnome-unstable]], [[kde-unstable]], [[staging]], or [[core-testing]] and [[extra-testing]] use:<br />
<br />
$ pkgctl db update<br />
<br />
== Other operations ==<br />
<br />
=== Removing a package ===<br />
<br />
Using {{ic|db-remove}} will remove a package from a specific binary repository.<br />
<br />
To remove a package from [[core]], [[extra]], [[gnome-unstable]], [[kde-unstable]], [[staging]], or [[core-testing]] and [[extra-testing]] use:<br />
<br />
$ pkgctl db remove core-testing ''libfoo''<br />
<br />
If removing the package from the repositories altogether, it is encouraged to archive it on Gitlab aswell.<br />
Just go to the GitLab page with {{ic|pkgctl repo web}} and archive it there.<br />
<br />
=== Moving a package between repositories ===<br />
<br />
Using {{ic|db-move}} will move a package between two binary repositories.<br />
<br />
To move packages of the same {{ic|pkgbase}} between [[core]], [[extra]], [[gnome-unstable]], [[kde-unstable]], [[staging]], or [[core-testing]] and [[extra-testing]], use:<br />
<br />
$ pkgctl db move ''source_repository target_repository pkgbase''...<br />
<br />
Under the hood it calls: <br />
<br />
$ ssh repos.archlinux.org "/packages/db-move ''from_repository to_repository packages''"<br />
<br />
e.g. to move packages of the {{ic|pkgbases}} {{ic|''foo''}} and {{ic|''bar''}} from [[core-testing]] to [[core]]:<br />
<br />
$ pkgctl db move core-testing core ''foo bar''<br />
<br />
== Miscellaneous stuff ==<br />
<br />
=== Avoid having to enter your password all the time ===<br />
<br />
When working with {{ic|extrapkg}} and the other devtools, quite a few ssh connections are established, even when using ssh keys and the ssh agent.<br />
You can work around that.<br />
<br />
Add this to your {{ic|~/.ssh/config}}:<br />
<br />
Host gitlab.archlinux.org<br />
ControlMaster auto<br />
ControlPath /run/user/%i/ssh-%r@%h:%p<br />
ControlPersist 15m<br />
<br />
Enter your password and leave that session open until you are finished.<br />
All ssh sessions to Gitlab will now be tunneled through this connection.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Pushing to the wrong repository ===<br />
<br />
If you find yourself accidentally having pushed a package to the wrong repository (e.g. running {{ic|pkgctl release}} with {{ic|--repo extra}} instead of {{ic|--repo core}} against {{ic|''example''-1.0.0-any.pkg.tar.zst}}) you can undo it.<br />
<br />
{{Note|This only applies to cases where the [[#Update the repository|repository update]] has not been done yet. If the repository has been updated already, refer to [[#Moving a package between repositories]].}}<br />
<br />
Remove the package from the staging location on the repositories server:<br />
<br />
$ ssh repos.archlinux.org "rm staging/extra/example-1.0.0-any.pkg.tar.zst*"<br />
<br />
Afterwards, proceed again with [[#Use devtools to sign, upload and commit|signing, uploading and committing]].</div>Jellyhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:NewMirrors&diff=779434DeveloperWiki:NewMirrors2023-05-23T14:11:01Z<p>Jelly: /* Mirror size */ add multilib-testing</p>
<hr />
<div>[[Category:Arch development]]<br />
== Adding a new mirror ==<br />
<br />
This text should outline the procedure for adding a new mirror for Arch packages.<br />
<br />
== Notes about private mirrors ==<br />
<br />
* Bandwidth is not free for the mirrors. They must pay for all the data they serve you<br />
** This still applies although you pay your ISP<br />
** A full mirror is over 50 GiB in size<br />
* There are many packages that will be downloaded that you will likely never use<br />
* Mirror operators will much prefer you to download only the packages you need<br />
* Really please look at the alternatives listed in [[pacman/Tips and tricks#Network shared pacman cache]] before setting up a private mirror<br />
<br />
== 2-tier mirroring scheme ==<br />
<br />
Due to the high load and bandwidth limits Arch Linux uses 2-tier mirroring scheme.<br />
<br />
There are few tier 1 mirrors that sync directly from archlinux.org every hour.<br />
<br />
All other mirrors should sync from one of tier 1 mirrors. Syncing from archlinux.org is not allowed.<br />
<br />
== For the mirror administrator ==<br />
<br />
=== Tier 2 requirements ===<br />
<br />
* Disk-space >= 60 GiB<br />
* Sync off a tier 1 mirror (see https://archlinux.org/mirrors/tier/1/)<br />
* Sync all contents of the upstream mirror (i.e. do not sync only some repositories)<br />
* Do not sync more often than every hour, but you should sync at least once a day<br />
* Sync on a random minute so it is more likely the requests will be spaced out with other mirrors<br />
* Use the following [[rsync]] options: {{ic|-rlptH --safe-links --delete-delay --delay-updates}}<br />
* If you ever wish to send downtime notifications to our users, please use the [https://lists.archlinux.org/mailman3/lists/arch-mirrors-announce.lists.archlinux.org/ arch-mirrors-announce] list. You do not need to subscribe to be able to post.<br />
* http or https support<br />
<br />
=== Tier 1 requirements ===<br />
<br />
* Tier 2 requirements<br />
* Bandwidth >= 100 Mbit/s<br />
* [[rsync]] support<br />
* Proven reliability (be a tier 2 mirror for a while and have reasonable uptime, response to out-of-sync notifications etc.)<br />
<br />
You can use rsync directly or the [https://gitlab.archlinux.org/archlinux/infrastructure/-/blob/master/roles/syncrepo/files/syncrepo-template.sh syncrepo-template.sh script] as a starting point. Please note that the script tries to minimize load and bandwidth used (about 3 MiB of metadata for each rsync run as of 2018-03-01) in case there are no changes. Feel free to remove this check if you do not sync very often or your upstream mirror does not provide the {{ic|lastupdate}} file.<br />
<br />
=== Create a feature-request ===<br />
<br />
{{Note|We are not accepting new ftp mirrors.}}<br />
<br />
Go to [https://bugs.archlinux.org/newtask/proj1 https://bugs.archlinux.org] and create a feature-request (category: mirrors) containing the following information:<br />
<br />
* Mirror domain name<br />
* Geographical location of the mirror (country)<br />
* URLs for supported access methods (http(s), [[rsync]]) (no ftp)<br />
* Your mirror's available bandwidth<br />
* An administrative contact email (optional, see below)<br />
* An alternative administrative contact email (optional)<br />
* (tier 1 mirrors) Rsync IPs so your server(s) can be allowed to sync off tier 0 (rsync.archlinux.org)<br />
* (tier 2 mirrors) The name of tier 1 mirror you are syncing from. You can find available tier 1 mirrors in https://archlinux.org/mirrors/tier/1/<br />
<br />
The contact email(s) will be used by Arch Linux staff to contact the mirror administrator if they have questions regarding the mirror or if there are problems with the mirror. If a contact email is not provided, the mirror listing may be removed at any time, especially if problems occur, without prior contact to the admin.<br />
<br />
=== Contact info and mailing lists ===<br />
<br />
Feel free to join the [https://lists.archlinux.org/mailman3/lists/arch-mirrors.lists.archlinux.org/ arch-mirrors mailing list] which can be used for general discussion about our mirrors. If you want to inform our users about downtime of your mirror please use the [https://lists.archlinux.org/mailman3/lists/arch-mirrors-announce.lists.archlinux.org/ arch-mirrors-announce] mailing list. You do not need to subscribe to be able to post to arch-mirrors-announce.<br />
<br />
If you want to reach the Arch Linux staff for questions, you can either use the arch-mirrors list, you can open a bug report on our tracker or you can send a mail to [mailto:mirrors@archlinux.org mirrors@archlinux.org].<br />
<br />
== The Arch Linux side ==<br />
<br />
* Add the mirror info to the Django admin site<br />
* Regenerate the rsync whitelist with the {{ic|gen_rsyncd.conf.pl}} script - only for tier 1 mirrors, or when disabling access to a previously untiered mirror (also done by an hourly cronjob)<br />
* Regenerate the {{Pkg|pacman-mirrorlist}} package<br />
<br />
== Mirror size ==<br />
<br />
To give you an impression how much space will be needed for a mirror here are some numbers (as of 2023-05-23):<br />
<br />
Mandatory:<br />
<br />
* pool (all packages) - 80 GiB<br />
* repositories (core, core-testing, extra, extra-testing, gnome-unstable, kde-unstable, multilib, multilib-testing) - total ~200 MiB<br />
<br />
Optional:<br />
<br />
* iso - 5 GiB (encouraged)<br />
* archive - 15 GiB (permanently frozen)<br />
* other - 18 GiB<br />
* sources - 114 GiB<br />
* images - 6 GiB<br />
* pool/*-debug - 60 GiB (will likely grow in the future)<br />
<br />
Most mirrors do not sync archive, other and sources directories, but sync everything else (including temporary repositories),<br />
so usually you will need about 70 GiB reserved for Arch Linux mirror.<br />
<br />
However, note that the required space may temporarily increase when a big rebuild happens and thus many packages exist twice in different versions. Please plan in a buffer of 30 GiB to 50 GiB on top of the above mentioned values.</div>Jellyhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:How_to_be_a_packager&diff=778820DeveloperWiki:How to be a packager2023-05-20T11:38:32Z<p>Jelly: drop ch examples, it's not an official workflow</p>
<hr />
<div>[[Category:DeveloperWiki]]<br />
== Follow package guidelines ==<br />
<br />
Package guidelines can be found in the Arch Linux documentation, follow them closely.<br />
<br />
[[Arch packaging standards]]<br />
<br />
== Preparation and setup ==<br />
<br />
=== Installing the packages ===<br />
<br />
Make sure you have the packages {{ic|devtools}} and {{ic|namcap}} installed.<br />
<br />
=== SSH configuration ===<br />
<br />
If you have multiple SSH keys in your SSH Agent, you will need to make sure that the correct key is being used to contact the Arch servers.<br />
Also, when your local username differs from the one being used on the Arch servers, you need to take care of that too.<br />
<br />
Example {{ic|~/.ssh/config}} excerpt:<br />
<br />
{{bc|<br />
host repos.archlinux.org<br />
hostname repos.archlinux.org<br />
port 22<br />
user foobar<br />
IdentityFile ~/.ssh/id_arch<br />
IdentitiesOnly yes<br />
}}<br />
<br />
Also make sure to [https://gitlab.archlinux.org/-/profile/keys set your ssh key] in Gitlab: <br />
<br />
{{bc|<br />
host gitlab.archlinux.org<br />
hostname gitlab.archlinux.org<br />
user foobar<br />
IdentityFile ~/.ssh/id_arch<br />
IdentitiesOnly yes<br />
}}<br />
<br />
=== makepkg configuration ===<br />
<br />
Make sure to configure your {{ic|~/.makepkg.conf}} with the correct {{ic|PACKAGER}} and {{ic|GPGKEY}} variables.<br />
Wrong signatures or missing {{ic|PACKAGER}} will prevent your packages from entering the repository.<br />
<br />
{{bc|1=<br />
PACKAGER="Foo Bar <foo.bar@archlinux.org>"<br />
GPGKEY="0x0123456789abcdef"<br />
}}<br />
<br />
=== Helper scripts (optional) ===<br />
<br />
The packaged helper scripts below can be installed from the {{Grp|archlinux-tools}} group. <br />
<br />
* {{pkg|arch-rebuild-order}} — List the rebuild order of packages using the local pacman syncdb's.<br />
* {{pkg|arch-signoff}} — Signoff packages from [testing] interactively in your terminal.<br />
* {{pkg|arch-repro-status}} — List the reproducible status of your packages interactively in your terminal with the ability to see the build logs and diffoscope output per un-reproducible package.<br />
* {{pkg|archlinux-contrib}} — Collection of contrib scripts used in Arch Linux.<br />
<br />
== The workflow ==<br />
<br />
=== Checkout/update a local package repository ===<br />
<br />
$ pkgctl repo clone packagename<br />
$ # update an existing specific package<br />
$ cd packagename<br />
$ git pull<br />
<br />
=== Adding a new package ===<br />
<br />
This step is only required when adding a new package to the repository for the first time.<br />
<br />
$ pkgctl repo create --clone new-package<br />
$ cd new-package<br />
$ cp /usr/share/pacman/PKGBUILD.proto PKGBUILD<br />
$ $EDITOR PKGBUILD<br />
$ git add .<br />
$ git commit<br />
<br />
{{Warning|dbscripts does not support packages with a different split package architecture.}}<br />
<br />
=== Change and build ===<br />
<br />
It is '''mandatory''' to build your package using a clean [[DeveloperWiki:Building in a clean chroot|chroot]].<br />
{{ic|pkgctl build}} does this automatically. <br />
<br />
$ cd some-package<br />
$ $EDITOR PKGBUILD<br />
$ pkgctl build<br />
<br />
=== Run namcap on both PKGBUILD and package ===<br />
<br />
{{Note|This is automatically done, when using the devtools build scripts.}}<br />
<br />
$ namcap PKGBUILD<br />
$ namcap some-package-1.0-1-x86_64.pkg.tar.xz<br />
<br />
=== Run checkpkg on the package ===<br />
<br />
Run in the directory with your freshly built package to get a file list diff compared with the package version currently in the repositories.<br />
<br />
$ checkpkg<br />
<br />
{{Note|This can be skipped when adding a new package to the repository for the first time (e.g. by importing it from [[AUR]] to [[Official repositories#extra|extra]]).}}<br />
<br />
=== Run sogrep on identified soname change ===<br />
<br />
If [[#Run checkpkg on the Package|checkpkg]] identified a shared object name (aka. soname) change in {{ic|package}}'s library {{ic|package.so}}, it is '''required''' to rebuild packages directly depending on it.<br />
<br />
To identify which packages rely on a given library in {{ic|package}} in a repository (e.g. {{ic|extra}}, use sogrep (see {{man|1|sogrep}}).<br />
<br />
$ sogrep <repository> package.so<br />
<br />
Build {{ic|package}} for its respective [[Official repositories#Staging repositories|staging]] environment (by following the remaining steps in [[#The Workflow|The Workflow]]) and create a [https://archlinux.org/todo/ TODO] with the identified dependants, so their maintainers can rebuild them against the new version of {{ic|package}}.<br />
<br />
{{Note|First sync with [https://archlinux.org/people/trusted-users/ trusted users] and/ or [https://archlinux.org/people/developers/ developers], if any packages currently in the [[Official repositories#Staging repositories|staging]] environment block the rebuilds against {{ic|package}}.}}<br />
<br />
=== Use devtools to sign, upload and commit ===<br />
<br />
Once you are satisfied with the package, you need to make sure all your changes are tracked in the repository.<br />
Run:<br />
<br />
$ git status<br />
<br />
in the {{ic|some-package}} directory and check the output carefully.<br />
If, for example, you have added a new {{ic|some-package.install}} file, you need to tell git to track that file, e.g.:<br />
<br />
$ git add some-package.install<br />
<br />
Make sure to '''never''' add the binary packages, makepkg logs, etc. to the repository!<br />
<br />
When you are ready to proceed, you can run the devtools scripts to sign, upload and commit your work:<br />
<br />
$ pkgctl release --message "update to 1.2.3, add post_upgrade hook to fix permissions"<br />
<br />
Please try to write concise commit messages.<br />
If the package is simply an upstream change, that is fine, but if anything more complex changes, please inform us by writing an appropriate commit message.<br />
<br />
This will upload the package and its signature to their repository specific location in your user's {{ic|~/staging}} directory on {{ic|repos.archlinux.org}} aswell as creating a signed tag for the version on the packages git repository.<br />
<br />
=== Update the repository ===<br />
<br />
Using {{ic|db-update}} will find new packages for a set of repositories, depending on which is being called.<br />
<br />
To release uploaded packages to [[core]], [[extra]], [[gnome-unstable]], [[kde-unstable]], [[Official repositories#Staging repositories|staging]], or [[Official repositories#testing|testing]] use:<br />
<br />
$ ssh repos.archlinux.org "/packages/db-update"<br />
<br />
To release uploaded packages to [[Official repositories#community|community]], [[Official repositories#Staging repositories|community-staging]], [[Official repositories#community-testing|community-testing]], [[multilib]], [[Official repositories#Staging repositories|multilib-staging]], or [[Official repositories#multilib-testing|multilib-testing]] use:<br />
<br />
$ ssh repos.archlinux.org "/community/db-update"<br />
<br />
== Other operations ==<br />
<br />
=== Removing a package ===<br />
<br />
Using {{ic|db-remove}} will remove a package from a specific binary repository.<br />
<br />
To remove a package from [[core]], [[extra]], [[gnome-unstable]], [[kde-unstable]], [[Official repositories#Staging repositories|staging]], or [[Official repositories#testing|testing]] use:<br />
<br />
$ ssh repos.archlinux.org "/packages/db-remove <repo> <arch> <package_name>"<br />
<br />
e.g.<br />
<br />
$ ssh repos.archlinux.org "/packages/db-remove core x86_64 openssh"<br />
<br />
To remove a package from [[Official repositories#community|community]], [[Official repositories#Staging repositories|community-staging]], [[Official repositories#community-testing|community-testing]], [[multilib]], [[Official repositories#Staging repositories|multilib-staging]], or [[Official repositories#multilib-testing|multilib-testing]] use:<br />
<br />
$ ssh repos.archlinux.org "/community/db-remove <repo> <arch> <package_name>"<br />
<br />
e.g.<br />
<br />
$ ssh repos.archlinux.org "/community/db-remove community x86_64 jack2"<br />
<br />
If removing the package from the repositories altogether, it is encouraged to remove the entire package directory from version control as well. Just go to the GitLab page with {{ic|pkgctl repo browse}} and remove it.<br />
<br />
=== Moving a package between repositories ===<br />
<br />
Using {{ic|db-move}} will move a package between two binary repositories.<br />
<br />
To move packages of the same {{ic|pkgbase}} between [[core]], [[extra]], [[gnome-unstable]], [[kde-unstable]], [[Official repositories#Staging repositories|staging]], or [[Official repositories#core-testing|core-testing]] use:<br />
<br />
$ pkgctl db move [SOURCE_REPO] [TARGET_REPO] [PKGBASE]...<br />
<br />
Under the hood it calls: <br />
<br />
$ ssh repos.archlinux.org "/packages/db-move <from_repo> <to_repo> [packages]"<br />
<br />
e.g. to move packages of the {{ic|pkgbases}} {{ic|foo}} and {{ic|bar}} from [[testing]] to [[core]]:<br />
<br />
$ pkgctl db move testing core foo bar"<br />
<br />
E.g. to move a a package from [[Official repositories#community|community]] to [[extra]], use:<br />
<br />
$ community2extra <package_name><br />
<br />
Alternatively, the move from testing is so common, that there are helper scripts:<br />
<br />
$ /packages/testing2x openssh bzip2 coreutils<br />
<br />
$ /packages/testing2x64 openssh bzip2 coreutils<br />
<br />
These scripts only work if the packages on the commandline are either in ''core'' or ''extra''.<br />
<br />
If a package is only in testing, you have to use ''testing2core'', ''testing2core64'', ''testing2extra'' or ''testing2extra64''.<br />
<br />
=== Tagging releases ===<br />
<br />
Fetch the package dir using {{ic|pkgctl repo clone}}, then:<br />
<br />
$ cd package-name<br />
$ pkgctl release<br />
<br />
This makes an svn copy of the trunk entries in a directory named {{ic|extra-x86_64}} indicating that this package is in the extra repository for the ''x86_64'' architecture.<br />
This will be done automatically when using tools such as {{ic|extrapkg}} (see [[#Use devtools to sign, upload and commit|Use devtools to sign, upload and commit]]).<br />
<br />
== Miscellaneous stuff ==<br />
<br />
=== Avoid having to enter your password all the time ===<br />
<br />
When working with {{ic|extrapkg}} and the other devtools, quite a few ssh connections are established, even when using ssh keys and the ssh agent.<br />
You can work around that.<br />
<br />
Add this to your {{ic|~/.ssh/config}}:<br />
<br />
Host gitlab.archlinux.org<br />
ControlMaster auto<br />
ControlPath /run/user/%i/ssh-%r@%h:%p<br />
ControlPersist 15m<br />
<br />
Enter your password and leave that session open until you are finished.<br />
All ssh sessions (including scp and svn+ssh) will now be tunneled through this connection.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Pushing to the wrong repository ===<br />
<br />
If you find yourself accidentally having pushed a package to the wrong repository (e.g. running {{ic|communitypkg}} instead of {{ic|extrapkg}} against {{ic|example-1.0.0-any.pkg.tar.zst}}) you can undo it.<br />
<br />
{{Note|This only applies to cases where the [[#Update the Repository|repository update]] has not been done yet. If the repository has been updated already, refer to [[#Moving a package between repos|moving a package between repos]].}}<br />
<br />
Remove the package from the staging location on the repositories server:<br />
<br />
$ ssh repos.archlinux.org "rm staging/community/example-1.0.0-any.pkg.tar.zst*"<br />
<br />
Afterwards, proceed again with [[#Use devtools to sign, upload and commit|signing, uploading and committing]].</div>Jellyhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:How_to_be_a_packager&diff=778707DeveloperWiki:How to be a packager2023-05-19T20:22:54Z<p>Jelly: /* Miscellaneous stuff */ remove unrequired -M for the first time</p>
<hr />
<div>[[Category:DeveloperWiki]]<br />
== Follow package guidelines ==<br />
<br />
Package guidelines can be found in the Arch Linux documentation, follow them closely.<br />
<br />
[[Arch packaging standards]]<br />
<br />
== Preparation and setup ==<br />
<br />
=== Installing the packages ===<br />
<br />
Make sure you have the packages {{ic|devtools}} and {{ic|namcap}} installed.<br />
<br />
=== SSH configuration ===<br />
<br />
If you have multiple SSH keys in your SSH Agent, you will need to make sure that the correct key is being used to contact the Arch servers.<br />
Also, when your local username differs from the one being used on the Arch servers, you need to take care of that too.<br />
<br />
Example {{ic|~/.ssh/config}} excerpt:<br />
<br />
{{bc|<br />
host repos.archlinux.org<br />
hostname repos.archlinux.org<br />
port 22<br />
user foobar<br />
IdentityFile ~/.ssh/id_arch<br />
IdentitiesOnly yes<br />
}}<br />
<br />
Also make sure to [https://gitlab.archlinux.org/-/profile/keys set your ssh key] in Gitlab: <br />
<br />
{{bc|<br />
host gitlab.archlinux.org<br />
hostname gitlab.archlinux.org<br />
user foobar<br />
IdentityFile ~/.ssh/id_arch<br />
IdentitiesOnly yes<br />
}}<br />
<br />
=== makepkg configuration ===<br />
<br />
Make sure to configure your {{ic|~/.makepkg.conf}} with the correct {{ic|PACKAGER}} and {{ic|GPGKEY}} variables.<br />
Wrong signatures or missing {{ic|PACKAGER}} will prevent your packages from entering the repository.<br />
<br />
{{bc|1=<br />
PACKAGER="Foo Bar <foo.bar@archlinux.org>"<br />
GPGKEY="0x0123456789abcdef"<br />
}}<br />
<br />
=== Helper scripts (optional) ===<br />
<br />
The packaged helper scripts below can be installed from the {{Grp|archlinux-tools}} group. <br />
<br />
* {{pkg|arch-rebuild-order}} — List the rebuild order of packages using the local pacman syncdb's.<br />
* {{pkg|arch-signoff}} — Signoff packages from [testing] interactively in your terminal.<br />
* {{pkg|arch-repro-status}} — List the reproducible status of your packages interactively in your terminal with the ability to see the build logs and diffoscope output per un-reproducible package.<br />
* {{pkg|archlinux-contrib}} — Collection of contrib scripts used in Arch Linux.<br />
<br />
==== ch ====<br />
<br />
This shell script eases setting up and maintaining the chroots for building the packages immensely.<br />
The script has been developed by [https://archlinux.org/people/developers/#bluewind Bluewind] and can be found here: [https://git.server-speed.net/users/flo/bin/plain/ch ch].<br />
<br />
As this script relies on [[Btrfs]], you have to create a Btrfs volume (20GiB is mostly sufficient), which can either be a file, a logical volume or a dedicated partition.<br />
Furthermore by default this script assumes that the Btrfs for the chroots is mounted at {{ic|/mnt/chroots/arch}}.<br />
<br />
Afterwards you can create a 64bit package using:<br />
<br />
$ ch build 64<br />
<br />
(automatically and conveniently invokes makechrootpkg with all required arguments)<br />
<br />
For further details please take a look at the head of the script, it provides some explanations and usage examples.<br />
<br />
== The workflow ==<br />
<br />
=== Checkout/update a local package repository ===<br />
<br />
$ pkgctl repo clone packagename<br />
$ # update an existing specific package<br />
$ cd packagename<br />
$ git pull<br />
<br />
=== Adding a new package ===<br />
<br />
This step is only required when adding a new package to the repository for the first time.<br />
<br />
$ pkgctl repo create --clone new-package<br />
$ cd new-package<br />
$ cp /usr/share/pacman/PKGBUILD.proto PKGBUILD<br />
$ $EDITOR PKGBUILD<br />
$ git add .<br />
$ git commit<br />
<br />
{{Warning|dbscripts does not support packages with a different split package architecture.}}<br />
<br />
=== Change and build ===<br />
<br />
It is '''mandatory''' to build your package using a clean [[DeveloperWiki:Building in a clean chroot|chroot]].<br />
{{ic|pkgctl build}} does this automatically. <br />
<br />
$ cd some-package<br />
$ $EDITOR PKGBUILD<br />
$ pkgctl build<br />
<br />
Or, if you are using the [[#ch|ch]] helper, simply do:<br />
<br />
$ cd some-package/trunk/<br />
$ $EDITOR PKGBUILD<br />
$ ch clean 64<br />
$ ch update 64<br />
$ ch build 64<br />
<br />
=== Run namcap on both PKGBUILD and package ===<br />
<br />
{{Note|This is automatically done, when using the devtools build scripts.}}<br />
<br />
$ namcap PKGBUILD<br />
$ namcap some-package-1.0-1-x86_64.pkg.tar.xz<br />
<br />
=== Run checkpkg on the package ===<br />
<br />
Run in the directory with your freshly built package to get a file list diff compared with the package version currently in the repositories.<br />
<br />
$ checkpkg<br />
<br />
{{Note|This can be skipped when adding a new package to the repository for the first time (e.g. by importing it from [[AUR]] to [[Official repositories#extra|extra]]).}}<br />
<br />
=== Run sogrep on identified soname change ===<br />
<br />
If [[#Run checkpkg on the Package|checkpkg]] identified a shared object name (aka. soname) change in {{ic|package}}'s library {{ic|package.so}}, it is '''required''' to rebuild packages directly depending on it.<br />
<br />
To identify which packages rely on a given library in {{ic|package}} in a repository (e.g. {{ic|extra}}, use sogrep (see {{man|1|sogrep}}).<br />
<br />
$ sogrep <repository> package.so<br />
<br />
Build {{ic|package}} for its respective [[Official repositories#Staging repositories|staging]] environment (by following the remaining steps in [[#The Workflow|The Workflow]]) and create a [https://archlinux.org/todo/ TODO] with the identified dependants, so their maintainers can rebuild them against the new version of {{ic|package}}.<br />
<br />
{{Note|First sync with [https://archlinux.org/people/trusted-users/ trusted users] and/ or [https://archlinux.org/people/developers/ developers], if any packages currently in the [[Official repositories#Staging repositories|staging]] environment block the rebuilds against {{ic|package}}.}}<br />
<br />
=== Use devtools to sign, upload and commit ===<br />
<br />
Once you are satisfied with the package, you need to make sure all your changes are tracked in the repository.<br />
Run:<br />
<br />
$ git status<br />
<br />
in the {{ic|some-package}} directory and check the output carefully.<br />
If, for example, you have added a new {{ic|some-package.install}} file, you need to tell git to track that file, e.g.:<br />
<br />
$ git add some-package.install<br />
<br />
Make sure to '''never''' add the binary packages, makepkg logs, etc. to the repository!<br />
<br />
When you are ready to proceed, you can run the devtools scripts to sign, upload and commit your work:<br />
<br />
$ pkgctl release --message "update to 1.2.3, add post_upgrade hook to fix permissions"<br />
<br />
Please try to write concise commit messages.<br />
If the package is simply an upstream change, that is fine, but if anything more complex changes, please inform us by writing an appropriate commit message.<br />
<br />
This will upload the package and its signature to their repository specific location in your user's {{ic|~/staging}} directory on {{ic|repos.archlinux.org}} aswell as creating a signed tag for the version on the packages git repository.<br />
<br />
=== Update the repository ===<br />
<br />
Using {{ic|db-update}} will find new packages for a set of repositories, depending on which is being called.<br />
<br />
To release uploaded packages to [[core]], [[extra]], [[gnome-unstable]], [[kde-unstable]], [[Official repositories#Staging repositories|staging]], or [[Official repositories#testing|testing]] use:<br />
<br />
$ ssh repos.archlinux.org "/packages/db-update"<br />
<br />
To release uploaded packages to [[Official repositories#community|community]], [[Official repositories#Staging repositories|community-staging]], [[Official repositories#community-testing|community-testing]], [[multilib]], [[Official repositories#Staging repositories|multilib-staging]], or [[Official repositories#multilib-testing|multilib-testing]] use:<br />
<br />
$ ssh repos.archlinux.org "/community/db-update"<br />
<br />
== Other operations ==<br />
<br />
=== Removing a package ===<br />
<br />
Using {{ic|db-remove}} will remove a package from a specific binary repository.<br />
<br />
To remove a package from [[core]], [[extra]], [[gnome-unstable]], [[kde-unstable]], [[Official repositories#Staging repositories|staging]], or [[Official repositories#testing|testing]] use:<br />
<br />
$ ssh repos.archlinux.org "/packages/db-remove <repo> <arch> <package_name>"<br />
<br />
e.g.<br />
<br />
$ ssh repos.archlinux.org "/packages/db-remove core x86_64 openssh"<br />
<br />
To remove a package from [[Official repositories#community|community]], [[Official repositories#Staging repositories|community-staging]], [[Official repositories#community-testing|community-testing]], [[multilib]], [[Official repositories#Staging repositories|multilib-staging]], or [[Official repositories#multilib-testing|multilib-testing]] use:<br />
<br />
$ ssh repos.archlinux.org "/community/db-remove <repo> <arch> <package_name>"<br />
<br />
e.g.<br />
<br />
$ ssh repos.archlinux.org "/community/db-remove community x86_64 jack2"<br />
<br />
If removing the package from the repositories altogether, it is encouraged to remove the entire package directory from version control as well. Just go to the GitLab page with {{ic|pkgctl repo browse}} and remove it.<br />
<br />
=== Moving a package between repositories ===<br />
<br />
Using {{ic|db-move}} will move a package between two binary repositories.<br />
<br />
To move packages of the same {{ic|pkgbase}} between [[core]], [[extra]], [[gnome-unstable]], [[kde-unstable]], [[Official repositories#Staging repositories|staging]], or [[Official repositories#core-testing|core-testing]] use:<br />
<br />
$ pkgctl db move [SOURCE_REPO] [TARGET_REPO] [PKGBASE]...<br />
<br />
Under the hood it calls: <br />
<br />
$ ssh repos.archlinux.org "/packages/db-move <from_repo> <to_repo> [packages]"<br />
<br />
e.g. to move packages of the {{ic|pkgbases}} {{ic|foo}} and {{ic|bar}} from [[testing]] to [[core]]:<br />
<br />
$ pkgctl db move testing core foo bar"<br />
<br />
E.g. to move a a package from [[Official repositories#community|community]] to [[extra]], use:<br />
<br />
$ community2extra <package_name><br />
<br />
Alternatively, the move from testing is so common, that there are helper scripts:<br />
<br />
$ /packages/testing2x openssh bzip2 coreutils<br />
<br />
$ /packages/testing2x64 openssh bzip2 coreutils<br />
<br />
These scripts only work if the packages on the commandline are either in ''core'' or ''extra''.<br />
<br />
If a package is only in testing, you have to use ''testing2core'', ''testing2core64'', ''testing2extra'' or ''testing2extra64''.<br />
<br />
=== Tagging releases ===<br />
<br />
Fetch the package dir using {{ic|pkgctl repo clone}}, then:<br />
<br />
$ cd package-name<br />
$ pkgctl release<br />
<br />
This makes an svn copy of the trunk entries in a directory named {{ic|extra-x86_64}} indicating that this package is in the extra repository for the ''x86_64'' architecture.<br />
This will be done automatically when using tools such as {{ic|extrapkg}} (see [[#Use devtools to sign, upload and commit|Use devtools to sign, upload and commit]]).<br />
<br />
== Miscellaneous stuff ==<br />
<br />
=== Avoid having to enter your password all the time ===<br />
<br />
When working with {{ic|extrapkg}} and the other devtools, quite a few ssh connections are established, even when using ssh keys and the ssh agent.<br />
You can work around that.<br />
<br />
Add this to your {{ic|~/.ssh/config}}:<br />
<br />
Host gitlab.archlinux.org<br />
ControlMaster auto<br />
ControlPath /run/user/%i/ssh-%r@%h:%p<br />
ControlPersist 15m<br />
<br />
Enter your password and leave that session open until you are finished.<br />
All ssh sessions (including scp and svn+ssh) will now be tunneled through this connection.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Pushing to the wrong repository ===<br />
<br />
If you find yourself accidentally having pushed a package to the wrong repository (e.g. running {{ic|communitypkg}} instead of {{ic|extrapkg}} against {{ic|example-1.0.0-any.pkg.tar.zst}}) you can undo it.<br />
<br />
{{Note|This only applies to cases where the [[#Update the Repository|repository update]] has not been done yet. If the repository has been updated already, refer to [[#Moving a package between repos|moving a package between repos]].}}<br />
<br />
Remove the package from the staging location on the repositories server:<br />
<br />
$ ssh repos.archlinux.org "rm staging/community/example-1.0.0-any.pkg.tar.zst*"<br />
<br />
Afterwards, proceed again with [[#Use devtools to sign, upload and commit|signing, uploading and committing]].</div>Jellyhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:How_to_be_a_packager&diff=778705DeveloperWiki:How to be a packager2023-05-19T20:22:12Z<p>Jelly: /* Avoid having to enter your password all the time */ fix ssh config layout</p>
<hr />
<div>[[Category:DeveloperWiki]]<br />
== Follow package guidelines ==<br />
<br />
Package guidelines can be found in the Arch Linux documentation, follow them closely.<br />
<br />
[[Arch packaging standards]]<br />
<br />
== Preparation and setup ==<br />
<br />
=== Installing the packages ===<br />
<br />
Make sure you have the packages {{ic|devtools}} and {{ic|namcap}} installed.<br />
<br />
=== SSH configuration ===<br />
<br />
If you have multiple SSH keys in your SSH Agent, you will need to make sure that the correct key is being used to contact the Arch servers.<br />
Also, when your local username differs from the one being used on the Arch servers, you need to take care of that too.<br />
<br />
Example {{ic|~/.ssh/config}} excerpt:<br />
<br />
{{bc|<br />
host repos.archlinux.org<br />
hostname repos.archlinux.org<br />
port 22<br />
user foobar<br />
IdentityFile ~/.ssh/id_arch<br />
IdentitiesOnly yes<br />
}}<br />
<br />
Also make sure to [https://gitlab.archlinux.org/-/profile/keys set your ssh key] in Gitlab: <br />
<br />
{{bc|<br />
host gitlab.archlinux.org<br />
hostname gitlab.archlinux.org<br />
user foobar<br />
IdentityFile ~/.ssh/id_arch<br />
IdentitiesOnly yes<br />
}}<br />
<br />
=== makepkg configuration ===<br />
<br />
Make sure to configure your {{ic|~/.makepkg.conf}} with the correct {{ic|PACKAGER}} and {{ic|GPGKEY}} variables.<br />
Wrong signatures or missing {{ic|PACKAGER}} will prevent your packages from entering the repository.<br />
<br />
{{bc|1=<br />
PACKAGER="Foo Bar <foo.bar@archlinux.org>"<br />
GPGKEY="0x0123456789abcdef"<br />
}}<br />
<br />
=== Helper scripts (optional) ===<br />
<br />
The packaged helper scripts below can be installed from the {{Grp|archlinux-tools}} group. <br />
<br />
* {{pkg|arch-rebuild-order}} — List the rebuild order of packages using the local pacman syncdb's.<br />
* {{pkg|arch-signoff}} — Signoff packages from [testing] interactively in your terminal.<br />
* {{pkg|arch-repro-status}} — List the reproducible status of your packages interactively in your terminal with the ability to see the build logs and diffoscope output per un-reproducible package.<br />
* {{pkg|archlinux-contrib}} — Collection of contrib scripts used in Arch Linux.<br />
<br />
==== ch ====<br />
<br />
This shell script eases setting up and maintaining the chroots for building the packages immensely.<br />
The script has been developed by [https://archlinux.org/people/developers/#bluewind Bluewind] and can be found here: [https://git.server-speed.net/users/flo/bin/plain/ch ch].<br />
<br />
As this script relies on [[Btrfs]], you have to create a Btrfs volume (20GiB is mostly sufficient), which can either be a file, a logical volume or a dedicated partition.<br />
Furthermore by default this script assumes that the Btrfs for the chroots is mounted at {{ic|/mnt/chroots/arch}}.<br />
<br />
Afterwards you can create a 64bit package using:<br />
<br />
$ ch build 64<br />
<br />
(automatically and conveniently invokes makechrootpkg with all required arguments)<br />
<br />
For further details please take a look at the head of the script, it provides some explanations and usage examples.<br />
<br />
== The workflow ==<br />
<br />
=== Checkout/update a local package repository ===<br />
<br />
$ pkgctl repo clone packagename<br />
$ # update an existing specific package<br />
$ cd packagename<br />
$ git pull<br />
<br />
=== Adding a new package ===<br />
<br />
This step is only required when adding a new package to the repository for the first time.<br />
<br />
$ pkgctl repo create --clone new-package<br />
$ cd new-package<br />
$ cp /usr/share/pacman/PKGBUILD.proto PKGBUILD<br />
$ $EDITOR PKGBUILD<br />
$ git add .<br />
$ git commit<br />
<br />
{{Warning|dbscripts does not support packages with a different split package architecture.}}<br />
<br />
=== Change and build ===<br />
<br />
It is '''mandatory''' to build your package using a clean [[DeveloperWiki:Building in a clean chroot|chroot]].<br />
{{ic|pkgctl build}} does this automatically. <br />
<br />
$ cd some-package<br />
$ $EDITOR PKGBUILD<br />
$ pkgctl build<br />
<br />
Or, if you are using the [[#ch|ch]] helper, simply do:<br />
<br />
$ cd some-package/trunk/<br />
$ $EDITOR PKGBUILD<br />
$ ch clean 64<br />
$ ch update 64<br />
$ ch build 64<br />
<br />
=== Run namcap on both PKGBUILD and package ===<br />
<br />
{{Note|This is automatically done, when using the devtools build scripts.}}<br />
<br />
$ namcap PKGBUILD<br />
$ namcap some-package-1.0-1-x86_64.pkg.tar.xz<br />
<br />
=== Run checkpkg on the package ===<br />
<br />
Run in the directory with your freshly built package to get a file list diff compared with the package version currently in the repositories.<br />
<br />
$ checkpkg<br />
<br />
{{Note|This can be skipped when adding a new package to the repository for the first time (e.g. by importing it from [[AUR]] to [[Official repositories#extra|extra]]).}}<br />
<br />
=== Run sogrep on identified soname change ===<br />
<br />
If [[#Run checkpkg on the Package|checkpkg]] identified a shared object name (aka. soname) change in {{ic|package}}'s library {{ic|package.so}}, it is '''required''' to rebuild packages directly depending on it.<br />
<br />
To identify which packages rely on a given library in {{ic|package}} in a repository (e.g. {{ic|extra}}, use sogrep (see {{man|1|sogrep}}).<br />
<br />
$ sogrep <repository> package.so<br />
<br />
Build {{ic|package}} for its respective [[Official repositories#Staging repositories|staging]] environment (by following the remaining steps in [[#The Workflow|The Workflow]]) and create a [https://archlinux.org/todo/ TODO] with the identified dependants, so their maintainers can rebuild them against the new version of {{ic|package}}.<br />
<br />
{{Note|First sync with [https://archlinux.org/people/trusted-users/ trusted users] and/ or [https://archlinux.org/people/developers/ developers], if any packages currently in the [[Official repositories#Staging repositories|staging]] environment block the rebuilds against {{ic|package}}.}}<br />
<br />
=== Use devtools to sign, upload and commit ===<br />
<br />
Once you are satisfied with the package, you need to make sure all your changes are tracked in the repository.<br />
Run:<br />
<br />
$ git status<br />
<br />
in the {{ic|some-package}} directory and check the output carefully.<br />
If, for example, you have added a new {{ic|some-package.install}} file, you need to tell git to track that file, e.g.:<br />
<br />
$ git add some-package.install<br />
<br />
Make sure to '''never''' add the binary packages, makepkg logs, etc. to the repository!<br />
<br />
When you are ready to proceed, you can run the devtools scripts to sign, upload and commit your work:<br />
<br />
$ pkgctl release --message "update to 1.2.3, add post_upgrade hook to fix permissions"<br />
<br />
Please try to write concise commit messages.<br />
If the package is simply an upstream change, that is fine, but if anything more complex changes, please inform us by writing an appropriate commit message.<br />
<br />
This will upload the package and its signature to their repository specific location in your user's {{ic|~/staging}} directory on {{ic|repos.archlinux.org}} aswell as creating a signed tag for the version on the packages git repository.<br />
<br />
=== Update the repository ===<br />
<br />
Using {{ic|db-update}} will find new packages for a set of repositories, depending on which is being called.<br />
<br />
To release uploaded packages to [[core]], [[extra]], [[gnome-unstable]], [[kde-unstable]], [[Official repositories#Staging repositories|staging]], or [[Official repositories#testing|testing]] use:<br />
<br />
$ ssh repos.archlinux.org "/packages/db-update"<br />
<br />
To release uploaded packages to [[Official repositories#community|community]], [[Official repositories#Staging repositories|community-staging]], [[Official repositories#community-testing|community-testing]], [[multilib]], [[Official repositories#Staging repositories|multilib-staging]], or [[Official repositories#multilib-testing|multilib-testing]] use:<br />
<br />
$ ssh repos.archlinux.org "/community/db-update"<br />
<br />
== Other operations ==<br />
<br />
=== Removing a package ===<br />
<br />
Using {{ic|db-remove}} will remove a package from a specific binary repository.<br />
<br />
To remove a package from [[core]], [[extra]], [[gnome-unstable]], [[kde-unstable]], [[Official repositories#Staging repositories|staging]], or [[Official repositories#testing|testing]] use:<br />
<br />
$ ssh repos.archlinux.org "/packages/db-remove <repo> <arch> <package_name>"<br />
<br />
e.g.<br />
<br />
$ ssh repos.archlinux.org "/packages/db-remove core x86_64 openssh"<br />
<br />
To remove a package from [[Official repositories#community|community]], [[Official repositories#Staging repositories|community-staging]], [[Official repositories#community-testing|community-testing]], [[multilib]], [[Official repositories#Staging repositories|multilib-staging]], or [[Official repositories#multilib-testing|multilib-testing]] use:<br />
<br />
$ ssh repos.archlinux.org "/community/db-remove <repo> <arch> <package_name>"<br />
<br />
e.g.<br />
<br />
$ ssh repos.archlinux.org "/community/db-remove community x86_64 jack2"<br />
<br />
If removing the package from the repositories altogether, it is encouraged to remove the entire package directory from version control as well. Just go to the GitLab page with {{ic|pkgctl repo browse}} and remove it.<br />
<br />
=== Moving a package between repositories ===<br />
<br />
Using {{ic|db-move}} will move a package between two binary repositories.<br />
<br />
To move packages of the same {{ic|pkgbase}} between [[core]], [[extra]], [[gnome-unstable]], [[kde-unstable]], [[Official repositories#Staging repositories|staging]], or [[Official repositories#core-testing|core-testing]] use:<br />
<br />
$ pkgctl db move [SOURCE_REPO] [TARGET_REPO] [PKGBASE]...<br />
<br />
Under the hood it calls: <br />
<br />
$ ssh repos.archlinux.org "/packages/db-move <from_repo> <to_repo> [packages]"<br />
<br />
e.g. to move packages of the {{ic|pkgbases}} {{ic|foo}} and {{ic|bar}} from [[testing]] to [[core]]:<br />
<br />
$ pkgctl db move testing core foo bar"<br />
<br />
E.g. to move a a package from [[Official repositories#community|community]] to [[extra]], use:<br />
<br />
$ community2extra <package_name><br />
<br />
Alternatively, the move from testing is so common, that there are helper scripts:<br />
<br />
$ /packages/testing2x openssh bzip2 coreutils<br />
<br />
$ /packages/testing2x64 openssh bzip2 coreutils<br />
<br />
These scripts only work if the packages on the commandline are either in ''core'' or ''extra''.<br />
<br />
If a package is only in testing, you have to use ''testing2core'', ''testing2core64'', ''testing2extra'' or ''testing2extra64''.<br />
<br />
=== Tagging releases ===<br />
<br />
Fetch the package dir using {{ic|pkgctl repo clone}}, then:<br />
<br />
$ cd package-name<br />
$ pkgctl release<br />
<br />
This makes an svn copy of the trunk entries in a directory named {{ic|extra-x86_64}} indicating that this package is in the extra repository for the ''x86_64'' architecture.<br />
This will be done automatically when using tools such as {{ic|extrapkg}} (see [[#Use devtools to sign, upload and commit|Use devtools to sign, upload and commit]]).<br />
<br />
== Miscellaneous stuff ==<br />
<br />
=== Avoid having to enter your password all the time ===<br />
<br />
When working with {{ic|extrapkg}} and the other devtools, quite a few ssh connections are established, even when using ssh keys and the ssh agent.<br />
You can work around that.<br />
<br />
Add this to your {{ic|~/.ssh/config}}:<br />
<br />
Host gitlab.archlinux.org<br />
ControlMaster auto<br />
ControlPath /run/user/%i/ssh-%r@%h:%p<br />
ControlPersist 15m<br />
<br />
<br />
Now, before you start working, open a ssh session with<br />
<br />
$ ssh -M repos.archlinux.org<br />
<br />
Enter your password and leave that session open until you are finished.<br />
All ssh sessions (including scp and svn+ssh) will now be tunneled through this connection.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Pushing to the wrong repository ===<br />
<br />
If you find yourself accidentally having pushed a package to the wrong repository (e.g. running {{ic|communitypkg}} instead of {{ic|extrapkg}} against {{ic|example-1.0.0-any.pkg.tar.zst}}) you can undo it.<br />
<br />
{{Note|This only applies to cases where the [[#Update the Repository|repository update]] has not been done yet. If the repository has been updated already, refer to [[#Moving a package between repos|moving a package between repos]].}}<br />
<br />
Remove the package from the staging location on the repositories server:<br />
<br />
$ ssh repos.archlinux.org "rm staging/community/example-1.0.0-any.pkg.tar.zst*"<br />
<br />
Afterwards, proceed again with [[#Use devtools to sign, upload and commit|signing, uploading and committing]].</div>Jellyhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:How_to_be_a_packager&diff=778704DeveloperWiki:How to be a packager2023-05-19T20:21:32Z<p>Jelly: /* Miscellaneous stuff */ fix the control path magic</p>
<hr />
<div>[[Category:DeveloperWiki]]<br />
== Follow package guidelines ==<br />
<br />
Package guidelines can be found in the Arch Linux documentation, follow them closely.<br />
<br />
[[Arch packaging standards]]<br />
<br />
== Preparation and setup ==<br />
<br />
=== Installing the packages ===<br />
<br />
Make sure you have the packages {{ic|devtools}} and {{ic|namcap}} installed.<br />
<br />
=== SSH configuration ===<br />
<br />
If you have multiple SSH keys in your SSH Agent, you will need to make sure that the correct key is being used to contact the Arch servers.<br />
Also, when your local username differs from the one being used on the Arch servers, you need to take care of that too.<br />
<br />
Example {{ic|~/.ssh/config}} excerpt:<br />
<br />
{{bc|<br />
host repos.archlinux.org<br />
hostname repos.archlinux.org<br />
port 22<br />
user foobar<br />
IdentityFile ~/.ssh/id_arch<br />
IdentitiesOnly yes<br />
}}<br />
<br />
Also make sure to [https://gitlab.archlinux.org/-/profile/keys set your ssh key] in Gitlab: <br />
<br />
{{bc|<br />
host gitlab.archlinux.org<br />
hostname gitlab.archlinux.org<br />
user foobar<br />
IdentityFile ~/.ssh/id_arch<br />
IdentitiesOnly yes<br />
}}<br />
<br />
=== makepkg configuration ===<br />
<br />
Make sure to configure your {{ic|~/.makepkg.conf}} with the correct {{ic|PACKAGER}} and {{ic|GPGKEY}} variables.<br />
Wrong signatures or missing {{ic|PACKAGER}} will prevent your packages from entering the repository.<br />
<br />
{{bc|1=<br />
PACKAGER="Foo Bar <foo.bar@archlinux.org>"<br />
GPGKEY="0x0123456789abcdef"<br />
}}<br />
<br />
=== Helper scripts (optional) ===<br />
<br />
The packaged helper scripts below can be installed from the {{Grp|archlinux-tools}} group. <br />
<br />
* {{pkg|arch-rebuild-order}} — List the rebuild order of packages using the local pacman syncdb's.<br />
* {{pkg|arch-signoff}} — Signoff packages from [testing] interactively in your terminal.<br />
* {{pkg|arch-repro-status}} — List the reproducible status of your packages interactively in your terminal with the ability to see the build logs and diffoscope output per un-reproducible package.<br />
* {{pkg|archlinux-contrib}} — Collection of contrib scripts used in Arch Linux.<br />
<br />
==== ch ====<br />
<br />
This shell script eases setting up and maintaining the chroots for building the packages immensely.<br />
The script has been developed by [https://archlinux.org/people/developers/#bluewind Bluewind] and can be found here: [https://git.server-speed.net/users/flo/bin/plain/ch ch].<br />
<br />
As this script relies on [[Btrfs]], you have to create a Btrfs volume (20GiB is mostly sufficient), which can either be a file, a logical volume or a dedicated partition.<br />
Furthermore by default this script assumes that the Btrfs for the chroots is mounted at {{ic|/mnt/chroots/arch}}.<br />
<br />
Afterwards you can create a 64bit package using:<br />
<br />
$ ch build 64<br />
<br />
(automatically and conveniently invokes makechrootpkg with all required arguments)<br />
<br />
For further details please take a look at the head of the script, it provides some explanations and usage examples.<br />
<br />
== The workflow ==<br />
<br />
=== Checkout/update a local package repository ===<br />
<br />
$ pkgctl repo clone packagename<br />
$ # update an existing specific package<br />
$ cd packagename<br />
$ git pull<br />
<br />
=== Adding a new package ===<br />
<br />
This step is only required when adding a new package to the repository for the first time.<br />
<br />
$ pkgctl repo create --clone new-package<br />
$ cd new-package<br />
$ cp /usr/share/pacman/PKGBUILD.proto PKGBUILD<br />
$ $EDITOR PKGBUILD<br />
$ git add .<br />
$ git commit<br />
<br />
{{Warning|dbscripts does not support packages with a different split package architecture.}}<br />
<br />
=== Change and build ===<br />
<br />
It is '''mandatory''' to build your package using a clean [[DeveloperWiki:Building in a clean chroot|chroot]].<br />
{{ic|pkgctl build}} does this automatically. <br />
<br />
$ cd some-package<br />
$ $EDITOR PKGBUILD<br />
$ pkgctl build<br />
<br />
Or, if you are using the [[#ch|ch]] helper, simply do:<br />
<br />
$ cd some-package/trunk/<br />
$ $EDITOR PKGBUILD<br />
$ ch clean 64<br />
$ ch update 64<br />
$ ch build 64<br />
<br />
=== Run namcap on both PKGBUILD and package ===<br />
<br />
{{Note|This is automatically done, when using the devtools build scripts.}}<br />
<br />
$ namcap PKGBUILD<br />
$ namcap some-package-1.0-1-x86_64.pkg.tar.xz<br />
<br />
=== Run checkpkg on the package ===<br />
<br />
Run in the directory with your freshly built package to get a file list diff compared with the package version currently in the repositories.<br />
<br />
$ checkpkg<br />
<br />
{{Note|This can be skipped when adding a new package to the repository for the first time (e.g. by importing it from [[AUR]] to [[Official repositories#extra|extra]]).}}<br />
<br />
=== Run sogrep on identified soname change ===<br />
<br />
If [[#Run checkpkg on the Package|checkpkg]] identified a shared object name (aka. soname) change in {{ic|package}}'s library {{ic|package.so}}, it is '''required''' to rebuild packages directly depending on it.<br />
<br />
To identify which packages rely on a given library in {{ic|package}} in a repository (e.g. {{ic|extra}}, use sogrep (see {{man|1|sogrep}}).<br />
<br />
$ sogrep <repository> package.so<br />
<br />
Build {{ic|package}} for its respective [[Official repositories#Staging repositories|staging]] environment (by following the remaining steps in [[#The Workflow|The Workflow]]) and create a [https://archlinux.org/todo/ TODO] with the identified dependants, so their maintainers can rebuild them against the new version of {{ic|package}}.<br />
<br />
{{Note|First sync with [https://archlinux.org/people/trusted-users/ trusted users] and/ or [https://archlinux.org/people/developers/ developers], if any packages currently in the [[Official repositories#Staging repositories|staging]] environment block the rebuilds against {{ic|package}}.}}<br />
<br />
=== Use devtools to sign, upload and commit ===<br />
<br />
Once you are satisfied with the package, you need to make sure all your changes are tracked in the repository.<br />
Run:<br />
<br />
$ git status<br />
<br />
in the {{ic|some-package}} directory and check the output carefully.<br />
If, for example, you have added a new {{ic|some-package.install}} file, you need to tell git to track that file, e.g.:<br />
<br />
$ git add some-package.install<br />
<br />
Make sure to '''never''' add the binary packages, makepkg logs, etc. to the repository!<br />
<br />
When you are ready to proceed, you can run the devtools scripts to sign, upload and commit your work:<br />
<br />
$ pkgctl release --message "update to 1.2.3, add post_upgrade hook to fix permissions"<br />
<br />
Please try to write concise commit messages.<br />
If the package is simply an upstream change, that is fine, but if anything more complex changes, please inform us by writing an appropriate commit message.<br />
<br />
This will upload the package and its signature to their repository specific location in your user's {{ic|~/staging}} directory on {{ic|repos.archlinux.org}} aswell as creating a signed tag for the version on the packages git repository.<br />
<br />
=== Update the repository ===<br />
<br />
Using {{ic|db-update}} will find new packages for a set of repositories, depending on which is being called.<br />
<br />
To release uploaded packages to [[core]], [[extra]], [[gnome-unstable]], [[kde-unstable]], [[Official repositories#Staging repositories|staging]], or [[Official repositories#testing|testing]] use:<br />
<br />
$ ssh repos.archlinux.org "/packages/db-update"<br />
<br />
To release uploaded packages to [[Official repositories#community|community]], [[Official repositories#Staging repositories|community-staging]], [[Official repositories#community-testing|community-testing]], [[multilib]], [[Official repositories#Staging repositories|multilib-staging]], or [[Official repositories#multilib-testing|multilib-testing]] use:<br />
<br />
$ ssh repos.archlinux.org "/community/db-update"<br />
<br />
== Other operations ==<br />
<br />
=== Removing a package ===<br />
<br />
Using {{ic|db-remove}} will remove a package from a specific binary repository.<br />
<br />
To remove a package from [[core]], [[extra]], [[gnome-unstable]], [[kde-unstable]], [[Official repositories#Staging repositories|staging]], or [[Official repositories#testing|testing]] use:<br />
<br />
$ ssh repos.archlinux.org "/packages/db-remove <repo> <arch> <package_name>"<br />
<br />
e.g.<br />
<br />
$ ssh repos.archlinux.org "/packages/db-remove core x86_64 openssh"<br />
<br />
To remove a package from [[Official repositories#community|community]], [[Official repositories#Staging repositories|community-staging]], [[Official repositories#community-testing|community-testing]], [[multilib]], [[Official repositories#Staging repositories|multilib-staging]], or [[Official repositories#multilib-testing|multilib-testing]] use:<br />
<br />
$ ssh repos.archlinux.org "/community/db-remove <repo> <arch> <package_name>"<br />
<br />
e.g.<br />
<br />
$ ssh repos.archlinux.org "/community/db-remove community x86_64 jack2"<br />
<br />
If removing the package from the repositories altogether, it is encouraged to remove the entire package directory from version control as well. Just go to the GitLab page with {{ic|pkgctl repo browse}} and remove it.<br />
<br />
=== Moving a package between repositories ===<br />
<br />
Using {{ic|db-move}} will move a package between two binary repositories.<br />
<br />
To move packages of the same {{ic|pkgbase}} between [[core]], [[extra]], [[gnome-unstable]], [[kde-unstable]], [[Official repositories#Staging repositories|staging]], or [[Official repositories#core-testing|core-testing]] use:<br />
<br />
$ pkgctl db move [SOURCE_REPO] [TARGET_REPO] [PKGBASE]...<br />
<br />
Under the hood it calls: <br />
<br />
$ ssh repos.archlinux.org "/packages/db-move <from_repo> <to_repo> [packages]"<br />
<br />
e.g. to move packages of the {{ic|pkgbases}} {{ic|foo}} and {{ic|bar}} from [[testing]] to [[core]]:<br />
<br />
$ pkgctl db move testing core foo bar"<br />
<br />
E.g. to move a a package from [[Official repositories#community|community]] to [[extra]], use:<br />
<br />
$ community2extra <package_name><br />
<br />
Alternatively, the move from testing is so common, that there are helper scripts:<br />
<br />
$ /packages/testing2x openssh bzip2 coreutils<br />
<br />
$ /packages/testing2x64 openssh bzip2 coreutils<br />
<br />
These scripts only work if the packages on the commandline are either in ''core'' or ''extra''.<br />
<br />
If a package is only in testing, you have to use ''testing2core'', ''testing2core64'', ''testing2extra'' or ''testing2extra64''.<br />
<br />
=== Tagging releases ===<br />
<br />
Fetch the package dir using {{ic|pkgctl repo clone}}, then:<br />
<br />
$ cd package-name<br />
$ pkgctl release<br />
<br />
This makes an svn copy of the trunk entries in a directory named {{ic|extra-x86_64}} indicating that this package is in the extra repository for the ''x86_64'' architecture.<br />
This will be done automatically when using tools such as {{ic|extrapkg}} (see [[#Use devtools to sign, upload and commit|Use devtools to sign, upload and commit]]).<br />
<br />
== Miscellaneous stuff ==<br />
<br />
=== Avoid having to enter your password all the time ===<br />
<br />
When working with {{ic|extrapkg}} and the other devtools, quite a few ssh connections are established, even when using ssh keys and the ssh agent.<br />
You can work around that.<br />
<br />
Add this to your {{ic|~/.ssh/config}}:<br />
<br />
Host gitlab.archlinux.org<br />
ControlMaster auto<br />
ControlPath /run/user/%i/ssh-%r@%h:%p<br />
ControlPersist 15m<br />
<br />
<br />
Now, before you start working, open a ssh session with<br />
<br />
$ ssh -M repos.archlinux.org<br />
<br />
Enter your password and leave that session open until you are finished.<br />
All ssh sessions (including scp and svn+ssh) will now be tunneled through this connection.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Pushing to the wrong repository ===<br />
<br />
If you find yourself accidentally having pushed a package to the wrong repository (e.g. running {{ic|communitypkg}} instead of {{ic|extrapkg}} against {{ic|example-1.0.0-any.pkg.tar.zst}}) you can undo it.<br />
<br />
{{Note|This only applies to cases where the [[#Update the Repository|repository update]] has not been done yet. If the repository has been updated already, refer to [[#Moving a package between repos|moving a package between repos]].}}<br />
<br />
Remove the package from the staging location on the repositories server:<br />
<br />
$ ssh repos.archlinux.org "rm staging/community/example-1.0.0-any.pkg.tar.zst*"<br />
<br />
Afterwards, proceed again with [[#Use devtools to sign, upload and commit|signing, uploading and committing]].</div>Jellyhttps://wiki.archlinux.org/index.php?title=Backlight&diff=773330Backlight2023-03-20T13:44:09Z<p>Jelly: Add tip about acpi_backlight overrides</p>
<hr />
<div>[[Category:Laptops]]<br />
[[Category:Power management]]<br />
[[ja:バックライト]]<br />
[[ru:Backlight]]<br />
[[zh-hans:Backlight]]<br />
Screen brightness might be tricky to control. On some machines physical hardware switches are missing and software solutions may not work well. However, it is generally possible to find a functional method for a given hardware. This article aims to summarize all possible ways to adjust the backlight.<br />
<br />
There are many ways to control brightness of a monitor, laptop or integrated panel (such as the iMac). According to [https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/397617 these] [https://lore.kernel.org/patchwork/patch/528936/#708706 discussions] and this [https://wiki.ubuntu.com/Kernel/Debugging/Backlight wiki page] the control method can be divided into these categories:<br />
<br />
* brightness is controlled by vendor-specified hotkey and there is no interface for the OS to adjust the brightness.<br />
* brightness is controlled by either the [[#ACPI|ACPI]], graphic or platform driver. In this case, backlight control is exposed to the user through {{ic|/sys/class/backlight}} which can be used by user-space [[#Backlight utilities|backlight utilities]].<br />
* brightness is controlled by writing into a graphic card register through [[#setpci|setpci]].<br />
<br />
{{Note|Since OLED screens have no backlight, brightness cannot be controlled by changing backlight power on laptops equipped with an OLED screen. In this case, perceived screen brightness can be adjusted with a PWM control (not implemented in the Linux kernel) or via [[#Color correction|software color correction]].}}<br />
<br />
== Hardware interfaces ==<br />
<br />
=== ACPI ===<br />
<br />
The brightness of the screen backlight is adjusted by setting the power level of the backlight LEDs or cathodes. The power level can often be controlled using the ACPI kernel module for video. An interface to this module is provided via a {{man|5|sysfs}} directory at {{ic|/sys/class/backlight/}}.<br />
<br />
The name of the directory depends on the graphics card model.<br />
<br />
{{hc|$ ls /sys/class/backlight/|<br />
acpi_video0<br />
}}<br />
<br />
In this case, the backlight is managed by an ATI graphics card. In the case of an Intel card, the directory is called {{ic|intel_backlight}}. In the following examples, {{ic|acpi_video0}} is used. If you use an Intel card, simply replace {{ic|acpi_video0}} with {{ic|intel_backlight}} in the examples.<br />
<br />
The directory contains the following files and subdirectories:<br />
<br />
{{hc|$ ls /sys/class/backlight/acpi_video0/|<br />
actual_brightness brightness max_brightness subsystem/ uevent <br />
bl_power device/ power/ type<br />
}}<br />
<br />
The maximum brightness can be displayed by reading from {{ic|max_brightness}}, which is often 15.<br />
<br />
{{hc|$ cat /sys/class/backlight/acpi_video0/max_brightness|<br />
15<br />
}}<br />
<br />
The brightness can be set by writing a number to {{ic|brightness}}. Attempting to set a brightness greater than the maximum results in an error.<br />
<br />
# echo 5 > /sys/class/backlight/acpi_video0/brightness<br />
<br />
By default, only {{ic|root}} can change the brightness by this method. To allow users in the {{ic|video}} group to change the brightness, a [[udev]] rule such as the following can be used:<br />
<br />
{{hc|/etc/udev/rules.d/backlight.rules|2=<br />
ACTION=="add", SUBSYSTEM=="backlight", RUN+="/bin/chgrp video $sys$devpath/brightness", RUN+="/bin/chmod g+w $sys$devpath/brightness"<br />
}}<br />
<br />
{{Accuracy|Explain why it is not possible to alter file permissions with {{ic|1=GROUP="video", MODE="0664"}}.|section=Udev rules for permissions of brightness doesn't work}}<br />
<br />
==== Kernel command-line options ====<br />
<br />
Sometimes ACPI does not work well due to different motherboard implementations and ACPI quirks. This results in, for instance, inaccurate brightness notifications. This includes some laptops with dual graphics (e.g., Nvidia/Radeon dedicated GPU with Intel/AMD integrated GPU). Additionally, ACPI sometimes needs to register its own {{ic|acpi_video0}} backlight even if one already exists (such as {{ic|intel_backlight}}), which can be done by adding one of the following [[kernel parameters]]:<br />
<br />
acpi_backlight=video<br />
acpi_backlight=vendor<br />
acpi_backlight=native<br />
<br />
If you find that changing the {{ic|acpi_video0}} backlight does not actually change the brightness, you may need to use {{ic|1=acpi_backlight=native}}.<br />
<br />
{{Tip|<br />
* On Nvidia Optimus laptops, the kernel parameter {{ic|nomodeset}} can interfere with the ability to adjust the backlight.<br />
* On an Asus notebooks you might also need to load the {{ic|asus-nb-wmi}} [[kernel module]].<br />
* Disabling legacy boot on Dell XPS13 breaks backlight support.<br />
* Since Linux 6.1 the backlight subsystem was [https://hansdegoede.livejournal.com/26427.html revamped], if your backlight does not work after an update first try to remove an existing {{ic|acpi_backlight}} kernel parameter.<br />
}}<br />
<br />
==== Udev rule ====<br />
<br />
If the ACPI interface is available, the backlight level can be set at boot using a [[udev]] rule:<br />
<br />
{{hc|/etc/udev/rules.d/81-backlight.rules|2=<br />
# Set backlight level to 8<br />
SUBSYSTEM=="backlight", ACTION=="add", KERNEL=="acpi_video0", ATTR{brightness}="8"<br />
}}<br />
<br />
{{Note|The systemd-backlight service restores the previous backlight brightness level at boot. To prevent conflicts for the above rules, see [[#Save and restore functionality]].}}<br />
<br />
{{Tip|To set the backlight depending on power state, see [[Power management#Using a script and an udev rule]] and use your favourite [[#Backlight utilities|backlight utility]] in the script.}}<br />
<br />
=== setpci ===<br />
<br />
In some cases (e.g. Intel Mobile 945GME [https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/397617]), it is possible to set the register of the graphic card to adjust the backlight. It means you adjust the backlight by manipulating the hardware directly, which can be risky and generally is not a good idea. Not all of the graphic cards support this method.<br />
<br />
When using this method, you need to use {{ic|lspci}} first to find out where your graphic card is.<br />
<br />
# setpci -s 00:02.0 F4.B=0<br />
<br />
=== External monitors ===<br />
<br />
[[Wikipedia:Display_Data_Channel#DDC.2FCI|DDC/CI]] (Display Data Channel Command Interface) can be used to communicate with external monitors implementing MCCS (Monitor Control Command Set) over I2C. DDC can control brightness, contrast, inputs, etc on supported monitors. Settings available via the OSD (On-Screen Display) panel can usually also be managed via DDC. The [[kernel module]] {{ic|i2c-dev}} may need to be loaded if the {{ic|/dev/i2c-*}} devices do not exist.<br />
<br />
{{Pkg|ddcutil}} can be used to query and set brightness settings:<br />
<br />
{{hc|# ddcutil capabilities {{!}} grep "Feature: 10"|<br />
Feature: 10 (Brightness)<br />
}}<br />
<br />
{{hc|1=# ddcutil getvcp 10|2=<br />
VCP code 0x10 (Brightness ): current value = 60, max value = 100<br />
}}<br />
<br />
# ddcutil setvcp 10 70<br />
<br />
Alternatively, one may use {{AUR|ddcci-driver-linux-dkms}} to expose external monitors in sysfs. Then, after loading the {{ic|ddcci}} [[kernel module]], one can use any [[#Backlight utilities|backlight utility]].<br />
<br />
{{Note|<br />
* Using {{ic|ddcci}} and {{ic|i2c-dev}} simultaneously may result in resource conflicts such as a {{ic|Device or resource busy}} error.<br />
* Users of NVIDIA's proprietary drivers may need to add {{ic|1=Option "RegistryDwords" "RMUseSwI2c=0x01; RMI2cSpeed=100"}} to the {{ic|Device}} section in {{ic|/etc/X11/xorg.conf.d/20-nvidia.conf}} (generated by ''nvidia-xconfig'') or {{ic|1=options nvidia NVreg_RegistryDwords=RMUseSwI2c=0x01;RMI2cSpeed=100}} to {{ic|/etc/modprobe/conf.d/nvidia.conf}}. Confirm that the settings are correctly applied with {{ic|grep RegistryDwords /proc/driver/nvidia/params}} and check that the values are not empty. See [https://forums.developer.nvidia.com/t/gddccontrol-issues-with-nvidia-drivers-i2c-monitor-display-ddc-dp-hdmi-failing/30427/33] and [https://forums.developer.nvidia.com/t/gddccontrol-issues-with-nvidia-drivers-i2c-monitor-display-ddc-dp-hdmi-failing/30427/61]<br />
* {{ic|ddcutil}} will fail to set some VCP features if there is a feature enabled on the monitor which already automatically adjusts them (e.g. [[Wikipedia:Contrast ratio#Dynamic contrast (DC)|Dynamic Contrast Ratio]] or BenQ's ''Eye Care'' technology).<br />
* To facilitate binding screen brightness control to a keyboard shortcut, it may be convenient to enable non-superuser access to the relevant I2C devices. This can be achieved by adding a group {{ic|i2c}} and configuring [[udev]] to set this group as the owner of the I2C devices. See [https://raspberrypi.stackexchange.com/a/4472].<br />
* If {{Pkg|ddcutil}} is installed, it provides the {{ic|/usr/share/ddcutil/data/90-nvidia-i2c.conf}} file, which can be copied to {{ic|/etc/X11/xorg.conf.d/}} instead of manually editing [[Xorg]] configuration files. It also provides {{ic|/usr/share/ddcutil/data/45-ddcutil-i2c.rules}} and {{ic|/usr/share/ddcutil/data/45-ddcutil-usb.rules}} for [[udev]] rules.<br />
}}<br />
<br />
== Switch off the backlight ==<br />
<br />
{{Merge|DPMS|Same topic.}}<br />
<br />
Switching off the backlight (for example when one locks a notebook) can be useful to conserve battery energy. Ideally the following command should work for any [[Xorg]] graphical session:<br />
<br />
$ xset dpms force off<br />
<br />
The backlight should switch on again on mouse movement or keyboard input. Alternately, {{ic|xset s}} could be used for a similar effect.<br />
<br />
If the previous commands do not work, there is a chance that ''vbetool'' may work. Note, however, that in this case the backlight must be manually activated again. The command is as follows:<br />
<br />
$ vbetool dpms off<br />
<br />
To activate the backlight again:<br />
<br />
$ vbetool dpms on<br />
<br />
For example, this can be put to use when closing the notebook lid using [[acpid]].<br />
<br />
== Save and restore functionality ==<br />
<br />
The [[systemd]] package includes the service {{ic|systemd-backlight@.service}}, which is enabled by default and "static". It saves the backlight brightness level at shutdown and restores it at boot. The service uses the ACPI method described in [[#ACPI]], generating services for each folder found in {{ic|/sys/class/backlight/}}. For example, if there is a folder named {{ic|acpi_video0}}, it generates a service called {{ic|systemd-backlight@backlight:acpi_video0.service}}. When using other methods of setting the backlight at boot, it is recommended to stop systemd-backlight from restoring the backlight by setting the [[kernel parameters]] parameter {{ic|1=systemd.restore_state=0}}. See {{man|8|systemd-backlight@.service}} for details.<br />
<br />
{{Note|Some laptops have multiple video cards (e.g. Optimus) and the backlight restoration fails. Try [[systemd#Using units|masking]] an instance of the service (e.g. {{ic|systemd-backlight@backlight:acpi_video1}} for {{ic|acpi_video1}}).}}<br />
<br />
Additionally, the {{AUR|brillo}} and {{Pkg|light}} utilities support save and restore functionality. These two may be more useful if one wishes to restore the screen brightness on a per-user basis, however no systemd units are provided to accomplish this.<br />
<br />
== Backlight utilities ==<br />
<br />
{{Note|The utilities in the following table can be used to control screen brightness. All of them are compatible with Wayland and do not require X. Some (like {{Pkg|brightnessctl}} or {{Pkg|light}}) add udev rules to allow members of the {{ic|video}} (or {{ic|input}}) group to modify brightness.}}<br />
<br />
{| class="wikitable sortable"<br />
! Package name<br />
! Controls keyboard backlights<br />
! Reacts to ambient brightness<br />
! Language<br />
! License<br />
! Notes<br />
|-<br />
| {{Pkg|acpilight}}<br />
| {{Yes}}<br />
| {{No}}<br />
| Python3<br />
| GPL-3.0-or-later<br />
| "xbacklight" executable provided<br />
|-<br />
| {{AUR|backlight_control}}<br />
| {{No}}<br />
| {{No}}<br />
| C<br />
| MIT<br />
| Extremely small and simple. Supports relative adjustments.<br />
|-<br />
| {{AUR|blight}}<br />
| {{Yes}}<br />
| {{No}}<br />
| Python3<br />
| ISC<br />
| Uses logind interface. Restricted to local users, but does not require suid or video group membership.<br />
|-<br />
| {{AUR|brightd}}<br />
| {{No}}<br />
| {{No}}<br />
| C<br />
| GPL-2.0<br />
| Dims the screen when there is no user input for some time.<br />
|-<br />
| {{Pkg|brightnessctl}}<br />
| {{Yes}}<br />
| {{No}}<br />
| C<br />
| MIT<br />
| -<br />
|-<br />
| {{AUR|brillo}}<br />
| {{Yes}}<br />
| {{No}}<br />
| C<br />
| GPL-3.0-only<br />
| Supports smooth and relative adjustments.<br />
|-<br />
| {{AUR|clight}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
| C<br />
| GPL-3.0-or-later<br />
| Manages screen temperature ([[Xorg]] only) and smoothly dims brightness after a timeout. Supports ambient light sensors [https://github.com/FedeDP/Clightd/wiki/Sensors]. Can turn webcam into an ambient light sensor.<br />
|-<br />
| {{AUR|enlighten-git}}<br />
| {{Yes}}<br />
| {{No}}<br />
| C<br />
| GPL-3.0-or-later<br />
| -<br />
|-<br />
| {{AUR|illum-git}}<br />
| {{No}}<br />
| {{No}}<br />
| C<br />
| AGPL-3.0<br />
| Reacts to key presses.<br />
|-<br />
| {{Pkg|light}}<br />
| {{Yes}}<br />
| {{No}}<br />
| C<br />
| GPL-3.0-only<br />
| Dependency free. Does not rely on X server.<br />
|-<br />
| {{AUR|lux}}<br />
| {{No}}<br />
| {{No}}<br />
| Shell<br />
| MIT<br />
| -<br />
|-<br />
| {{AUR|macbook-lighter}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
| Bash,Perl<br />
| GPL<br />
| Macbook screen/keyboard backlight CLI and auto-adjust on ambient light.<br />
|-<br />
| {{AUR|wlr-brightness-git}}<br />
| {{No}}<br />
| {{No}}<br />
| C<br />
| MIT<br />
| Also supports newer OLED displays that need gamma adjustment. Uses wlroots.<br />
|-<br />
| {{AUR|wluma}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
| Rust<br />
| ISC<br />
| Automatic brightness adjustment based on screen contents and ambient light. Can use webcam or time to simulate ambient light sensor. Supports keyboards and external monitors. Uses wlroots.<br />
|-<br />
| {{AUR|ybacklight}}<br />
| {{No}}<br />
| {{No}}<br />
| Perl<br />
| GPL-2.0<br />
| Small Perl script similar to xbacklight but using sysfs drivers.<br />
|- <br />
| {{AUR|xbacklight-notify}}<br />
| {{No}}<br />
| {{No}}<br />
| C<br />
| MIT<br />
| Simple notifification daemon<br />
|}<br />
<br />
{{Tip|Commands involving these utilities can be bound to the {{ic|XF86MonBrightnessUp}} and {{ic|XF86MonBrightnessDown}} keyboard keys as described in [[Keyboard shortcuts#Xorg]].}}<br />
<br />
=== xbacklight ===<br />
<br />
Brightness can be set using the {{Pkg|xorg-xbacklight}} package.<br />
<br />
{{Note|1=<nowiki/><br />
* xbacklight only works with [[Intel]]. Other drivers did not add support for the RandR backlight property. <br />
* xbacklight currently does not work with the modesetting driver [https://gitlab.freedesktop.org/xorg/xserver/issues/47].<br />
}}<br />
<br />
To set brightness to 50% of maximum:<br />
<br />
$ xbacklight -set 50<br />
<br />
Increments can be used instead of absolute values, for example to increase or decrease brightness by 10%:<br />
<br />
$ xbacklight -inc 10<br />
$ xbacklight -dec 10<br />
<br />
If you get the "No outputs have backlight property" error, it is because xrandr/xbacklight does not choose the right directory in {{ic|/sys/class/backlight}}. You can specify the directory by setting the {{ic|Backlight}} option of the device section in {{ic|/etc/X11/xorg.conf.d/20-''video''.conf}}. For instance, if the name of the directory is {{ic|intel_backlight}} and using the [[Intel]] driver, the device section may be configured as follows:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "intel"<br />
Option "Backlight" "intel_backlight"<br />
EndSection}}<br />
<br />
{{Note|Using this with an iGPU+dGPU setup can cause unpredictable screen update lag and/or flickering in user interface items inside apps that are offloaded to the dGPU. Only use this if all else fails.}}<br />
<br />
See {{Bug|27677}} and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651741 for details.<br />
<br />
If you have enabled [[Intel graphics#Fastboot|Intel Fastboot]] you might also get the {{ic|No outputs have backlight property}} error. In this case, trying the above method may cause Xorg to crash on start up. You should disable it to fix the issue. It is [https://bugs.freedesktop.org/show_bug.cgi?id=108225 known] to cause issues with brightness control.<br />
<br />
=== light ===<br />
<br />
Install {{Pkg|light}} and add your user to the {{ic|video}} group.<br />
<br />
Increase backlight brightness by 5 percent:<br />
<br />
$ light -A 5<br />
<br />
Decrease backlight brightness by 5 percent:<br />
<br />
$ light -U 5<br />
<br />
Set backlight brightness to 100 percent:<br />
<br />
$ light -S 100<br />
<br />
=== Using DBus with GNOME ===<br />
<br />
Brightness can also be adjusted as the GNOME controls do. Changes are reflected in the GNOME UI using this method.<br />
<br />
$ gdbus call --session --dest org.gnome.SettingsDaemon.Power --object-path /org/gnome/SettingsDaemon/Power --method org.freedesktop.DBus.Properties.Set org.gnome.SettingsDaemon.Power.Screen Brightness "<int32 50>"<br />
<br />
Steps in brightness for keyboard control can be implemented with this method as well.<br />
<br />
$ gdbus call --session --dest org.gnome.SettingsDaemon.Power --object-path /org/gnome/SettingsDaemon/Power --method org.gnome.SettingsDaemon.Power.Screen.StepUp<br />
$ gdbus call --session --dest org.gnome.SettingsDaemon.Power --object-path /org/gnome/SettingsDaemon/Power --method org.gnome.SettingsDaemon.Power.Screen.StepDown<br />
<br />
=== Using DBus with KDE ===<br />
<br />
See https://userbase.kde.org/KDE_Connect/Tutorials/Useful_commands#Brightness_settings.<br />
<br />
== Color correction ==<br />
<br />
{{Expansion|Which utilities require [[Xorg]] and which work in [[Wayland]]?}}<br />
<br />
Color correction does not change the backlight power, it just modifies the video [[Wikipedia:Lookup table#Lookup tables in image processing|lookup table]]: this means that your battery life will be unaffected by the change. Nevertheless, it could be useful when no backlight control is available (desktop PCs or laptops with OLED screens).<br />
<br />
* {{App|Clight|User daemon utility that aims to fully manage your display. It can manage the screen temperature depending on the current time of the day, just like redshift does. It tries to use {{Pkg|geoclue}} to retrieve the user position if neither latitude or longitude are set in the configuration file. It also supports fixed times for sunrise and sunset.|https://github.com/FedeDP/Clight|{{AUR|clight}}}}<br />
* {{App|icc-brightness|Control OLED display brightness by applying ICC color profiles.|https://github.com/udifuchs/icc-brightness|{{AUR|icc-brightness-gnome-git}}}}<br />
* {{App|Monica|Monitor calibration tool. It works as frontend to xgamma to alter the gamma correction.|https://web.archive.org/web/20090815224839/http://www.pcbypaul.com/software/monica.html|{{AUR|monica}}}}<br />
* {{App|[[Redshift]]|Color temperature adjustment tool. It adjusts the color temperature of your screen according to your surroundings. This may help your eyes hurt less if you are working in front of the screen at night. This program is inspired by [[Wikipedia:f.lux|f.lux]].|http://jonls.dk/redshift/|{{Pkg|redshift}}}}<br />
* {{App|xcalib|Lightweight monitor calibration loader which can load an ICC monitor profile to be shared across desktop applications.|https://github.com/OpenICC/xcalib|{{Pkg|xcalib}}}}<br />
* {{App|xgamma|Alter a monitor's gamma correction.|https://xorg.freedesktop.org/|{{Pkg|xorg-xgamma}}}}<br />
<br />
=== Wayland ===<br />
<br />
[[Redshift]] does not support Wayland (without a patch or fork like {{AUR|redshift-wayland-git}}). But it is possible to apply the desired temperature in [[tty]] before starting a compositor. For example:<br />
<br />
$ redshift -m drm -PO 3000<br />
<br />
Otherwise some compositors can apply color correction during runtime:<br />
<br />
* On [[GNOME]], the built-in [[GNOME#Night Light|Night Light]] can be used.<br />
* On [[KDE Plasma]], the built-in [[KDE#Night Color]] can be used.<br />
* On Sway 1.0 and other wlroots-based compositors, as well as Orbital, Redshift fork {{Pkg|gammastep}}, {{AUR|clight}}, {{AUR|wlsunset-git}}, or {{AUR|wl-gammarelay}} can be used.<br />
<br />
=== Xorg: adjust perceived brightness with xrandr ===<br />
<br />
[[xrandr]] may be used to adjust the perceived brightness. <br />
<br />
To adjust perceived brightness above its maximum level (the same caveats mentioned above for Nvidia apply):<br />
<br />
$ xrandr --output ''output_name'' --brightness 2<br />
<br />
This should roughly double luma in the image. It will sacrifice color quality for brightness, nevertheless it is particularly suited for situations where the ambient light is very bright (e.g. sunlight).<br />
<br />
This can also be used to reduce perceived brightness in a dark room by specifying some value less than 1 (e.g. 0.5), this is useful when no backlight control is available (e.g. desktop PC).<br />
<br />
The ''output name'' of the connected device may be determined by calling {{ic|xrandr}}:<br />
<br />
$ xrandr | grep -w connected | cut -f '1' -d ' '<br />
<br />
Users may find it convenient to implement this as an alias:<br />
<br />
$ alias b='echo -e "enter brightness:\n"; read val; xrandr --output ''output name'' --brightness "${val}"'<br />
<br />
To automatically call xrandr when a backlight file changes, {{aur|oled_shmoled}} can be used like so:<br />
<br />
$ oled_shmoled ''output_name''<br />
<br />
=== NVIDIA settings ===<br />
<br />
Users of [[NVIDIA]]'s proprietary drivers can change display brightness via the [[NVIDIA#nvidia-settings|nvidia-settings]] utility under "X Server Color Correction." However, note that this has absolutely nothing to do with backlight (intensity), it merely adjusts the color output. (Reducing brightness this way is a power-inefficient last resort when all other options fail; increasing brightness spoils your color output completely, in a way similar to overexposed photos.)<br />
<br />
== Troubleshooting ==<br />
<br />
=== Backlight PWM modulation frequency (Intel i915 only) ===<br />
<br />
{{Accuracy|Modern LED display using IPS panel usually utilize DC dimming instead of PWM dimming. This can be indicated by the two upper bytes of 0xC8254 register 0x0001, which means the frequency is almost infinity.}}<br />
<br />
Laptops with LED backlight are known to have screen flicker sometimes. This is because the most efficient way of controlling LED backlight brightness is by turning the LED's on and off very quickly varying the amount of time they are on. <br />
<br />
However, the frequency of the switching, so-called PWM (pulse-width modulation) frequency, may not be high enough for the eye to perceive it as a single brightness and instead see flickering. This causes some people to have symptoms such as headaches and eyestrain.<br />
<br />
If you have an Intel i915 GPU, then it may be possible to adjust PWM frequency to eliminate flicker.<br />
<br />
Period of PWM (inverse to frequency) is stored in 2 higher bytes of {{ic|0xC8254}} register (if you are using the Intel GM45 chipset use address {{ic|0x61254}} instead). To manipulate registers values install {{Pkg|intel-gpu-tools}} from the official repositories.<br />
<br />
To increase the frequency, period must be reduced. For example:<br />
<br />
{{hc|# intel_reg read 0xC8254|<br />
0xC8254 : 0x12281228|<br />
}}<br />
<br />
Then to double PWM frequency divide 2 higher bytes (4 higher hex digits) by 2 and write back resulting value, keeping lower bytes unchanged:<br />
<br />
# intel_reg write 0xC8254 0x09141228<br />
<br />
You can use online calculator to calculate desired value https://devbraindom.blogspot.com/2013/03/eliminate-led-screen-flicker-with-intel.html<br />
<br />
To set new frequency automatically, consider writing an udev rule or install {{AUR|intelpwm-udev}}.<br />
<br />
=== Inverted Brightness (Intel i915 only) ===<br />
<br />
Symptoms:<br />
<br />
* after installing {{pkg|xf86-video-intel}} systemd-backlight.service turns off the backlight during boot<br />
** possible solution: mask systemd-backlight.service<br />
* switching from X to another VT turns the backlight off<br />
* the brightness keys are inverted (i.e. turning up the brightness makes the screen darker)<br />
<br />
This problem may be solved by adding {{ic|1=i915.invert_brightness=1}} to the list of [[kernel parameters]].<br />
<br />
=== Unable to control eDP Panel brightness (Intel i915 only) ===<br />
<br />
Embedded Display Port (eDP) v1.2 introduced a new display panel control protocol for backlight and other controls that works through the AUX channel [https://www.vesa.org/wp-content/uploads/2010/12/DisplayPort-DevCon-Presentation-eDP-Dec-2010-v3.pdf]<br />
<br />
By default the i915 driver tries to use PWM to control backlight brightness, which might not work.<br />
<br />
To set the backlight through writes to DPCD registers using the AUX channel set {{ic|1=i915.enable_dpcd_backlight=1}} as a [[kernel parameter]].<br />
<br />
{{Note|The parameter changed from bool to int in {{pkg|linux}} 5.4.}}<br />
<br />
=== sysfs modified but no brightness change ===<br />
<br />
{{Note|This behavior and their workarounds have been confirmed on the Dell M6700 with Nvidia K5000m (BIOS version prior to A10) and Clevo P750ZM (Eurocom P5 Pro Extreme) with Nvidia 980m.}}<br />
<br />
On some systems, the brightness hotkeys on your keyboard correctly modify the values of the acpi interface in {{ic|/sys/class/backlight/acpi_video0/actual_brightness}} but the brightness of the screen is not changed. Brightness applets from [[desktop environments]] may also show changes to no effect.<br />
<br />
If you have tested the recommended kernel parameters and only {{ic|xbacklight}} works, then you may be facing an incompatibility between your BIOS and kernel driver.<br />
<br />
In this case the only solution is to wait for a fix either from the BIOS or GPU driver manufacturer.<br />
<br />
A workaround is to use the inotify kernel api to trigger {{ic|xbacklight}} each time the value of {{ic|/sys/class/backlight/acpi_video0/actual_brightness}} changes.<br />
<br />
First [[install]] {{Pkg|inotify-tools}}. Then create a script around inotify that will be launched upon each boot or through [[autostart]].<br />
<br />
{{hc|/usr/local/bin/xbacklightmon|<nowiki><br />
#!/bin/sh<br />
<br />
path=/sys/class/backlight/acpi_video0<br />
<br />
luminance() {<br />
read -r level < "$path"/actual_brightness<br />
factor=$((100 / max))<br />
printf '%d\n' "$((level * factor))"<br />
}<br />
<br />
read -r max < "$path"/max_brightness<br />
<br />
xbacklight -set "$(luminance)"<br />
<br />
inotifywait -me modify --format '' "$path"/actual_brightness | while read; do<br />
xbacklight -set "$(luminance)"<br />
done<br />
</nowiki>}}<br />
<br />
=== Backlight not working in MATE ===<br />
<br />
Make sure the {{Pkg|mate-power-manager}} package is [[install]]ed.<br />
<br />
=== Backlight keys not working in Xfce ===<br />
<br />
In xfce4, the [https://docs.xfce.org/xfce/xfce4-power-manager/start Xfce4 Power Manager] handles the brightness keys.<br />
<br />
In some installations of Xfce, the "Handle display brightness keys" setting may be turned off by default.<br />
<br />
To activate the brightness keys again, open the [https://docs.xfce.org/xfce/xfce4-power-manager/preferences Xfce Power Manager dialog] and toggle on "Handle display brightness keys":<br />
<br />
$ xfce4-power-manager -c<br />
<br />
=== xbacklight returns : No outputs have backlight property ===<br />
<br />
Depending on the video card installed, sometimes xbacklight from {{Pkg|xorg-xbacklight}} returns the message "No outputs have backlight property". Installing {{Pkg|acpilight}} provides an alternative xbacklight that may work as expected.<br />
<br />
=== Backlight is always at full brightness after a reboot with amdgpu driver ===<br />
<br />
Due to a [https://bugzilla.kernel.org/show_bug.cgi?id=203905 bug] introduced recently in the amdgpu driver, the backlight's {{ic|actual_brightness}} value is reported as a 16-bit integer, which is outside the 8-bit range specified in {{ic|max_brightness}}. This causes the {{ic|systemd-backlight}} service to attempt to restore, at boot time, a value that is too large and ends being truncated to maximum brightness (255).<br />
<br />
While the bug is not addressed, one possible workaround is to modify the stored brightness to within the correct range before it is restored. This can be accomplished with a script and a service unit:<br />
<br />
{{hc|fix-brightness.sh|2=<br />
#!/bin/bash<br />
<br />
# Change the line below according to your hardware<br />
BRIGHTNESS_FILE="/var/lib/systemd/backlight/pci-0000:04:00.0:backlight:amdgpu_bl0"<br />
BRIGHTNESS=$(cat "$BRIGHTNESS_FILE")<br />
BRIGHTNESS=$(($BRIGHTNESS*255/65535))<br />
BRIGHTNESS=${BRIGHTNESS/.*} # truncating to int, just in case<br />
echo $BRIGHTNESS > "$BRIGHTNESS_FILE"<br />
}}<br />
<br />
{{hc|fix-brightness.service|2=<br />
[Unit]<br />
Description=Convert 16-bit brightness values to 8-bit before systemd-backlight applies it<br />
Before=systemd-backlight@backlight:amdgpu_bl0.service<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=<path to the script above><br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
On certain systems, the backlight level reported by the driver is in the correct range [0, 255], but systemd still fails to restore the correct value. This is probably due to a race in the [https://gitlab.freedesktop.org/drm/amd/-/issues/1337 kernel]. In this case, truncating the brightness level will not help since it is already in the correct range. Instead, saving the brightness level to systemd before shutting down could work as a workaround. This can be accomplished by the following script and service unit:<br />
<br />
{{hc|fix-brightness.sh|2=<br />
#!/bin/sh<br />
<br />
# Backlight level from systemd's perspective (change if needed)<br />
readonly SYSTEMD_BACKLIGHT_FILE='/var/lib/systemd/backlight/pci-0000:04:00.0:backlight:amdgpu_bl0'<br />
<br />
# Backlight level from AMDGPU driver<br />
readonly AMDGPU_BACKLIGHT_FILE='/sys/class/backlight/amdgpu_bl0/brightness'<br />
<br />
# Read current value from the driver and apply it to systemd<br />
readonly AMDGPU_BACKLIGHT_VALUE=$(cat "$AMDGPU_BACKLIGHT_FILE")<br />
echo "$AMDGPU_BACKLIGHT_VALUE" > "$SYSTEMD_BACKLIGHT_FILE"<br />
}}<br />
<br />
{{hc|fix-brightness.service|2=<br />
[Unit]<br />
Description=Save brightness value from AMDGPU<br />
DefaultDependencies=no<br />
After=final.target<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=<path to the script above><br />
<br />
[Install]<br />
WantedBy=final.target<br />
}}</div>Jellyhttps://wiki.archlinux.org/index.php?title=TUXEDO_InfinityBook_Pro_15v4&diff=773326TUXEDO InfinityBook Pro 15v42023-03-20T13:23:13Z<p>Jelly: /* Function keys */ this should not be required anymore after Linux 6.0</p>
<hr />
<div>[[Category:TUXEDO]]<br />
{{Laptop style|Stub}}<br />
<br />
{| class="wikitable" style="float: right;"<br />
! Hardware !! PCI/USB ID !! Working?<br />
|-<br />
| GPU || || {{Yes}}<br />
|-<br />
| Ethernet || || {{Yes}}<br />
|-<br />
| Wireless || || {{Yes}}<br />
|-<br />
| Bluetooth || || {{Yes}}<br />
|-<br />
| Audio || || {{Yes}}<br />
|-<br />
| Touchpad || || {{Yes}}<br />
|-<br />
| Card Reader || || {{Yes}}<br />
|-<br />
| Webcam || || {{Yes}}<br />
|-<br />
| IR Camera || || {{Yes}}<br />
|-<br />
| Thunderbolt 3 || || {{Yes}}<br />
|-<br />
| Fingerprint sensor || || {{No}}<br />
|}<br />
<br />
== Configuration ==<br />
<br />
=== Video ===<br />
<br />
==== Drivers ====<br />
<br />
See [[Intel graphics#Installation|Intel Graphics]] and [[Hardware video acceleration|Hardware Acceleration]]<br />
<br />
=== Function keys ===<br />
<br />
The most {{ic|Fn}} function keys work out of the box. For the {{ic|Fn}} function keys {{ic|F10}}, {{ic|F11}} and {{ic|F12}} the following must be set as [[kernel parameter]]. If {{AUR|tuxedo-keyboard-dkms}} is installed this is not necessary.<br />
{{bc|<nowiki>acpi_os_name=Linux acpi_osi=</nowiki>}}<br />
<br />
=== Keyboard backlight ===<br />
<br />
TUXEDO Computers provides a driver for their models with RGB keyboard. TUXEDO Keyboard can be installed manually from [https://github.com/tuxedocomputers/tuxedo-keyboard source] or you use {{AUR|tuxedo-keyboard-dkms}}<br />
<br />
=== TUXEDO Control Center ===<br />
<br />
TUXEDO Computers provides their own control center, TUXEDO Control Center (TCC), "to help you control performance, energy, fan and comfort settings". Install the {{AUR|tuxedo-control-center-bin}} package.<br />
<br />
== Power management ==<br />
<br />
=== Suspend ===<br />
<br />
See [[Power management/Suspend and hibernate#Changing suspend method]].<br />
<br />
Read more at the help page from TUXEDO [https://www.tuxedocomputers.com/en/Infos/Help-Support/Instructions/Fine-tuning-of-power-management-with-suspend-standby.tuxedo].<br />
<br />
=== Undervolting ===<br />
<br />
With the TUXEDO Premium BIOS you can undervolt the CPU over the BIOS. You can switch between {{ic|-10mV}} and {{ic|-100mV}}. The selectable values are not dangerous, but test it in small steps. So try {{ic|-60mV}}, if it is stable you can try {{ic|-70mV}} and so on You also can use {{Pkg|intel-undervolt}}. Read [[Undervolting CPU]] for more Informations.<br><br />
As default {{ic|-50mV}} is pre-selected. You can change the value over the BIOS under '''''Setup Utility > Advanced > Advanced Chipset Control > BIOS-controlled Undervolting'''''.<br />
<br />
=== BIOS Performance Profiles ===<br />
<br />
With the TUXEDO Premium BIOS you can select one of four Performance Profiles. As default the {{ic|Entertainment}} is pre-selected.<br />
* Quiet<br />
* Power Saving<br />
* Entertainment<br />
* Performance<br />
You can change the Profile over the BIOS under '''''Setup Utility > Advanced > Advanced Chipset Control > Performance Profile Select'''''.<br><br />
More informations can found at the help page from TUXEDO [https://www.tuxedocomputers.com/en/Infos/Help-Support/Instructions/Premium-BIOS-BIOS-Performance-Profiles.tuxedo]<br />
<br />
=== Thunderbolt ===<br />
<br />
The integreated Thunderbolt Controller will only shown up when a Thunderbolt device is connected or if you manually [[Thunderbolt#Forcing power|force Thunderbolt power]].</div>Jellyhttps://wiki.archlinux.org/index.php?title=Backlight&diff=773325Backlight2023-03-20T13:16:48Z<p>Jelly: Setting =none disables all backlight interfaces so users should try =native instead</p>
<hr />
<div>[[Category:Laptops]]<br />
[[Category:Power management]]<br />
[[ja:バックライト]]<br />
[[ru:Backlight]]<br />
[[zh-hans:Backlight]]<br />
Screen brightness might be tricky to control. On some machines physical hardware switches are missing and software solutions may not work well. However, it is generally possible to find a functional method for a given hardware. This article aims to summarize all possible ways to adjust the backlight.<br />
<br />
There are many ways to control brightness of a monitor, laptop or integrated panel (such as the iMac). According to [https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/397617 these] [https://lore.kernel.org/patchwork/patch/528936/#708706 discussions] and this [https://wiki.ubuntu.com/Kernel/Debugging/Backlight wiki page] the control method can be divided into these categories:<br />
<br />
* brightness is controlled by vendor-specified hotkey and there is no interface for the OS to adjust the brightness.<br />
* brightness is controlled by either the [[#ACPI|ACPI]], graphic or platform driver. In this case, backlight control is exposed to the user through {{ic|/sys/class/backlight}} which can be used by user-space [[#Backlight utilities|backlight utilities]].<br />
* brightness is controlled by writing into a graphic card register through [[#setpci|setpci]].<br />
<br />
{{Note|Since OLED screens have no backlight, brightness cannot be controlled by changing backlight power on laptops equipped with an OLED screen. In this case, perceived screen brightness can be adjusted with a PWM control (not implemented in the Linux kernel) or via [[#Color correction|software color correction]].}}<br />
<br />
== Hardware interfaces ==<br />
<br />
=== ACPI ===<br />
<br />
The brightness of the screen backlight is adjusted by setting the power level of the backlight LEDs or cathodes. The power level can often be controlled using the ACPI kernel module for video. An interface to this module is provided via a {{man|5|sysfs}} directory at {{ic|/sys/class/backlight/}}.<br />
<br />
The name of the directory depends on the graphics card model.<br />
<br />
{{hc|$ ls /sys/class/backlight/|<br />
acpi_video0<br />
}}<br />
<br />
In this case, the backlight is managed by an ATI graphics card. In the case of an Intel card, the directory is called {{ic|intel_backlight}}. In the following examples, {{ic|acpi_video0}} is used. If you use an Intel card, simply replace {{ic|acpi_video0}} with {{ic|intel_backlight}} in the examples.<br />
<br />
The directory contains the following files and subdirectories:<br />
<br />
{{hc|$ ls /sys/class/backlight/acpi_video0/|<br />
actual_brightness brightness max_brightness subsystem/ uevent <br />
bl_power device/ power/ type<br />
}}<br />
<br />
The maximum brightness can be displayed by reading from {{ic|max_brightness}}, which is often 15.<br />
<br />
{{hc|$ cat /sys/class/backlight/acpi_video0/max_brightness|<br />
15<br />
}}<br />
<br />
The brightness can be set by writing a number to {{ic|brightness}}. Attempting to set a brightness greater than the maximum results in an error.<br />
<br />
# echo 5 > /sys/class/backlight/acpi_video0/brightness<br />
<br />
By default, only {{ic|root}} can change the brightness by this method. To allow users in the {{ic|video}} group to change the brightness, a [[udev]] rule such as the following can be used:<br />
<br />
{{hc|/etc/udev/rules.d/backlight.rules|2=<br />
ACTION=="add", SUBSYSTEM=="backlight", RUN+="/bin/chgrp video $sys$devpath/brightness", RUN+="/bin/chmod g+w $sys$devpath/brightness"<br />
}}<br />
<br />
{{Accuracy|Explain why it is not possible to alter file permissions with {{ic|1=GROUP="video", MODE="0664"}}.|section=Udev rules for permissions of brightness doesn't work}}<br />
<br />
==== Kernel command-line options ====<br />
<br />
Sometimes ACPI does not work well due to different motherboard implementations and ACPI quirks. This results in, for instance, inaccurate brightness notifications. This includes some laptops with dual graphics (e.g., Nvidia/Radeon dedicated GPU with Intel/AMD integrated GPU). Additionally, ACPI sometimes needs to register its own {{ic|acpi_video0}} backlight even if one already exists (such as {{ic|intel_backlight}}), which can be done by adding one of the following [[kernel parameters]]:<br />
<br />
acpi_backlight=video<br />
acpi_backlight=vendor<br />
acpi_backlight=native<br />
<br />
If you find that changing the {{ic|acpi_video0}} backlight does not actually change the brightness, you may need to use {{ic|1=acpi_backlight=native}}.<br />
<br />
{{Tip|<br />
* On Nvidia Optimus laptops, the kernel parameter {{ic|nomodeset}} can interfere with the ability to adjust the backlight.<br />
* On an Asus notebooks you might also need to load the {{ic|asus-nb-wmi}} [[kernel module]].<br />
* Disabling legacy boot on Dell XPS13 breaks backlight support.<br />
}}<br />
<br />
==== Udev rule ====<br />
<br />
If the ACPI interface is available, the backlight level can be set at boot using a [[udev]] rule:<br />
<br />
{{hc|/etc/udev/rules.d/81-backlight.rules|2=<br />
# Set backlight level to 8<br />
SUBSYSTEM=="backlight", ACTION=="add", KERNEL=="acpi_video0", ATTR{brightness}="8"<br />
}}<br />
<br />
{{Note|The systemd-backlight service restores the previous backlight brightness level at boot. To prevent conflicts for the above rules, see [[#Save and restore functionality]].}}<br />
<br />
{{Tip|To set the backlight depending on power state, see [[Power management#Using a script and an udev rule]] and use your favourite [[#Backlight utilities|backlight utility]] in the script.}}<br />
<br />
=== setpci ===<br />
<br />
In some cases (e.g. Intel Mobile 945GME [https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/397617]), it is possible to set the register of the graphic card to adjust the backlight. It means you adjust the backlight by manipulating the hardware directly, which can be risky and generally is not a good idea. Not all of the graphic cards support this method.<br />
<br />
When using this method, you need to use {{ic|lspci}} first to find out where your graphic card is.<br />
<br />
# setpci -s 00:02.0 F4.B=0<br />
<br />
=== External monitors ===<br />
<br />
[[Wikipedia:Display_Data_Channel#DDC.2FCI|DDC/CI]] (Display Data Channel Command Interface) can be used to communicate with external monitors implementing MCCS (Monitor Control Command Set) over I2C. DDC can control brightness, contrast, inputs, etc on supported monitors. Settings available via the OSD (On-Screen Display) panel can usually also be managed via DDC. The [[kernel module]] {{ic|i2c-dev}} may need to be loaded if the {{ic|/dev/i2c-*}} devices do not exist.<br />
<br />
{{Pkg|ddcutil}} can be used to query and set brightness settings:<br />
<br />
{{hc|# ddcutil capabilities {{!}} grep "Feature: 10"|<br />
Feature: 10 (Brightness)<br />
}}<br />
<br />
{{hc|1=# ddcutil getvcp 10|2=<br />
VCP code 0x10 (Brightness ): current value = 60, max value = 100<br />
}}<br />
<br />
# ddcutil setvcp 10 70<br />
<br />
Alternatively, one may use {{AUR|ddcci-driver-linux-dkms}} to expose external monitors in sysfs. Then, after loading the {{ic|ddcci}} [[kernel module]], one can use any [[#Backlight utilities|backlight utility]].<br />
<br />
{{Note|<br />
* Using {{ic|ddcci}} and {{ic|i2c-dev}} simultaneously may result in resource conflicts such as a {{ic|Device or resource busy}} error.<br />
* Users of NVIDIA's proprietary drivers may need to add {{ic|1=Option "RegistryDwords" "RMUseSwI2c=0x01; RMI2cSpeed=100"}} to the {{ic|Device}} section in {{ic|/etc/X11/xorg.conf.d/20-nvidia.conf}} (generated by ''nvidia-xconfig'') or {{ic|1=options nvidia NVreg_RegistryDwords=RMUseSwI2c=0x01;RMI2cSpeed=100}} to {{ic|/etc/modprobe/conf.d/nvidia.conf}}. Confirm that the settings are correctly applied with {{ic|grep RegistryDwords /proc/driver/nvidia/params}} and check that the values are not empty. See [https://forums.developer.nvidia.com/t/gddccontrol-issues-with-nvidia-drivers-i2c-monitor-display-ddc-dp-hdmi-failing/30427/33] and [https://forums.developer.nvidia.com/t/gddccontrol-issues-with-nvidia-drivers-i2c-monitor-display-ddc-dp-hdmi-failing/30427/61]<br />
* {{ic|ddcutil}} will fail to set some VCP features if there is a feature enabled on the monitor which already automatically adjusts them (e.g. [[Wikipedia:Contrast ratio#Dynamic contrast (DC)|Dynamic Contrast Ratio]] or BenQ's ''Eye Care'' technology).<br />
* To facilitate binding screen brightness control to a keyboard shortcut, it may be convenient to enable non-superuser access to the relevant I2C devices. This can be achieved by adding a group {{ic|i2c}} and configuring [[udev]] to set this group as the owner of the I2C devices. See [https://raspberrypi.stackexchange.com/a/4472].<br />
* If {{Pkg|ddcutil}} is installed, it provides the {{ic|/usr/share/ddcutil/data/90-nvidia-i2c.conf}} file, which can be copied to {{ic|/etc/X11/xorg.conf.d/}} instead of manually editing [[Xorg]] configuration files. It also provides {{ic|/usr/share/ddcutil/data/45-ddcutil-i2c.rules}} and {{ic|/usr/share/ddcutil/data/45-ddcutil-usb.rules}} for [[udev]] rules.<br />
}}<br />
<br />
== Switch off the backlight ==<br />
<br />
{{Merge|DPMS|Same topic.}}<br />
<br />
Switching off the backlight (for example when one locks a notebook) can be useful to conserve battery energy. Ideally the following command should work for any [[Xorg]] graphical session:<br />
<br />
$ xset dpms force off<br />
<br />
The backlight should switch on again on mouse movement or keyboard input. Alternately, {{ic|xset s}} could be used for a similar effect.<br />
<br />
If the previous commands do not work, there is a chance that ''vbetool'' may work. Note, however, that in this case the backlight must be manually activated again. The command is as follows:<br />
<br />
$ vbetool dpms off<br />
<br />
To activate the backlight again:<br />
<br />
$ vbetool dpms on<br />
<br />
For example, this can be put to use when closing the notebook lid using [[acpid]].<br />
<br />
== Save and restore functionality ==<br />
<br />
The [[systemd]] package includes the service {{ic|systemd-backlight@.service}}, which is enabled by default and "static". It saves the backlight brightness level at shutdown and restores it at boot. The service uses the ACPI method described in [[#ACPI]], generating services for each folder found in {{ic|/sys/class/backlight/}}. For example, if there is a folder named {{ic|acpi_video0}}, it generates a service called {{ic|systemd-backlight@backlight:acpi_video0.service}}. When using other methods of setting the backlight at boot, it is recommended to stop systemd-backlight from restoring the backlight by setting the [[kernel parameters]] parameter {{ic|1=systemd.restore_state=0}}. See {{man|8|systemd-backlight@.service}} for details.<br />
<br />
{{Note|Some laptops have multiple video cards (e.g. Optimus) and the backlight restoration fails. Try [[systemd#Using units|masking]] an instance of the service (e.g. {{ic|systemd-backlight@backlight:acpi_video1}} for {{ic|acpi_video1}}).}}<br />
<br />
Additionally, the {{AUR|brillo}} and {{Pkg|light}} utilities support save and restore functionality. These two may be more useful if one wishes to restore the screen brightness on a per-user basis, however no systemd units are provided to accomplish this.<br />
<br />
== Backlight utilities ==<br />
<br />
{{Note|The utilities in the following table can be used to control screen brightness. All of them are compatible with Wayland and do not require X. Some (like {{Pkg|brightnessctl}} or {{Pkg|light}}) add udev rules to allow members of the {{ic|video}} (or {{ic|input}}) group to modify brightness.}}<br />
<br />
{| class="wikitable sortable"<br />
! Package name<br />
! Controls keyboard backlights<br />
! Reacts to ambient brightness<br />
! Language<br />
! License<br />
! Notes<br />
|-<br />
| {{Pkg|acpilight}}<br />
| {{Yes}}<br />
| {{No}}<br />
| Python3<br />
| GPL-3.0-or-later<br />
| "xbacklight" executable provided<br />
|-<br />
| {{AUR|backlight_control}}<br />
| {{No}}<br />
| {{No}}<br />
| C<br />
| MIT<br />
| Extremely small and simple. Supports relative adjustments.<br />
|-<br />
| {{AUR|blight}}<br />
| {{Yes}}<br />
| {{No}}<br />
| Python3<br />
| ISC<br />
| Uses logind interface. Restricted to local users, but does not require suid or video group membership.<br />
|-<br />
| {{AUR|brightd}}<br />
| {{No}}<br />
| {{No}}<br />
| C<br />
| GPL-2.0<br />
| Dims the screen when there is no user input for some time.<br />
|-<br />
| {{Pkg|brightnessctl}}<br />
| {{Yes}}<br />
| {{No}}<br />
| C<br />
| MIT<br />
| -<br />
|-<br />
| {{AUR|brillo}}<br />
| {{Yes}}<br />
| {{No}}<br />
| C<br />
| GPL-3.0-only<br />
| Supports smooth and relative adjustments.<br />
|-<br />
| {{AUR|clight}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
| C<br />
| GPL-3.0-or-later<br />
| Manages screen temperature ([[Xorg]] only) and smoothly dims brightness after a timeout. Supports ambient light sensors [https://github.com/FedeDP/Clightd/wiki/Sensors]. Can turn webcam into an ambient light sensor.<br />
|-<br />
| {{AUR|enlighten-git}}<br />
| {{Yes}}<br />
| {{No}}<br />
| C<br />
| GPL-3.0-or-later<br />
| -<br />
|-<br />
| {{AUR|illum-git}}<br />
| {{No}}<br />
| {{No}}<br />
| C<br />
| AGPL-3.0<br />
| Reacts to key presses.<br />
|-<br />
| {{Pkg|light}}<br />
| {{Yes}}<br />
| {{No}}<br />
| C<br />
| GPL-3.0-only<br />
| Dependency free. Does not rely on X server.<br />
|-<br />
| {{AUR|lux}}<br />
| {{No}}<br />
| {{No}}<br />
| Shell<br />
| MIT<br />
| -<br />
|-<br />
| {{AUR|macbook-lighter}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
| Bash,Perl<br />
| GPL<br />
| Macbook screen/keyboard backlight CLI and auto-adjust on ambient light.<br />
|-<br />
| {{AUR|wlr-brightness-git}}<br />
| {{No}}<br />
| {{No}}<br />
| C<br />
| MIT<br />
| Also supports newer OLED displays that need gamma adjustment. Uses wlroots.<br />
|-<br />
| {{AUR|wluma}}<br />
| {{Yes}}<br />
| {{Yes}}<br />
| Rust<br />
| ISC<br />
| Automatic brightness adjustment based on screen contents and ambient light. Can use webcam or time to simulate ambient light sensor. Supports keyboards and external monitors. Uses wlroots.<br />
|-<br />
| {{AUR|ybacklight}}<br />
| {{No}}<br />
| {{No}}<br />
| Perl<br />
| GPL-2.0<br />
| Small Perl script similar to xbacklight but using sysfs drivers.<br />
|- <br />
| {{AUR|xbacklight-notify}}<br />
| {{No}}<br />
| {{No}}<br />
| C<br />
| MIT<br />
| Simple notifification daemon<br />
|}<br />
<br />
{{Tip|Commands involving these utilities can be bound to the {{ic|XF86MonBrightnessUp}} and {{ic|XF86MonBrightnessDown}} keyboard keys as described in [[Keyboard shortcuts#Xorg]].}}<br />
<br />
=== xbacklight ===<br />
<br />
Brightness can be set using the {{Pkg|xorg-xbacklight}} package.<br />
<br />
{{Note|1=<nowiki/><br />
* xbacklight only works with [[Intel]]. Other drivers did not add support for the RandR backlight property. <br />
* xbacklight currently does not work with the modesetting driver [https://gitlab.freedesktop.org/xorg/xserver/issues/47].<br />
}}<br />
<br />
To set brightness to 50% of maximum:<br />
<br />
$ xbacklight -set 50<br />
<br />
Increments can be used instead of absolute values, for example to increase or decrease brightness by 10%:<br />
<br />
$ xbacklight -inc 10<br />
$ xbacklight -dec 10<br />
<br />
If you get the "No outputs have backlight property" error, it is because xrandr/xbacklight does not choose the right directory in {{ic|/sys/class/backlight}}. You can specify the directory by setting the {{ic|Backlight}} option of the device section in {{ic|/etc/X11/xorg.conf.d/20-''video''.conf}}. For instance, if the name of the directory is {{ic|intel_backlight}} and using the [[Intel]] driver, the device section may be configured as follows:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "intel"<br />
Option "Backlight" "intel_backlight"<br />
EndSection}}<br />
<br />
{{Note|Using this with an iGPU+dGPU setup can cause unpredictable screen update lag and/or flickering in user interface items inside apps that are offloaded to the dGPU. Only use this if all else fails.}}<br />
<br />
See {{Bug|27677}} and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651741 for details.<br />
<br />
If you have enabled [[Intel graphics#Fastboot|Intel Fastboot]] you might also get the {{ic|No outputs have backlight property}} error. In this case, trying the above method may cause Xorg to crash on start up. You should disable it to fix the issue. It is [https://bugs.freedesktop.org/show_bug.cgi?id=108225 known] to cause issues with brightness control.<br />
<br />
=== light ===<br />
<br />
Install {{Pkg|light}} and add your user to the {{ic|video}} group.<br />
<br />
Increase backlight brightness by 5 percent:<br />
<br />
$ light -A 5<br />
<br />
Decrease backlight brightness by 5 percent:<br />
<br />
$ light -U 5<br />
<br />
Set backlight brightness to 100 percent:<br />
<br />
$ light -S 100<br />
<br />
=== Using DBus with GNOME ===<br />
<br />
Brightness can also be adjusted as the GNOME controls do. Changes are reflected in the GNOME UI using this method.<br />
<br />
$ gdbus call --session --dest org.gnome.SettingsDaemon.Power --object-path /org/gnome/SettingsDaemon/Power --method org.freedesktop.DBus.Properties.Set org.gnome.SettingsDaemon.Power.Screen Brightness "<int32 50>"<br />
<br />
Steps in brightness for keyboard control can be implemented with this method as well.<br />
<br />
$ gdbus call --session --dest org.gnome.SettingsDaemon.Power --object-path /org/gnome/SettingsDaemon/Power --method org.gnome.SettingsDaemon.Power.Screen.StepUp<br />
$ gdbus call --session --dest org.gnome.SettingsDaemon.Power --object-path /org/gnome/SettingsDaemon/Power --method org.gnome.SettingsDaemon.Power.Screen.StepDown<br />
<br />
=== Using DBus with KDE ===<br />
<br />
See https://userbase.kde.org/KDE_Connect/Tutorials/Useful_commands#Brightness_settings.<br />
<br />
== Color correction ==<br />
<br />
{{Expansion|Which utilities require [[Xorg]] and which work in [[Wayland]]?}}<br />
<br />
Color correction does not change the backlight power, it just modifies the video [[Wikipedia:Lookup table#Lookup tables in image processing|lookup table]]: this means that your battery life will be unaffected by the change. Nevertheless, it could be useful when no backlight control is available (desktop PCs or laptops with OLED screens).<br />
<br />
* {{App|Clight|User daemon utility that aims to fully manage your display. It can manage the screen temperature depending on the current time of the day, just like redshift does. It tries to use {{Pkg|geoclue}} to retrieve the user position if neither latitude or longitude are set in the configuration file. It also supports fixed times for sunrise and sunset.|https://github.com/FedeDP/Clight|{{AUR|clight}}}}<br />
* {{App|icc-brightness|Control OLED display brightness by applying ICC color profiles.|https://github.com/udifuchs/icc-brightness|{{AUR|icc-brightness-gnome-git}}}}<br />
* {{App|Monica|Monitor calibration tool. It works as frontend to xgamma to alter the gamma correction.|https://web.archive.org/web/20090815224839/http://www.pcbypaul.com/software/monica.html|{{AUR|monica}}}}<br />
* {{App|[[Redshift]]|Color temperature adjustment tool. It adjusts the color temperature of your screen according to your surroundings. This may help your eyes hurt less if you are working in front of the screen at night. This program is inspired by [[Wikipedia:f.lux|f.lux]].|http://jonls.dk/redshift/|{{Pkg|redshift}}}}<br />
* {{App|xcalib|Lightweight monitor calibration loader which can load an ICC monitor profile to be shared across desktop applications.|https://github.com/OpenICC/xcalib|{{Pkg|xcalib}}}}<br />
* {{App|xgamma|Alter a monitor's gamma correction.|https://xorg.freedesktop.org/|{{Pkg|xorg-xgamma}}}}<br />
<br />
=== Wayland ===<br />
<br />
[[Redshift]] does not support Wayland (without a patch or fork like {{AUR|redshift-wayland-git}}). But it is possible to apply the desired temperature in [[tty]] before starting a compositor. For example:<br />
<br />
$ redshift -m drm -PO 3000<br />
<br />
Otherwise some compositors can apply color correction during runtime:<br />
<br />
* On [[GNOME]], the built-in [[GNOME#Night Light|Night Light]] can be used.<br />
* On [[KDE Plasma]], the built-in [[KDE#Night Color]] can be used.<br />
* On Sway 1.0 and other wlroots-based compositors, as well as Orbital, Redshift fork {{Pkg|gammastep}}, {{AUR|clight}}, {{AUR|wlsunset-git}}, or {{AUR|wl-gammarelay}} can be used.<br />
<br />
=== Xorg: adjust perceived brightness with xrandr ===<br />
<br />
[[xrandr]] may be used to adjust the perceived brightness. <br />
<br />
To adjust perceived brightness above its maximum level (the same caveats mentioned above for Nvidia apply):<br />
<br />
$ xrandr --output ''output_name'' --brightness 2<br />
<br />
This should roughly double luma in the image. It will sacrifice color quality for brightness, nevertheless it is particularly suited for situations where the ambient light is very bright (e.g. sunlight).<br />
<br />
This can also be used to reduce perceived brightness in a dark room by specifying some value less than 1 (e.g. 0.5), this is useful when no backlight control is available (e.g. desktop PC).<br />
<br />
The ''output name'' of the connected device may be determined by calling {{ic|xrandr}}:<br />
<br />
$ xrandr | grep -w connected | cut -f '1' -d ' '<br />
<br />
Users may find it convenient to implement this as an alias:<br />
<br />
$ alias b='echo -e "enter brightness:\n"; read val; xrandr --output ''output name'' --brightness "${val}"'<br />
<br />
To automatically call xrandr when a backlight file changes, {{aur|oled_shmoled}} can be used like so:<br />
<br />
$ oled_shmoled ''output_name''<br />
<br />
=== NVIDIA settings ===<br />
<br />
Users of [[NVIDIA]]'s proprietary drivers can change display brightness via the [[NVIDIA#nvidia-settings|nvidia-settings]] utility under "X Server Color Correction." However, note that this has absolutely nothing to do with backlight (intensity), it merely adjusts the color output. (Reducing brightness this way is a power-inefficient last resort when all other options fail; increasing brightness spoils your color output completely, in a way similar to overexposed photos.)<br />
<br />
== Troubleshooting ==<br />
<br />
=== Backlight PWM modulation frequency (Intel i915 only) ===<br />
<br />
{{Accuracy|Modern LED display using IPS panel usually utilize DC dimming instead of PWM dimming. This can be indicated by the two upper bytes of 0xC8254 register 0x0001, which means the frequency is almost infinity.}}<br />
<br />
Laptops with LED backlight are known to have screen flicker sometimes. This is because the most efficient way of controlling LED backlight brightness is by turning the LED's on and off very quickly varying the amount of time they are on. <br />
<br />
However, the frequency of the switching, so-called PWM (pulse-width modulation) frequency, may not be high enough for the eye to perceive it as a single brightness and instead see flickering. This causes some people to have symptoms such as headaches and eyestrain.<br />
<br />
If you have an Intel i915 GPU, then it may be possible to adjust PWM frequency to eliminate flicker.<br />
<br />
Period of PWM (inverse to frequency) is stored in 2 higher bytes of {{ic|0xC8254}} register (if you are using the Intel GM45 chipset use address {{ic|0x61254}} instead). To manipulate registers values install {{Pkg|intel-gpu-tools}} from the official repositories.<br />
<br />
To increase the frequency, period must be reduced. For example:<br />
<br />
{{hc|# intel_reg read 0xC8254|<br />
0xC8254 : 0x12281228|<br />
}}<br />
<br />
Then to double PWM frequency divide 2 higher bytes (4 higher hex digits) by 2 and write back resulting value, keeping lower bytes unchanged:<br />
<br />
# intel_reg write 0xC8254 0x09141228<br />
<br />
You can use online calculator to calculate desired value https://devbraindom.blogspot.com/2013/03/eliminate-led-screen-flicker-with-intel.html<br />
<br />
To set new frequency automatically, consider writing an udev rule or install {{AUR|intelpwm-udev}}.<br />
<br />
=== Inverted Brightness (Intel i915 only) ===<br />
<br />
Symptoms:<br />
<br />
* after installing {{pkg|xf86-video-intel}} systemd-backlight.service turns off the backlight during boot<br />
** possible solution: mask systemd-backlight.service<br />
* switching from X to another VT turns the backlight off<br />
* the brightness keys are inverted (i.e. turning up the brightness makes the screen darker)<br />
<br />
This problem may be solved by adding {{ic|1=i915.invert_brightness=1}} to the list of [[kernel parameters]].<br />
<br />
=== Unable to control eDP Panel brightness (Intel i915 only) ===<br />
<br />
Embedded Display Port (eDP) v1.2 introduced a new display panel control protocol for backlight and other controls that works through the AUX channel [https://www.vesa.org/wp-content/uploads/2010/12/DisplayPort-DevCon-Presentation-eDP-Dec-2010-v3.pdf]<br />
<br />
By default the i915 driver tries to use PWM to control backlight brightness, which might not work.<br />
<br />
To set the backlight through writes to DPCD registers using the AUX channel set {{ic|1=i915.enable_dpcd_backlight=1}} as a [[kernel parameter]].<br />
<br />
{{Note|The parameter changed from bool to int in {{pkg|linux}} 5.4.}}<br />
<br />
=== sysfs modified but no brightness change ===<br />
<br />
{{Note|This behavior and their workarounds have been confirmed on the Dell M6700 with Nvidia K5000m (BIOS version prior to A10) and Clevo P750ZM (Eurocom P5 Pro Extreme) with Nvidia 980m.}}<br />
<br />
On some systems, the brightness hotkeys on your keyboard correctly modify the values of the acpi interface in {{ic|/sys/class/backlight/acpi_video0/actual_brightness}} but the brightness of the screen is not changed. Brightness applets from [[desktop environments]] may also show changes to no effect.<br />
<br />
If you have tested the recommended kernel parameters and only {{ic|xbacklight}} works, then you may be facing an incompatibility between your BIOS and kernel driver.<br />
<br />
In this case the only solution is to wait for a fix either from the BIOS or GPU driver manufacturer.<br />
<br />
A workaround is to use the inotify kernel api to trigger {{ic|xbacklight}} each time the value of {{ic|/sys/class/backlight/acpi_video0/actual_brightness}} changes.<br />
<br />
First [[install]] {{Pkg|inotify-tools}}. Then create a script around inotify that will be launched upon each boot or through [[autostart]].<br />
<br />
{{hc|/usr/local/bin/xbacklightmon|<nowiki><br />
#!/bin/sh<br />
<br />
path=/sys/class/backlight/acpi_video0<br />
<br />
luminance() {<br />
read -r level < "$path"/actual_brightness<br />
factor=$((100 / max))<br />
printf '%d\n' "$((level * factor))"<br />
}<br />
<br />
read -r max < "$path"/max_brightness<br />
<br />
xbacklight -set "$(luminance)"<br />
<br />
inotifywait -me modify --format '' "$path"/actual_brightness | while read; do<br />
xbacklight -set "$(luminance)"<br />
done<br />
</nowiki>}}<br />
<br />
=== Backlight not working in MATE ===<br />
<br />
Make sure the {{Pkg|mate-power-manager}} package is [[install]]ed.<br />
<br />
=== Backlight keys not working in Xfce ===<br />
<br />
In xfce4, the [https://docs.xfce.org/xfce/xfce4-power-manager/start Xfce4 Power Manager] handles the brightness keys.<br />
<br />
In some installations of Xfce, the "Handle display brightness keys" setting may be turned off by default.<br />
<br />
To activate the brightness keys again, open the [https://docs.xfce.org/xfce/xfce4-power-manager/preferences Xfce Power Manager dialog] and toggle on "Handle display brightness keys":<br />
<br />
$ xfce4-power-manager -c<br />
<br />
=== xbacklight returns : No outputs have backlight property ===<br />
<br />
Depending on the video card installed, sometimes xbacklight from {{Pkg|xorg-xbacklight}} returns the message "No outputs have backlight property". Installing {{Pkg|acpilight}} provides an alternative xbacklight that may work as expected.<br />
<br />
=== Backlight is always at full brightness after a reboot with amdgpu driver ===<br />
<br />
Due to a [https://bugzilla.kernel.org/show_bug.cgi?id=203905 bug] introduced recently in the amdgpu driver, the backlight's {{ic|actual_brightness}} value is reported as a 16-bit integer, which is outside the 8-bit range specified in {{ic|max_brightness}}. This causes the {{ic|systemd-backlight}} service to attempt to restore, at boot time, a value that is too large and ends being truncated to maximum brightness (255).<br />
<br />
While the bug is not addressed, one possible workaround is to modify the stored brightness to within the correct range before it is restored. This can be accomplished with a script and a service unit:<br />
<br />
{{hc|fix-brightness.sh|2=<br />
#!/bin/bash<br />
<br />
# Change the line below according to your hardware<br />
BRIGHTNESS_FILE="/var/lib/systemd/backlight/pci-0000:04:00.0:backlight:amdgpu_bl0"<br />
BRIGHTNESS=$(cat "$BRIGHTNESS_FILE")<br />
BRIGHTNESS=$(($BRIGHTNESS*255/65535))<br />
BRIGHTNESS=${BRIGHTNESS/.*} # truncating to int, just in case<br />
echo $BRIGHTNESS > "$BRIGHTNESS_FILE"<br />
}}<br />
<br />
{{hc|fix-brightness.service|2=<br />
[Unit]<br />
Description=Convert 16-bit brightness values to 8-bit before systemd-backlight applies it<br />
Before=systemd-backlight@backlight:amdgpu_bl0.service<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=<path to the script above><br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
On certain systems, the backlight level reported by the driver is in the correct range [0, 255], but systemd still fails to restore the correct value. This is probably due to a race in the [https://gitlab.freedesktop.org/drm/amd/-/issues/1337 kernel]. In this case, truncating the brightness level will not help since it is already in the correct range. Instead, saving the brightness level to systemd before shutting down could work as a workaround. This can be accomplished by the following script and service unit:<br />
<br />
{{hc|fix-brightness.sh|2=<br />
#!/bin/sh<br />
<br />
# Backlight level from systemd's perspective (change if needed)<br />
readonly SYSTEMD_BACKLIGHT_FILE='/var/lib/systemd/backlight/pci-0000:04:00.0:backlight:amdgpu_bl0'<br />
<br />
# Backlight level from AMDGPU driver<br />
readonly AMDGPU_BACKLIGHT_FILE='/sys/class/backlight/amdgpu_bl0/brightness'<br />
<br />
# Read current value from the driver and apply it to systemd<br />
readonly AMDGPU_BACKLIGHT_VALUE=$(cat "$AMDGPU_BACKLIGHT_FILE")<br />
echo "$AMDGPU_BACKLIGHT_VALUE" > "$SYSTEMD_BACKLIGHT_FILE"<br />
}}<br />
<br />
{{hc|fix-brightness.service|2=<br />
[Unit]<br />
Description=Save brightness value from AMDGPU<br />
DefaultDependencies=no<br />
After=final.target<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=<path to the script above><br />
<br />
[Install]<br />
WantedBy=final.target<br />
}}</div>Jellyhttps://wiki.archlinux.org/index.php?title=Taskd&diff=773223Taskd2023-03-19T10:52:40Z<p>Jelly: /* taskd.service fails on boot */ fix url.</p>
<hr />
<div>[[Category:Networking]]<br />
[[ja:Taskd]]<br />
[https://github.com/GothenburgBitFactory/taskserver taskd] is a lightweight, secure server for [[Wikipedia:Taskwarrior|Taskwarrior]] ({{Pkg|task}}). It allows users to intelligently synchronize their tasks between multiple clients, including between desktop and mobile ones.<br />
<br />
== Server ==<br />
<br />
=== Installation ===<br />
<br />
[[Install]] {{Pkg|taskd}} or {{AUR|taskd-git}} for the development version.<br />
<br />
=== Configuration ===<br />
<br />
Once taskd is installed, you need to set it up. The first step is to {{bc|$ export TASKDDATA<nowiki>=</nowiki>/var/lib/taskd }} (otherwise you need to append {{ic|--data /var/lib/taskd}} to every taskd command).<br />
<br />
Next, edit the {{ic|/usr/share/doc/taskd/pki/vars}} file. The {{ic|CN<nowiki>=</nowiki>}} line must either match the server's hostname or IP address, depending on how you connect. Once the file is edited to your heart's content, change to the directory {{ic|/usr/share/doc/taskd/pki/}} and run {{ic|./generate}}. This will create self-signed certificates for your server. Copy all generated {{ic|.pem}} to {{ic|/var/lib/taskd}}. Note that at least the {{ic|ca.cert.pem}} and {{ic|ca.key.pem}} must remain in the {{ic|pki}} folder for the user-certificate generation later on. <br />
<br />
{{Note|for {{AUR|taskd-git}}, ''/usr/share/doc/taskd'' is moved to ''/usr/lib/taskd''}}<br />
<br />
Now you need to configure taskd. Use {{ic|taskd config}} or add the following to {{ic|/var/lib/taskd/config}} directly.<br />
{{hc|/var/lib/taskd/config|<nowiki><br />
client.cert=/var/lib/taskd/client.cert.pem<br />
client.key=/var/lib/taskd/client.key.pem<br />
server.cert=/var/lib/taskd/server.cert.pem<br />
server.key=/var/lib/taskd/server.key.pem<br />
server.crl=/var/lib/taskd/server.crl.pem<br />
ca.cert=/var/lib/taskd/ca.cert.pem<br />
<br />
chown taskd:taskd ca.cert.pem ca.key.pem server.cert.pem server.crl.pem server.key.pem<br />
chmod 400 ca.cert.pem ca.key.pem server.cert.pem server.crl.pem server.key.pem<br />
</nowiki>}}<br />
<br />
Additionally you should change where taskd logs to, since the default is {{ic|/tmp/taskd.log}}. This can be done by running<br />
{{bc|# touch /var/log/taskd.log<br />
# chown taskd:taskd /var/log/taskd.log<br />
# taskd config --force log /var/log/taskd.log}}<br />
<br />
The last step is to set taskd's server name, which must be the same as the one used in the certificates: {{ic|taskd config --force server servername:port}}. Note that taskd has no default port and it must be set manually.<br />
<br />
=== Running ===<br />
<br />
[[Start/enable]] {{ic|taskd.service}}.<br />
<br />
=== Adding a user in taskd ===<br />
<br />
taskd organizes data into groups and users, with each user being in a group.<br />
<br />
To add a user, run the following commands, substituting {{ic|[group]}} and {{ic|[username]}} as you wish.<br />
{{bc|<br />
# taskd add org [group]<br />
# taskd add user [group] [username]<br />
}}<br />
Note the key the last command returns, the user will need it to synchronize.<br />
<br />
Make sure new group and user are readable by user {{ic|taskd}}.<br />
{{bc|# chown -R taskd:taskd /var/lib/taskd/orgs}}<br />
<br />
Return to {{ic|/usr/share/doc/taskd/pki/}} and run {{bc|# ./generate.client username}} This will return {{ic|username.cert.pem}} and {{ic|username.key.pem}}. <br />
<br />
The {{ic|username.key.pem}}, {{ic|username.cert.pem}} and {{ic|ca.cert.pem}} must be copied into to the user's Taskwarrior user data directory (default {{ic|~/.task}}).<br />
<br />
== Client ==<br />
<br />
=== User configuration ===<br />
<br />
Once the {{ic|.pem}} files have been copied to a user's Taskwarrior data directory, their configuration must be updated to point to the files.<br />
<br />
Add the following to the {{ic|config}} file in the same directory:<br />
<br />
{{hc|/var/lib/taskd/config|<nowiki><br />
taskd.server=servername:port<br />
taskd.credentials=group/username/key<br />
taskd.certificate=~/.task/username.cert.pem<br />
taskd.key=~/.task/username.key.pem<br />
taskd.ca=~/.task/ca.cert.pem<br />
</nowiki>}}<br />
<br />
Paths are relative to the directory in which {{ic|task}} is executed, so paths should be relative to {{ic|~}} or absolute.<br />
<br />
The key in {{ic|taskd.credentials}} is the created directory in {{ic|/var/lib/taskd/orgs/group/username}}<br />
<br />
Perform the initial synchronization and consent to sending your Taskwarrior data to the server:<br />
{{bc|$ task sync init}}<br />
<br />
Send local changes to the server:<br />
{{bc|$ task sync}}<br />
<br />
=== Using the Android Taskwarrior app ===<br />
<br />
Before you even download the android app, you need to create a folder. On your external storage (or if you only have an internal one, then there) create the folder {{ic|Android/data/kvj.taskw/files/key}} where "key" is the same as the key given when creating the user with {{ic|taskd}}. Then add the {{ic|username.key.pem}}, {{ic|username.cert.pem}} and {{ic|ca.cert.pem}} files to that folder.<br />
<br />
Create a new file in that folder called {{ic|.taskrc.android}}. It should look like this:<br />
<br />
{{hc|/sdcard/Android/data/kvj.taskw/files/[uuid]/.taskrc.android|2=<br />
taskd.server=servername:port<br />
taskd.credentials=group/username/key<br />
taskd.certificate=username.cert.pem<br />
taskd.key=username.key.pem<br />
taskd.ca=ca.cert.pem<br />
}}<br />
<br />
{{Note|Ensure that the configuration file {{ic|.taskrc.android}} has a newline at the end. Otherwise, it will not be parsed correctly.}}<br />
<br />
Now download the app and start it. When prompted to add a profile, choose the data folder that you just created. Taskwarrior should now sync and work as expected.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Unreachable Server ===<br />
<br />
Should the server be unreachable but running, it bound itself to an IPv6 address. You can force IPv4 by adding {{ic|family<nowiki>=</nowiki>IPv4}} to {{ic|/var/lib/taskd/config}}.<br />
<br />
If the server stalls on "Server starting", it may be failing to resolve the address you have specified in the {{ic|server}} option. After a while the server will time out with "Name or service not known". In that case, try adding an external {{ic|/etc/hosts}} entry aliasing that address to your external IP address (see [[Domain name resolution]]),<br />
<br />
Restart taskd after attempting these, then check if your issue is fixed.<br />
<br />
=== "Bad Key" ===<br />
<br />
If the server responds with a "Bad Key" error even though you just generated them, check the permissions of the created folders (everything in {{ic|/var/lib/taskd/}} and subfolders). taskd does not set its own uid / gid, so those folders must be manually chowned to taskd.<br />
<br />
=== taskd.service fails on boot ===<br />
<br />
Taskd 1.1's systemd unit does not have the correct network target dependency so might fail at times on boot. The snippet below adds the correct dependencies, this was already fixed [https://github.com/GothenburgBitFactory/taskserver/blob/1.2.0/scripts/systemd/taskd.service upstream].<br />
<br />
{{hc|/etc/systemd/system/taskd.service.d/online.conf|<nowiki><br />
[Unit]<br />
After=<br />
Wants=network-online.target<br />
After=network-online.target<br />
<br />
[Install]<br />
WantedBy=<br />
WantedBy=network.target<br />
</nowiki>}}<br />
<br />
=== Systemd hardening ===<br />
<br />
Taskd is not sandboxed by default, the overrides below disallow taskd from writing in anything except /var/lib/taskd and /var/log/taskd.log.<br />
<br />
{{hc|/etc/systemd/system/taskd.service.d/hardening.conf|<nowiki><br />
[Service]<br />
PrivateTmp=true<br />
ProtectSystem=strict<br />
ProtectHome=true<br />
ReadWritePaths=/var/lib/taskd /var/log/taskd.log<br />
ProtectKernelTunables=true<br />
ProtectControlGroups=true<br />
ProtectHostname=true<br />
NoNewPrivileges=true<br />
MemoryDenyWriteExecute=true<br />
LockPersonality=true<br />
</nowiki>}}</div>Jellyhttps://wiki.archlinux.org/index.php?title=Taskd&diff=773222Taskd2023-03-19T10:51:52Z<p>Jelly: /* taskd.service fails on boot */ remove timer leftover...</p>
<hr />
<div>[[Category:Networking]]<br />
[[ja:Taskd]]<br />
[https://github.com/GothenburgBitFactory/taskserver taskd] is a lightweight, secure server for [[Wikipedia:Taskwarrior|Taskwarrior]] ({{Pkg|task}}). It allows users to intelligently synchronize their tasks between multiple clients, including between desktop and mobile ones.<br />
<br />
== Server ==<br />
<br />
=== Installation ===<br />
<br />
[[Install]] {{Pkg|taskd}} or {{AUR|taskd-git}} for the development version.<br />
<br />
=== Configuration ===<br />
<br />
Once taskd is installed, you need to set it up. The first step is to {{bc|$ export TASKDDATA<nowiki>=</nowiki>/var/lib/taskd }} (otherwise you need to append {{ic|--data /var/lib/taskd}} to every taskd command).<br />
<br />
Next, edit the {{ic|/usr/share/doc/taskd/pki/vars}} file. The {{ic|CN<nowiki>=</nowiki>}} line must either match the server's hostname or IP address, depending on how you connect. Once the file is edited to your heart's content, change to the directory {{ic|/usr/share/doc/taskd/pki/}} and run {{ic|./generate}}. This will create self-signed certificates for your server. Copy all generated {{ic|.pem}} to {{ic|/var/lib/taskd}}. Note that at least the {{ic|ca.cert.pem}} and {{ic|ca.key.pem}} must remain in the {{ic|pki}} folder for the user-certificate generation later on. <br />
<br />
{{Note|for {{AUR|taskd-git}}, ''/usr/share/doc/taskd'' is moved to ''/usr/lib/taskd''}}<br />
<br />
Now you need to configure taskd. Use {{ic|taskd config}} or add the following to {{ic|/var/lib/taskd/config}} directly.<br />
{{hc|/var/lib/taskd/config|<nowiki><br />
client.cert=/var/lib/taskd/client.cert.pem<br />
client.key=/var/lib/taskd/client.key.pem<br />
server.cert=/var/lib/taskd/server.cert.pem<br />
server.key=/var/lib/taskd/server.key.pem<br />
server.crl=/var/lib/taskd/server.crl.pem<br />
ca.cert=/var/lib/taskd/ca.cert.pem<br />
<br />
chown taskd:taskd ca.cert.pem ca.key.pem server.cert.pem server.crl.pem server.key.pem<br />
chmod 400 ca.cert.pem ca.key.pem server.cert.pem server.crl.pem server.key.pem<br />
</nowiki>}}<br />
<br />
Additionally you should change where taskd logs to, since the default is {{ic|/tmp/taskd.log}}. This can be done by running<br />
{{bc|# touch /var/log/taskd.log<br />
# chown taskd:taskd /var/log/taskd.log<br />
# taskd config --force log /var/log/taskd.log}}<br />
<br />
The last step is to set taskd's server name, which must be the same as the one used in the certificates: {{ic|taskd config --force server servername:port}}. Note that taskd has no default port and it must be set manually.<br />
<br />
=== Running ===<br />
<br />
[[Start/enable]] {{ic|taskd.service}}.<br />
<br />
=== Adding a user in taskd ===<br />
<br />
taskd organizes data into groups and users, with each user being in a group.<br />
<br />
To add a user, run the following commands, substituting {{ic|[group]}} and {{ic|[username]}} as you wish.<br />
{{bc|<br />
# taskd add org [group]<br />
# taskd add user [group] [username]<br />
}}<br />
Note the key the last command returns, the user will need it to synchronize.<br />
<br />
Make sure new group and user are readable by user {{ic|taskd}}.<br />
{{bc|# chown -R taskd:taskd /var/lib/taskd/orgs}}<br />
<br />
Return to {{ic|/usr/share/doc/taskd/pki/}} and run {{bc|# ./generate.client username}} This will return {{ic|username.cert.pem}} and {{ic|username.key.pem}}. <br />
<br />
The {{ic|username.key.pem}}, {{ic|username.cert.pem}} and {{ic|ca.cert.pem}} must be copied into to the user's Taskwarrior user data directory (default {{ic|~/.task}}).<br />
<br />
== Client ==<br />
<br />
=== User configuration ===<br />
<br />
Once the {{ic|.pem}} files have been copied to a user's Taskwarrior data directory, their configuration must be updated to point to the files.<br />
<br />
Add the following to the {{ic|config}} file in the same directory:<br />
<br />
{{hc|/var/lib/taskd/config|<nowiki><br />
taskd.server=servername:port<br />
taskd.credentials=group/username/key<br />
taskd.certificate=~/.task/username.cert.pem<br />
taskd.key=~/.task/username.key.pem<br />
taskd.ca=~/.task/ca.cert.pem<br />
</nowiki>}}<br />
<br />
Paths are relative to the directory in which {{ic|task}} is executed, so paths should be relative to {{ic|~}} or absolute.<br />
<br />
The key in {{ic|taskd.credentials}} is the created directory in {{ic|/var/lib/taskd/orgs/group/username}}<br />
<br />
Perform the initial synchronization and consent to sending your Taskwarrior data to the server:<br />
{{bc|$ task sync init}}<br />
<br />
Send local changes to the server:<br />
{{bc|$ task sync}}<br />
<br />
=== Using the Android Taskwarrior app ===<br />
<br />
Before you even download the android app, you need to create a folder. On your external storage (or if you only have an internal one, then there) create the folder {{ic|Android/data/kvj.taskw/files/key}} where "key" is the same as the key given when creating the user with {{ic|taskd}}. Then add the {{ic|username.key.pem}}, {{ic|username.cert.pem}} and {{ic|ca.cert.pem}} files to that folder.<br />
<br />
Create a new file in that folder called {{ic|.taskrc.android}}. It should look like this:<br />
<br />
{{hc|/sdcard/Android/data/kvj.taskw/files/[uuid]/.taskrc.android|2=<br />
taskd.server=servername:port<br />
taskd.credentials=group/username/key<br />
taskd.certificate=username.cert.pem<br />
taskd.key=username.key.pem<br />
taskd.ca=ca.cert.pem<br />
}}<br />
<br />
{{Note|Ensure that the configuration file {{ic|.taskrc.android}} has a newline at the end. Otherwise, it will not be parsed correctly.}}<br />
<br />
Now download the app and start it. When prompted to add a profile, choose the data folder that you just created. Taskwarrior should now sync and work as expected.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Unreachable Server ===<br />
<br />
Should the server be unreachable but running, it bound itself to an IPv6 address. You can force IPv4 by adding {{ic|family<nowiki>=</nowiki>IPv4}} to {{ic|/var/lib/taskd/config}}.<br />
<br />
If the server stalls on "Server starting", it may be failing to resolve the address you have specified in the {{ic|server}} option. After a while the server will time out with "Name or service not known". In that case, try adding an external {{ic|/etc/hosts}} entry aliasing that address to your external IP address (see [[Domain name resolution]]),<br />
<br />
Restart taskd after attempting these, then check if your issue is fixed.<br />
<br />
=== "Bad Key" ===<br />
<br />
If the server responds with a "Bad Key" error even though you just generated them, check the permissions of the created folders (everything in {{ic|/var/lib/taskd/}} and subfolders). taskd does not set its own uid / gid, so those folders must be manually chowned to taskd.<br />
<br />
=== taskd.service fails on boot ===<br />
<br />
Taskd 1.1's systemd unit does not have the correct network target dependency so might fail at times on boot. The snippet below adds the correct dependencies, this was already fixed [[upstream [https://github.com/GothenburgBitFactory/taskserver/blob/1.2.0/scripts/systemd/taskd.service].<br />
<br />
{{hc|/etc/systemd/system/taskd.service.d/online.conf|<nowiki><br />
[Unit]<br />
After=<br />
Wants=network-online.target<br />
After=network-online.target<br />
<br />
[Install]<br />
WantedBy=<br />
WantedBy=network.target<br />
</nowiki>}}<br />
<br />
=== Systemd hardening ===<br />
<br />
Taskd is not sandboxed by default, the overrides below disallow taskd from writing in anything except /var/lib/taskd and /var/log/taskd.log.<br />
<br />
{{hc|/etc/systemd/system/taskd.service.d/hardening.conf|<nowiki><br />
[Service]<br />
PrivateTmp=true<br />
ProtectSystem=strict<br />
ProtectHome=true<br />
ReadWritePaths=/var/lib/taskd /var/log/taskd.log<br />
ProtectKernelTunables=true<br />
ProtectControlGroups=true<br />
ProtectHostname=true<br />
NoNewPrivileges=true<br />
MemoryDenyWriteExecute=true<br />
LockPersonality=true<br />
</nowiki>}}</div>Jellyhttps://wiki.archlinux.org/index.php?title=Taskd&diff=773221Taskd2023-03-19T10:51:41Z<p>Jelly: /* taskd.service fails on boot */ formatting</p>
<hr />
<div>[[Category:Networking]]<br />
[[ja:Taskd]]<br />
[https://github.com/GothenburgBitFactory/taskserver taskd] is a lightweight, secure server for [[Wikipedia:Taskwarrior|Taskwarrior]] ({{Pkg|task}}). It allows users to intelligently synchronize their tasks between multiple clients, including between desktop and mobile ones.<br />
<br />
== Server ==<br />
<br />
=== Installation ===<br />
<br />
[[Install]] {{Pkg|taskd}} or {{AUR|taskd-git}} for the development version.<br />
<br />
=== Configuration ===<br />
<br />
Once taskd is installed, you need to set it up. The first step is to {{bc|$ export TASKDDATA<nowiki>=</nowiki>/var/lib/taskd }} (otherwise you need to append {{ic|--data /var/lib/taskd}} to every taskd command).<br />
<br />
Next, edit the {{ic|/usr/share/doc/taskd/pki/vars}} file. The {{ic|CN<nowiki>=</nowiki>}} line must either match the server's hostname or IP address, depending on how you connect. Once the file is edited to your heart's content, change to the directory {{ic|/usr/share/doc/taskd/pki/}} and run {{ic|./generate}}. This will create self-signed certificates for your server. Copy all generated {{ic|.pem}} to {{ic|/var/lib/taskd}}. Note that at least the {{ic|ca.cert.pem}} and {{ic|ca.key.pem}} must remain in the {{ic|pki}} folder for the user-certificate generation later on. <br />
<br />
{{Note|for {{AUR|taskd-git}}, ''/usr/share/doc/taskd'' is moved to ''/usr/lib/taskd''}}<br />
<br />
Now you need to configure taskd. Use {{ic|taskd config}} or add the following to {{ic|/var/lib/taskd/config}} directly.<br />
{{hc|/var/lib/taskd/config|<nowiki><br />
client.cert=/var/lib/taskd/client.cert.pem<br />
client.key=/var/lib/taskd/client.key.pem<br />
server.cert=/var/lib/taskd/server.cert.pem<br />
server.key=/var/lib/taskd/server.key.pem<br />
server.crl=/var/lib/taskd/server.crl.pem<br />
ca.cert=/var/lib/taskd/ca.cert.pem<br />
<br />
chown taskd:taskd ca.cert.pem ca.key.pem server.cert.pem server.crl.pem server.key.pem<br />
chmod 400 ca.cert.pem ca.key.pem server.cert.pem server.crl.pem server.key.pem<br />
</nowiki>}}<br />
<br />
Additionally you should change where taskd logs to, since the default is {{ic|/tmp/taskd.log}}. This can be done by running<br />
{{bc|# touch /var/log/taskd.log<br />
# chown taskd:taskd /var/log/taskd.log<br />
# taskd config --force log /var/log/taskd.log}}<br />
<br />
The last step is to set taskd's server name, which must be the same as the one used in the certificates: {{ic|taskd config --force server servername:port}}. Note that taskd has no default port and it must be set manually.<br />
<br />
=== Running ===<br />
<br />
[[Start/enable]] {{ic|taskd.service}}.<br />
<br />
=== Adding a user in taskd ===<br />
<br />
taskd organizes data into groups and users, with each user being in a group.<br />
<br />
To add a user, run the following commands, substituting {{ic|[group]}} and {{ic|[username]}} as you wish.<br />
{{bc|<br />
# taskd add org [group]<br />
# taskd add user [group] [username]<br />
}}<br />
Note the key the last command returns, the user will need it to synchronize.<br />
<br />
Make sure new group and user are readable by user {{ic|taskd}}.<br />
{{bc|# chown -R taskd:taskd /var/lib/taskd/orgs}}<br />
<br />
Return to {{ic|/usr/share/doc/taskd/pki/}} and run {{bc|# ./generate.client username}} This will return {{ic|username.cert.pem}} and {{ic|username.key.pem}}. <br />
<br />
The {{ic|username.key.pem}}, {{ic|username.cert.pem}} and {{ic|ca.cert.pem}} must be copied into to the user's Taskwarrior user data directory (default {{ic|~/.task}}).<br />
<br />
== Client ==<br />
<br />
=== User configuration ===<br />
<br />
Once the {{ic|.pem}} files have been copied to a user's Taskwarrior data directory, their configuration must be updated to point to the files.<br />
<br />
Add the following to the {{ic|config}} file in the same directory:<br />
<br />
{{hc|/var/lib/taskd/config|<nowiki><br />
taskd.server=servername:port<br />
taskd.credentials=group/username/key<br />
taskd.certificate=~/.task/username.cert.pem<br />
taskd.key=~/.task/username.key.pem<br />
taskd.ca=~/.task/ca.cert.pem<br />
</nowiki>}}<br />
<br />
Paths are relative to the directory in which {{ic|task}} is executed, so paths should be relative to {{ic|~}} or absolute.<br />
<br />
The key in {{ic|taskd.credentials}} is the created directory in {{ic|/var/lib/taskd/orgs/group/username}}<br />
<br />
Perform the initial synchronization and consent to sending your Taskwarrior data to the server:<br />
{{bc|$ task sync init}}<br />
<br />
Send local changes to the server:<br />
{{bc|$ task sync}}<br />
<br />
=== Using the Android Taskwarrior app ===<br />
<br />
Before you even download the android app, you need to create a folder. On your external storage (or if you only have an internal one, then there) create the folder {{ic|Android/data/kvj.taskw/files/key}} where "key" is the same as the key given when creating the user with {{ic|taskd}}. Then add the {{ic|username.key.pem}}, {{ic|username.cert.pem}} and {{ic|ca.cert.pem}} files to that folder.<br />
<br />
Create a new file in that folder called {{ic|.taskrc.android}}. It should look like this:<br />
<br />
{{hc|/sdcard/Android/data/kvj.taskw/files/[uuid]/.taskrc.android|2=<br />
taskd.server=servername:port<br />
taskd.credentials=group/username/key<br />
taskd.certificate=username.cert.pem<br />
taskd.key=username.key.pem<br />
taskd.ca=ca.cert.pem<br />
}}<br />
<br />
{{Note|Ensure that the configuration file {{ic|.taskrc.android}} has a newline at the end. Otherwise, it will not be parsed correctly.}}<br />
<br />
Now download the app and start it. When prompted to add a profile, choose the data folder that you just created. Taskwarrior should now sync and work as expected.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Unreachable Server ===<br />
<br />
Should the server be unreachable but running, it bound itself to an IPv6 address. You can force IPv4 by adding {{ic|family<nowiki>=</nowiki>IPv4}} to {{ic|/var/lib/taskd/config}}.<br />
<br />
If the server stalls on "Server starting", it may be failing to resolve the address you have specified in the {{ic|server}} option. After a while the server will time out with "Name or service not known". In that case, try adding an external {{ic|/etc/hosts}} entry aliasing that address to your external IP address (see [[Domain name resolution]]),<br />
<br />
Restart taskd after attempting these, then check if your issue is fixed.<br />
<br />
=== "Bad Key" ===<br />
<br />
If the server responds with a "Bad Key" error even though you just generated them, check the permissions of the created folders (everything in {{ic|/var/lib/taskd/}} and subfolders). taskd does not set its own uid / gid, so those folders must be manually chowned to taskd.<br />
<br />
=== taskd.service fails on boot ===<br />
<br />
Taskd 1.1's systemd unit does not have the correct network target dependency so might fail at times on boot. The snippet below adds the correct dependencies, this was already fixed [[upstream [https://github.com/GothenburgBitFactory/taskserver/blob/1.2.0/scripts/systemd/taskd.service].<br />
<br />
{{hc|/etc/systemd/system/taskd.service.d/online.conf|<nowiki><br />
[Unit]<br />
After=<br />
Wants=network-online.target<br />
After=network-online.target<br />
<br />
[Install]<br />
WantedBy=<br />
WantedBy=network.target<br />
</nowiki>}}<br />
<br />
Then [[disable]] {{ic|taskd.service}} and [[enable]] {{ic|taskd.timer}}<br />
<br />
=== Systemd hardening ===<br />
<br />
Taskd is not sandboxed by default, the overrides below disallow taskd from writing in anything except /var/lib/taskd and /var/log/taskd.log.<br />
<br />
{{hc|/etc/systemd/system/taskd.service.d/hardening.conf|<nowiki><br />
[Service]<br />
PrivateTmp=true<br />
ProtectSystem=strict<br />
ProtectHome=true<br />
ReadWritePaths=/var/lib/taskd /var/log/taskd.log<br />
ProtectKernelTunables=true<br />
ProtectControlGroups=true<br />
ProtectHostname=true<br />
NoNewPrivileges=true<br />
MemoryDenyWriteExecute=true<br />
LockPersonality=true<br />
</nowiki>}}</div>Jellyhttps://wiki.archlinux.org/index.php?title=Taskd&diff=773220Taskd2023-03-19T10:51:28Z<p>Jelly: Correct taskd boot failure section, a timer is the wrong solution.</p>
<hr />
<div>[[Category:Networking]]<br />
[[ja:Taskd]]<br />
[https://github.com/GothenburgBitFactory/taskserver taskd] is a lightweight, secure server for [[Wikipedia:Taskwarrior|Taskwarrior]] ({{Pkg|task}}). It allows users to intelligently synchronize their tasks between multiple clients, including between desktop and mobile ones.<br />
<br />
== Server ==<br />
<br />
=== Installation ===<br />
<br />
[[Install]] {{Pkg|taskd}} or {{AUR|taskd-git}} for the development version.<br />
<br />
=== Configuration ===<br />
<br />
Once taskd is installed, you need to set it up. The first step is to {{bc|$ export TASKDDATA<nowiki>=</nowiki>/var/lib/taskd }} (otherwise you need to append {{ic|--data /var/lib/taskd}} to every taskd command).<br />
<br />
Next, edit the {{ic|/usr/share/doc/taskd/pki/vars}} file. The {{ic|CN<nowiki>=</nowiki>}} line must either match the server's hostname or IP address, depending on how you connect. Once the file is edited to your heart's content, change to the directory {{ic|/usr/share/doc/taskd/pki/}} and run {{ic|./generate}}. This will create self-signed certificates for your server. Copy all generated {{ic|.pem}} to {{ic|/var/lib/taskd}}. Note that at least the {{ic|ca.cert.pem}} and {{ic|ca.key.pem}} must remain in the {{ic|pki}} folder for the user-certificate generation later on. <br />
<br />
{{Note|for {{AUR|taskd-git}}, ''/usr/share/doc/taskd'' is moved to ''/usr/lib/taskd''}}<br />
<br />
Now you need to configure taskd. Use {{ic|taskd config}} or add the following to {{ic|/var/lib/taskd/config}} directly.<br />
{{hc|/var/lib/taskd/config|<nowiki><br />
client.cert=/var/lib/taskd/client.cert.pem<br />
client.key=/var/lib/taskd/client.key.pem<br />
server.cert=/var/lib/taskd/server.cert.pem<br />
server.key=/var/lib/taskd/server.key.pem<br />
server.crl=/var/lib/taskd/server.crl.pem<br />
ca.cert=/var/lib/taskd/ca.cert.pem<br />
<br />
chown taskd:taskd ca.cert.pem ca.key.pem server.cert.pem server.crl.pem server.key.pem<br />
chmod 400 ca.cert.pem ca.key.pem server.cert.pem server.crl.pem server.key.pem<br />
</nowiki>}}<br />
<br />
Additionally you should change where taskd logs to, since the default is {{ic|/tmp/taskd.log}}. This can be done by running<br />
{{bc|# touch /var/log/taskd.log<br />
# chown taskd:taskd /var/log/taskd.log<br />
# taskd config --force log /var/log/taskd.log}}<br />
<br />
The last step is to set taskd's server name, which must be the same as the one used in the certificates: {{ic|taskd config --force server servername:port}}. Note that taskd has no default port and it must be set manually.<br />
<br />
=== Running ===<br />
<br />
[[Start/enable]] {{ic|taskd.service}}.<br />
<br />
=== Adding a user in taskd ===<br />
<br />
taskd organizes data into groups and users, with each user being in a group.<br />
<br />
To add a user, run the following commands, substituting {{ic|[group]}} and {{ic|[username]}} as you wish.<br />
{{bc|<br />
# taskd add org [group]<br />
# taskd add user [group] [username]<br />
}}<br />
Note the key the last command returns, the user will need it to synchronize.<br />
<br />
Make sure new group and user are readable by user {{ic|taskd}}.<br />
{{bc|# chown -R taskd:taskd /var/lib/taskd/orgs}}<br />
<br />
Return to {{ic|/usr/share/doc/taskd/pki/}} and run {{bc|# ./generate.client username}} This will return {{ic|username.cert.pem}} and {{ic|username.key.pem}}. <br />
<br />
The {{ic|username.key.pem}}, {{ic|username.cert.pem}} and {{ic|ca.cert.pem}} must be copied into to the user's Taskwarrior user data directory (default {{ic|~/.task}}).<br />
<br />
== Client ==<br />
<br />
=== User configuration ===<br />
<br />
Once the {{ic|.pem}} files have been copied to a user's Taskwarrior data directory, their configuration must be updated to point to the files.<br />
<br />
Add the following to the {{ic|config}} file in the same directory:<br />
<br />
{{hc|/var/lib/taskd/config|<nowiki><br />
taskd.server=servername:port<br />
taskd.credentials=group/username/key<br />
taskd.certificate=~/.task/username.cert.pem<br />
taskd.key=~/.task/username.key.pem<br />
taskd.ca=~/.task/ca.cert.pem<br />
</nowiki>}}<br />
<br />
Paths are relative to the directory in which {{ic|task}} is executed, so paths should be relative to {{ic|~}} or absolute.<br />
<br />
The key in {{ic|taskd.credentials}} is the created directory in {{ic|/var/lib/taskd/orgs/group/username}}<br />
<br />
Perform the initial synchronization and consent to sending your Taskwarrior data to the server:<br />
{{bc|$ task sync init}}<br />
<br />
Send local changes to the server:<br />
{{bc|$ task sync}}<br />
<br />
=== Using the Android Taskwarrior app ===<br />
<br />
Before you even download the android app, you need to create a folder. On your external storage (or if you only have an internal one, then there) create the folder {{ic|Android/data/kvj.taskw/files/key}} where "key" is the same as the key given when creating the user with {{ic|taskd}}. Then add the {{ic|username.key.pem}}, {{ic|username.cert.pem}} and {{ic|ca.cert.pem}} files to that folder.<br />
<br />
Create a new file in that folder called {{ic|.taskrc.android}}. It should look like this:<br />
<br />
{{hc|/sdcard/Android/data/kvj.taskw/files/[uuid]/.taskrc.android|2=<br />
taskd.server=servername:port<br />
taskd.credentials=group/username/key<br />
taskd.certificate=username.cert.pem<br />
taskd.key=username.key.pem<br />
taskd.ca=ca.cert.pem<br />
}}<br />
<br />
{{Note|Ensure that the configuration file {{ic|.taskrc.android}} has a newline at the end. Otherwise, it will not be parsed correctly.}}<br />
<br />
Now download the app and start it. When prompted to add a profile, choose the data folder that you just created. Taskwarrior should now sync and work as expected.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Unreachable Server ===<br />
<br />
Should the server be unreachable but running, it bound itself to an IPv6 address. You can force IPv4 by adding {{ic|family<nowiki>=</nowiki>IPv4}} to {{ic|/var/lib/taskd/config}}.<br />
<br />
If the server stalls on "Server starting", it may be failing to resolve the address you have specified in the {{ic|server}} option. After a while the server will time out with "Name or service not known". In that case, try adding an external {{ic|/etc/hosts}} entry aliasing that address to your external IP address (see [[Domain name resolution]]),<br />
<br />
Restart taskd after attempting these, then check if your issue is fixed.<br />
<br />
=== "Bad Key" ===<br />
<br />
If the server responds with a "Bad Key" error even though you just generated them, check the permissions of the created folders (everything in {{ic|/var/lib/taskd/}} and subfolders). taskd does not set its own uid / gid, so those folders must be manually chowned to taskd.<br />
<br />
=== taskd.service fails on boot ===<br />
<br />
Taskd 1.1's systemd unit does not have the correct network target dependency so might fail at times on boot. The snippet below adds the correct dependencies, this was already fixed [[upstream [https://github.com/GothenburgBitFactory/taskserver/blob/1.2.0/scripts/systemd/taskd.service].<br />
<br />
{{hc|/etc/systemd/system/taskd.service.d/online.conf|<nowiki><br />
# <br />
[Unit]<br />
After=<br />
Wants=network-online.target<br />
After=network-online.target<br />
<br />
[Install]<br />
WantedBy=<br />
WantedBy=network.target<br />
</nowiki>}}<br />
<br />
Then [[disable]] {{ic|taskd.service}} and [[enable]] {{ic|taskd.timer}}<br />
<br />
=== Systemd hardening ===<br />
<br />
Taskd is not sandboxed by default, the overrides below disallow taskd from writing in anything except /var/lib/taskd and /var/log/taskd.log.<br />
<br />
{{hc|/etc/systemd/system/taskd.service.d/hardening.conf|<nowiki><br />
[Service]<br />
PrivateTmp=true<br />
ProtectSystem=strict<br />
ProtectHome=true<br />
ReadWritePaths=/var/lib/taskd /var/log/taskd.log<br />
ProtectKernelTunables=true<br />
ProtectControlGroups=true<br />
ProtectHostname=true<br />
NoNewPrivileges=true<br />
MemoryDenyWriteExecute=true<br />
LockPersonality=true<br />
</nowiki>}}</div>Jellyhttps://wiki.archlinux.org/index.php?title=Taskd&diff=773219Taskd2023-03-19T10:43:15Z<p>Jelly: /* Systemd hardening */ explain why</p>
<hr />
<div>[[Category:Networking]]<br />
[[ja:Taskd]]<br />
[https://github.com/GothenburgBitFactory/taskserver taskd] is a lightweight, secure server for [[Wikipedia:Taskwarrior|Taskwarrior]] ({{Pkg|task}}). It allows users to intelligently synchronize their tasks between multiple clients, including between desktop and mobile ones.<br />
<br />
== Server ==<br />
<br />
=== Installation ===<br />
<br />
[[Install]] {{Pkg|taskd}} or {{AUR|taskd-git}} for the development version.<br />
<br />
=== Configuration ===<br />
<br />
Once taskd is installed, you need to set it up. The first step is to {{bc|$ export TASKDDATA<nowiki>=</nowiki>/var/lib/taskd }} (otherwise you need to append {{ic|--data /var/lib/taskd}} to every taskd command).<br />
<br />
Next, edit the {{ic|/usr/share/doc/taskd/pki/vars}} file. The {{ic|CN<nowiki>=</nowiki>}} line must either match the server's hostname or IP address, depending on how you connect. Once the file is edited to your heart's content, change to the directory {{ic|/usr/share/doc/taskd/pki/}} and run {{ic|./generate}}. This will create self-signed certificates for your server. Copy all generated {{ic|.pem}} to {{ic|/var/lib/taskd}}. Note that at least the {{ic|ca.cert.pem}} and {{ic|ca.key.pem}} must remain in the {{ic|pki}} folder for the user-certificate generation later on. <br />
<br />
{{Note|for {{AUR|taskd-git}}, ''/usr/share/doc/taskd'' is moved to ''/usr/lib/taskd''}}<br />
<br />
Now you need to configure taskd. Use {{ic|taskd config}} or add the following to {{ic|/var/lib/taskd/config}} directly.<br />
{{hc|/var/lib/taskd/config|<nowiki><br />
client.cert=/var/lib/taskd/client.cert.pem<br />
client.key=/var/lib/taskd/client.key.pem<br />
server.cert=/var/lib/taskd/server.cert.pem<br />
server.key=/var/lib/taskd/server.key.pem<br />
server.crl=/var/lib/taskd/server.crl.pem<br />
ca.cert=/var/lib/taskd/ca.cert.pem<br />
<br />
chown taskd:taskd ca.cert.pem ca.key.pem server.cert.pem server.crl.pem server.key.pem<br />
chmod 400 ca.cert.pem ca.key.pem server.cert.pem server.crl.pem server.key.pem<br />
</nowiki>}}<br />
<br />
Additionally you should change where taskd logs to, since the default is {{ic|/tmp/taskd.log}}. This can be done by running<br />
{{bc|# touch /var/log/taskd.log<br />
# chown taskd:taskd /var/log/taskd.log<br />
# taskd config --force log /var/log/taskd.log}}<br />
<br />
The last step is to set taskd's server name, which must be the same as the one used in the certificates: {{ic|taskd config --force server servername:port}}. Note that taskd has no default port and it must be set manually.<br />
<br />
=== Running ===<br />
<br />
[[Start/enable]] {{ic|taskd.service}}.<br />
<br />
=== Adding a user in taskd ===<br />
<br />
taskd organizes data into groups and users, with each user being in a group.<br />
<br />
To add a user, run the following commands, substituting {{ic|[group]}} and {{ic|[username]}} as you wish.<br />
{{bc|<br />
# taskd add org [group]<br />
# taskd add user [group] [username]<br />
}}<br />
Note the key the last command returns, the user will need it to synchronize.<br />
<br />
Make sure new group and user are readable by user {{ic|taskd}}.<br />
{{bc|# chown -R taskd:taskd /var/lib/taskd/orgs}}<br />
<br />
Return to {{ic|/usr/share/doc/taskd/pki/}} and run {{bc|# ./generate.client username}} This will return {{ic|username.cert.pem}} and {{ic|username.key.pem}}. <br />
<br />
The {{ic|username.key.pem}}, {{ic|username.cert.pem}} and {{ic|ca.cert.pem}} must be copied into to the user's Taskwarrior user data directory (default {{ic|~/.task}}).<br />
<br />
== Client ==<br />
<br />
=== User configuration ===<br />
<br />
Once the {{ic|.pem}} files have been copied to a user's Taskwarrior data directory, their configuration must be updated to point to the files.<br />
<br />
Add the following to the {{ic|config}} file in the same directory:<br />
<br />
{{hc|/var/lib/taskd/config|<nowiki><br />
taskd.server=servername:port<br />
taskd.credentials=group/username/key<br />
taskd.certificate=~/.task/username.cert.pem<br />
taskd.key=~/.task/username.key.pem<br />
taskd.ca=~/.task/ca.cert.pem<br />
</nowiki>}}<br />
<br />
Paths are relative to the directory in which {{ic|task}} is executed, so paths should be relative to {{ic|~}} or absolute.<br />
<br />
The key in {{ic|taskd.credentials}} is the created directory in {{ic|/var/lib/taskd/orgs/group/username}}<br />
<br />
Perform the initial synchronization and consent to sending your Taskwarrior data to the server:<br />
{{bc|$ task sync init}}<br />
<br />
Send local changes to the server:<br />
{{bc|$ task sync}}<br />
<br />
=== Using the Android Taskwarrior app ===<br />
<br />
Before you even download the android app, you need to create a folder. On your external storage (or if you only have an internal one, then there) create the folder {{ic|Android/data/kvj.taskw/files/key}} where "key" is the same as the key given when creating the user with {{ic|taskd}}. Then add the {{ic|username.key.pem}}, {{ic|username.cert.pem}} and {{ic|ca.cert.pem}} files to that folder.<br />
<br />
Create a new file in that folder called {{ic|.taskrc.android}}. It should look like this:<br />
<br />
{{hc|/sdcard/Android/data/kvj.taskw/files/[uuid]/.taskrc.android|2=<br />
taskd.server=servername:port<br />
taskd.credentials=group/username/key<br />
taskd.certificate=username.cert.pem<br />
taskd.key=username.key.pem<br />
taskd.ca=ca.cert.pem<br />
}}<br />
<br />
{{Note|Ensure that the configuration file {{ic|.taskrc.android}} has a newline at the end. Otherwise, it will not be parsed correctly.}}<br />
<br />
Now download the app and start it. When prompted to add a profile, choose the data folder that you just created. Taskwarrior should now sync and work as expected.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Unreachable Server ===<br />
<br />
Should the server be unreachable but running, it bound itself to an IPv6 address. You can force IPv4 by adding {{ic|family<nowiki>=</nowiki>IPv4}} to {{ic|/var/lib/taskd/config}}.<br />
<br />
If the server stalls on "Server starting", it may be failing to resolve the address you have specified in the {{ic|server}} option. After a while the server will time out with "Name or service not known". In that case, try adding an external {{ic|/etc/hosts}} entry aliasing that address to your external IP address (see [[Domain name resolution]]),<br />
<br />
Restart taskd after attempting these, then check if your issue is fixed.<br />
<br />
=== "Bad Key" ===<br />
<br />
If the server responds with a "Bad Key" error even though you just generated them, check the permissions of the created folders (everything in {{ic|/var/lib/taskd/}} and subfolders). taskd does not set its own uid / gid, so those folders must be manually chowned to taskd.<br />
<br />
=== taskd.service fails to start on boot ===<br />
<br />
In case your systemd unit for taskd fails to start on boot you can add a delay for this particular unit by adding a [[systemd timer]]:<br />
<br />
{{hc|/etc/systemd/system/taskd.timer|<nowiki><br />
[Unit]<br />
Description=Start taskd.service after fixed amount of time<br />
<br />
[Timer]<br />
OnStartupSec=10<br />
Unit=taskd.service<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
Then [[disable]] {{ic|taskd.service}} and [[enable]] {{ic|taskd.timer}}<br />
<br />
=== Systemd hardening ===<br />
<br />
Taskd is not sandboxed by default, the overrides below disallow taskd from writing in anything except /var/lib/taskd and /var/log/taskd.log.<br />
<br />
{{hc|/etc/systemd/system/taskd.service.d/hardening.conf|<nowiki><br />
[Service]<br />
PrivateTmp=true<br />
ProtectSystem=strict<br />
ProtectHome=true<br />
ReadWritePaths=/var/lib/taskd /var/log/taskd.log<br />
ProtectKernelTunables=true<br />
ProtectControlGroups=true<br />
ProtectHostname=true<br />
NoNewPrivileges=true<br />
MemoryDenyWriteExecute=true<br />
LockPersonality=true<br />
</nowiki>}}</div>Jellyhttps://wiki.archlinux.org/index.php?title=Taskd&diff=773218Taskd2023-03-19T10:30:38Z<p>Jelly: Add systemd hardening option</p>
<hr />
<div>[[Category:Networking]]<br />
[[ja:Taskd]]<br />
[https://github.com/GothenburgBitFactory/taskserver taskd] is a lightweight, secure server for [[Wikipedia:Taskwarrior|Taskwarrior]] ({{Pkg|task}}). It allows users to intelligently synchronize their tasks between multiple clients, including between desktop and mobile ones.<br />
<br />
== Server ==<br />
<br />
=== Installation ===<br />
<br />
[[Install]] {{Pkg|taskd}} or {{AUR|taskd-git}} for the development version.<br />
<br />
=== Configuration ===<br />
<br />
Once taskd is installed, you need to set it up. The first step is to {{bc|$ export TASKDDATA<nowiki>=</nowiki>/var/lib/taskd }} (otherwise you need to append {{ic|--data /var/lib/taskd}} to every taskd command).<br />
<br />
Next, edit the {{ic|/usr/share/doc/taskd/pki/vars}} file. The {{ic|CN<nowiki>=</nowiki>}} line must either match the server's hostname or IP address, depending on how you connect. Once the file is edited to your heart's content, change to the directory {{ic|/usr/share/doc/taskd/pki/}} and run {{ic|./generate}}. This will create self-signed certificates for your server. Copy all generated {{ic|.pem}} to {{ic|/var/lib/taskd}}. Note that at least the {{ic|ca.cert.pem}} and {{ic|ca.key.pem}} must remain in the {{ic|pki}} folder for the user-certificate generation later on. <br />
<br />
{{Note|for {{AUR|taskd-git}}, ''/usr/share/doc/taskd'' is moved to ''/usr/lib/taskd''}}<br />
<br />
Now you need to configure taskd. Use {{ic|taskd config}} or add the following to {{ic|/var/lib/taskd/config}} directly.<br />
{{hc|/var/lib/taskd/config|<nowiki><br />
client.cert=/var/lib/taskd/client.cert.pem<br />
client.key=/var/lib/taskd/client.key.pem<br />
server.cert=/var/lib/taskd/server.cert.pem<br />
server.key=/var/lib/taskd/server.key.pem<br />
server.crl=/var/lib/taskd/server.crl.pem<br />
ca.cert=/var/lib/taskd/ca.cert.pem<br />
<br />
chown taskd:taskd ca.cert.pem ca.key.pem server.cert.pem server.crl.pem server.key.pem<br />
chmod 400 ca.cert.pem ca.key.pem server.cert.pem server.crl.pem server.key.pem<br />
</nowiki>}}<br />
<br />
Additionally you should change where taskd logs to, since the default is {{ic|/tmp/taskd.log}}. This can be done by running<br />
{{bc|# touch /var/log/taskd.log<br />
# chown taskd:taskd /var/log/taskd.log<br />
# taskd config --force log /var/log/taskd.log}}<br />
<br />
The last step is to set taskd's server name, which must be the same as the one used in the certificates: {{ic|taskd config --force server servername:port}}. Note that taskd has no default port and it must be set manually.<br />
<br />
=== Running ===<br />
<br />
[[Start/enable]] {{ic|taskd.service}}.<br />
<br />
=== Adding a user in taskd ===<br />
<br />
taskd organizes data into groups and users, with each user being in a group.<br />
<br />
To add a user, run the following commands, substituting {{ic|[group]}} and {{ic|[username]}} as you wish.<br />
{{bc|<br />
# taskd add org [group]<br />
# taskd add user [group] [username]<br />
}}<br />
Note the key the last command returns, the user will need it to synchronize.<br />
<br />
Make sure new group and user are readable by user {{ic|taskd}}.<br />
{{bc|# chown -R taskd:taskd /var/lib/taskd/orgs}}<br />
<br />
Return to {{ic|/usr/share/doc/taskd/pki/}} and run {{bc|# ./generate.client username}} This will return {{ic|username.cert.pem}} and {{ic|username.key.pem}}. <br />
<br />
The {{ic|username.key.pem}}, {{ic|username.cert.pem}} and {{ic|ca.cert.pem}} must be copied into to the user's Taskwarrior user data directory (default {{ic|~/.task}}).<br />
<br />
== Client ==<br />
<br />
=== User configuration ===<br />
<br />
Once the {{ic|.pem}} files have been copied to a user's Taskwarrior data directory, their configuration must be updated to point to the files.<br />
<br />
Add the following to the {{ic|config}} file in the same directory:<br />
<br />
{{hc|/var/lib/taskd/config|<nowiki><br />
taskd.server=servername:port<br />
taskd.credentials=group/username/key<br />
taskd.certificate=~/.task/username.cert.pem<br />
taskd.key=~/.task/username.key.pem<br />
taskd.ca=~/.task/ca.cert.pem<br />
</nowiki>}}<br />
<br />
Paths are relative to the directory in which {{ic|task}} is executed, so paths should be relative to {{ic|~}} or absolute.<br />
<br />
The key in {{ic|taskd.credentials}} is the created directory in {{ic|/var/lib/taskd/orgs/group/username}}<br />
<br />
Perform the initial synchronization and consent to sending your Taskwarrior data to the server:<br />
{{bc|$ task sync init}}<br />
<br />
Send local changes to the server:<br />
{{bc|$ task sync}}<br />
<br />
=== Using the Android Taskwarrior app ===<br />
<br />
Before you even download the android app, you need to create a folder. On your external storage (or if you only have an internal one, then there) create the folder {{ic|Android/data/kvj.taskw/files/key}} where "key" is the same as the key given when creating the user with {{ic|taskd}}. Then add the {{ic|username.key.pem}}, {{ic|username.cert.pem}} and {{ic|ca.cert.pem}} files to that folder.<br />
<br />
Create a new file in that folder called {{ic|.taskrc.android}}. It should look like this:<br />
<br />
{{hc|/sdcard/Android/data/kvj.taskw/files/[uuid]/.taskrc.android|2=<br />
taskd.server=servername:port<br />
taskd.credentials=group/username/key<br />
taskd.certificate=username.cert.pem<br />
taskd.key=username.key.pem<br />
taskd.ca=ca.cert.pem<br />
}}<br />
<br />
{{Note|Ensure that the configuration file {{ic|.taskrc.android}} has a newline at the end. Otherwise, it will not be parsed correctly.}}<br />
<br />
Now download the app and start it. When prompted to add a profile, choose the data folder that you just created. Taskwarrior should now sync and work as expected.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Unreachable Server ===<br />
<br />
Should the server be unreachable but running, it bound itself to an IPv6 address. You can force IPv4 by adding {{ic|family<nowiki>=</nowiki>IPv4}} to {{ic|/var/lib/taskd/config}}.<br />
<br />
If the server stalls on "Server starting", it may be failing to resolve the address you have specified in the {{ic|server}} option. After a while the server will time out with "Name or service not known". In that case, try adding an external {{ic|/etc/hosts}} entry aliasing that address to your external IP address (see [[Domain name resolution]]),<br />
<br />
Restart taskd after attempting these, then check if your issue is fixed.<br />
<br />
=== "Bad Key" ===<br />
<br />
If the server responds with a "Bad Key" error even though you just generated them, check the permissions of the created folders (everything in {{ic|/var/lib/taskd/}} and subfolders). taskd does not set its own uid / gid, so those folders must be manually chowned to taskd.<br />
<br />
=== taskd.service fails to start on boot ===<br />
<br />
In case your systemd unit for taskd fails to start on boot you can add a delay for this particular unit by adding a [[systemd timer]]:<br />
<br />
{{hc|/etc/systemd/system/taskd.timer|<nowiki><br />
[Unit]<br />
Description=Start taskd.service after fixed amount of time<br />
<br />
[Timer]<br />
OnStartupSec=10<br />
Unit=taskd.service<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
Then [[disable]] {{ic|taskd.service}} and [[enable]] {{ic|taskd.timer}}<br />
<br />
=== Systemd hardening ===<br />
<br />
{{hc|/etc/systemd/system/taskd.service.d/override.conf|<nowiki><br />
[Service]<br />
PrivateTmp=true<br />
ProtectSystem=strict<br />
ProtectHome=true<br />
ReadWritePaths=/var/lib/taskd /var/log/taskd.log<br />
ProtectKernelTunables=true<br />
ProtectControlGroups=true<br />
ProtectHostname=true<br />
NoNewPrivileges=true<br />
MemoryDenyWriteExecute=true<br />
LockPersonality=true<br />
</nowiki>}}</div>Jellyhttps://wiki.archlinux.org/index.php?title=Taskd&diff=773217Taskd2023-03-19T10:21:07Z<p>Jelly: /* User configuration */ explain what the key is</p>
<hr />
<div>[[Category:Networking]]<br />
[[ja:Taskd]]<br />
[https://github.com/GothenburgBitFactory/taskserver taskd] is a lightweight, secure server for [[Wikipedia:Taskwarrior|Taskwarrior]] ({{Pkg|task}}). It allows users to intelligently synchronize their tasks between multiple clients, including between desktop and mobile ones.<br />
<br />
== Server ==<br />
<br />
=== Installation ===<br />
<br />
[[Install]] {{Pkg|taskd}} or {{AUR|taskd-git}} for the development version.<br />
<br />
=== Configuration ===<br />
<br />
Once taskd is installed, you need to set it up. The first step is to {{bc|$ export TASKDDATA<nowiki>=</nowiki>/var/lib/taskd }} (otherwise you need to append {{ic|--data /var/lib/taskd}} to every taskd command).<br />
<br />
Next, edit the {{ic|/usr/share/doc/taskd/pki/vars}} file. The {{ic|CN<nowiki>=</nowiki>}} line must either match the server's hostname or IP address, depending on how you connect. Once the file is edited to your heart's content, change to the directory {{ic|/usr/share/doc/taskd/pki/}} and run {{ic|./generate}}. This will create self-signed certificates for your server. Copy all generated {{ic|.pem}} to {{ic|/var/lib/taskd}}. Note that at least the {{ic|ca.cert.pem}} and {{ic|ca.key.pem}} must remain in the {{ic|pki}} folder for the user-certificate generation later on. <br />
<br />
{{Note|for {{AUR|taskd-git}}, ''/usr/share/doc/taskd'' is moved to ''/usr/lib/taskd''}}<br />
<br />
Now you need to configure taskd. Use {{ic|taskd config}} or add the following to {{ic|/var/lib/taskd/config}} directly.<br />
{{hc|/var/lib/taskd/config|<nowiki><br />
client.cert=/var/lib/taskd/client.cert.pem<br />
client.key=/var/lib/taskd/client.key.pem<br />
server.cert=/var/lib/taskd/server.cert.pem<br />
server.key=/var/lib/taskd/server.key.pem<br />
server.crl=/var/lib/taskd/server.crl.pem<br />
ca.cert=/var/lib/taskd/ca.cert.pem<br />
<br />
chown taskd:taskd ca.cert.pem ca.key.pem server.cert.pem server.crl.pem server.key.pem<br />
chmod 400 ca.cert.pem ca.key.pem server.cert.pem server.crl.pem server.key.pem<br />
</nowiki>}}<br />
<br />
Additionally you should change where taskd logs to, since the default is {{ic|/tmp/taskd.log}}. This can be done by running<br />
{{bc|# touch /var/log/taskd.log<br />
# chown taskd:taskd /var/log/taskd.log<br />
# taskd config --force log /var/log/taskd.log}}<br />
<br />
The last step is to set taskd's server name, which must be the same as the one used in the certificates: {{ic|taskd config --force server servername:port}}. Note that taskd has no default port and it must be set manually.<br />
<br />
=== Running ===<br />
<br />
[[Start/enable]] {{ic|taskd.service}}.<br />
<br />
=== Adding a user in taskd ===<br />
<br />
taskd organizes data into groups and users, with each user being in a group.<br />
<br />
To add a user, run the following commands, substituting {{ic|[group]}} and {{ic|[username]}} as you wish.<br />
{{bc|<br />
# taskd add org [group]<br />
# taskd add user [group] [username]<br />
}}<br />
Note the key the last command returns, the user will need it to synchronize.<br />
<br />
Make sure new group and user are readable by user {{ic|taskd}}.<br />
{{bc|# chown -R taskd:taskd /var/lib/taskd/orgs}}<br />
<br />
Return to {{ic|/usr/share/doc/taskd/pki/}} and run {{bc|# ./generate.client username}} This will return {{ic|username.cert.pem}} and {{ic|username.key.pem}}. <br />
<br />
The {{ic|username.key.pem}}, {{ic|username.cert.pem}} and {{ic|ca.cert.pem}} must be copied into to the user's Taskwarrior user data directory (default {{ic|~/.task}}).<br />
<br />
== Client ==<br />
<br />
=== User configuration ===<br />
<br />
Once the {{ic|.pem}} files have been copied to a user's Taskwarrior data directory, their configuration must be updated to point to the files.<br />
<br />
Add the following to the {{ic|config}} file in the same directory:<br />
<br />
{{hc|/var/lib/taskd/config|<nowiki><br />
taskd.server=servername:port<br />
taskd.credentials=group/username/key<br />
taskd.certificate=~/.task/username.cert.pem<br />
taskd.key=~/.task/username.key.pem<br />
taskd.ca=~/.task/ca.cert.pem<br />
</nowiki>}}<br />
<br />
Paths are relative to the directory in which {{ic|task}} is executed, so paths should be relative to {{ic|~}} or absolute.<br />
<br />
The key in {{ic|taskd.credentials}} is the created directory in {{ic|/var/lib/taskd/orgs/group/username}}<br />
<br />
Perform the initial synchronization and consent to sending your Taskwarrior data to the server:<br />
{{bc|$ task sync init}}<br />
<br />
Send local changes to the server:<br />
{{bc|$ task sync}}<br />
<br />
=== Using the Android Taskwarrior app ===<br />
<br />
Before you even download the android app, you need to create a folder. On your external storage (or if you only have an internal one, then there) create the folder {{ic|Android/data/kvj.taskw/files/key}} where "key" is the same as the key given when creating the user with {{ic|taskd}}. Then add the {{ic|username.key.pem}}, {{ic|username.cert.pem}} and {{ic|ca.cert.pem}} files to that folder.<br />
<br />
Create a new file in that folder called {{ic|.taskrc.android}}. It should look like this:<br />
<br />
{{hc|/sdcard/Android/data/kvj.taskw/files/[uuid]/.taskrc.android|2=<br />
taskd.server=servername:port<br />
taskd.credentials=group/username/key<br />
taskd.certificate=username.cert.pem<br />
taskd.key=username.key.pem<br />
taskd.ca=ca.cert.pem<br />
}}<br />
<br />
{{Note|Ensure that the configuration file {{ic|.taskrc.android}} has a newline at the end. Otherwise, it will not be parsed correctly.}}<br />
<br />
Now download the app and start it. When prompted to add a profile, choose the data folder that you just created. Taskwarrior should now sync and work as expected.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Unreachable Server ===<br />
<br />
Should the server be unreachable but running, it bound itself to an IPv6 address. You can force IPv4 by adding {{ic|family<nowiki>=</nowiki>IPv4}} to {{ic|/var/lib/taskd/config}}.<br />
<br />
If the server stalls on "Server starting", it may be failing to resolve the address you have specified in the {{ic|server}} option. After a while the server will time out with "Name or service not known". In that case, try adding an external {{ic|/etc/hosts}} entry aliasing that address to your external IP address (see [[Domain name resolution]]),<br />
<br />
Restart taskd after attempting these, then check if your issue is fixed.<br />
<br />
=== "Bad Key" ===<br />
<br />
If the server responds with a "Bad Key" error even though you just generated them, check the permissions of the created folders (everything in {{ic|/var/lib/taskd/}} and subfolders). taskd does not set its own uid / gid, so those folders must be manually chowned to taskd.<br />
<br />
=== taskd.service fails to start on boot ===<br />
<br />
In case your systemd unit for taskd fails to start on boot you can add a delay for this particular unit by adding a [[systemd timer]]:<br />
<br />
{{hc|/etc/systemd/system/taskd.timer|<nowiki><br />
[Unit]<br />
Description=Start taskd.service after fixed amount of time<br />
<br />
[Timer]<br />
OnStartupSec=10<br />
Unit=taskd.service<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
Then [[disable]] {{ic|taskd.service}} and [[enable]] {{ic|taskd.timer}}</div>Jellyhttps://wiki.archlinux.org/index.php?title=User:Jelly&diff=725974User:Jelly2022-04-09T16:01:42Z<p>Jelly: </p>
<hr />
<div>== Arch projects ==<br />
<br />
* Testing ansible setup (how to deploy without secrets)<br />
* Auto-rebuild service for todolists and rebuilds. Investigate with foutrelis what needs to be done.</div>Jellyhttps://wiki.archlinux.org/index.php?title=Python_package_guidelines&diff=723987Python package guidelines2022-03-22T19:43:36Z<p>Jelly: Document the common setuptools-scm workaround</p>
<hr />
<div>[[Category:Arch package guidelines]]<br />
[[ja:Python パッケージガイドライン]]<br />
[[pt:Python package guidelines]]<br />
[[zh-hans:Python package guidelines]]<br />
{{Package guidelines}}<br />
This document covers standards and guidelines on writing [[PKGBUILD]]s for [[Python]] software.<br />
<br />
== Package naming ==<br />
<br />
For [[Python#Python 3|Python 3]] library modules, use {{ic|python-''modulename''}}. Also use the prefix if the package provides a program that is strongly coupled to the Python ecosystem (e.g. ''pip'' or ''tox''). For other applications, use only the program name.<br />
<br />
The same applies to Python 2 except that the prefix (if needed) is {{Ic|python2-}}.<br />
<br />
{{Note|The package name should be entirely lowercase.}}<br />
<br />
== Architecture ==<br />
<br />
See [[PKGBUILD#arch]].<br />
<br />
A Python package that contains C extensions is architecture-dependent. Otherwise it is most likely architecture-independent.<br />
<br />
Packages built using [https://setuptools.pypa.io/ setuptools] define their C extensions using the {{ic|ext_modules}} keyword in {{ic|setup.py}}.<br />
<br />
== Source ==<br />
<br />
Download URLs linked from the PyPI website include an unpredictable hash that needs to be fetched from the PyPI website each time a package must be updated. This makes them unsuitable for use in a PKGBUILD. PyPI [https://github.com/pypa/pypi-legacy/issues/438#issuecomment-226940730 provides] an alternative stable scheme: [[PKGBUILD#source]] {{ic|1=source=()}} array should use the following URL templates:<br />
<br />
;Source package:<br />
:{{ic|<nowiki>https://files.pythonhosted.org/packages/source/${_name::1}/$_name/$_name-$pkgver.tar.gz</nowiki>}}<br />
;Pure Python wheel package<br />
:{{ic|<nowiki>https://files.pythonhosted.org/packages/py2.py3/${_name::1}/$_name/${_name//-/_}-$pkgver-py2.py3-none-any.whl</nowiki>}} (Bilingual – Python 2 and Python 3 compatible)<br />
:{{ic|<nowiki>https://files.pythonhosted.org/packages/py3/${_name::1}/$_name/${_name//-/_}-$pkgver-py3-none-any.whl</nowiki>}} (Python 3 only)<br />
:Note that the distribution name can contain dashes, while its representation in a wheel filename cannot (they are converted to underscores).<br />
;Arch specific wheel package<br />
:in this example for {{ic|1=source_x86_64=('...')}}. Also {{ic|1=_py=cp310}} can be used to not repeat the python version:<br />
:{{ic|<nowiki>https://files.pythonhosted.org/packages/$_py/${_name::1}/$_name/${_name//-/_}-$pkgver-$_py-${_py}m-manylinux1_x86_64.whl</nowiki>}}<br />
<br />
Note that a custom {{ic|'''_name'''}} variable is used instead of {{ic|pkgname}} since python packages are generally prefixed with {{ic|python-}}. This variable can generically be defined as follows:<br />
<br />
_name=${pkgname#python-}<br />
<br />
== Installation methods ==<br />
<br />
Python packages are generally installed using language-specific package manager such as [https://pip.pypa.io/ pip], which fetches packages from an online respository (usually [https://pypi.org/ PyPI], the Python Package Index) and tracks the relevant files.<br />
<br />
However, for managing Python packages from within {{ic|PKGBUILD}}s, One needs to "install" the python package to the temporary location {{ic|''$pkgdir''/usr/lib/python''<python version>''/site-packages/''$pkgname''}}.<br />
<br />
For Python packages using [https://www.python.org/dev/peps/pep-0517/ standard metadata] to specify their build backend in {{ic|pyproject.toml}}, this can most easily achieved using {{pkg|python-build}} and {{pkg|python-installer}}.<br />
Old packages might fail to specify that they use setuptools, and only offer a {{ic|setup.py}} that has to be invoked manually.<br />
<br />
{{Note|Dependencies from the package's metadata must be defined in the {{ic|depends}} array otherwise they will not be installed.}}<br />
<br />
=== Standards based (PEP 517) ===<br />
<br />
A standards based workflow is straightforward: Build a wheel using {{pkg|python-build}} and install it to {{ic|$pkgdir}} using {{pkg|python-installer}}:<br />
<br />
{{bc|1=<br />
makedepends=(python-build python-installer)<br />
<br />
build() {<br />
''python'' -m build --wheel --no-isolation<br />
}<br />
<br />
package() {<br />
''python'' -m installer --destdir="$pkgdir" dist/*.whl<br />
}<br />
}}<br />
<br />
where<br />
<br />
* {{ic|1=--wheel}} results in only a wheel file to be built, no source distribution.<br />
* {{ic|1=--no-isolation}} means that the package is built using what is installed on your system (which includes packages you specified in {{ic|depends}}), by default the tool creates an isolated virtual environment and performs the build there.<br />
* {{ic|1=--destdir="$pkgdir"}} prevents trying to directly install in the host system instead of inside the package file, which would result in a permission error<br />
* {{ic|1=--compile-bytecode=...}} or {{ic|1=--no-compile-bytecode}} can be passed to {{ic|installer}}, but the default is sensibly picked, so this should not be necessary.<br />
<br />
{{Warning|Skipping {{ic|build}} and putting the {{ic|.whl}} file in your {{ic|source}} array is discouraged in favor of building from source, and should only be used when the latter is not a viable option (for example, packages which '''only''' come with wheel sources, and therefore cannot be built from source).}}<br />
<br />
=== setuptools or distutils ===<br />
<br />
If no {{ic|pyproject.toml}} can be found or it fails to contain a {{ic|[build-system]}} table, it means the project is using the old legacy format, which uses a ''setup.py'' file which invokes ''setuptools'' or ''distutils''. Note that while ''distutils'' is included in Python's standardlib, having ''setuptools'' installed means that you use a patched version of ''distutils''.<br />
<br />
{{bc|1=<br />
makedepends=('python-setuptools') # unless it only requires distutils<br />
<br />
build() {<br />
''python'' setup.py build<br />
}<br />
<br />
package() {<br />
''python'' setup.py install --root="$pkgdir" --optimize=1<br />
}<br />
}}<br />
<br />
where:<br />
<br />
* {{ic|1=--root="$pkgdir"}} works like {{ic|1=--destdir}} above<br />
* {{ic|1=--optimize=1}} compiles optimized bytecode files (''.pyo'' for Python 2, ''.opt-1.pyc'' for Python 3) so they can be tracked by [[pacman]] instead of being created on the host system on demand.<br />
* Adding {{ic|1=--skip-build}} optimizes away the unnecessary attempt to re-run the build steps already run in the {{ic|build()}} function, if that is the case.<br />
<br />
If the resulting package includes executables which [https://setuptools.readthedocs.io/en/latest/setuptools.html#automatic-script-creation import the ''deprecated'' pkg_resources module], then ''setuptools'' must be additionally specified as a {{ic|depends}} in the split {{ic|package_*()}} functions; alternatively, if the PKGBUILD only installs the Python package for a single version of Python, ''setuptools'' should be moved from {{ic|makedepends}} to {{ic|depends}}.<br />
<br />
Some packages try to use ''setuptools'' and fall back to ''distutils'' if ''setuptools'' could not be imported. In this case, setuptools should be added as a {{ic|makedepends}}, so that the resulting python metadata is better.<br />
<br />
If a package needs ''setuptools'' to build due to including executables (which is not supported by ''distutils''), but only imports ''distutils'', then building will raise a warning, and the resulting package will be broken (it will not contain the executables):<br />
<br />
{{bc|1=<br />
/usr/lib/python3.8/distutils/dist.py:274: UserWarning: Unknown distribution option: 'entry_points'<br />
warnings.warn(msg)<br />
}}<br />
<br />
An upstream bug should be reported. To work around the problem, an undocumented setuptools feature can be used:<br />
<br />
{{bc|1=<br />
# fails because of distutils<br />
python setup.py build<br />
<br />
# works by using a setuptools shim<br />
python -m setuptools.launch setup.py build<br />
}}<br />
<br />
If a package uses ''setuptools-scm'' the package most likely won't build with an error such as:<br />
<br />
{{bc|1=<br />
LookupError: setuptools-scm was unable to detect version for /build/python-jsonschema/src/jsonschema-3.2.0.<br />
<br />
Make sure you're either building from a fully intact git repository or PyPI tarballs. Most other sources (such as GitHub's tarballs, a git checkout without the .git folder) don't contain the necessary metadata and will not work.<br />
}}<br />
<br />
To get it building {{ic|SETUPTOOLS_SCM_PRETEND_VERSION}} has to be exported as env variable with ''$pkgver'' as value:<br />
<br />
{{bc|1=<br />
export SETUPTOOLS_SCM_PRETEND_VERSION=$pkgver<br />
}}<br />
<br />
== Check ==<br />
<br />
{{Warning|Avoid using {{ic|tox}} to run testsuites as it is explicitly designed to test repeatable configurations downloaded from PyPI while {{ic|tox}} is running, and does '''not''' test the version that will be installed by the package. This defeats the purpose of having a ''check'' function at all.}}<br />
<br />
Most python projects providing a testsuite use nosetests or pytest to run tests with {{ic|test}} in the name of the file or directory containing the testsuite. In general, simply running {{ic|nosetests}} or {{ic|pytest}} is enough to run the testsuite.<br />
<br />
{{bc|<br />
check(){<br />
cd "$srcdir/foo-$pkgver"<br />
<br />
# For nosetests<br />
nosetests<br />
<br />
# For pytest<br />
pytest<br />
}<br />
}}<br />
<br />
If there is a compiled C extension, the tests need to be run using a {{ic|$PYTHONPATH}}, that reflects the current major and minor version of Python in order to find and load it.<br />
<br />
{{bc|1=<br />
check(){<br />
cd "$pkgname-$pkgver"<br />
local python_version=$(python -c 'import sys; print(".".join(map(str, sys.version_info[:2])))')<br />
# For nosetests<br />
PYTHONPATH="$PWD/build/lib.linux-$CARCH-${python_version}" nosetests<br />
<br />
# For pytest<br />
PYTHONPATH="$PWD/build/lib.linux-$CARCH-${python_version}" pytest<br />
}<br />
}}<br />
<br />
Some projects provide {{ic|setup.py}} entry points for running the test. This works for both {{ic|pytest}} and {{ic|nosetests}}.<br />
<br />
{{bc|<br />
check(){<br />
cd "$srcdir/foo-$pkgver"<br />
<br />
# For nosetests<br />
python setup.py nosetests<br />
<br />
# For pytest - needs python-pytest-runner<br />
python setup.py pytest<br />
}<br />
}}<br />
<br />
== Tips and tricks ==<br />
<br />
=== Discovering detached PGP signatures on PyPI ===<br />
<br />
If detached PGP signatures for a given Python sdist tarball exist, they should be used to verify the tarball. However, the signature files do not show up directly in the files download section of any given project on pypi.org. To discover the sdist tarballs and their potential signature files, it is possible to use this service to get an overview per project: https://pypi.debian.net/<br />
<br />
For {{Pkg|python-requests}}, this would be https://pypi.debian.net/requests.<br />
<br />
=== Using site-packages ===<br />
<br />
Sometimes during building, testing or installation it is required to refer to the system's {{ic|site-packages}} directory. To not hardcode the directory, use a call to the system Python version to retrieve the path and store it in a local variable:<br />
<br />
{{bc|1=<br />
check(){<br />
cd "$pkgname-$pkgver"<br />
local site_packages=$(python -c "import site; print(site.getsitepackages()[0])")<br />
...<br />
}<br />
}}<br />
<br />
=== Test directory in site-package ===<br />
<br />
Make sure to not install a directory named just {{ic|tests}} into {{ic|site-packages}} (e.g. {{ic|/usr/lib/python2.7/site-packages/tests/}}), as it easily conflicts with other Python packages.</div>Jellyhttps://wiki.archlinux.org/index.php?title=User_talk:Nl6720&diff=707269User talk:Nl67202021-12-23T12:01:11Z<p>Jelly: PLS</p>
<hr />
<div>__NOINDEX__{{Lowercase title}}<br />
<br />
== <s>Linking a category</s> ==<br />
<br />
Regarding [https://wiki.archlinux.org/index.php?title=GUID_Partition_Table&curid=9539&diff=447822&oldid=447821], you can use a colon to link categories:<br />
{{Merge|:Category:Boot loaders|foo bar}}<br />
See: [[mw:Help:Categories#Linking_to_a_category]] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:50, 25 August 2016 (UTC)<br />
<br />
:Thanks! --&#160;[[User:nl6720|<span style="font-family:serif; font-weight:bold; color:#800080;">nl6720</span>]]&#8239;[[User talk:nl6720|<span style="color:#808080; vertical-align:super; font-size:smaller; font-weight:lighter;">talk</span>]] 12:57, 25 August 2016 (UTC)<br />
<br />
== <s>Email address</s> ==<br />
<br />
Hey Nl6720,<br />
<br />
You've [[Special:EmailUser/Nl6720|disabled]] email from other users, but I'd like to send you a private message. If interested, would you mind contacting me on {{ic|alad <at> archlinux <dot> info}} (address in [[ArchWiki:Administrators]])?<br />
<br />
Cheers -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:50, 2 October 2016 (UTC)<br />
<br />
:I re-enabled email from other users. --&#160;[[User:nl6720|<span style="font-family:serif; font-weight:bold; color:#800080;">nl6720</span>]]&#8239;[[User talk:nl6720|<span style="color:#808080; vertical-align:super; font-size:smaller; font-weight:lighter;">talk</span>]] 13:54, 2 October 2016 (UTC)<br />
== <s>Clarification for: [https://wiki.archlinux.org/index.php?title=Zsh&diff=next&oldid=452490 The content seems questionable too, but I know nothing about these frameworks]</s> ==<br />
<br />
It's a problem I met, for which I couldn't find a solution with googling, so I had to retreat to asking at IRC. In short, it's that the default Archlinux config shipped somewhere in /etc/ overwrites variables for runtime, i.e. one can't even overwrite them manually. I thought it would be useful to many others. Probably, it may cause problems not only with "oh-my-zsh", but I decided to put info in that paragraph because I'm not sure if there is a better place.<br />
<br />
And sorry for html formatting, markup is pretty unusual, and [https://wiki.archlinux.org/index.php/Help:Style/Formatting_and_punctuation the formatting page] is surprisingly unhelpful. I.e. how to write a link I figured out only because I thought, perhaps wikipedia.org using the same markup formatting; which turned out to be right. [[User:Hi-Angel|Hi-Angel]] ([[User talk:Hi-Angel|talk]]) 10:23, 6 October 2016 (UTC)<br />
<br />
:User's files are sourced after their system-wide counterparts (i.e. {{ic|~/.zshrc}} is sourced after {{ic|/etc/zsh/zshrc}}), so things set in {{ic|~/.zshrc}} should ''normally'' not be undone by {{ic|/etc/zsh/zshrc}}. But I guess it's possible for {{ic|/etc/zsh/zshrc}} to define a function that changes {{ic|$PROMPT}} under certain conditions. I probably shouldn't have called the content questionable.<br />
:About formatting, start with [[Help:Editing]] then [[Help:Style]], [[Help:Style/Formatting and punctuation]] and [[Help:Style/White space]]. There is also [[Help:Cheatsheet]]. --&#160;[[User:nl6720|<span style="font-family:serif; font-weight:bold; color:#800080;">nl6720</span>]]&#8239;[[User talk:nl6720|<span style="color:#808080; vertical-align:super; font-size:smaller; font-weight:lighter;">talk</span>]] 10:48, 6 October 2016 (UTC)<br />
<br />
== <s>GRUB UEFI install</s> ==<br />
We were amending the page at the same time, can you review my latest change to see if it is consistent with your definition of esp? -- [[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 13:04, 5 March 2018 (UTC)<br />
<br />
:Looks good to me. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 14:35, 5 March 2018 (UTC)<br />
<br />
== <s>rEFInd</s> ==<br />
[[User:nl6720|nl6720]] rEFInd is able to:<br />
* auto-detect the kernels if the file system drivers are there<br />
* launch the last one booted - for this to work it needs to list all unfolded<br />
so the following minimal configuration works:<br />
# cp /usr/share/refind/refind_x64.efi /esp/EFI/Boot/bootx64.efi<br />
# cp -r /usr/share/refind/drivers_x64/ /esp/EFI/Boot/<br />
# echo 'extra_kernel_version_strings linux,linux-lts,linux-git;' > /esp/EFI/Boot/refind.conf<br />
# echo 'fold_linux_kernels false' >> /esp/EFI/Boot/refind.conf<br />
<br />
rod smith was so kind to add the "extra_kernel_version_strings" option end of 2017 so rEFInd could handle the kernel naming conventions in arch. and with it, rEFInds problem of finding the correct fallback image was fixed, and the necessity to provide a configuration. there is no editing of a file necessary, no additional boot parameters, no tinkering with nvram, etc. currently i find really hard to detect out of the description that this works. i am inclined to break up the text slightly different - not focussing on "manual" and "scripted", and "configuration" but more in "install into EFI default location", "install in rEFInd location", "secure boot". currently the section "scripted" contains secure boot, shim, editing files. what you think? --[[User:Soloturn|Soloturn]] ([[User talk:Soloturn|talk]]) 03:40, 14 March 2018 (UTC)<br />
<br />
:The first sentence of the section mentions the {{ic|refind-install}} script so it should be obvious that the whole section is about using the script. Just in case I've now [[Special:Diff/513615|renamed]] the section to avoid any confusion. Secure boot is under the "Scripted installation" section because {{ic|refind-install}} provides a way to automate installation on Secure Boot enabled systems. I'll repeat, the whole section is about {{ic|refind-install}} and its provided options.<br />
:{{ic|extra_kernel_version_strings}} was added to support multiple kernels without version numbers in their filenames, unless I've missed something rEFInd still doesn't support automatically detecting and matching '''fallback''' initramfs images with their respective kernels.<br />
:I've removed your "minimal configuration" because it mixed installation (i.e. getting rEFInd binary to the ESP) and configuration (editing {{ic|refind.conf}}), those sections are split for a good reason. Before drastically changing an article, you '''must''' first discuss it in the article talk page ([[Talk:REFInd]] in this case), please read [[ArchWiki:Contributing#Announce article rewrites in a talk page]]. Also I would not accept adding {{ic|echo 'extra_kernel_version_strings linux,linux-lts,linux-git;' > /esp/EFI/Boot/refind.conf}} to [[rEFInd]], the {{ic|/usr/share/refind/refind.conf-sample}} file has a lot of comments explaining its content, it's more useful to copy the sample and edit it. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:20, 14 March 2018 (UTC)<br />
ok, will try. i had enough difficulties with boot loader installation. so much that i took the time to address it with the software itself, and the wiki page. i even asked rod if he would be able to adjust refind a little to make it configuration-less. but he thought using the 2 lines are appropriately minimal - and no editing of a config file would be necessary. while coding arch kernel names into rEFInd would be a bad idea. --[[User:Soloturn|Soloturn]] ([[User talk:Soloturn|talk]]) 06:18, 19 March 2018 (UTC)<br />
<br />
:Closing. Any further discussion will be in [[Talk:REFInd#add a paragraph with simple installation]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:47, 19 March 2018 (UTC)<br />
<br />
== <s>Firewall Limiting</s> ==<br />
<br />
Hi Nl6720,<br />
<br />
Thank you for the improvements to my solution to the firewall. Could I just ask, why is it you chose to explicitly list most the packet types opposed to allowing them all? Is there a security concern when the ones you omitted?<br />
<br />
[[User:Sainty|Sainty]] ([[User talk:Sainty|talk]]) 17:42, 1 July 2018 (UTC)<br />
<br />
:I compared [[Wikipedia:Internet Control Message Protocol#Control messages]] and [[Wikipedia:Internet Control Message Protocol for IPv6#Types]] with the ICMP types with names in [https://git.netfilter.org/nftables/tree/src/proto.c nftables proto.c]. I skipped those listed as deprecated and the one I didn't think should be needed. AFAIK only the redirects ''can potentially have'' security issues, so I skipped those too. I doubt it's really that much ''safer'' to specify only those ICMP types so it could just be considered a personal preference to allow only those that could be needed. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 15:19, 2 July 2018 (UTC)<br />
<br />
== <s>Closing of several discussions in one edit</s> ==<br />
<br />
Please use one edit per discussion removal. See [https://wiki.archlinux.org/index.php?title=Help_talk:Discussion&oldid=329134] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:47, 20 September 2018 (UTC)<br />
<br />
:Sorry! Somehow I overlooked that rule in [[Help:Discussion#Closing a discussion]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:55, 20 September 2018 (UTC)<br />
<br />
== <s>dm-crypt hooks</s> ==<br />
<br />
https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#LVM_on_LUKS<br />
<br />
>that is obvious since the examples provide full HOOK lines and "udev" is not listed in the example with the "systemd" hook<br />
<br />
It is not obvious. The obvious ones are the ones that are highlighted.<br />
<br />
How about highlighting udev too so it becomes obvious?<br />
{{Unsigned|09:55, 27 December 2018 (UTC)|C0rn3j}}<br />
<br />
:I think it would actually be better to remove bold from {{ic|systemd}}, it's not a hook that needs to be '''added''' when using full system encryption. Also, you [[Special:Diff/560528|added the note]] to only one "Configuring mkinitcpio" section, while all of them have the same issue. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:15, 27 December 2018 (UTC)<br />
<br />
:The style of the HOOK examples now match ([[Special:Diff/560861]], [[Special:Diff/560863]]). Closing. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:04, 30 December 2018 (UTC)<br />
<br />
== <s>firefox edit</s> ==<br />
<br />
[[special:diff/572054]] you could save yourself some writing and link to [[Desktop_entries#Modify_environment_variables]] instead -- [[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 17:04, 27 April 2019 (UTC)<br />
<br />
: I didn't notice that section. Thanks! -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 04:07, 28 April 2019 (UTC)<br />
<br />
== <s>Regarding "Undo revision 574893" and "Undo revision 574894"</s> ==<br />
<br />
I mistakenly had "fixed" the link syntax on the "Persistent block device naming page". Thanks for mentioning the specific style page rule that was in violation ([[Help:Style#Hypertext_metaphor]]), that was quite helpful. If you could do that in the future as well for any mistakes I make, I'd greatly appreciate it. In the meantime I'm going to make sure I extensively read over the [[Help:Style]] page before attempting to correct style usage, but given how extensive the styling rules are, there's a decent chance I'll make a few mistakes along the way. Linking to the specific rule definitely provides me with good constructive feedback. --[[User:Aeros167|Aeros167]] ([[User talk:Aeros167|talk]]) 07:46, 9 June 2019 (UTC)<br />
<br />
:I usually link the rule of the style issue I'm fixing, unless I'm feeling lazy, but I can't just write "style" in the summary when undoing an edit. And having a proper edit summary is also a wiki rule: [[ArchWiki:Contributing#Always properly use the edit summary]].<br />
:You don't need to memorize all the rules, just know where to find them. The related articles box in [[Help:Style]] links to most of the relevant pages.<br />
: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:12, 9 June 2019 (UTC)<br />
<br />
== Improving style on external github links ==<br />
<br />
This might be a question better directed at the bureaucrats or site admins, but I'm curious as to your opinion on this as one of the most active maintainers of the site, and you seem to be particularly involved when it comes to link styling. According to [[Help:Editing#Links]], "It is often more useful to give the link an alternative label rather than displaying the URL." (regarding external site links). However, I noticed that on any section that lists a number of applications, such as [[List of applications]], virtually every single one of the external links uses the URL instead of an alternative label.<br />
<br />
For sites that are specific to an individual application, I think it is appropriate to show the full url. However, for common sites that are used as a homepage for a number of applications, such as github repositories, it might be a better styling practice to set an alternative label like "github" or "github repository". [[Help:Editing#Links]] is not particularly strict on external links, but I personally think it would look significantly cleaner this way. Let me know what you think, I'd like to potentially bring this up with others as well. Also let me know if there's someone specific (such as a bureaucrat or admin that specializes in styling) I should discuss this with.<br />
<br />
If the others are on board with this suggestion, I'd be more than willing to start applying this to a number of different pages. I think it would make for a good starter project for me to work on. As a long term aspiration of sorts, I am interested in prospect of eventually becoming a maintainer (I know that I have a long ways to go). I think it'd be a great way to improve my skills at technical documentation, while contributing to one of the most useful sites for linux documentation. -- [[User:Aeros167|Aeros167]] ([[User talk:Aeros167|talk]]) 21:32, 9 June 2019 (UTC)<br />
<br />
:The [[List of applications]] page uses [[Template:App]], so you can propose changes in [[Template talk:App]] or [[Help talk:Style]]. Personally I don't agree to this change, I don't see a need to hide the URL by using a link title in [[Template:App]]. If the link was in a block of text, then I could agree to it, but not when specifically listing the URL. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:20, 10 June 2019 (UTC)<br />
<br />
::Ah no problem, it was just an idea. If the current template is already well established with a fairly recent dedicated page, it will likely stay the same. I'll keep that in mind though for replacing the URL with the substitute if it's in a block of text, I find the text substitutions to be quite useful within those contexts especially. Are there any other frequently used Template pages that would be useful to be aware of? I checked [[Template]] (similar to how [[Help]] directs to all pages in the help category) but that seems to be a dead end. -- [[User:Aeros167|Aeros167]] ([[User talk:Aeros167|talk]]) 09:40, 10 June 2019 (UTC)<br />
<br />
:::AFAIK templates are not categorized so you can find a list of them in [[Special:UncategorizedTemplates]]. A more useful list, separating them by usage, is available in [[Help:Template#List of templates]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:13, 10 June 2019 (UTC)<br />
<br />
== Is there any reason why you chose to remove the note about ISO Image mode? ==<br />
<br />
https://wiki.archlinux.org/index.php/USB_flash_installation_media#Using_Rufus<br />
<br />
The note that says DD Image mode has to be used is not correct. ISO image mode will work for most people. You only need to use DD Image mode if the drive doesn't boot.<br />
[[User:Tonij|Tonij]] ([[User talk:Tonij|talk]]) 17:12, 2 August 2019 (UTC)<br />
<br />
:DD Image mode writes the iso to the drive as it was intended by Arch developers while using ISO image mode means trusting that Rufus correctly copies the bootloader configuration. Any messing with the boot setup is bound to result in some incompatibilities, which is exactly what happens with the crap known as UNetbootin, luckily Rufus has not deteriorated to such extent. I restored [[Special:Diff/578638]] in [[Special:Diff/578856]]. Frankly, I'm not a fan of Rufus since it keeps hiding useful features. [https://github.com/pbatard/rufus/issues/1148][https://github.com/pbatard/rufus/wiki/FAQ#why-doesnt-rufus-create-a-windows-installation-usb-that-can-be-booted-in-dual-biosuefi-mode] -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 18:51, 2 August 2019 (UTC)<br />
<br />
Also if someone is using GPT, they never had any intention of booting in BIOS. What is the point of saying that they should use MBR in that situation? [[User:Tonij|Tonij]] ([[User talk:Tonij|talk]]) 17:22, 2 August 2019 (UTC)<br />
<br />
:That's an unfounded claim. The installation media should be bootable for both BIOS and UEFI systems and that means using MBR in Rufus. Any other specialization is outside the scope of the [[USB flash installation media]] article. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 18:51, 2 August 2019 (UTC)<br />
<br />
Read this: https://www.reddit.com/r/ManjaroLinux/comments/b5fzj4/make_sure_you_burned_the_iso_in_dd_mode/ejdcz9y?utm_source=share&utm_medium=web2x [[User:Tonij|Tonij]] ([[User talk:Tonij|talk]]) 17:32, 2 August 2019 (UTC)<br />
<br />
== dm-crypt/Encrypting an entire system ==<br />
<br />
About the revert: Ok, thanks. I also had problems with some kind of "escape template-breaking characters" that I couldn't solve before you reverted very fast (so I was looking into changing something wrong with the link, but you very too fast). In the future, there will be a release where LUKS2 can be used... Then the wiki could be updated, I guess. I wasn't sure about how often people updated the wiki (and am not used to this, one time has to be the first), but it seems very frequently you guys update the wiki and thanks a lot for that. I also didn't remove the LUKS1-warning, because some people will use old versions for a long time. Thanks and I'll leave it here until we have a release and people begin using that new release with LUKS2-support (but then you or someone else probably updates the wiki before). Cheers! :-) [[User:Newsboost|Newsboost]] ([[User talk:Newsboost|talk]]) 17:51, 26 January 2020 (UTC)<br />
<br />
:The template-breaking character issue was because of {{ic|1==}} in the Phoronix URL. Since the URL was in [[Template:Warning]], normally you would need to escape it with e.g. {{ic|<nowiki>{{Warning|1=text text [https://www.phoronix.com/scan.php?page=news_item&px=GRUB-Boots-LUKS2-Disk-Encrypt]}}</nowiki>}}, but since it starts with a list, it becomes a little more annoying:<br />
{{bc|<nowiki><br />
{{Warning|1&#61;&lt;nowiki&gt;&lt;/nowiki&gt;<br />
* list item<br />
* list item [https://www.phoronix.com/scan.php?page=news_item&px=GRUB-Boots-LUKS2-Disk-Encrypt]<br />
}}<br />
</nowiki>}}<br />
:Without {{ic|&lt;nowiki&gt;&lt;/nowiki&gt;}} the first item would not get parsed as a list item.<br />
:About GRUB, when a new release with LUKS2 support lands in the stable repos, feel free to update the warnings (or remove them if GRUB miraculously gains Argon2 support), until then I think that the dm-crypt pages should retain the current warnings. I'm certain I'm not the only one with such opinion.<br />
:That said, this does not prevent you from editing [[GRUB#Encrypted /boot]]. Currently it does not give a clear solution for using LUKS2, but only hints about PBKDFs. It ''should'' be possible to use GRUB from git with LUKS2 created with the {{ic|cryptsetup luksFormat --pbkdf pbkdf2}}, but I couldn't test it since {{AUR|grub-git}} didn't build for me when I tried it a few weeks ago.<br />
:Anyway, don't get discouraged from editing the wiki just because one of your edits was undone :) <br />
: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:11, 27 January 2020 (UTC)<br />
::Yeah, frontend web-devel isn't really my thing, this template-breaking character stuff confused me a lot. So thanks a lot for explaining some details about this, I had major challenges "fixing" that broken template-stuff. About GRUB and LUKS2: I think I'll also skip the grub-git-method (I don't want to risk anything, but after a new release has been out for some weeks it'll be safer to test). I've been so unlucky for the past year that I for various reasons had to reinstall Arch Linux and therefore have been through the encrypted boot-procedure (too) many times recently. I takes me around 30 hours to fully setup an Arch Linux to my taste, incl. getting packages setup, window managers etc up and running so I hope I won't have to do it too many times again in year 2020 (this time I'll take an image with clonezilla and hopefully that can be used to save time in the future). I use luks1 for boot partition /boot, which after unlocking, unlocks my root-partition which is actually contained in a luks2-container with detached header and LVM inside. So I guess I'm not a normal user, anyway, maybe other people could use that procedure I've gathered and am using with the detached header... I'll watch out and hopefully soon I can use luks2 (and maybe detached header, e.g. on USB-stick) for the boot-partition. Once GRUB with LUKS2-support is stable, I'll see if I can contribute a bit about the detached header-setup, which I think is really nice. There are some details I'm not fully into, e.g. Argon2 and pbkdf2 but I'll see if I can contribute somewhere in the future, when something strikes my eyes. So I fully understand you, I think, this just serves as a bit of practice for me so I better know how things work the next time. Thanks a lot for your feedback, I'll have that in mind when I in the future browse and use the wiki! [[User:Newsboost|Newsboost]] ([[User talk:Newsboost|talk]]) 20:32, 27 January 2020 (UTC)<br />
<br />
:::Just in case you don't know, the setup for LUKS with a detached header is documented in [[dm-crypt/Specialties#Encrypted system using a detached LUKS header]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:26, 28 January 2020 (UTC)<br />
<br />
::::I'm not sure if I've seen that (can't remember). I usually have a folder with text-files that contain instructions for how to setup things and once I've done things a few times, that becomes my only source of "truth" or information (unless a new version of something causes unforeseen problems, in which case I try to solve it and update the instructions again till next time). That being said, I think the arch linux wiki is a great source and many of my own rewritten instructions are based on info from the wiki in some form (sometimes I extend things with detailed examples, I think the wiki isn't suited for that). I'll have in mind that if I notice something on the wiki that other users could benefit from, I'll see if I can contribute. I also copied your comment about the template-stuff to my own https://wiki.archlinux.org/index.php/User_talk:Newsboost (+ a reference to the broken url), so I guess I can always easily find that info again, if something similar appears, i.e. I would then be less dependent on remembering where to find the this conversation)... Now I went through the process of editing here a few times, I think I'll feel more comfortable the next time, thanks :-) [[User:Newsboost|Newsboost]] ([[User talk:Newsboost|talk]]) 17:01, 28 January 2020 (UTC)<br />
<br />
== F2FS warning ==<br />
<br />
Hello, I see you reverted my F2FS warning. Fair point for the doc. I have this link [https://web.archive.org/web/20200925120546/https://archived.forum.manjaro.org/t/record-fsync-data-failed-on-f2fs-file-system-how-to-fix-foregt-the-help-i-reinstalled-its-just-easier/121051] which gives a lot of details on what is going on. Basically, if you shut down your system improperly at the wrong time, F2FS will be corrupt <i>beyond repair</i>. Even {{ic|fsck.f2fs}} will error out. I had found a weird, temporary fix allowing to mount the filesystem read only and even to allow the system to boot for a day or so. I've got a write-up (in French) about that on my blog ([https://lesviallon.fr/p/f2fs-record-fsync-data-failed-469431])<br />
This has happened to several users before, and most smartphone manufacturers, Samsung itself included (they created F2FS), don't use it on their phones because of the stability issues. Do you think this data is sufficient? [[User:Aviallon|Aviallon]] ([[User talk:Aviallon|talk]]) 12:34, 25 September 2020 (UTC)<br />
<br />
:I didn't doubt that the issue with F2FS is real. I've had my own issues with this file system ({{Bug|63839}}) which made me switch to [[XFS|a different one]]. It's just that without any sort of reference that warning was fairly useless. Your links look good and there's even a kernel bugzilla link in you blog. If you can create a section in [[F2FS]] based on you blog post (adjusted for the wiki's style, of course) then it would be perfect :) -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:23, 25 September 2020 (UTC)<br />
<br />
::Understood! I will do that right away! Does that mean I should only put this information in Known Issues, and that I shouldn't put a warning like with [[Btrfs]] ? [[User:Aviallon|Aviallon]] ([[User talk:Aviallon|talk]]) 13:56, 25 September 2020 (UTC)<br />
<br />
:::You should definitely document your issue in "Known issues". Now whether it should be also linked from a warning in the intro, I'd say go by the consensus of [[Talk:F2FS#Adding warning about F2FS potentially being unsafe?]] -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 14:05, 25 September 2020 (UTC)<br />
<br />
== TPM/Data-at-rest encryption with LUKS ==<br />
<br />
Hello, I'm curious about a recent edit you made to [[TPM#Data-at-rest_encryption_with_LUKS]]. I am the one who wrote the part that you edited, but I'm fine with most of your changes. The only thing I take issue with is the statement "This means that access to data is not protected in case the hardware gets stolen." This seems to imply that if the hardware is stolen, the data is as good as unencrypted. Given that full disk encryption is mostly useful in the case that the hardware is stolen, this implies that using a TPM to unlock your drive is as good as not encrypting it at all, which I don't think is fair to say.<br />
<br />
Cold boot attacks, bus sniffing attacks, and other potential ways of circumventing a TPM are not trivial to perform, and are no comparison at all to the ease with which one can access an unencrypted drive. Furthermore, in the (admittedly unlikely) case where an attacker steals only the drive and not the entire computer, the fact that a TPM was set up to unlock the drive won't help them at all. Perhaps this could be changed to something like "This increases the number of options an attacker has to attempt to steal the data," or even "This makes the data significantly less secure."<br />
<br />
Thoughts?<br />
<br />
[[User:Forgonewarrior|Forgonewarrior]] ([[User talk:Forgonewarrior|talk]]) 08:37, 10 April 2021 (UTC)<br />
<br />
:By "hardware" I meant the whole PC not just the drive. If TPM automatically unlocks the the LUKS encrypted root volume on boot, then the thief just needs to power on the PC to get access to the data. So yes, it is almost as good as unencrypted. Getting passed user login is out of scope, and, while I can't think of a way to sidestep it, relying on it for data safety would be naive. See also https://github.com/systemd/systemd/issues/19229. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:46, 10 April 2021 (UTC)<br />
<br />
== Konsole true color ==<br />
<br />
I have seen your edit in [[Konsole]]. You changed {{ic|1=TERM=konsole-256color}} to {{ic|1=TERM=konsole-direct}}. I was the one who added that section.<br />
<br />
It seems {{ic|1=TERM=konsole-direct}} is broken. {{ic|vim}} and {{ic|nvim}} don't display correctly and {{ic|vis}} simply segfaults.<br />
<br />
But you were right {{ic|1=TERM=konsole-256color}} is not for true color.<br />
<br />
I think we should undo your last edit and change the section title from "True-color programs do not display correctly" to "Some color programs do not display correctly".<br />
<br />
{{Unsigned|09:30, 17 April 2021 (UTC)|ENV25}}<br />
<br />
:From what I see, [[nvim]] with {{ic|set termguicolors}}[https://gist.github.com/XVilka/8346728] looks the same with {{ic|1=TERM=xterm-256color}}, {{ic|1=TERM=konsole-256color}} and {{ic|1=TERM=konsole-direct}}. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:25, 17 April 2021 (UTC)<br />
<br />
== Make alad overlord again ==</div>Jellyhttps://wiki.archlinux.org/index.php?title=Arch_package_guidelines/Security&diff=705195Arch package guidelines/Security2021-12-10T12:39:16Z<p>Jelly: /* File access */ add inaccessible paths</p>
<hr />
<div>[[Category:Arch package guidelines]]<br />
[[Category:Security]]<br />
[[pt:Arch package guidelines (Português)/Security]]<br />
This page describes security packaging guidelines for Arch Linux packages. For C/C++ projects the compiler and linker can apply security hardening options. Arch Linux applies PIE, Fortify source, stack protector, nx and relro by default.<br />
<br />
== Usage ==<br />
<br />
Hardening protections can be reviewed by running {{Pkg|checksec}}.<br />
<br />
$ checksec --file=/usr/bin/cat<br />
<br />
== RELRO ==<br />
<br />
RELRO is a generic mitigation technique to harden the data sections of an ELF binary/process. When a program is loaded several ELF memory sections need to be written to by the linker but can be turned read-only before turning control over to the program. This prevents attackers of overriding some ELF sections. There are two different RELRO modes:<br />
<br />
* Partial RELRO ({{ic|-Wl,-z,relro}}) some sections are marked as read-only after program load except the GOT ({{ic|.got.plt}}) is still writeable.<br />
* Full RELRO ({{ic|-Wl,-z,now}}) during program load all dynamic symbols are resolved, allowing for the complete GOT to be marked read-only.<br />
<br />
If an application reports partial relro, investigate if the build toolchain passes our LDFLAGS or allows overriding LDFLAGS. For Go packages investigate if the build method uses {{ic|build.go}} as pure golang Makefile replacement which does not allow passing of LDFLAGS.<br />
<br />
=== Haskell ===<br />
<br />
For Haskell it is not clear how to achieve Full RELRO at the moment.<br />
<br />
== Stack canary ==<br />
<br />
A [[Wikipedia:Stack canary|stack canary]] is added by the compiler between the buffer and control data on the stack. If this well known value is corrupted, a buffer overflow occurred and the running program segfaults to prevent possible arbitrary code execution.<br />
<br />
The {{Pkg|gcc}} package has it enabled stack protection by default with the [https://github.com/archlinux/svntogit-packages/blob/packages/gcc/trunk/PKGBUILD#L100 --enable-default-ssp] compile option.<br />
<br />
== NX ==<br />
<br />
=== C/C++ ===<br />
<br />
Executable-space protection marks memory regions as non-executable, such that an attempt to execute machine code in these regions will cause an exception. It makes use of hardware features such as the NX bit (no-execute bit), or in some cases software emulation of those features.<br />
<br />
== PIE ==<br />
<br />
=== C/C++ ===<br />
<br />
The {{Pkg|gcc}} package has it enabled by default for C/C++ with [https://github.com/archlinux/svntogit-packages/blob/packages/gcc/trunk/PKGBUILD#L99 --enable-default-pie].<br />
<br />
=== Golang ===<br />
<br />
Pass the following flags to {{ic|go build}}:<br />
<br />
export GOFLAGS='-buildmode=pie'<br />
export CGO_CPPFLAGS="-D_FORTIFY_SOURCE=2"<br />
export CGO_LDFLAGS="-Wl,-z,relro,-z,now"<br />
<br />
=== Haskell ===<br />
<br />
Pass the following flag to {{ic|runhaskell Setup.hs configure}}:<br />
<br />
--ghc-option='-pie'<br />
<br />
== RPATH/RUNPATH ==<br />
<br />
RUNPATH/RPATH provides further search paths for the object it is listed in (it can be used both for executable and for shared objects).<br />
<br />
$ objdump -x /usr/bin/perl | egrep 'RPATH|RUNPATH'<br />
<br />
If the RPATH value contains a path within an attackers control it can possibly execute code by installing a malicious library in that directory for example [https://nvd.nist.gov/vuln/detail/CVE-2006-1566 CVE-2006-1566] [https://www.cvedetails.com/cve/CVE-2005-4280/ CVE-2005-4280]. See [[Debian:RpathIssue]].<br />
<br />
The RPATH entry is set by the linker by passing for example the following string to LDFLAGS {{ic|-Wl,-rpath -Wl,/usr/local/lib}}. To make an RUNPATH entry append {{ic|--enable-new-dtags}} to the linker flags.<br />
<br />
== FORTIFY ==<br />
<br />
Fortify source is a macro that adds buffer overflow protection in various functions that perform operations on memory and strings. It checks whether an attacker tries to copy more bytes to overflow a buffer and then stops the execution of the program. This protection is enabled with the default {{ic|CPPFLAGS}}:<br />
<br />
{{hc|makepkg.conf|2=<br />
CPPFLAGS="-D_FORTIFY_SOURCE=2"<br />
}}<br />
<br />
See [[makepkg#Configuration]].<br />
<br />
== systemd services ==<br />
<br />
{{Move|systemd/Sandboxing|Covers the same topic as [[systemd#Sandboxing application environments]]. Both could be merged and moved to a dedicated page. See [[User:NetSysFire/systemd sandboxing]] for a proposed draft.|Talk:Security#systemd unit hardening and system.conf tweaks}}<br />
<br />
If a [[systemd]] service file is shipped with the package due to upstream not providing any, look into applying the following systemd service hardening features. Systemd provides a way to analyse security features which are enabled for a service.<br />
<br />
$ systemd-analyze security reflector.service<br />
<br />
=== File access ===<br />
<br />
A service can be hardened by restricting file system access.<br />
<br />
Set up a new file system namespace for the executed process and mounts private {{ic|/tmp}} and {{ic|var/tmp}} directories inside it that is not shared by processes outside the namespace. Useful for programs which write data to {{ic|/tmp}}.<br />
<br />
PrivateTmp=true<br />
<br />
ProtectSystem has three different varieties of mounting directories as read-only for the executed process. The "full" option mounts {{ic|/usr}}, {{ic|/boot}} and {{ic|/etc}} read only. ProtectHome makes {{ic|/home}}, {{ic|/root}} and {{ic|/run/user}} inaccessible to the executed process.<br />
<br />
ProtectSystem=strict<br />
ProtectHome=true<br />
<br />
Sets up a new {{ic|/dev}} namespace for the executed process and only adds API pseudo devices such as {{ic|/dev/null}}, {{ic|/dev/zero}} or {{ic|/dev/random}}, but not for physical devices or system memory, system ports and others. This is useful to secure the execute process from writing directly to physical devices, systemd also adds a system call filter for calls within the {{ic|@raw-io}} set.<br />
<br />
PrivateDevices=true<br />
<br />
These options make the executed process unable to change kernel variables accessible through {{ic|/proc/sys}}, {{ic|/sys}}, etc. ProtectControlGroups makes the {{ic|/sys/fs/cgroup}} hierarchy read-only.<br />
<br />
ProtectKernelTunables=true<br />
ProtectControlGroups=true<br />
<br />
Making file paths inaccessible can be done as following:<br />
<br />
InaccessiblePaths=/etc<br />
<br />
More detailed information can be found in {{man|5|systemd.exec}}.<br />
<br />
=== User ===<br />
<br />
Ensure that the executed process and its children can never gain new privileges through {{man|2|execve}}.<br />
<br />
NoNewPrivileges=true<br />
<br />
=== Memory ===<br />
<br />
Prohibit attempts to create memory mappings that are both writable and executable, to change mappings to be executable or to create executable shared memory. This sandboxes a process against allowing an attacker to write in to memory which is also executed. Note that enabling this is not compatible with all applications which rely on a [[Wikipedia:JIT (computing)|JIT]].<br />
<br />
MemoryDenyWriteExecute=true<br />
<br />
=== System calls ===<br />
<br />
Locks down the {{man|2|personality}} system call so that the kernel execution domain can not be changed.<br />
<br />
LockPersonality=true<br />
<br />
System calls can be restricted in a service as well, systemd can display syscalls to filter on:<br />
<br />
$ systemd-analyze syscall-filter<br />
<br />
Predefined groups are available, e.g. to use the recommended starting point for whitelisting system calls for system services use:<br />
<br />
SystemCallFilter=@system-service<br />
<br />
=== Network ===<br />
<br />
If the running process does not require any network access it can be fully disabled by setting up a new network namespace for the process and only configuration a loopback interface.<br />
<br />
PrivateNetwork=true<br />
<br />
If network is required, the type of address families used can be restricted for the {{man|2|socket}} system call by for example only allowing UNIX sockets.<br />
<br />
RestrictAddressFamilies=AF_UNIX<br />
<br />
For when only network to localhost or specific IP ranges is required a process can be restricted by only allowing network access to localhost. <br />
<br />
IPAddressAllow=localhost<br />
IPAddressDeny=any<br />
<br />
More information about network filtering can be found in {{man|5|systemd.resource-control}}.<br />
<br />
=== Various ===<br />
<br />
Sets up a new UTS namespace for the execute process and disallows changing the hostname or domainname.<br />
<br />
ProtectHostname=true</div>Jellyhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:How_to_be_a_packager&diff=695647DeveloperWiki:How to be a packager2021-09-13T16:49:58Z<p>Jelly: Add warning about split packages architecture</p>
<hr />
<div>[[Category:DeveloperWiki]]<br />
== Follow Package Guidelines ==<br />
<br />
Package guidelines can be found in the Arch Linux documentation.<br />
Please follow them closely.<br />
<br />
[[Arch packaging standards]]<br />
<br />
== Preparation and Setup ==<br />
<br />
=== Installing the Packages ===<br />
<br />
Make sure you have the packages {{ic|devtools}} and {{ic|namcap}} installed.<br />
<br />
=== SSH Config ===<br />
<br />
If you have multiple SSH keys in your SSH Agent, you will need to make sure that the correct key is being used to contact the Arch servers.<br />
Also, when your local username differs from the one being used on the Arch servers, you need to take care of that too.<br />
<br />
Example {{ic|~/.ssh/config}} excerpt:<br />
{{bc|<br />
host repos.archlinux.org<br />
hostname repos.archlinux.org<br />
port 22<br />
user foobar<br />
IdentityFile ~/.ssh/id_arch<br />
IdentitiesOnly yes<br />
}}<br />
<br />
=== makepkg Config ===<br />
<br />
Make sure to configure your {{ic|~/.makepkg.conf}} with the correct {{ic|PACKAGER}} and {{ic|GPGKEY}} variables.<br />
Wrong signatures or missing {{ic|PACKAGER}} will prevent your packages from entering the repository.<br />
<br />
{{bc|1=<br />
PACKAGER="Foo Bar <foo.bar@archlinux.org>"<br />
GPGKEY="0x0123456789abcdef"<br />
}}<br />
<br />
=== Local SVN Setup using Non-Recursive Checkouts ===<br />
<br />
As SVN provides the ability to do scoped checkouts you can initialize an empty local checkout and later on only fetch the packages that you want.<br />
To setup the local checkouts run the following commands.<br />
<br />
For core, extra, testing and staging repos:<br />
<br />
svn checkout -N svn+ssh://svn-packages@repos.archlinux.org/srv/repos/svn-packages/svn svn-packages<br />
<br />
For community, community-testing, community-staging, multilib, multilib-testing, multilib-staging:<br />
<br />
svn checkout -N svn+ssh://svn-community@repos.archlinux.org/srv/repos/svn-community/svn svn-community<br />
<br />
This creates two directories named {{ic|svn-packages}} and {{ic|svn-community}} which contain nothing but are properly setup as svn repositories.<br />
<br />
=== Helper Scripts (optional) ===<br />
<br />
The packaged helper scripts below can be installed from the {{Grp|archlinux-tools}} group. <br />
<br />
* {{pkg|arch-rebuild-order}} — List the rebuild order of packages using the local pacman syncdb's.<br />
* {{pkg|arch-signoff}} — Signoff packages from [testing] interactively in your terminal.<br />
* {{pkg|arch-repro-status}} — List the reproducible status of your packages interactively in your terminal with the ability to see the build logs and diffoscope output per unreproducible package.<br />
* {{pkg|archlinux-contrib}} — Collection of contrib scripts used in Arch Linux.<br />
<br />
==== ch ====<br />
<br />
This shell script eases setting up and maintaining the chroots for building the packages immensely.<br />
The script has been developed by [https://archlinux.org/people/developers/#bluewind Bluewind] and can be found here: [https://git.server-speed.net/users/flo/bin/plain/ch ch].<br />
<br />
As this script relies on [[Btrfs]], you have to create a Btrfs volume (20GiB is mostly sufficient), which can either be a file, a logical volume or a dedicated partition.<br />
Furthermore by default this script assumes that the Btrfs for the chroots is mounted at {{ic|/mnt/chroots/arch}}.<br />
<br />
Afterwards you can create a 64bit package using:<br />
<br />
ch build 64<br />
<br />
(automatically and conveniently invokes makechrootpkg with all required arguments)<br />
<br />
For further details please take a look at the head of the script, it provides some explanations and usage examples.<br />
<br />
== The Workflow ==<br />
<br />
=== Checkout/update your Local Repository ===<br />
cd svn-community<br />
# update a specific package<br />
svn update <package_name><br />
# update all packages<br />
svn update<br />
<br />
=== Adding a new Package ===<br />
This step is only required when adding a new package to the repository for the first time.<br />
cd svn-community<br />
mkdir -p new-package/{repos,trunk}<br />
cd new-package<br />
cp /usr/share/pacman/PKGBUILD.proto trunk/PKGBUILD<br />
$EDITOR trunk/PKGBUILD<br />
svn add .<br />
svn commit<br />
<br />
{{Warning|dbscripts does not support packages with a different split package architecture.}}<br />
<br />
=== Updating the needed Package ===<br />
svn update some-package<br />
<br />
=== Change and build ===<br />
It is '''mandatory''' to build your package using a clean [[DeveloperWiki:Building_in_a_Clean_Chroot|chroot]].<br />
To ensure this, build with the scripts provided by devtools (i.e. {{ic|extra-x86_64-build}} for [[Official_repositories#extra|extra]] and [[Official_repositories#community|community]], {{ic|multilib-build}} for [[Official_repositories#multilib|multilib]], {{ic|multilib-staging-build}} for [[Official_repositories#Staging_repositories|multilib-staging]], {{ic|multilib-testing-build}} for [[Official_repositories#multilib-testing|multilib-testing]], {{ic|staging-x86_64-build}} for [[Official_repositories#Staging_repositories|staging]] and [[Official_repositories#Staging_repositories|community-staging]], {{ic|testing-x86_64-build}} for [[Official_repositories#testing|testing]] and [[Official_repositories#community-testing|community-testing]]).<br />
<br />
cd some-package/trunk/<br />
$EDITOR PKGBUILD<br />
extra-x86_64-build<br />
<br />
Or, if you are using the [[#ch|ch]] helper, simply do:<br />
cd some-package/trunk/<br />
$EDITOR PKGBUILD<br />
ch clean 64<br />
ch update 64<br />
ch build 64<br />
<br />
=== Run namcap on both PKGBUILD and Package ===<br />
{{Note|This is automatically done, when using the devtools build scripts.}}<br />
namcap PKGBUILD<br />
namcap some-package-1.0-1-x86_64.pkg.tar.xz<br />
<br />
=== Run checkpkg on the Package ===<br />
Run in the directory with your freshly built package to get a file list diff compared with the package version currently in the repos.<br />
checkpkg<br />
<br />
{{Note|This can be skipped when adding a new package to the repository for the first time (e.g. by importing it from [[AUR]] to [[Official_repositories#community|community]]).}}<br />
<br />
=== Run sogrep on identified soname change ===<br />
If [[#Run checkpkg on the Package|checkpkg]] identified a shared object name (aka. soname) change in {{ic|package}}'s library {{ic|package.so}}, it is '''required''' to rebuild packages directly depending on it.<br />
<br />
To identify which packages rely on a given library in {{ic|package}} in a repository (e.g. {{ic|extra}} or {{ic|community}}), use sogrep (see {{man|1|sogrep}}).<br />
sogrep <repository> package.so<br />
<br />
Build {{ic|package}} for its respective [[Official_repositories#Staging_repositories|staging]] environment (by following the remaining steps in [[#The Workflow|The Workflow]]) and create a [https://archlinux.org/todo/ TODO] with the identified dependants, so their maintainers can rebuild them against the new version of {{ic|package}}.<br />
<br />
{{Note|First sync with [https://archlinux.org/people/trusted-users/ trusted users] and/ or [https://archlinux.org/people/developers/ developers], if any packages currently in the [[Official_repositories#Staging_repositories|staging]] environment block the rebuilds against {{ic|package}}.}}<br />
<br />
=== Use devtools to sign, upload and commit ===<br />
Once you are satisfied with the package, you need to make sure all your changes are tracked in the repository.<br />
Run:<br />
<br />
svn status<br />
<br />
in the {{ic|some-package/trunk/}} directory and check the output carefully.<br />
If, for example, you have added a new {{ic|some-package.install}} file, you need to tell svn to track that file, e.g.:<br />
<br />
svn add some-package.install<br />
<br />
Make sure to '''never''' add the binary packages, makepkg logs, etc. to the repository!<br />
<br />
When you are ready to proceed, you can run the devtools scripts to sign, upload and commit your work (i.e. {{ic|communitypkg}} for [[Official_repositories#community|community]], {{ic|community-stagingpkg}} for [[Official_repositories#Staging_repositories|community-staging]], {{ic|community-testingpkg}} for [[Official_repositories#community-testing|community-testing]], {{ic|extrapkg}} for [[Official_repositories#extra|extra]], {{ic|gnome-unstablepkg}} for [[Official_repositories#gnome-unstable|gnome-unstable]], {{ic|kde-unstablepkg}} for [[Official_repositories#kde-unstable|kde-unstable]], {{ic|multilibpkg}} for [[Official_repositories#multilib|multilib]], {{ic|multilib-stagingpkg}} for [[Official_repositories#Staging_repositories|multilib-staging]], {{ic|multilib-testingpkg}} for [[Official_repositories#multilib-testing|multilib-testing]], {{ic|stagingpkg}} for [[Official_repositories#Staging_repositories|staging]], {{ic|testingpkg}} for [[Official_repositories#testing|testing]]), e.g.:<br />
<br />
extrapkg "update to 1.2.3, add post_upgrade hook to fix permissions"<br />
<br />
Please try to write concise commit messages.<br />
If the package is simply an upstream change, that is fine, but if anything more complex changes, please inform us by writing an appropriate commit message.<br />
<br />
This will upload the package and its signature to their repository specific location in your user's {{ic|~/staging}} directory on {{ic|repos.archlinux.org}}.<br />
<br />
=== Update the Repository ===<br />
Using {{ic|db-update}} will find new packages for a set of repositories, depending on which is being called.<br />
<br />
To release uploaded packages to [[Official_repositories#core|core]], [[Official_repositories#extra|extra]], [[Official_repositories#gnome-unstable|gnome-unstable]], [[Official_repositories#kde-unstable|kde-unstable]], [[Official_repositories#Staging_repositories|staging]], or [[Official_repositories#testing|testing]] use:<br />
<br />
ssh repos.archlinux.org "/packages/db-update"<br />
<br />
To release uploaded packages to [[Official_repositories#community|community]], [[Official_repositories#Staging_repositories|community-staging]], [[Official_repositories#community-testing|community-testing]], [[Official_repositories#multilib|multilib]], [[Official_repositories#Staging_repositories|multilib-staging]], or [[Official_repositories#multilib-testing|multilib-testing]] use:<br />
<br />
ssh repos.archlinux.org "/community/db-update"<br />
<br />
== Other Operations ==<br />
<br />
=== Removing a Package ===<br />
Using {{ic|db-remove}} will remove a package from a specific binary repository.<br />
<br />
To remove a package from [[Official_repositories#core|core]], [[Official_repositories#extra|extra]], [[Official_repositories#gnome-unstable|gnome-unstable]], [[Official_repositories#kde-unstable|kde-unstable]], [[Official_repositories#Staging_repositories|staging]], or [[Official_repositories#testing|testing]] use:<br />
<br />
ssh repos.archlinux.org "/packages/db-remove <repo> <arch> <package_name>"<br />
<br />
e.g.<br />
<br />
ssh repos.archlinux.org "/packages/db-remove core x86_64 openssh"<br />
<br />
To remove a package from [[Official_repositories#community|community]], [[Official_repositories#Staging_repositories|community-staging]], [[Official_repositories#community-testing|community-testing]], [[Official_repositories#multilib|multilib]], [[Official_repositories#Staging_repositories|multilib-staging]], or [[Official_repositories#multilib-testing|multilib-testing]] use:<br />
<br />
ssh repos.archlinux.org "/community/db-remove <repo> <arch> <package_name>"<br />
<br />
e.g.<br />
<br />
ssh repos.archlinux.org "/community/db-remove community x86_64 jack2"<br />
<br />
If removing the package from the repositories altogether, it is encouraged to remove the entire package directory from version control as well.<br />
<br />
svn update <package_name><br />
svn rm --force <package_name><br />
svn commit <package_name> -m "Deleting <package_name> because of reason."<br />
<br />
Sometime the previous command yields:<br />
svn: E155035: "'/path/to/pkg/<PKG>' is the root of a working copy and cannot be deleted"<br />
<br />
You can remotely remove it with:<br />
svn rm svn+ssh://svn-packages@repos.archlinux.org/srv/repos/svn-packages/svn/<PKG><br />
<br />
=== Moving a package between repos ===<br />
Using {{ic|db-move}} will move a package between two binary repositories.<br />
<br />
To move a package somewhere between [[Official_repositories#core|core]], [[Official_repositories#extra|extra]], [[Official_repositories#gnome-unstable|gnome-unstable]], [[Official_repositories#kde-unstable|kde-unstable]], [[Official_repositories#Staging_repositories|staging]], or [[Official_repositories#testing|testing]] use:<br />
<br />
ssh repos.archlinux.org "/packages/db-move <from_repo> <to_repo> <package_name>"<br />
<br />
e.g.:<br />
<br />
ssh repos.archlinux.org "/packages/db-move testing core openssh"<br />
<br />
To move a package somewhere between [[Official_repositories#community|community]], [[Official_repositories#Staging_repositories|community-staging]], [[Official_repositories#community-testing|community-testing]], [[Official_repositories#multilib|multilib]], [[Official_repositories#Staging_repositories|multilib-staging]], or [[Official_repositories#multilib-testing|multilib-testing]] use:<br />
<br />
ssh repos.archlinux.org "/community/db-move <from_repo> <to_repo> <package_name>"<br />
<br />
e.g.:<br />
<br />
ssh repos.archlinux.org "/community/db-move community-testing community jack2"<br />
<br />
Alternatively, the move from testing is so common, that there are helper scripts:<br />
<br />
/packages/testing2x openssh bzip2 coreutils<br />
/packages/testing2x64 openssh bzip2 coreutils<br />
<br />
These scripts only work if the packages on the commandline are either in ''core'' or ''extra''.<br />
If a package is only in testing, you have to use ''testing2core'', ''testing2core64'', ''testing2extra'' or ''testing2extra64''.<br />
<br />
For the special case of moving a binary package and its version controlled [[PKGBUILD]] (and potentially additional files) between [[Official_repositories#community|community]] and [[Official_repositories#extra|extra]] (either direction), there are the two devtools helper scripts {{ic|community2extra}} and {{ic|extra2community}}.<br />
<br />
E.g. to move a a package from [[Official_repositories#community|community]] to [[Official_repositories#extra|extra]], use:<br />
community2extra <package_name><br />
<br />
=== "Tagging" releases ===<br />
<br />
Fetch the package dir using {{ic|archco}} or {{ic|communityco}} or from an svn checkout.<br />
Then:<br />
cd package-name/trunk<br />
archrelease extra-x86_64<br />
<br />
This makes an svn copy of the trunk entries in a directory named {{ic|extra-x86_64}} indicating that this package is in the extra repository for the ''x86_64'' architecture.<br />
This will be done automatically when using tools such as {{ic|extrapkg}} (see [[#Use devtools to sign, upload and commit|Use devtools to sign, upload and commit]]).<br />
<br />
== Miscellaneous Stuff ==<br />
<br />
=== Cleaning up your checkout ===<br />
<br />
Since you are now maintaining a non-recursive checkout, you may want to get rid of packages that you are no longer tracking:<br />
<br />
svn update package1 package2 --set-depth exclude<br />
<br />
Or if you want an empty toplevel again:<br />
<br />
svn update --set-depth empty<br />
<br />
=== Avoid having to enter your password all the time ===<br />
<br />
When working with {{ic|extrapkg}} and the other devtools, quite a few ssh connections are established, even when using ssh keys and the ssh agent.<br />
You can work around that.<br />
<br />
Add this to your {{ic|~/.ssh/config}}:<br />
<br />
ControlPath ~/.ssh/master-%h-%p-%r<br />
<br />
Host repos.archlinux.org<br />
<br />
Now, before you start working, open a ssh session with<br />
<br />
ssh -M repos.archlinux.org<br />
<br />
Enter your password and leave that session open until you are finished.<br />
All ssh sessions (including scp and svn+ssh) will now be tunneled through this connection.<br />
<br />
=== Showing contributions on Github ===<br />
<br />
Your packaging contributions in [https://github.com/archlinux/svntogit-community svn-community] and [https://github.com/archlinux/svntogit-packages svn-packages] are contributed under ''$username@eb2447ed-0c53-47e4-bac8-5bc4a241df78'' for ''svn-packages'' and ''$username@9fca08f4-af9d-4005-b8df-a31f2cc04f65'' for ''svn-community'' where the username is the user on repos.archlinux.org. These contributions can be added to your Github profile by adding these addresses to your [https://github.com/settings/emails Github Email Settings], verification is not required for contributions to show up.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Pushing to the wrong repository ===<br />
<br />
If you find yourself accidentally having pushed a package to the wrong repository (e.g. running {{ic|communitypkg}} instead of {{ic|extrapkg}} against {{ic|example-1.0.0-any.pkg.tar.zst}}) you can undo it.<br />
<br />
{{Note|This only applies to cases where the [[#Update the Repository|repository update]] has not been done yet. If the repository has been updated already, refer to [[#Moving a package between repos|moving a package between repos]].}}<br />
<br />
Remove the package from the staging location on the repos server:<br />
<br />
ssh repos.archlinux.org "rm staging/community/example-1.0.0-any.pkg.tar.zst*"<br />
<br />
Update your local svn directory and remove the wrong repos entry (assuming you are already in {{ic|svn-packages/example/}}):<br />
<br />
svn update<br />
svn rm repos/community-any<br />
svn commit -m "Cleanup after accidental push to community."<br />
<br />
Afterwards, proceed again with [[#Use devtools to sign, upload and commit|signing, uploading and committing]].</div>Jellyhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:Staff_Services&diff=692373DeveloperWiki:Staff Services2021-08-21T14:36:53Z<p>Jelly: Update email configuration as users can no longer log in and get shell access on mail.archlinux.org</p>
<hr />
<div>[[Category:DeveloperWiki]]<br />
== Staff Services ==<br />
<br />
Arch Linux provides a number of services for Arch Linux Staff which they can freely use but fair use is applicable.<br />
<br />
== accounts.archlinux.org ==<br />
<br />
This server hosts Keycloak, a single sign on server Arch Linux uses to easily onboard new users to new groups and provide a seemless login experience through all our services once they all use SSO. Currently Gitab, Matrix and Hedgedoc use SSO and staff only need a Keycloak account to be able to use these services.<br />
<br />
Generally it’s recommended to secure this account. By default all staff accounts require 2-Factor authentication through OTP or Webauthn. Keycloak allows multiple 2-Factor authentication providers to be set up, it is recommended to set up a backup 2-Factor authentication method in case you lose access to one of your devices.<br />
<br />
This can be configured in the keycloak [https://accounts.archlinux.org/auth/realms/archlinux/account/#/security/signingin security page]. Note that the first configured device is configured as the default.<br />
<br />
== Email ==<br />
<br />
For all staff an @archlinux.org email address is available, during onboarding an email address should have been created for you.<br />
<br />
=== Configuration ===<br />
<br />
SMTP/IMAP server: mail.archlinux.org, SMTP port: 465 (TLS), IMAP port: 993 (TLS), username: the system account name, password: set by each user themselves with {{ic|ssh mail.archlinux.org}}<br />
<br />
Email forwarding can be achieved by creating a sieve rule.<br />
<br />
=== Sieve ===<br />
<br />
* GUI: https://github.com/thsmi/sieve (not available on Arch repos yet)<br />
* TUI: {{Pkg|sieve-connect}}<br />
* Script linting: {{AUR|check-sieve}}, ([https://checksieve.com website])<br />
* Thunderbird has a [https://addons.thunderbird.net/thunderbird/addon/sieve/ sieve] addon<br />
<br />
== Hedgedoc instance ==<br />
<br />
Hedgedoc is an open source collaborative markdown editor to be used to work together on documents or share sensitive snippets. As staff you can login to [https://md.archlinux.org hedgedoc] using your Keycloak account.<br />
<br />
{{Tip|<br />
* By default only Staff is able to edit and view the document you shared as URL.<br />
* To allow outsiders to edit view documents select a different option than ''Limited'' in the right top dropdown menu.<br />
}}<br />
<br />
== Public HTML / Home directory (pkgbuild.com) ==<br />
<br />
A personal web hosting server for Staff to share patches, packages and other Arch Linux related files.<br />
<br />
$ mkdir ~/public_html<br />
$ setfacl -m user:http:x ~<br />
$ setfacl -m user:http:rx ~/public_html<br />
<br />
Then visit {{ic|<nowiki>https://pkgbuild.com/</nowiki>''username''/}}.<br />
<br />
== Build server (build.archlinux.org) ==<br />
<br />
A build server is available for Developers / Trusted Users to build packages using devtools.<br />
<br />
Traditionally {{ic|extra-x86_64-build}} and similar devtool commands runs build chroots locally on the users computer. {{ic|offload-build -r extra}} accomplishes the same on the build server.<br />
<br />
== Gitlab ==<br />
<br />
Gitlab can be used to collaborate on Arch Linux projects in the {{ic|Arch Linux}} namespace or to host Arch Linux related projects in your personal space. To request an official new project in the Arch Linux namespace create an [https://gitlab.archlinux.org/archlinux/infrastructure/-/issues issue] in the infrastructure repository using the {{ic|New Official Project}} template.<br />
<br />
== Archweb ==<br />
<br />
[https://archlinux.org archlinux.org] is not only the main website for our distribution, all Staff have an account there to be shown as team member of their respected team on the website. Apart from that it offers the following functionality:<br />
<br />
* Signing off packages in testing repositories, see the [[Arch_Testing_Team|Arch Testing Team page]]<br />
* Adopting/orphaning packages as Developer / Trusted user<br />
* Viewing your out of date packages and reports on packages you maintain in the repository<br />
** For example [https://archlinux.org/devel/reports/non-reproducible-packages non reproducible packages]<br />
* Creating To Do lists for rebuilds or packaging change tasks.<br />
* Posting news articles, requires a proposal on {{ic|arch-dev-public}} and a 1 day waiting period<br />
<br />
== Tier 0 Mirror ==<br />
<br />
A Tier 0 Mirror is available for Staff to access the most recent packages from Arch Linux for debugging, rebuilds. Access is granted via [https://archlinux.org/devel/tier0mirror/ archweb].<br />
<br />
== Hosting upstream tarballs ==<br />
<br />
Sometimes packagers need to keep an archive of previous upstream releases, secure a copy of sources which upstream deletes or distribute releases for internal packages.<br />
<br />
https://sources.archlinux.org is the internal service for hosting these sources. This service is hosted on {{ic|repos.archlinux.org}} under {{ic|/srv/sources}}. There are two directories available.<br />
<br />
{{ic|sources/}} is used to rehost distributed package sources which needs the sources available for package compliance. This is mostly limited to the {{ic|GPL}} licenses. This is an automatic process administerd by {{ic|dbscripts}} with the {{ic|sourceballs}} service.<br />
<br />
{{ic|other/}} is for source rehosting. There is no set structure but generally the top-level directory is used for {{ic|[core]}} and {{ic|[extra]}}, while {{ic|other/community/}} is used for {{ic|[community]}}.<br />
<br />
Directories here can be used for package releases. Some upstreams have a tendency to remove past releases, and to accomplish reproducible builds and have older packages still be buildable it’s a good idea to upload these releases for safe-keeping.<br />
<br />
== IRC Cloak ==<br />
<br />
IRC cloaks are used on the IRC network to show affiliation to an open-source project on the Libera Chat network. These are visible through {{ic|/whois}} and displayed as {{ic|~taco@archlinux/trusteduser/Taco}}. These are given out by the group contacts for each project.<br />
<br />
For an up-to-date list of group contacts see [[Arch IRC channels#Libera Chat group contacts]].<br />
<br />
== Matrix ==<br />
<br />
<!-- To be kept in sync with https://gitlab.archlinux.org/archlinux/infrastructure/-/blob/master/docs/matrix.md --><br />
<br />
We offer a Matrix homeserver for Arch team members. Matrix is a federated communication service with a variety of available clients for multiple platforms, mobile included. The flagship [https://element.io/ Element clients] offer us file upload, end-to-end encryption, push notifications and integrations with third-party services.<br />
<br />
=== Signing in ===<br />
<br />
For the initial sign-in you need to use a client that supports OpenID Single-Sign-On, such as [https://app.element.io/ Element Web]. Enter {{ic|@username:archlinux.org}} as the username and Element should offer to sign into our homeserver.<br />
<br />
You will be automatically invited to several rooms: <br />
* {{ic|#archlinux:archlinux.org}}: A public room for Arch Linux users. <br />
* {{ic|#internal:archlinux.org}}: A staff-only room with end-to-end encryption.<br />
<br />
Password login is currently disabled, which might exclude some clients. It can be re-enabled should demand exist.<br />
<br />
If you need to provide your client with a homeserver address, use {{ic|<nowiki>https://matrix.archlinux.org</nowiki>}}.<br />
<br />
=== IRC bridges ===<br />
<br />
==== Our bridge ====<br />
<br />
We bridge several of our private IRC channels on Libera Chat to Matrix, which you need to be invited into: <br />
* {{ic|#developers:archlinux.org}}: Bridged with {{ic|#archlinux-dev}}.<br />
* {{ic|#trusted-users:archlinux.org}}: Bridged with {{ic|#archlinux-tu}}.<br />
* {{ic|#staff:archlinux.org}}: Bridged with {{ic|#archlinux-staff}}.<br />
<br />
Please request an invitation in {{ic|#internal:archlinux.org}} for the rooms you need to be in.<br />
<br />
==== Matrix.org bridge ====<br />
<br />
Channels without keys are available via the official Libera Chat bridge. For example: <br />
* {{ic|#archlinux-devops:libera.chat}}: Bridged with {{ic|#archlinux-devops}}.<br />
* {{ic|#archlinux-projects:libera.chat}}: Bridged with {{ic|#archlinux-projects}}.<br />
<br />
'''Please avoid joining large bridged rooms (such as {{ic|#archlinux:libera.chat}}), as these slow down the server immensely.'''<br />
<br />
Libera Chat may require you to have a registered nick to join certain channels. Once {{ic|@appservice:libera.chat}} contacts you, tell it {{ic|!username ''username''}}, then {{ic|!storepass ''password''}} with the username and the password of your Libera Chat NickServ account. Then {{ic|!reconnect}} and it will reconnect you as registered.</div>Jellyhttps://wiki.archlinux.org/index.php?title=Lenovo_ThinkPad_T14/T14s_(Intel)_Gen_1&diff=691313Lenovo ThinkPad T14/T14s (Intel) Gen 12021-08-08T14:58:39Z<p>Jelly: Audio works once, sof-firmware is installed.</p>
<hr />
<div>[[Category:Lenovo]]<br />
{{Laptop style|Hardware table needs IDs added and a function keys section should be added}}<br />
<br />
{| class="wikitable" style="float: right;"<br />
|-<br />
! Hardware !! PCI/USB ID !! Working?<br />
|-<br />
| Touchpad || || {{Yes}}<br />
|-<br />
| TrackPoint || || {{Yes}}<br />
|-<br />
| Touchscreen || || {{Y|Partial}}<br />
|-<br />
| GPU || || {{Yes}}<br />
|-<br />
| Webcam || || {{Yes}}<br />
|-<br />
| Bluetooth || || {{Y|Untested}}<br />
|-<br />
| Audio || || {{Yes}}<br />
|-<br />
| Wireless || || {{Yes}}<br />
|-<br />
| Mobile broadband || || {{Y|Untested}}<br />
|-<br />
| Fingerprint reader || || {{Y|Untested}}<br />
|-<br />
| Smartcard reader || || {{Y|Untested}}<br />
|}<br />
<br />
{{Related articles start}}<br />
{{Related|Lenovo Thinkpad T14 (AMD) Gen 1}}<br />
{{Related|Lenovo Thinkpad T14s (AMD) Gen 1}}<br />
{{Related|Lenovo ThinkPad T495s}}<br />
{{Related|Lenovo ThinkPad T495}}<br />
{{Related articles end}}<br />
<br />
This article covers the installation and configuration of Arch Linux on a Lenovo ThinkPad T14/T14s (Intel) Gen 1 laptop. Everything seems to work pretty much out the box with kernel >=5.9.0.<br />
<br />
For a general overview of laptop-related articles and recommendations, see [[Laptop]].<br />
<br />
== Firmware ==<br />
<br />
=== Secure boot ===<br />
<br />
As of January 2021 deleting SecureBoot keys and installing your own keys (for example by using [[Unified_Extensible_Firmware_Interface/Secure_Boot#Using_KeyTool|KeyTool]]) will brick the device. This is a problem that is similar to one which [https://forums.lenovo.com/t5/ThinkPad-X-Series-Laptops/BIOS-BUG-X1C7-quot-Configuration-changed-restart-system-quot-loop-after-enrolled-my-own-secureboot-key/m-p/4607484 has been reported on some other Lenovo laptops] and is likely due to a faulty firmware. If the device is stuck in a boot loop after replacing the SecureBoot keys, the only way to repair it is by replacing the mainboard of the device. Hopefully, the issue will get fixed with a firmware update in the future.<br />
<br />
== Power modes ==<br />
<br />
{{Warning|BEWARE OF POSSIBLE SKIN BURNS, THE DEVICE GOES BEYOND 75 C IN POWER MODE. Some Thinkpad laptops has a "lap mode" detection, used to throttle the device if it detects that you are using it in your lap, which is not something that is implemented for Linux, there is not anything that will detect that the laptop is in your lap and throttle the device. See [https://web.archive.org/web/20190926163900/https://forums.lenovo.com/lnv/attachments/lnv/Special_Interest_Linux/13642/1/Linux%20Thermal%20throttling.pdf]}}<br />
<br />
Lenovo Vantage software manages 3 power modes in Windows with Intel DPTF, they are managed through [[acpi]] calls: <br />
<br />
* economy<br />
* balanced<br />
* performance<br />
<br />
There is not a software to manage Intel DPTF for this laptop, so we need to do that manually.<br />
<br />
If you do not enable the performance mode, the '''GPU will throttle at 57 C and the CPU Mhz will be throttled too'''. Which makes applications stutter. So far, in a desk, using the performance mode while connected to the power supply was not a problem.<br />
<br />
For the ThinkPad T14 Intel, the ACPI calls are as follows:<br />
<br />
{| class="wikitable"<br />
| economy || \_SB.PCI0.LPCB.EC._Q6F<br />
|-<br />
| balanced || \_SB.PCI0.LPCB.EC._Q6E<br />
|-<br />
| performance || \_SB.PCI0.LPCB.EC._Q6D<br />
|}<br />
<br />
To enable ACPI method calls through {{ic|/proc/acpi/call}}, install the {{Pkg|acpi_call}} kernel module. Install {{Pkg|acpi_call-lts}} if you are using {{Pkg|linux-lts}}.<br />
<br />
{{Tip|Alternatively, install {{Pkg|acpi_call-dkms}} for [[Dynamic Kernel Module Support]] (DKMS).}}<br />
<br />
Then call one of the ACPI methods above to enable a power mode. For example, run the following command to enable performance mode:<br />
<br />
# echo '\_SB.PCI0.LPCB.EC._Q6D' | tee /proc/acpi/call >/dev/null<br />
<br />
The result of the call can be determined by examining the contents of {{ic|/proc/acpi/call}}. A successful call for the previous method is indicated by the following output:<br />
<br />
{{hc|# cat /proc/acpi/call; printf '\n'|<br />
0x8012b01<br />
}}<br />
<br />
You can check what is the throttling temperature in Celsius for the [[NVIDIA]] GPU if you want to make sure, note that you need the {{Pkg|nvidia-settings}} package installed:<br />
<br />
$ nvidia-settings -q GPUMaxOperatingTempThreshold<br />
<br />
An output of {{ic|87C}} or {{ic|75C}} means it is in performance mode.<br />
<br />
== Suspend ==<br />
<br />
S3 suspend works, optionally you can set the ''Config > Power > Sleep'' to Linux in bios.<br />
<br />
== Smartcard Reader ==<br />
<br />
Untested, see [[Lenovo Thinkpad T14s (AMD) Gen 1#Smartcard Reader]]<br />
<br />
== Wireless ==<br />
<br />
Untested, see [[Lenovo Thinkpad T14 (AMD) Gen 1#Wireless]].<br />
<br />
== Touchscreen ==<br />
<br />
Works out of the box but with incorrect touch coordinates.<br />
<br />
Needs to be better configured.<br />
<br />
== Sound ==<br />
<br />
This laptop requires firmware in order for the soundcard to work. See [[Advanced Linux Sound Architecture#ALSA firmware]].<br />
<br />
== See also ==<br />
<br />
=== T14 links ===<br />
<br />
* [https://psref.lenovo.com/syspool/Sys/PDF/ThinkPad/ThinkPad_T14_Gen_1_Intel/ThinkPad_T14_Gen_1_Intel_Spec.pdf Product Specifications Reference (PSREF)]<br />
* [https://download.lenovo.com/pccbbs/mobiles_pdf/t14_gen1_p14s_gen1_hmm_en.pdf Hardware maintenance manual]<br />
* [https://download.lenovo.com/pccbbs/mobiles_pdf/t14_t15_p14s_p15s_ug_en.pdf User guide]<br />
* https://ubuntu.com/certified/202005-27918<br />
<br />
=== T14s links ===<br />
<br />
* [https://psref.lenovo.com/syspool/Sys/PDF/ThinkPad/ThinkPad_T14s_Gen_1_Intel/ThinkPad_T14s_Gen_1_Intel_Spec.pdf Product Specifications Reference (PSREF)]<br />
* [https://download.lenovo.com/pccbbs/mobiles_pdf/t14s_gen1_x13_gen1_hmm_en.pdf Hardware maintenance manual]<br />
* [https://download.lenovo.com/pccbbs/mobiles_pdf/t14s_gen_x13_gen1_ug_en.pdf User guide]<br />
* https://ubuntu.com/certified/202004-27845</div>Jellyhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:How_to_be_a_packager&diff=689262DeveloperWiki:How to be a packager2021-07-24T14:18:56Z<p>Jelly: /* Miscellaneous Stuff */ Add Github contributions howto</p>
<hr />
<div>[[Category:DeveloperWiki]]<br />
== Follow Package Guidelines ==<br />
<br />
Package guidelines can be found in the Arch Linux documentation.<br />
Please follow them closely.<br />
<br />
[[Arch packaging standards]]<br />
<br />
== Preparation and Setup ==<br />
<br />
=== Installing the Packages ===<br />
<br />
Make sure you have the packages {{ic|devtools}} and {{ic|namcap}} installed.<br />
<br />
=== SSH Config ===<br />
<br />
If you have multiple SSH keys in your SSH Agent, you will need to make sure that the correct key is being used to contact the Arch servers.<br />
Also, when your local username differs from the one being used on the Arch servers, you need to take care of that too.<br />
<br />
Example {{ic|~/.ssh/config}} excerpt:<br />
{{bc|<br />
host repos.archlinux.org<br />
hostname repos.archlinux.org<br />
port 22<br />
user foobar<br />
IdentityFile ~/.ssh/id_arch<br />
IdentitiesOnly yes<br />
}}<br />
<br />
=== makepkg Config ===<br />
<br />
Make sure to configure your {{ic|~/.makepkg.conf}} with the correct {{ic|PACKAGER}} and {{ic|GPGKEY}} variables.<br />
Wrong signatures or missing {{ic|PACKAGER}} will prevent your packages from entering the repository.<br />
<br />
{{bc|1=<br />
PACKAGER="Foo Bar <foo.bar@archlinux.org>"<br />
GPGKEY="0x0123456789abcdef"<br />
}}<br />
<br />
=== Local SVN Setup using Non-Recursive Checkouts ===<br />
<br />
As SVN provides the ability to do scoped checkouts you can initialize an empty local checkout and later on only fetch the packages that you want.<br />
To setup the local checkouts run the following commands.<br />
<br />
For core, extra, testing and staging repos:<br />
<br />
svn checkout -N svn+ssh://svn-packages@repos.archlinux.org/srv/repos/svn-packages/svn svn-packages<br />
<br />
For community, community-testing, community-staging, multilib, multilib-testing, multilib-staging:<br />
<br />
svn checkout -N svn+ssh://svn-community@repos.archlinux.org/srv/repos/svn-community/svn svn-community<br />
<br />
This creates two directories named {{ic|svn-packages}} and {{ic|svn-community}} which contain nothing but are properly setup as svn repositories.<br />
<br />
=== Helper Scripts (optional) ===<br />
<br />
The packaged helper scripts below can be installed from the {{Grp|archlinux-tools}} group. <br />
<br />
* {{pkg|arch-rebuild-order}} — List the rebuild order of packages using the local pacman syncdb's.<br />
* {{pkg|arch-signoff}} — Signoff packages from [testing] interactively in your terminal.<br />
* {{pkg|arch-repro-status}} — List the reproducible status of your packages interactively in your terminal with the ability to see the build logs and diffoscope output per unreproducible package.<br />
* {{pkg|archlinux-contrib}} — Collection of contrib scripts used in Arch Linux.<br />
<br />
==== ch ====<br />
<br />
This shell script eases setting up and maintaining the chroots for building the packages immensely.<br />
The script has been developed by [https://archlinux.org/people/developers/#bluewind Bluewind] and can be found here: [https://git.server-speed.net/users/flo/bin/plain/ch ch].<br />
<br />
As this script relies on [[Btrfs]], you have to create a Btrfs volume (20GiB is mostly sufficient), which can either be a file, a logical volume or a dedicated partition.<br />
Furthermore by default this script assumes that the Btrfs for the chroots is mounted at {{ic|/mnt/chroots/arch}}.<br />
<br />
Afterwards you can create a 64bit package using:<br />
<br />
ch build 64<br />
<br />
(automatically and conveniently invokes makechrootpkg with all required arguments)<br />
<br />
For further details please take a look at the head of the script, it provides some explanations and usage examples.<br />
<br />
== The Workflow ==<br />
<br />
=== Checkout/update your Local Repository ===<br />
cd svn-community<br />
# update a specific package<br />
svn update <package_name><br />
# update all packages<br />
svn update<br />
<br />
=== Adding a new Package ===<br />
This step is only required when adding a new package to the repository for the first time.<br />
cd svn-community<br />
mkdir -p new-package/{repos,trunk}<br />
cd new-package<br />
cp /usr/share/pacman/PKGBUILD.proto trunk/PKGBUILD<br />
$EDITOR trunk/PKGBUILD<br />
svn add .<br />
svn commit<br />
<br />
=== Updating the needed Package ===<br />
svn update some-package<br />
<br />
=== Change and build ===<br />
It is '''mandatory''' to build your package using a clean [[DeveloperWiki:Building_in_a_Clean_Chroot|chroot]].<br />
To ensure this, build with the scripts provided by devtools (i.e. {{ic|extra-x86_64-build}} for [[Official_repositories#extra|extra]] and [[Official_repositories#community|community]], {{ic|multilib-build}} for [[Official_repositories#multilib|multilib]], {{ic|multilib-staging-build}} for [[Official_repositories#Staging_repositories|multilib-staging]], {{ic|multilib-testing-build}} for [[Official_repositories#multilib-testing|multilib-testing]], {{ic|staging-x86_64-build}} for [[Official_repositories#Staging_repositories|staging]] and [[Official_repositories#Staging_repositories|community-staging]], {{ic|testing-x86_64-build}} for [[Official_repositories#testing|testing]] and [[Official_repositories#community-testing|community-testing]]).<br />
<br />
cd some-package/trunk/<br />
$EDITOR PKGBUILD<br />
extra-x86_64-build<br />
<br />
Or, if you are using the [[#ch|ch]] helper, simply do:<br />
cd some-package/trunk/<br />
$EDITOR PKGBUILD<br />
ch clean 64<br />
ch update 64<br />
ch build 64<br />
<br />
=== Run namcap on both PKGBUILD and Package ===<br />
{{Note|This is automatically done, when using the devtools build scripts.}}<br />
namcap PKGBUILD<br />
namcap some-package-1.0-1-x86_64.pkg.tar.xz<br />
<br />
=== Run checkpkg on the Package ===<br />
Run in the directory with your freshly built package to get a file list diff compared with the package version currently in the repos.<br />
checkpkg<br />
<br />
{{Note|This can be skipped when adding a new package to the repository for the first time (e.g. by importing it from [[AUR]] to [[Official_repositories#community|community]]).}}<br />
<br />
=== Run sogrep on identified soname change ===<br />
If [[#Run checkpkg on the Package|checkpkg]] identified a shared object name (aka. soname) change in {{ic|package}}'s library {{ic|package.so}}, it is '''required''' to rebuild packages directly depending on it.<br />
<br />
To identify which packages rely on a given library in {{ic|package}} in a repository (e.g. {{ic|extra}} or {{ic|community}}), use sogrep (see {{man|1|sogrep}}).<br />
sogrep <repository> package.so<br />
<br />
Build {{ic|package}} for its respective [[Official_repositories#Staging_repositories|staging]] environment (by following the remaining steps in [[#The Workflow|The Workflow]]) and create a [https://archlinux.org/todo/ TODO] with the identified dependants, so their maintainers can rebuild them against the new version of {{ic|package}}.<br />
<br />
{{Note|First sync with [https://archlinux.org/people/trusted-users/ trusted users] and/ or [https://archlinux.org/people/developers/ developers], if any packages currently in the [[Official_repositories#Staging_repositories|staging]] environment block the rebuilds against {{ic|package}}.}}<br />
<br />
=== Use devtools to sign, upload and commit ===<br />
Once you are satisfied with the package, you need to make sure all your changes are tracked in the repository.<br />
Run:<br />
<br />
svn status<br />
<br />
in the {{ic|some-package/trunk/}} directory and check the output carefully.<br />
If, for example, you have added a new {{ic|some-package.install}} file, you need to tell svn to track that file, e.g.:<br />
<br />
svn add some-package.install<br />
<br />
Make sure to '''never''' add the binary packages, makepkg logs, etc. to the repository!<br />
<br />
When you are ready to proceed, you can run the devtools scripts to sign, upload and commit your work (i.e. {{ic|communitypkg}} for [[Official_repositories#community|community]], {{ic|community-stagingpkg}} for [[Official_repositories#Staging_repositories|community-staging]], {{ic|community-testingpkg}} for [[Official_repositories#community-testing|community-testing]], {{ic|extrapkg}} for [[Official_repositories#extra|extra]], {{ic|gnome-unstablepkg}} for [[Official_repositories#gnome-unstable|gnome-unstable]], {{ic|kde-unstablepkg}} for [[Official_repositories#kde-unstable|kde-unstable]], {{ic|multilibpkg}} for [[Official_repositories#multilib|multilib]], {{ic|multilib-stagingpkg}} for [[Official_repositories#Staging_repositories|multilib-staging]], {{ic|multilib-testingpkg}} for [[Official_repositories#multilib-testing|multilib-testing]], {{ic|stagingpkg}} for [[Official_repositories#Staging_repositories|staging]], {{ic|testingpkg}} for [[Official_repositories#testing|testing]]), e.g.:<br />
<br />
extrapkg "update to 1.2.3, add post_upgrade hook to fix permissions"<br />
<br />
Please try to write concise commit messages.<br />
If the package is simply an upstream change, that is fine, but if anything more complex changes, please inform us by writing an appropriate commit message.<br />
<br />
This will upload the package and its signature to their repository specific location in your user's {{ic|~/staging}} directory on {{ic|repos.archlinux.org}}.<br />
<br />
=== Update the Repository ===<br />
Using {{ic|db-update}} will find new packages for a set of repositories, depending on which is being called.<br />
<br />
To release uploaded packages to [[Official_repositories#core|core]], [[Official_repositories#extra|extra]], [[Official_repositories#gnome-unstable|gnome-unstable]], [[Official_repositories#kde-unstable|kde-unstable]], [[Official_repositories#Staging_repositories|staging]], or [[Official_repositories#testing|testing]] use:<br />
<br />
ssh repos.archlinux.org "/packages/db-update"<br />
<br />
To release uploaded packages to [[Official_repositories#community|community]], [[Official_repositories#Staging_repositories|community-staging]], [[Official_repositories#community-testing|community-testing]], [[Official_repositories#multilib|multilib]], [[Official_repositories#Staging_repositories|multilib-staging]], or [[Official_repositories#multilib-testing|multilib-testing]] use:<br />
<br />
ssh repos.archlinux.org "/community/db-update"<br />
<br />
== Other Operations ==<br />
<br />
=== Removing a Package ===<br />
Using {{ic|db-remove}} will remove a package from a specific binary repository.<br />
<br />
To remove a package from [[Official_repositories#core|core]], [[Official_repositories#extra|extra]], [[Official_repositories#gnome-unstable|gnome-unstable]], [[Official_repositories#kde-unstable|kde-unstable]], [[Official_repositories#Staging_repositories|staging]], or [[Official_repositories#testing|testing]] use:<br />
<br />
ssh repos.archlinux.org "/packages/db-remove <repo> <arch> <package_name>"<br />
<br />
e.g.<br />
<br />
ssh repos.archlinux.org "/packages/db-remove core x86_64 openssh"<br />
<br />
To remove a package from [[Official_repositories#community|community]], [[Official_repositories#Staging_repositories|community-staging]], [[Official_repositories#community-testing|community-testing]], [[Official_repositories#multilib|multilib]], [[Official_repositories#Staging_repositories|multilib-staging]], or [[Official_repositories#multilib-testing|multilib-testing]] use:<br />
<br />
ssh repos.archlinux.org "/community/db-remove <repo> <arch> <package_name>"<br />
<br />
e.g.<br />
<br />
ssh repos.archlinux.org "/community/db-remove community x86_64 jack2"<br />
<br />
If removing the package from the repositories altogether, it is encouraged to remove the entire package directory from version control as well.<br />
<br />
svn update <package_name><br />
svn rm --force <package_name><br />
svn commit <package_name> -m "Deleting <package_name> because of reason."<br />
<br />
Sometime the previous command yields:<br />
svn: E155035: "'/path/to/pkg/<PKG>' is the root of a working copy and cannot be deleted"<br />
<br />
You can remotely remove it with:<br />
svn rm svn+ssh://svn-packages@repos.archlinux.org/srv/repos/svn-packages/svn/<PKG><br />
<br />
=== Moving a package between repos ===<br />
Using {{ic|db-move}} will move a package between two binary repositories.<br />
<br />
To move a package somewhere between [[Official_repositories#core|core]], [[Official_repositories#extra|extra]], [[Official_repositories#gnome-unstable|gnome-unstable]], [[Official_repositories#kde-unstable|kde-unstable]], [[Official_repositories#Staging_repositories|staging]], or [[Official_repositories#testing|testing]] use:<br />
<br />
ssh repos.archlinux.org "/packages/db-move <from_repo> <to_repo> <package_name>"<br />
<br />
e.g.:<br />
<br />
ssh repos.archlinux.org "/packages/db-move testing core openssh"<br />
<br />
To move a package somewhere between [[Official_repositories#community|community]], [[Official_repositories#Staging_repositories|community-staging]], [[Official_repositories#community-testing|community-testing]], [[Official_repositories#multilib|multilib]], [[Official_repositories#Staging_repositories|multilib-staging]], or [[Official_repositories#multilib-testing|multilib-testing]] use:<br />
<br />
ssh repos.archlinux.org "/community/db-move <from_repo> <to_repo> <package_name>"<br />
<br />
e.g.:<br />
<br />
ssh repos.archlinux.org "/community/db-move community-testing community jack2"<br />
<br />
Alternatively, the move from testing is so common, that there are helper scripts:<br />
<br />
/packages/testing2x openssh bzip2 coreutils<br />
/packages/testing2x64 openssh bzip2 coreutils<br />
<br />
These scripts only work if the packages on the commandline are either in ''core'' or ''extra''.<br />
If a package is only in testing, you have to use ''testing2core'', ''testing2core64'', ''testing2extra'' or ''testing2extra64''.<br />
<br />
For the special case of moving a binary package and its version controlled [[PKGBUILD]] (and potentially additional files) between [[Official_repositories#community|community]] and [[Official_repositories#extra|extra]] (either direction), there are the two devtools helper scripts {{ic|community2extra}} and {{ic|extra2community}}.<br />
<br />
E.g. to move a a package from [[Official_repositories#community|community]] to [[Official_repositories#extra|extra]], use:<br />
community2extra <package_name><br />
<br />
=== "Tagging" releases ===<br />
<br />
Fetch the package dir using {{ic|archco}} or {{ic|communityco}} or from an svn checkout.<br />
Then:<br />
cd package-name/trunk<br />
archrelease extra-x86_64<br />
<br />
This makes an svn copy of the trunk entries in a directory named {{ic|extra-x86_64}} indicating that this package is in the extra repository for the ''x86_64'' architecture.<br />
This will be done automatically when using tools such as {{ic|extrapkg}} (see [[#Use devtools to sign, upload and commit|Use devtools to sign, upload and commit]]).<br />
<br />
== Miscellaneous Stuff ==<br />
<br />
=== Cleaning up your checkout ===<br />
<br />
Since you are now maintaining a non-recursive checkout, you may want to get rid of packages that you are no longer tracking:<br />
<br />
svn update package1 package2 --set-depth exclude<br />
<br />
Or if you want an empty toplevel again:<br />
<br />
svn update --set-depth empty<br />
<br />
=== Avoid having to enter your password all the time ===<br />
<br />
When working with {{ic|extrapkg}} and the other devtools, quite a few ssh connections are established, even when using ssh keys and the ssh agent.<br />
You can work around that.<br />
<br />
Add this to your {{ic|~/.ssh/config}}:<br />
<br />
ControlPath ~/.ssh/master-%h-%p-%r<br />
<br />
Host repos.archlinux.org<br />
<br />
Now, before you start working, open a ssh session with<br />
<br />
ssh -M repos.archlinux.org<br />
<br />
Enter your password and leave that session open until you are finished.<br />
All ssh sessions (including scp and svn+ssh) will now be tunneled through this connection.<br />
<br />
=== Showing contributions on Github ===<br />
<br />
Your packaging contributions in [https://github.com/archlinux/svntogit-community svn-community] and [https://github.com/archlinux/svntogit-packages svn-packages] are contributed under ''$username@eb2447ed-0c53-47e4-bac8-5bc4a241df78'' for ''svn-packages'' and ''$username@9fca08f4-af9d-4005-b8df-a31f2cc04f65'' for ''svn-community'' where the username is the user on repos.archlinux.org. These contributions can be added to your Github profile by adding these addresses to your [https://github.com/settings/emails Github Email Settings], verification is not required for contributions to show up.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Pushing to the wrong repository ===<br />
<br />
If you find yourself accidentally having pushed a package to the wrong repository (e.g. running {{ic|communitypkg}} instead of {{ic|extrapkg}} against {{ic|example-1.0.0-any.pkg.tar.zst}}) you can undo it.<br />
<br />
{{Note|This only applies to cases where the [[#Update the Repository|repository update]] has not been done yet. If the repository has been updated already, refer to [[#Moving a package between repos|moving a package between repos]].}}<br />
<br />
Remove the package from the staging location on the repos server:<br />
<br />
ssh repos.archlinux.org "rm staging/community/example-1.0.0-any.pkg.tar.zst*"<br />
<br />
Update your local svn directory and remove the wrong repos entry (assuming you are already in {{ic|svn-packages/example/}}):<br />
<br />
svn update<br />
svn rm repos/community-any<br />
svn commit -m "Cleanup after accidental push to community."<br />
<br />
Afterwards, proceed again with [[#Use devtools to sign, upload and commit|signing, uploading and committing]].</div>Jellyhttps://wiki.archlinux.org/index.php?title=Package_Maintainer_guidelines&diff=689261Package Maintainer guidelines2021-07-24T13:49:30Z<p>Jelly: /* Remote build on PKGBUILD.com */ Update to build.archlinux.org, soyuz does not exists anymore</p>
<hr />
<div>[[Category:Package development]]<br />
[[es:AUR Trusted User Guidelines]]<br />
[[ja:AUR Trusted User ガイドライン]]<br />
[[pt:AUR Trusted User Guidelines]]<br />
[[zh-hans:AUR Trusted User Guidelines]]<br />
{{Related articles start}}<br />
{{Related|Arch User Repository}}<br />
{{Related|DeveloperWiki#Packaging Guidelines}}<br />
{{Related articles end}}<br />
'''Trusted Users (TU)''' are members of the community charged with keeping the AUR in working order. They maintain popular packages ([https://mailman.archlinux.org/pipermail/aur-general/2010-September/010649.html communicating with and sending patches upstream as needed]), and vote in administrative matters. A TU is elected from active community members by current TUs in a democratic process. TUs are the only members who have a final say in the direction of the AUR.<br />
<br />
The TUs are governed using the [https://tu-bylaws.aur.archlinux.org TU bylaws]<br />
<br />
== TODO list for new Trusted Users ==<br />
<br />
# Read this entire wiki article.<br />
# Read the [https://tu-bylaws.aur.archlinux.org TU Bylaws].<br />
# Make sure your account details on the [[AUR]] are up-to-date.<br />
# Ask one of your sponsors to give you TU status on the AUR.<br />
# Add yourself to the [[Trusted Users]] page.<br />
# Remind a [[ArchWiki:Access levels and roles#Access levels|bureaucrat]] to add your wiki account to the {{int:group-archtu}} group.<br />
# Remind a [https://bbs.archlinux.org/userlist.php?username=&show_group=1&sort_by=username&sort_dir=ASC&search=Submit BBS admin] to change your account on forums.<br />
# Ask one of your sponsors for the [ircs://irc.libera.chat/archlinux-staff #archlinux-staff] and [ircs://irc.libera.chat/archlinux-tu #archlinux-tu] keys and join us in the channels (this is not mandatory, but a great way of getting to know parts of the team and collaborate).<br />
#* If you need a bouncer, ask heftig for a [[Matrix]] invite. <br />
#* If you want an {{ic|@archlinux/trusteduser/''username''}} cloak, ask our [[Arch IRC channels#Libera Chat group contacts|group contacts]] to get you one.<br />
# Ask one of your sponsors to create a ticket in [https://gitlab.archlinux.org/archlinux/infrastructure/-/issues the infrastructure repository issue tracker] (using the {{ic|Onboarding}} template) and provide them with the following information:<br />
#* An SSH public key. If you do not have one, follow [[SSH keys#Generating an SSH key pair]] to create one.<br />
#* A username which will be used for your SSO account and for your (to be created) {{ic|@archlinux.org}} email address.<br />
#* Your full name.<br />
#* Your (personal) e-mail address and a valid PGP public key ID for it, which will be used to provide the initial password for the dev interface (archweb) to you and which will be linked to your (to be created) SSO account.<br />
#* Whether your private or your (to be created) {{ic|''username''@archlinux.org}} email address should be used for the non-public mailing lists and be allowed to post to the [https://lists.archlinux.org/listinfo/arch-dev-public arch-dev-public] mailing list.<br />
# Set the password for your {{ic|@archlinux.org}} e-mail address by following [[DeveloperWiki:Staff Services#Email]].<br />
# Create a PGP key pair for [[package signing]] by following the [https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/wikis/workflows/add-a-new-packager-key workflow for adding a new packager key] (using your new {{ic|<username>@archlinux.org}} address as uid).<br />
# Ask one of your sponsors to create a ticket in the [https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues archlinux-keyring repository issue tracker] (using the {{ic|New Packager Key}} template) in order to have your PGP key signed by (at least) three main key holders.<br />
# Install the {{pkg|devtools}} package.<br />
# [[AUR submission guidelines#Authentication|Configure your private ssh key]] for {{ic|repos.archlinux.org}}.<br />
# Ssh to yourname@repos.archlinux.org (once you have permissions).<br />
# Start contributing!<br />
<br />
== The TU and the AUR ==<br />
<br />
The TUs should also make an effort to check package submissions in the [[AUR]] for malicious code and good PKGBUILDing standards. In around 80% of cases the PKGBUILDs in the UNSUPPORTED are very simple and can be quickly checked for sanity and malicious code by the TU team.<br />
<br />
TUs should also check PKGBUILDs for minor mistakes, suggest corrections and improvements. The TU should endeavor to confirm that all packages follow the Arch Packaging Guidelines/Standards and in doing so share their skills with other package builders in an effort to raise the standard of package building across the distribution.<br />
<br />
TUs are also in an excellent position to document recommended practices.<br />
<br />
=== Rewriting git history ===<br />
<br />
In some cases rewriting the history of an AUR repository is required, for example when a user inadvertently uses their real name in a published commit. This can be automated with {{man|1|git-filter-branch}}. <br />
<br />
To force push the new history, forward the {{ic|1=AUR_OVERWRITE=1}} environment variable to {{man|1|git-push}}. See [https://gitlab.archlinux.org/archlinux/aurweb/-/commit/c5302d3a33028f483cc2e01225226d4ae047dd4a] for details.<br />
<br />
{{Warning|It is recommended to create a backup of the repository before rewriting history.}}<br />
<br />
; Modify committer or author identity<br />
<br />
Use {{ic|git filter-branch --env-filter}} with the {{ic|GIT_AUTHOR_NAME}}, {{ic|GIT_AUTHOR_EMAIL}}, {{ic|GIT_COMMITTER_NAME}} and {{ic|GIT_COMMITTER_EMAIL}} [[environment variables]]. For example:<br />
<br />
{{bc|1=<br />
git filter-branch --env-filter '<br />
if test "$GIT_AUTHOR_EMAIL" = "lepetit@prince.com"; then<br />
GIT_AUTHOR_EMAIL=user@users.noreply.github.com<br />
fi<br />
if test "$GIT_AUTHOR_NAME" = "Antoine de Saint-Exupéry"; then<br />
GIT_AUTHOR_NAME=user<br />
fi'<br />
}}<br />
<br />
{{Note|{{man|1|git-log}} only displays the git ''author'' by default. Use {{ic|1=git log --pretty=fuller}} to display the ''author'' and ''committer''.}}<br />
<br />
== The TU and [community], Guidelines for Package Maintenance ==<br />
<br />
=== Rules for Packages Entering the [community] Repo ===<br />
<br />
* A package must not already exist in any of the Arch Linux repositories. You should take necessary precautions to ensure no other packager is in the process of promoting the same package. Double-check the AUR package comments, read the latest subject headings in [https://mailman.archlinux.org/mailman/listinfo/aur-general aur-general], search [https://bugs.archlinux.org/index.php?project=0&do=index&switch=1 all projects in the bugtracker], [[wikipedia:Grep|grep]] the [http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.log.html Subversion log], and send a quick message to the private TU [[IRC channel]].<br />
* [[AUR helpers#Pacman wrappers|Pacman wrappers]], as a special exception, will never be permitted. If wanting to otherwise add an [[AUR helper]], write an email to {{ic|arch-dev-public}} with the proposed addition, and respect any objections provided by team members.<br />
* Only "popular" packages may enter the repo, as defined by 1% usage from [https://pkgstats.archlinux.de/packages pkgstats] or 10 votes on the AUR.<br />
* Automatic exceptions to this rule are:<br />
** i18n packages<br />
** accessibility packages<br />
** drivers<br />
** dependencies of packages who satisfy the definition of popular, including makedeps and optdeps<br />
** packages that are part of a collection and are intended to be distributed together, provided a part of this collection satisfies the definition of popular<br />
* Any additions not covered by the above criteria must first be proposed on the aur-general mailing list, explaining the reason for the exemption (e.g. renamed package, new package). The agreement of three other TUs is required for the package to be accepted into [community]. Proposed additions from TUs with large numbers of "non-popular" packages are more likely to be rejected.<br />
* TUs are strongly encouraged to move packages they currently maintain from [community] if they have low usage. No enforcement will be made, although resigning TUs packages may be filtered before adoption can occur.<br />
* It is good practice to always bump the '''pkgrel''' by ''1'' (in other words, set it to ''n + 1'') when promoting a package from AUR. This is to facilitate automatic updates for those who already have the package installed, so that they may continue to receive updates from the official channel. Another positive effect of this is that users are not warned that their local copy is newer, as is the case if a packager does reset the '''pkgrel''' to ''1''.<br />
<br />
=== Accessing and Updating the Repository ===<br />
<br />
{{Merge|DeveloperWiki:HOWTO Be A Packager|Duplicate with some minor differences}}<br />
<br />
The [community] repository now uses '''devtools''' which is the same system used for uploading packages to [core] and [extra] to {{ic|repos.archlinux.org}}. Thus most of the instructions in [[DeveloperWiki:HOWTO Be A Packager|Packager Guide]] work without any change. Information which is specific for the [community] repository (like changed URLs) have been put here. The devtools require packagers to [[makepkg#Packager information|set the PACKAGER variable]] in {{ic|makepkg.conf}}.<br />
<br />
Initially you should do a '''non-recursive checkout''' of the [community] repository:<br />
<br />
<nowiki>$ svn checkout -N svn+ssh://svn-community@repos.archlinux.org/srv/repos/svn-community/svn svn-community</nowiki><br />
<br />
This creates a directory named "svn-community" which contains nothing but a ".svn" folder.<br />
<br />
For '''checking''' out, '''updating''' all packages or '''adding''' a package see the [[DeveloperWiki:HOWTO Be A Packager|Packager Guide]].<br />
<br />
To '''remove''' a package:<br />
<br />
$ ssh repos.archlinux.org /community/db-repo-remove community arch pkgname<br />
<br />
Here and in the following text, ''arch'' should be ''x86_64'' which is the only architecture supported by Arch Linux since [https://archlinux.org/news/the-end-of-i686-support/ i686 support has been deprecated].<br />
<br />
{{Note|If you are editing packages of the ''any'' architecture you can simply run the x86_64 scripts which will also work.}}<br />
<br />
When you are done with editing the PKGBUILD, etc., you should '''commit''' the changes ({{ic|svn commit}}).<br />
<br />
Build the package with the helper script {{ic|extra-x86_64-build}}. If you want to upload to testing you need to build with the testing script {{ic|testing-x86_64-build}} instead.<br />
<br />
Sign the package with {{ic|gpg --detach-sign *.pkg.tar.xz}}. If you are using a different PGP key for package signing you can add it to {{ic|~/.makepkg.conf}} with {{ic|1=GPGKEY=''identifier''}}.<br />
<br />
When you want to '''release''' a package, first copy the package along with its signatures to the ''staging/community'' directory on ''repos.archlinux.org'' using {{ic|scp}} and then '''tag''' the package by going to the ''pkgname/trunk'' directory and issuing {{ic|archrelease community-arch}}. This makes an svn copy of the trunk entries in a directory named ''community-x86_64'' indicating that this package is in the community repository for that architecture. Note that the staging directory is different from the staging repository and every package needs to be uploaded to the staging directory. This process can be automated with the {{ic|communitypkg}} script, see the summary below.<br />
<br />
'''Package update summary:'''<br />
<br />
* '''Update''' the package directory: {{ic|svn update some-package}}.<br />
* '''Change''' to the package trunk directory: {{ic|cd some-package/trunk}}.<br />
* '''Edit''' the PKGBUILD, make necessary changes, update hashes with {{ic|updpkgsums}}.<br />
* '''Build''' the package: {{ic|makechrootpkg}} or {{ic|extra-x86_64-build}}. It is '''mandatory''' to build in a [[DeveloperWiki:Building in a clean chroot|clean chroot]].<br />
* '''[[Namcap]]''' the PKGBUILD and the binary {{ic|pkg.tar.gz}}.<br />
* '''Commit''', '''Sign''', '''Copy''' and '''Tag''' the package using {{ic|communitypkg "commit message"}}. This automates the following:<br />
** '''Commit''' the changes to trunk: {{ic|svn commit}}.<br />
** '''Sign''' the package: {{ic|gpg --detach-sign *.pkg.tar.xz}}.<br />
** '''Copy''' the package and its signature to ''repos.archlinux.org'': {{ic|scp *.pkg.tar.xz *.pkg.tar.xz.sig repos.archlinux.org:staging/community/}}.<br />
** '''Tag''' the package: {{ic|archrelease community-x86_64}}.<br />
* '''Update''' the repository: {{ic|ssh repos.archlinux.org /community/db-update}}.<br />
<br />
Also see the ''Miscellaneous'' section in the [[DeveloperWiki:HOWTO Be A Packager|Packager Guide]] and [[SSH keys#ssh-agent]].<br />
<br />
=== Disowning packages ===<br />
<br />
If a TU cannot or does not want to maintain a package any longer, a notice should be posted to the AUR Mailing List, so another TU can<br />
maintain it. A package can still be disowned even if no other TU wants to maintain it, but the TUs should try not to drop many packages (they should not take on more than they have time for). If a package has become obsolete or is not used any longer, it can be removed completely as well.<br />
<br />
If a package has been removed completely, it can be uploaded once again (fresh) to UNSUPPORTED, where a regular user can maintain the package instead of the TU.<br />
<br />
=== Moving packages from unsupported to [community] ===<br />
<br />
Follow the normal procedures for adding a package to community, but remember to delete the corresponding package from unsupported!<br />
<br />
=== Moving packages from [community] to unsupported ===<br />
<br />
Remove the package using the instructions above and upload your source to the AUR.<br />
<br />
=== Moving packages from [community-testing] to [community] ===<br />
<br />
$ ssh repos.archlinux.org /community/db-move community-testing community ''package''<br />
<br />
=== Deleting packages from unsupported ===<br />
<br />
There is no point in removing dummy packages, because they will be re-created in an attempt to track dependencies. If someone uploads a<br />
real package then all dependents will point to the correct place.<br />
<br />
=== Remote build on build.archlinux.org ===<br />
<br />
{{Warning|The following procedures defeats the Web Of Trust model: a user with root access to PKGBUILD.com could alter the package and/or the signature before it gets published.}}<br />
<br />
Trusted users and developers can connect to build.archlinux.org via SSH to, among others, build packages using the devtools.<br />
This has numerous advantages over a local setup:<br />
<br />
* Builds are fast and network speed is high.<br />
* The environment needs setup only once.<br />
* Your local system need not be Arch Linux.<br />
<br />
The process is similar to that of a local setup with devtools. Your GnuPG private is required for signing but you do not want to upload it for obvious security reasons. As such, you will need to forward the GnuPG agent socket from your local machine to the server: this will allow you to sign packages on the build server without communicating your key. This also means that we need to disable the agent on the server before we can run anything.<br />
<br />
First, connect to build.archlinux.org and disable<br />
<br />
$ ssh build.archlinux.org<br />
$ systemctl --user mask gpg-agent.service<br />
<br />
Make sure gpg-agent is not running ({{ic|systemctl --user stop gpg-agent.service}}). At this point, make sure that no sockets exist in the folder pointed by {{ic|gpgconf --list-dir socketdir}}. If they do, remove them or log out and in again.<br />
If you have a custom $GNUPGHOME (eg. to move it to {{ic|~/.config/gnupg}}), you will need to unset that, as it is not possible in gnupg to set the homedir without setting the socketdir.<br />
On build.archlinux.org, ''StreamLocalBindUnlink yes'' is set in ''sshd_config'', therefore removing the sockets manually on logout is not necessary.<br />
<br />
While the PGP private keys remain on your local machine, the public keys '''must''' be on the build server. Export your public ring to the build server, e.g. from you local machine<br />
<br />
$ scp ~/.gnupg/pubring.gpg build.archlinux.org:~/.gnupg/pubring.gpg<br />
<br />
SSH is required to checkout and commit to the SVN repository. You can either set up a new SSH key pair on the server (it is highly discouraged to put your local private key on a server for security reasons) or reuse your local keys via socket forwarding. If you opt for the latter, make sure to disable ssh-agent on the build server if you had enabled it previously (it is not running by default).<br />
<br />
Configure you build environment on the build server:<br />
<br />
{{hc|1=~/.makepkg.conf|2=<br />
PACKAGER="John Doe <john@doe.example>"<br />
## Optional<br />
PKGDEST="/home/johndoe/packages"<br />
SRCDEST="/home/johndoe/sources"<br />
SRCPKGDEST="/home/johndoe/srcpackages"<br />
LOGDEST="/home/johndoe/logs"<br />
## If your PGP key is not the default, specify the right fingerprint:<br />
GPGKEY="ABCD1234..."<br />
}}<br />
<br />
{{Warning|Forwarding your gpg-agent socket to a remote machine makes it possible for anyone with root access to that system to use your unlocked GPG credentials. To circumvent this issue, we need to disable passphrase caching.}}<br />
<br />
Disable passphrase caching with the following settings:<br />
<br />
{{hc|gpg-agent.conf|<br />
default-cache-ttl 0<br />
max-cache-ttl 0<br />
}}<br />
<br />
Because we will want to keep our usual GPG agent running with its current settings, we are going to run another GPG agent dedicated to the task at hand. Create a {{ic|~/.gnupg-archlinux}} folder and symlink everything from {{ic|~/.gnupg}} there, except {{ic|~/.gnupg/gpg-agent.conf}}. Configure the new GPG agent:<br />
<br />
{{hc|~/.gnupg-archlinux|<br />
extra-socket /home/doe/.gnupg-archlinux/S.gpg-agent.extra<br />
default-cache-ttl 0<br />
max-cache-ttl 0<br />
pinentry-program /usr/bin/pinentry-gtk-2<br />
}}<br />
<br />
The {{ic|gpg-agent-extra.socket}} will be forwarded to build.archlinux.org. <br />
<br />
Start the dedicated agent with<br />
<br />
$ gpg-agent --homedir ~/.gnupg-archlinux --daemon<br />
<br />
Connect with:<br />
<br />
$ ssh -R $REMOTE_SSH_AUTH_SOCK:$SSH_AUTH_SOCK -R /run/user/$REMOTE_UID/gnupg/S.gpg-agent:/home/doe/.gnupg-archlinux/S.gpg-agent.extra build.archlinux.org<br />
<br />
or, if using GnuPG as your SSH agent:<br />
<br />
$ ssh -R /run/user/$REMOTE_UID/gnupg/S.gpg-agent.ssh:/run/user/$LOCAL_UID/gnupg/S.gpg-agent.ssh -R /run/user/$REMOTE_UID/gnupg/S.gpg-agent:/home/doe/.gnupg-archlinux/S.gpg-agent.extra build.archlinux.org<br />
<br />
Replace ''$REMOTE_UID'' and ''$LOCAL_UID'' by your user identifier as returned by {{ic|id -u}} on the build server and locally, respectively.<br />
If using ssh-agent, replace ''$REMOTE_SSH_AUTH_SOCK'' by the path to the SSH socket on the remote host (it can be anything).<br />
<br />
You can make the forwarding permanent for that host. For instance with gpg-agent.ssh:<br />
<br />
{{hc|~/.ssh/config|<br />
Host build.archlinux.org<br />
RemoteForward /run/user/$REMOTE_UID/gnupg/S.gpg-agent /run/user/$LOCAL_UID/gnupg/S.gpg-agent.extra<br />
RemoteForward /run/user/$REMOTE_UID/gnupg/S.gpg-agent.ssh /run/user/$LOCAL_UID/gnupg/S.gpg-agent.ssh<br />
}}<br />
<br />
Again, replace ''$REMOTE_UID'' and ''$LOCAL_UID'' with their respective values.<br />
<br />
From then on, the procedure should be exactly the same as a local build:<br />
<br />
$ ssh build.archlinux.org<br />
$ svn checkout -N svn+ssh://svn-community@repos.archlinux.org/srv/repos/svn-community/svn svn-community<br />
$ ...<br />
<br />
{{Note|pinentry-curses might not work with socket forwarding. If it fails for you, try using a different pinentry.}}<br />
<br />
== TODO list retiring a Trusted User ==<br />
<br />
When a TU resigns the following list has be followed, these steps do not apply when a TU resigns but is still a Developer.<br />
<br />
# All packages packaged by the retiree should be resigned (so rebuild). Packages packaged by the retiree can be found in Archweb https://archlinux.org/packages/?sort=&q=&packager=$packager&flagged= where packager is the username on Archweb.<br />
# The account of the retiree should be disabled on Archweb and added to the 'Retired Trusted users' group. The retiree should be removed from the 'Trusted Users' and the repository permissions should be reduced to none.<br />
# The shell access to our servers should be disabled. (notably repos.archlinux.org, pkgbuild.com)<br />
# The GPG key should be removed and a new archlinux-keyring package should be pushed to the repos. Create bug reports in the keyring project to remove the keys of the retired Trusted Users.<br />
# Remove the TU group from their AUR account.<br />
# A [[ArchWiki:Access levels and roles#Access levels|bureaucrat]] should remove their wiki account from the {{int:group-archtu}} group.<br />
# A [https://bbs.archlinux.org/userlist.php?username=&show_group=1&sort_by=username&sort_dir=ASC&search=Submit BBS admin] should change their account on forums.</div>Jellyhttps://wiki.archlinux.org/index.php?title=User:Jelly&diff=687703User:Jelly2021-07-12T10:55:51Z<p>Jelly: /* Arch projects */ update</p>
<hr />
<div>== Arch projects ==<br />
<br />
* Testing ansible setup (how to deploy without secrets)<br />
* Set up Caching for AUR (either varnish or nginx minicache?)<br />
* JSON output for todolists<br />
* Bugzilla integration<br />
* Auto-rebuild service for todolists and rebuilds. Investigate with foutrelis what needs to be done.</div>Jellyhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:Staff_Services&diff=675900DeveloperWiki:Staff Services2021-06-06T11:10:35Z<p>Jelly: Add Tier 0 mirror</p>
<hr />
<div>== Staff Services ==<br />
<br />
Arch Linux provides a number of services for Arch Linux Staff which they can freely use but fair use is applicable.<br />
<br />
== accounts.archlinux.org ==<br />
<br />
This server hosts Keycloak, a single sign on server Arch Linux uses to easily onboard new users to new groups and provide a seemless login experience through all our services once they all use SSO. Currently Gitab, Matrix and Hedgedoc use SSO and staff only need a Keycloak account to be able to use these services.<br />
<br />
Generally it’s recommended to secure this account. By default all staff accounts require 2-Factor authentication through OTP or Webauthn. Keycloak allows multiple 2-Factor authentication providers to be set up, it is recommended to set up a backup 2-Factor authentication method in case you lose access to one of your devices.<br />
<br />
This can be configured in the keycloak [https://accounts.archlinux.org/auth/realms/archlinux/account/#/security/signingin security page]. Note that the first configured device is configured as the default.<br />
<br />
== Email ==<br />
<br />
For all staff an @archlinux.org email address is available, during onboarding an email address should have been created for you.<br />
<br />
=== Configuration ===<br />
<br />
SMTP/IMAP server: mail.archlinux.org SMTP port: 465 (TLS), [deprecated: 587 STARTTLS] IMAP port: 993 (TLS) username: the system account name password: set by each user themselves with passwd on mail.archlinux.org<br />
<br />
Email forwarding can be achieved by creating {{ic|~/.forward}} containing the email.<br />
<br />
=== Sieve ===<br />
<br />
* GUI: https://github.com/thsmi/sieve (not available on Arch repos yet)<br />
* TUI: {{AUR|sieve-connect}}<br />
* Script linting: {{AUR|check-sieve}}, ([https://checksieve.com website])<br />
* Thunderbird has a [https://addons.thunderbird.net/thunderbird/addon/sieve/ sieve] addon<br />
<br />
== Hedgedoc instance ==<br />
<br />
Hedgedoc is an open source collaborative markdown editor to be used to work together on documents or share sensitive snippets. As staff you can login to [https://md.archlinux.org hedgedoc] using your Keycloak account.<br />
<br />
{{Tip|<br />
* By default only Staff is able to edit and view the document you shared as URL.<br />
* To allow outsiders to edit view documents select a different option than ''Limited'' in the right top dropdown menu.<br />
}}<br />
<br />
== Public HTML / Home directory (pkgbuild.com) ==<br />
<br />
A personal web hosting server for Staff to share patches, packages and other Arch Linux related files.<br />
<br />
$ mkdir ~/public_html<br />
$ setfacl -m user:http:x ~<br />
$ setfacl -m user:http:rx ~/public_html<br />
<br />
Then visit {{ic|<nowiki>https://pkgbuild.com/</nowiki>''username''/}}.<br />
<br />
== Build server (build.archlinux.org) ==<br />
<br />
A build server is available for Developers / Trusted Users to build packages using devtools.<br />
<br />
Traditionally {{ic|extra-x86_64-build}} and similar devtool commands runs build chroots locally on the users computer. {{ic|offload-build -r extra}} accomplishes the same on the build server.<br />
<br />
== Gitlab ==<br />
<br />
Gitlab can be used to collaborate on Arch Linux projects in the {{ic|Arch Linux}} namespace or to host Arch Linux related projects in your personal space. To request an official new project in the Arch Linux namespace create an [https://gitlab.archlinux.org/archlinux/infrastructure/-/issues issue] in the infrastructure repository using the {{ic|New Official Project}} template.<br />
<br />
== Archweb ==<br />
<br />
[https://archlinux.org archlinux.org] is not only the main website for our distribution, all Staff have an account there to be shown as team member of their respected team on the website. Apart from that it offers the following functionality:<br />
<br />
* Signing off packages in testing repositories, see the [[Arch_Testing_Team|Arch Testing Team page]]<br />
* Adopting/orphaning packages as Developer / Trusted user<br />
* Viewing your out of date packages and reports on packages you maintain in the repository<br />
** For example [https://archlinux.org/devel/reports/non-reproducible-packages non reproducible packages]<br />
* Creating To Do lists for rebuilds or packaging change tasks.<br />
* Posting news articles, requires a proposal on {{ic|arch-dev-public}} and a 1 day waiting period<br />
<br />
== Tier 0 Mirror ==<br />
<br />
A Tier 0 Mirror is available for Staff to access the most recent packages from Arch Linux for debugging, rebuilds. Access is granted via [archweb https://archlinux.org/devel/tier0mirror/].<br />
<br />
== Hosting upstream tarballs ==<br />
<br />
Sometimes packagers need to keep an archive of previous upstream releases, secure a copy of sources which upstream deletes or distribute releases for internal packages.<br />
<br />
https://sources.archlinux.org is the internal service for hosting these sources. This service is hosted on {{ic|repos.archlinux.org}} under {{ic|/srv/sources}}. There are two directories available.<br />
<br />
{{ic|sources/}} is used to rehost distributed package sources which needs the sources available for package compliance. This is mostly limited to the {{ic|GPL}} licenses. This is an automatic process administerd by {{ic|dbscripts}} with the {{ic|sourceballs}} service.<br />
<br />
{{ic|other/}} is for source rehosting. There is no set structure but generally the top-level directory is used for {{ic|[core]}} and {{ic|[extra]}}, while {{ic|other/community/}} is used for {{ic|[community]}}.<br />
<br />
Directories here can be used for package releases. Some upstreams have a tendency to remove past releases, and to accomplish reproducible builds and have older packages still be buildable it’s a good idea to upload these releases for safe-keeping.<br />
<br />
== IRC Cloak ==<br />
<br />
IRC cloaks are used on the IRC network to show affiliation to an open-source project on the Libera Chat network. These are visible through {{ic|/whois}} and displayed as {{ic|~taco@archlinux/trusteduser/Taco}}. These are given out by the group contacts for each project.<br />
<br />
For an up-to-date list of group contacts see [[Arch IRC channels#Libera Chat group contacts]].<br />
<br />
== Matrix ==<br />
<br />
<!-- To be kept in sync with https://gitlab.archlinux.org/archlinux/infrastructure/-/blob/master/docs/matrix.md --><br />
<br />
We offer a Matrix homeserver for Arch team members. Matrix is a federated communication service with a variety of available clients for multiple platforms, mobile included. The flagship [https://element.io/ Element clients] offer us file upload, end-to-end encryption, push notifications and integrations with third-party services.<br />
<br />
=== Signing in ===<br />
<br />
For the initial sign-in you need to use a client that supports OpenID Single-Sign-On, such as [https://app.element.io/ Element Web]. Enter {{ic|@username:archlinux.org}} as the username and Element should offer to sign into our homeserver.<br />
<br />
You will be automatically invited to several rooms: <br />
* {{ic|#archlinux:archlinux.org}}: A public room for Arch Linux users. <br />
* {{ic|#internal:archlinux.org}}: A staff-only room with end-to-end encryption.<br />
<br />
Password login is currently disabled, which might exclude some clients. It can be re-enabled should demand exist.<br />
<br />
If you need to provide your client with a homeserver address, use {{ic|<nowiki>https://matrix.archlinux.org</nowiki>}}.<br />
<br />
=== IRC bridges ===<br />
<br />
==== Our bridge ====<br />
<br />
We bridge several of our private IRC channels on Libera Chat to Matrix, which you need to be invited into: <br />
* {{ic|#developers:archlinux.org}}: Bridged with {{ic|#archlinux-dev}}.<br />
* {{ic|#trusted-users:archlinux.org}}: Bridged with {{ic|#archlinux-tu}}.<br />
* {{ic|#staff:archlinux.org}}: Bridged with {{ic|#archlinux-staff}}.<br />
<br />
Please request an invitation in {{ic|#internal:archlinux.org}} for the rooms you need to be in.<br />
<br />
==== Matrix.org bridge ====<br />
<br />
Channels without keys are available via the official Libera Chat bridge. For example: <br />
* {{ic|#archlinux-devops:libera.chat}}: Bridged with {{ic|#archlinux-devops}}.<br />
* {{ic|#archlinux-projects:libera.chat}}: Bridged with {{ic|#archlinux-projects}}.<br />
<br />
'''Please avoid joining large bridged rooms (such as {{ic|#archlinux:libera.chat}}), as these slow down the server immensely.'''<br />
<br />
Libera Chat may require you to have a registered nick to join certain channels. Once {{ic|@appservice:libera.chat}} contacts you, tell it {{ic|!username ''username''}}, then {{ic|!storepass ''password''}} with the username and the password of your Libera Chat NickServ account. Then {{ic|!reconnect}} and it will reconnect you as registered.</div>Jellyhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:Brynhild&diff=672917DeveloperWiki:Brynhild2021-05-23T19:17:04Z<p>Jelly: arch services page is archived</p>
<hr />
<div><br />
#redirect [[ArchWiki:Archive]]<br />
[[Category:Archive]]</div>Jellyhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:Gerolde_(dev)&diff=672916DeveloperWiki:Gerolde (dev)2021-05-23T19:16:42Z<p>Jelly: arch services is archived</p>
<hr />
<div><br />
#redirect [[ArchWiki:Archive]]<br />
[[Category:Archive]]</div>Jellyhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:Dom0&diff=672915DeveloperWiki:Dom02021-05-23T19:16:24Z<p>Jelly: archive services page is archived</p>
<hr />
<div><br />
#redirect [[ArchWiki:Archive]]<br />
[[Category:Archive]]</div>Jellyhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:Gudrun_(web)&diff=672914DeveloperWiki:Gudrun (web)2021-05-23T19:16:13Z<p>Jelly: archive as the redirected page is also archived</p>
<hr />
<div><br />
#redirect [[ArchWiki:Archive]]<br />
[[Category:Archive]]</div>Jellyhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:Staff_Services&diff=672913DeveloperWiki:Staff Services2021-05-23T19:01:45Z<p>Jelly: Add a dedicated page for all Arch Linux Staff services.</p>
<hr />
<div>= Staff Services =<br />
<br />
Arch Linux provides a number of services for Arch Linux Staff which they can freely use but fair use is applicable.<br />
<br />
= accounts.archlinux.org =<br />
<br />
This server hosts Keycloak, a single sign on server Arch Linux uses to easily onboard new users to new groups and provide a seemless login experience through all our services once they all use SSO. Currently Gitab, Matrix and Hedgedoc use SSO and staff only need a Keycloak account to be able to use these services.<br />
<br />
Generally it’s recommended to secure this account. By default all staff accounts require 2-Factor authentication through OTP or Webauthn. Keycloak allows multiple 2-Factor authentication providers to be set up, it is recommended to set up a backup 2-Factor authentication method in case you lose access to one of your devices.<br />
<br />
This can be configured in the keycloak [https://accounts.archlinux.org/auth/realms/archlinux/account/#/security/signingin security page]. Note that the first configured device is configured as the default.<br />
<br />
= Email =<br />
<br />
For all staff an @archlinux.org email address is available, during onboarding an email address should have been created for you.<br />
<br />
== Configuration ==<br />
<br />
SMTP/IMAP server: mail.archlinux.org SMTP port: 465 (TLS), [deprecated: 587 STARTTLS] IMAP port: 993 (TLS) username: the system account name password: set by each user themselves with passwd on mail.archlinux.org<br />
<br />
Email forwarding can be achieved by creating <code>~/.forward</code> containing the email.<br />
<br />
== Sieve ==<br />
<br />
* GUI: https://github.com/thsmi/sieve (not available on Arch repos yet)<br />
* TUI: [https://aur.archlinux.org/packages/sieve-connect/ sieve-connect]<br />
* Script linting: check-sieve ([https://aur.archlinux.org/packages/check-sieve/ AUR]), ([https://checksieve.com website])<br />
* Thunderbird has a [https://addons.thunderbird.net/en-US/thunderbird/addon/sieve/ sieve] addon<br />
<br />
= Hedgedoc instance =<br />
<br />
Hedgedoc is an open source collaborative markdown editor to be used to work together on documents or share sensitive snippets. As staff you can login to [https://md.archlinux.org hedgedoc] using your Keycloak account.<br />
<br />
Some tips: * By default only Staff is able to edit and view the document you shared as url * To allow outsiders to edit view documents select a different option then “limited” in the right top dropdown meu<br />
<br />
= Public HTML / Home directory (pkgbuild.com) =<br />
<br />
A personal web hosting server for Staff to share patches, packages and other Arch Linux related files.<br />
<br />
<pre>mkdir ~/public_html<br />
setfacl -m user:http:x ~<br />
setfacl -m user:http:rx ~/public_html</pre><br />
Then visit <code>https://pkgbuild.com/$username/</code>.<br />
<br />
= Build server (build.archlinux.org) =<br />
<br />
A build server is available for Developers / Trusted Users to build packages using devtools.<br />
<br />
Traditionally <code>extra-x86_64-build</code> and similar devtool commands runs build chroots locally on the users computer. <code>offload-build -r extra</code> accomplishes the same on the build server.<br />
<br />
= Gitlab =<br />
<br />
Gitlab can be used to collaborate on Arch Linux projects in the <code>Arch Linux</code> namespace or to host Arch Linux related projects in your personal space. To request an official new project in the Arch Linux namespace create an [https://gitlab.archlinux.org/archlinux/infrastructure/-/issues issue] in the infrastructure repository using the <code>New Official Project</code> template.<br />
<br />
= Archweb =<br />
<br />
[https://archlinux.org archlinux.org] is not only the main website for our distribution, all Staff have an account there to be shown as team member of their respected team on the website. Apart from that it offers the following functionality:<br />
<br />
* Signing off packages in testing repositories, see the [[Arch_Testing_Team|Arch Testing Team page]]<br />
* Adopting/orphaning packages as Developer / Trusted user<br />
* Viewing your out of date packages and reports on packages you maintain in the repository<br />
** For example [https://archlinux.org/devel/reports/non-reproducible-packages non reproducible packages]<br />
* Creating To Do lists for rebuilds or packaging change tasks.<br />
* Posting news articles, requires a proposal on <code>arch-dev-public</code> and a 1 day waiting period<br />
<br />
= Hosting upstream tarballs =<br />
<br />
Sometimes packagers need to keep an archive of previous upstream releases, secure a copy of sources which upstream deletes or distribute releases for internal packages.<br />
<br />
https://sources.archlinux.org is the internal service for hosting these sources. This service is hosted on <code>repos.archlinux.org</code> under <code>/srv/sources</code>. There are two directories available.<br />
<br />
<code>sources/</code> is used to rehost distributed package sources which needs the sources available for package compliance. This is mostly limited to the <code>GPL</code> licenses. This is an automatic process administerd by <code>dbscripts</code> with the <code>sourceballs</code> service.<br />
<br />
<code>other/</code> is for source rehosting. There is no set structure but generally the top-level directory is used for <code>[core]</code> and <code>[extra]</code>, while <code>other/community/</code> is used for <code>[community]</code>.<br />
<br />
Directories here can be used for package releases. Some upstreams have a tendency to remove past releases, and to accomplish reproducible builds and have older packages still be buildable it’s a good idea to upload these releases for safe-keeping.<br />
<br />
= IRC Cloak =<br />
<br />
IRC cloaks are used on the IRC network to show affiliation to an open-source project on the Freenode network. These are visible through <code>/whois</code> and displayed as <code>~taco@archlinux/trusteduser/Taco</code>. These are given out by the group contacts for each project.<br />
<br />
For an up-to-date list of group contacts please visit the [[Arch_IRC_channels#Freenode_group_contacts|IRC Channels page]].<br />
<br />
= Matrix =<br />
<br />
We offer a Matrix homeserver for Arch team members. Matrix is a federated communication service with a variety of available clients for multiple platforms, mobile included. The flagship [https://element.io/ Element clients] offer us file upload, end-to-end encryption, push notifications and integrations with third-party services.<br />
<br />
== Signing in ==<br />
<br />
For the initial sign-in you need to use a client that supports OpenID Single-Sign-On, such as [https://app.element.io/ Element Web]. Enter <code>@username:archlinux.org</code> as the username and Element should offer to sign into our homeserver.<br />
<br />
You will be automatically invited to several rooms: <br />
* <code>#archlinux:archlinux.org</code>: A public room for Arch Linux users. <br />
* <code>#staff:archlinux.org</code>: Bridged with the <code>#archlinux-staff</code> IRC channel on Freenode.<br />
* <code>#internal:archlinux.org</code>: A staff-only room with end-to-end encryption.<br />
<br />
After signing in you can use Element’s settings to set a password for the account if you want to use a client that does not support SSO.<br />
<br />
If you need to provide your client with a homeserver address, use <code>https://matrix.archlinux.org</code>.<br />
<br />
=== Our bridge ===<br />
<br />
We bridge several of our private IRC channels on Freenode to Matrix, which you need to be invited into: <br />
* <code>#developers:archlinux.org</code>: Bridged with <code>#archlinux-dev</code>.<br />
* <code>#trusted-users:archlinux.org</code>: Bridged with <code>#archlinux-tu</code>.<br />
* <code>#staff:archlinux.org</code>: Bridged with <code>#archlinux-staff</code>.<br />
<br />
=== Matrix.org bridge ===<br />
<br />
Channels without keys are available via the “official” Freenode bridge at Matrix.org. For example: <br />
* <code>#freenode_#archlinux-devops:matrix.org</code>: Bridged with <code>#archlinux-devops</code>.<br />
* <code>#freenode_#archlinux-projects:matrix.org</code>: Bridged with <code>#archlinux-projects</code>.<br />
<br />
'''Please avoid joining large bridged rooms (such as <code>#freenode_#archlinux:matrix.org</code>), as these slow down the server immensely.'''<br />
<br />
Freenode may require you to have a registered nick to join certain channels. Once <code>@appservice-irc:matrix.org</code> contacts you, tell it to <code>!storepass &lt;username&gt;:&lt;password&gt;</code> with the username and the password of your Freenode account and it will reconnect you as registered.</div>Jellyhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:Apps_that_need_kdelibs3&diff=672912DeveloperWiki:Apps that need kdelibs32021-05-23T19:00:55Z<p>Jelly: archive obsolete kdelibs page</p>
<hr />
<div><br />
#redirect [[ArchWiki:Archive]]<br />
[[Category:Archive]]</div>Jellyhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:Backups&diff=672911DeveloperWiki:Backups2021-05-23T19:00:22Z<p>Jelly: Archive ancient backups page</p>
<hr />
<div><br />
#redirect [[ArchWiki:Archive]]<br />
[[Category:Archive]]</div>Jellyhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:Arch_Services&diff=672909DeveloperWiki:Arch Services2021-05-23T18:50:52Z<p>Jelly: Archive page, the information is now available and up to date here https://gitlab.archlinux.org/archlinux/infrastructure/-/blob/master/docs/servers.md</p>
<hr />
<div>#redirect [[ArchWiki:Archive]]<br />
[[Category:Archive]]</div>Jellyhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:PKGBUILD.com&diff=672906DeveloperWiki:PKGBUILD.com2021-05-23T18:09:38Z<p>Jelly: /* Warning */ dragon is renamed to build.archlinux.org</p>
<hr />
<div>[[Category:Arch development]]<br />
==Warning==<br />
This article now describes the build server at '''build.archlinux.org''' instead.<br />
<br />
==Directories that must be used==<br />
<br />
All users should use '''only''' {{ic|~/packages}} for storing packages builds and {{ic|~/svn-packages}}.<br />
These directories are excluded from backups and all other directories are automatically backed up.<br />
<br />
==Creating chroots and building packages==<br />
<br />
Devtools 0.9.10 has build helpers that can be used. <br />
<br />
/usr/bin/extra-x86_64-build<br />
/usr/bin/multilib-build<br />
/usr/bin/staging-x86_64-build<br />
/usr/bin/testing-x86_64-build<br />
<br />
This can be used to _create_ and build packages. Chroots are created by default in /var/tmp/archbuild.<br />
To build packages that depend on each other you should use makechrootpkg directly.<br />
<br />
$ sudo extra-x86_64-build<br />
$ sudo testing-x86_64-build<br />
<br />
==x86_64==<br />
<br />
$ sudo makechrootpkg -cr /var/lib/archbuild/extra-x86_64 -- -i<br />
<br />
next package<br />
<br />
$ sudo makechrootpkg -r /var/lib/archbuild/extra-x86_64<br />
<br />
==Packager && Makeflags==<br />
<br />
Add ~/.makepkg.conf with PACKAGER information<br />
<br />
PACKAGER="Name <email>"<br />
MAKEFLAGS="-j5"<br />
<br />
==Connecting to sigurd or gerolde from brynhild==<br />
<br />
On your local system add this:<br />
$ cat .ssh/config<br />
Host pkgbuild.com<br />
Hostname pkgbuild.com<br />
User youruser<br />
ForwardAgent yes<br />
<br />
==Generating rebuilding list when soname is bumped==<br />
<br />
Available in repo-tools.git (https://projects.archlinux.de/repo-tools.git/) and available on brynhild:<br />
<br />
$ sogrep <repo> <soname><br />
$ sogrep extra x264.so.107</div>Jellyhttps://wiki.archlinux.org/index.php?title=Package_Maintainer_guidelines&diff=669816Package Maintainer guidelines2021-05-08T21:23:59Z<p>Jelly: Update tubylaws link</p>
<hr />
<div>[[Category:Package development]]<br />
[[es:AUR Trusted User Guidelines]]<br />
[[ja:AUR Trusted User ガイドライン]]<br />
[[pt:AUR Trusted User Guidelines]]<br />
[[zh-hans:AUR Trusted User Guidelines]]<br />
{{Related articles start}}<br />
{{Related|Arch User Repository}}<br />
{{Related articles end}}<br />
'''Trusted Users (TU)''' are members of the community charged with keeping the AUR in working order. They maintain popular packages ([https://mailman.archlinux.org/pipermail/aur-general/2010-September/010649.html communicating with and sending patches upstream as needed]), and vote in administrative matters. A TU is elected from active community members by current TUs in a democratic process. TUs are the only members who have a final say in the direction of the AUR.<br />
<br />
The TUs are governed using the [https://tu-bylaws.aur.archlinux.org TU bylaws]<br />
<br />
== TODO list for new Trusted Users ==<br />
<br />
# Read this entire wiki article.<br />
# Read the [https://tu-bylaws.aur.archlinux.org TU Bylaws].<br />
# Make sure your account details on the [[AUR]] are up-to-date.<br />
# Add yourself to the [[Trusted Users]] page.<br />
# Remind a [[ArchWiki:Access levels and roles#Access levels|bureaucrat]] to add your wiki account to the {{int:group-archtu}} group.<br />
# Subscribe to the public mailing list for Arch Linux development, [https://lists.archlinux.org/listinfo/arch-dev-public arch-dev-public].<br />
# Request subscription to the internal trusted user mailing list.<br />
# Remind a [https://bbs.archlinux.org/userlist.php?username=&show_group=1&sort_by=username&sort_dir=ASC&search=Submit BBS admin] to change your account on forums.<br />
# Ask some TU for the #archlinux-tu@freenode key and hang out with us in the channel. You do not have to do this, but it would be neat since this is where most dark secrets are spilled and where many new ideas are conceived.<br />
#* If you need a bouncer, ask heftig for a [[Matrix]] invite. <br />
#* Once in the channel, if you want an @archlinux/trusteduser/* cloak ask our [[Arch IRC channels#Freenode group contacts|group contacts]] to get you one.<br />
# Create a PGP key for [[package signing]] or use your existing PGP key. Make sure the key also contains an encryption subkey so you can receive encrypted verification tokens.<br />
# Send a signed email to Jelle van der Waa (jelle@vdwaa.nl):<br />
#* Attach one SSH public key. If you do not have one, use {{ic|ssh-keygen}} to generate one. Check the [[Using SSH Keys]] wiki page for more information about SSH keys.<br />
#* Ask him to whitelist you from arch-dev-public.<br />
#* Tell him if you want an @archlinux.org email.<br />
#* Preferred username and e-mail address which initial password should be sent to in order to access dev interface (archweb). If you already have an account, ask to be added to the Trusted Users group.<br />
#* Ask him to create an account on Arch Linux SSO for you and which username you want on that. He will also add you to the Trusted Users group on SSO. <br />
# Ask your sponsor:<br />
#* to give you TU status on the AUR.<br />
#* to open a new task in the "Keyring" project of the bug tracker following the instructions in [https://lists.archlinux.org/pipermail/arch-dev-public/2013-September/025456.html this message] in order to have your PGP key signed by three master key holders.<br />
# Install the {{pkg|devtools}} package.<br />
# [[AUR submission guidelines#Authentication|Configure your private ssh key]] for {{ic|repos.archlinux.org}}.<br />
# Ssh to yourname@repos.archlinux.org (once you have permissions).<br />
# If you are not upgraded to a Trusted User group on bug tracker in two days, report this as a bug to arch-dev-public.<br />
# Start contributing!<br />
<br />
== The TU and the AUR ==<br />
<br />
The TUs should also make an effort to check package submissions in the [[AUR]] for malicious code and good PKGBUILDing standards. In around 80% of cases the PKGBUILDs in the UNSUPPORTED are very simple and can be quickly checked for sanity and malicious code by the TU team.<br />
<br />
TUs should also check PKGBUILDs for minor mistakes, suggest corrections and improvements. The TU should endeavor to confirm that all packages follow the Arch Packaging Guidelines/Standards and in doing so share their skills with other package builders in an effort to raise the standard of package building across the distribution.<br />
<br />
TUs are also in an excellent position to document recommended practices.<br />
<br />
=== Rewriting git history ===<br />
<br />
In some cases rewriting the history of an AUR repository is required, for example when a user inadvertently uses their real name in a published commit. This can be automated with {{man|1|git-filter-branch}}. <br />
<br />
To force push the new history, forward the {{ic|1=AUR_OVERWRITE=1}} environment variable to {{man|1|git-push}}. See [https://gitlab.archlinux.org/archlinux/aurweb/-/commit/c5302d3a33028f483cc2e01225226d4ae047dd4a] for details.<br />
<br />
{{Warning|It is recommended to create a backup of the repository before rewriting history.}}<br />
<br />
; Modify committer or author identity<br />
<br />
Use {{ic|git filter-branch --env-filter}} with the {{ic|GIT_AUTHOR_NAME}}, {{ic|GIT_AUTHOR_EMAIL}}, {{ic|GIT_COMMITTER_NAME}} and {{ic|GIT_COMMITTER_EMAIL}} [[environment variables]]. For example:<br />
<br />
{{bc|1=<br />
git filter-branch --env-filter '<br />
if test "$GIT_AUTHOR_EMAIL" = "lepetit@prince.com"; then<br />
GIT_AUTHOR_EMAIL=user@users.noreply.github.com<br />
fi<br />
if test "$GIT_AUTHOR_NAME" = "Antoine de Saint-Exupéry"; then<br />
GIT_AUTHOR_NAME=user<br />
fi'<br />
}}<br />
<br />
{{Note|{{man|1|git-log}} only displays the git ''author'' by default. Use {{ic|1=git log --pretty=fuller}} to display the ''author'' and ''committer''.}}<br />
<br />
== The TU and [community], Guidelines for Package Maintenance ==<br />
<br />
=== Rules for Packages Entering the [community] Repo ===<br />
<br />
* A package must not already exist in any of the Arch Linux repositories. You should take necessary precautions to ensure no other packager is in the process of promoting the same package. Double-check the AUR package comments, read the latest subject headings in [https://mailman.archlinux.org/mailman/listinfo/aur-general aur-general], search [https://bugs.archlinux.org/index.php?project=0&do=index&switch=1 all projects in the bugtracker], [[wikipedia:Grep|grep]] the [http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.log.html Subversion log], and send a quick message to the private TU [[IRC channel]].<br />
* [[AUR helpers#Pacman wrappers|Pacman wrappers]], as a special exception, will never be permitted. If wanting to otherwise add an [[AUR helper]], write an email to {{ic|arch-dev-public}} with the proposed addition, and respect any objections provided by team members.<br />
* Only "popular" packages may enter the repo, as defined by 1% usage from [https://pkgstats.archlinux.de/packages pkgstats] or 10 votes on the AUR.<br />
* Automatic exceptions to this rule are:<br />
** i18n packages<br />
** accessibility packages<br />
** drivers<br />
** dependencies of packages who satisfy the definition of popular, including makedeps and optdeps<br />
** packages that are part of a collection and are intended to be distributed together, provided a part of this collection satisfies the definition of popular<br />
* Any additions not covered by the above criteria must first be proposed on the aur-general mailing list, explaining the reason for the exemption (e.g. renamed package, new package). The agreement of three other TUs is required for the package to be accepted into [community]. Proposed additions from TUs with large numbers of "non-popular" packages are more likely to be rejected.<br />
* TUs are strongly encouraged to move packages they currently maintain from [community] if they have low usage. No enforcement will be made, although resigning TUs packages may be filtered before adoption can occur.<br />
* It is good practice to always bump the '''pkgrel''' by ''1'' (in other words, set it to ''n + 1'') when promoting a package from AUR. This is to facilitate automatic updates for those who already have the package installed, so that they may continue to receive updates from the official channel. Another positive effect of this is that users are not warned that their local copy is newer, as is the case if a packager does reset the '''pkgrel''' to ''1''.<br />
<br />
=== Accessing and Updating the Repository ===<br />
<br />
{{Merge|DeveloperWiki:HOWTO Be A Packager|Duplicate with some minor differences}}<br />
<br />
The [community] repository now uses '''devtools''' which is the same system used for uploading packages to [core] and [extra] to {{ic|repos.archlinux.org}}. Thus most of the instructions in [[DeveloperWiki:HOWTO Be A Packager|Packager Guide]] work without any change. Information which is specific for the [community] repository (like changed URLs) have been put here. The devtools require packagers to [[Makepkg#Packager_information|set the PACKAGER variable]] in {{ic|makepkg.conf}}.<br />
<br />
Initially you should do a '''non-recursive checkout''' of the [community] repository:<br />
<br />
<nowiki>$ svn checkout -N svn+ssh://svn-community@repos.archlinux.org/srv/repos/svn-community/svn svn-community</nowiki><br />
<br />
This creates a directory named "svn-community" which contains nothing but a ".svn" folder.<br />
<br />
For '''checking''' out, '''updating''' all packages or '''adding''' a package see the [[DeveloperWiki:HOWTO Be A Packager|Packager Guide]].<br />
<br />
To '''remove''' a package:<br />
<br />
$ ssh repos.archlinux.org /community/db-repo-remove community arch pkgname<br />
<br />
Here and in the following text, ''arch'' should be ''x86_64'' which is the only architecture supported by Arch Linux since [https://archlinux.org/news/the-end-of-i686-support/ i686 support has been deprecated].<br />
<br />
{{Note|If you are editing packages of the ''any'' architecture you can simply run the x86_64 scripts which will also work.}}<br />
<br />
When you are done with editing the PKGBUILD, etc., you should '''commit''' the changes ({{ic|svn commit}}).<br />
<br />
Build the package with the helper script {{ic|extra-x86_64-build}}. If you want to upload to testing you need to build with the testing script {{ic|testing-x86_64-build}} instead.<br />
<br />
Sign the package with {{ic|gpg --detach-sign *.pkg.tar.xz}}. If you are using a different PGP key for package signing you can add it to {{ic|~/.makepkg.conf}} with {{ic|1=GPGKEY=<identifier>}}.<br />
<br />
When you want to '''release''' a package, first copy the package along with its signatures to the ''staging/community'' directory on ''repos.archlinux.org'' using {{ic|scp}} and then '''tag''' the package by going to the ''pkgname/trunk'' directory and issuing {{ic|archrelease community-arch}}. This makes an svn copy of the trunk entries in a directory named ''community-x86_64'' indicating that this package is in the community repository for that architecture. Note that the staging directory is different from the staging repository and every package needs to be uploaded to the staging directory. This process can be automated with the {{ic|communitypkg}} script, see the summary below.<br />
<br />
'''Package update summary:'''<br />
<br />
* '''Update''' the package directory: {{ic|svn update some-package}}.<br />
* '''Change''' to the package trunk directory: {{ic|cd some-package/trunk}}.<br />
* '''Edit''' the PKGBUILD, make necessary changes, update hashes with {{ic|updpkgsums}}.<br />
* '''Build''' the package: {{ic|makechrootpkg}} or {{ic|extra-x86_64-build}}. It is '''mandatory''' to build in a [[DeveloperWiki:Building in a clean chroot|clean chroot]].<br />
* '''[[Namcap]]''' the PKGBUILD and the binary {{ic|pkg.tar.gz}}.<br />
* '''Commit''', '''Sign''', '''Copy''' and '''Tag''' the package using {{ic|communitypkg "commit message"}}. This automates the following:<br />
** '''Commit''' the changes to trunk: {{ic|svn commit}}.<br />
** '''Sign''' the package: {{ic|gpg --detach-sign *.pkg.tar.xz}}.<br />
** '''Copy''' the package and its signature to ''repos.archlinux.org'': {{ic|scp *.pkg.tar.xz *.pkg.tar.xz.sig repos.archlinux.org:staging/community/}}.<br />
** '''Tag''' the package: {{ic|archrelease community-x86_64}}.<br />
* '''Update''' the repository: {{ic|ssh repos.archlinux.org /community/db-update}}.<br />
<br />
Also see the ''Miscellaneous'' section in the [[DeveloperWiki:HOWTO Be A Packager|Packager Guide]] and [[SSH keys#ssh-agent]].<br />
<br />
=== Disowning packages ===<br />
<br />
If a TU cannot or does not want to maintain a package any longer, a notice should be posted to the AUR Mailing List, so another TU can<br />
maintain it. A package can still be disowned even if no other TU wants to maintain it, but the TUs should try not to drop many packages (they should not take on more than they have time for). If a package has become obsolete or is not used any longer, it can be removed completely as well.<br />
<br />
If a package has been removed completely, it can be uploaded once again (fresh) to UNSUPPORTED, where a regular user can maintain the package instead of the TU.<br />
<br />
=== Moving packages from unsupported to [community] ===<br />
<br />
Follow the normal procedures for adding a package to community, but remember to delete the corresponding package from unsupported!<br />
<br />
=== Moving packages from [community] to unsupported ===<br />
<br />
Remove the package using the instructions above and upload your source to the AUR.<br />
<br />
=== Moving packages from [community-testing] to [community] ===<br />
<br />
$ ssh repos.archlinux.org /community/db-move community-testing community <package><br />
<br />
=== Deleting packages from unsupported ===<br />
<br />
There is no point in removing dummy packages, because they will be re-created in an attempt to track dependencies. If someone uploads a<br />
real package then all dependents will point to the correct place.<br />
<br />
=== Remote build on PKGBUILD.com ===<br />
<br />
{{Warning|The following procedures defeats the Web Of Trust model: a user with root access to PKGBUILD.com could alter the package and/or the signature before it gets published.}}<br />
<br />
Trusted users and developers can connect to [https://pkgbuild.com/ PKGBUILD.com] via SSH to, among others, build packages using the devtools.<br />
This has numerous advantages over a local setup:<br />
<br />
* Builds are fast and network speed is high.<br />
* The environment needs setup only once.<br />
* Your local system need not be Arch Linux.<br />
<br />
The process is similar to that of a local setup with devtools. Your GnuPG private is required for signing but you do not want to upload it to soyuz for obvious security reasons. As such, you will need to forward the GnuPG agent socket from your local machine to the server: this will allow you to sign packages on soyuz without communicating your key. This also means that we need to disable the agent on the server before we can run anything.<br />
<br />
First, connect to soyuz and disable<br />
<br />
$ ssh soyuz.archlinux.org<br />
$ systemctl --user mask gpg-agent.service<br />
<br />
Make sure gpg-agent is not running ({{ic|systemctl --user stop gpg-agent.service}}). At this point, make sure that no sockets exist in the folder pointed by {{ic|gpgconf --list-dir socketdir}}. If they do, remove them or log out and in again.<br />
If you have a custom $GNUPGHOME (eg. to move it to {{ic|~/.config/gnupg}}), you will need to unset that, as it is not possible in gnupg to set the homedir without setting the socketdir.<br />
On soyuz, ''StreamLocalBindUnlink yes'' is set in ''sshd_config'', therefore removing the sockets manually on logout is not necessary.<br />
<br />
While the PGP private keys remain on your local machine, the public keys '''must''' be on soyuz. Export your public ring to soyuz, e.g. from you local machine<br />
<br />
$ scp ~/.gnupg/pubring.gpg soyuz.archlinux.org:~/.gnupg/pubring.gpg<br />
<br />
SSH is required to checkout and commit to the SVN repository. You can either set up a new SSH key pair on the server (it is highly discouraged to put your local private key on soyuz for security reasons) or reuse your local keys via socket forwarding. If you opt for the latter, make sure to disable ssh-agent on soyuz if you had enabled it previously (it is not running by default).<br />
<br />
Configure you build environment on soyuz:<br />
<br />
{{hc|1=~/.makepkg.conf|2=<br />
PACKAGER="John Doe <john@doe.example>"<br />
## Optional<br />
PKGDEST="/home/johndoe/packages"<br />
SRCDEST="/home/johndoe/sources"<br />
SRCPKGDEST="/home/johndoe/srcpackages"<br />
LOGDEST="/home/johndoe/logs"<br />
## If your PGP key is not the default, specify the right fingerprint:<br />
GPGKEY="ABCD1234..."<br />
}}<br />
<br />
{{Warning|Forwarding your gpg-agent socket to a remote machine makes it possible for anyone with root access to that system to use your unlocked GPG credentials. To circumvent this issue, we need to disable passphrase caching.}}<br />
<br />
Disable passphrase caching with the following settings:<br />
<br />
{{hc|gpg-agent.conf|<br />
default-cache-ttl 0<br />
max-cache-ttl 0<br />
}}<br />
<br />
Because we will want to keep our usual GPG agent running with its current settings, we are going to run another GPG agent dedicated to the task at hand. Create a {{ic|~/.gnupg-archlinux}} folder and symlink everything from {{ic|~/.gnupg}} there, except {{ic|~/.gnupg/gpg-agent.conf}}. Configure the new GPG agent:<br />
<br />
{{hc|~/.gnupg-archlinux|<br />
extra-socket /home/doe/.gnupg-archlinux/S.gpg-agent.extra<br />
default-cache-ttl 0<br />
max-cache-ttl 0<br />
pinentry-program /usr/bin/pinentry-gtk-2<br />
}}<br />
<br />
The {{ic|gpg-agent-extra.socket}} will be forwarded to PKGBUILD.com. <br />
<br />
Start the dedicated agent with<br />
<br />
$ gpg-agent --homedir ~/.gnupg-archlinux --daemon<br />
<br />
Connect with:<br />
<br />
$ ssh -R $REMOTE_SSH_AUTH_SOCK:$SSH_AUTH_SOCK -R /run/user/$REMOTE_UID/gnupg/S.gpg-agent:/home/doe/.gnupg-archlinux/S.gpg-agent.extra soyuz.archlinux.org<br />
<br />
or, if using GnuPG as your SSH agent:<br />
<br />
$ ssh -R /run/user/$REMOTE_UID/gnupg/S.gpg-agent.ssh:/run/user/$LOCAL_UID/gnupg/S.gpg-agent.ssh -R /run/user/$REMOTE_UID/gnupg/S.gpg-agent:/home/doe/.gnupg-archlinux/S.gpg-agent.extra soyuz.archlinux.org<br />
<br />
Replace ''$REMOTE_UID'' and ''$LOCAL_UID'' by your user identifier as returned by {{ic|id -u}} on soyuz and locally, respectively.<br />
If using ssh-agent, replace ''$REMOTE_SSH_AUTH_SOCK'' by the path to the SSH socket on the remote host (it can be anything).<br />
<br />
You can make the forwarding permanent for that host. For instance with gpg-agent.ssh:<br />
<br />
{{hc|~/.ssh/config|<br />
Host soyuz.archlinux.org<br />
RemoteForward /run/user/$REMOTE_UID/gnupg/S.gpg-agent /run/user/$LOCAL_UID/gnupg/S.gpg-agent.extra<br />
RemoteForward /run/user/$REMOTE_UID/gnupg/S.gpg-agent.ssh /run/user/$LOCAL_UID/gnupg/S.gpg-agent.ssh<br />
}}<br />
<br />
Again, replace ''$REMOTE_UID'' and ''$LOCAL_UID'' with their respective values.<br />
<br />
From then on, the procedure should be exactly the same as a local build:<br />
<br />
$ ssh soyuz.archlinux.org<br />
$ svn checkout -N svn+ssh://svn-community@repos.archlinux.org/srv/repos/svn-community/svn svn-community<br />
$ ...<br />
<br />
{{Note|pinentry-curses might not work with socket forwarding. If it fails for you, try using a different pinentry.}}<br />
<br />
== TODO list retiring a Trusted User ==<br />
<br />
When a TU resigns the following list has be followed, these steps do not apply when a TU resigns but is still a Developer.<br />
<br />
# All packages packaged by the retiree should be resigned (so rebuild). Packages packaged by the retiree can be found in Archweb https://archlinux.org/packages/?sort=&q=&packager=$packager&flagged= where packager is the username on Archweb.<br />
# The account of the retiree should be disabled on Archweb and added to the 'Retired Trusted users' group. The retiree should be removed from the 'Trusted Users' and the repository permissions should be reduced to none.<br />
# The shell access to our servers should be disabled. (notably repos.archlinux.org, pkgbuild.com)<br />
# The GPG key should be removed and a new archlinux-keyring package should be pushed to the repos. Create bug reports in the keyring project to remove the keys of the retired Trusted Users.<br />
# Remove the TU group from their AUR account.<br />
# A [[ArchWiki:Access levels and roles#Access levels|bureaucrat]] should remove their wiki account from the {{int:group-archtu}} group.<br />
# A [https://bbs.archlinux.org/userlist.php?username=&show_group=1&sort_by=username&sort_dir=ASC&search=Submit BBS admin] should change their account on forums.<br />
<br />
== See also ==<br />
<br />
* [[DeveloperWiki#Packaging Guidelines]]</div>Jellyhttps://wiki.archlinux.org/index.php?title=Trusted_Users_Bylaw_Amendment&diff=669815Trusted Users Bylaw Amendment2021-05-08T21:22:54Z<p>Jelly: update bylaws links</p>
<hr />
<div>[[Category:Arch development]]<br />
[[pt:Trusted Users Bylaw Amendment]]<br />
{{Redirect|Trusted Users|Is this still relevant? Can we just link https://tu-bylaws.aur.archlinux.org/#_amendment_of_bylaws from [[Trusted Users]]? (if a direct link is needed at all)}}<br />
{{Move|Trusted Users/Bylaw Amendment|The subject is very connected. See discussion ->|section=Rename_page}}<br />
<br />
'''This is a page to coordinate the amendment of the bylaws with respect to Standard Voting Procedure. If you are looking for the actual bylaws go here https://tu-bylaws.aur.archlinux.org/'''<br />
<br />
Standard Voting Procedure (SVP) describes the formal procedure used by [[TU]]s to accept or reject proposals regarding TU affairs.<br />
<br />
SVP begins with a proposal, for example the addition of a TU or an amendment to the bylaws. The proposal should be clear and concise and it must be posted on the aur-general mailing list (aur-general). The proposal must also be worded unambiguously, and such that a YES or NO answer may be given.<br />
<br />
The discussion period begins when the proposal is posted on aur-general. The duration of the discussion period shall be 5 full days UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. Official discussion shall take place on aur-general. During the discussion period, votes shall not be cast.<br />
<br />
The voting period begins when the discussion period ends. The duration of the voting period shall be 7 full days UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. During the voting period, TUs may vote YES, NO or ABSTAIN. Votes shall be cast under the Trusted User section of the AUR homepage. At the end of the voting period, all votes shall be tallied.<br />
<br />
In the context of SVP, TUs are considered active if they are marked as active when the voting period ends.<br />
<br />
Quorum shall be 66% of all active TUs and participation shall be measured by the sum of YES, NO and ABSTAIN votes, UNLESS otherwise stated in a section of the bylaws pertaining to the proposal.<br />
<br />
The proposal is accepted if EITHER<br />
A) the number of YES votes is greater than half the number of active TUs OR<br />
B) quorum has been established and the number of YES votes is greater than the number of NO votes<br />
UNLESS otherwise stated in a section of the bylaws pertaining to the proposal.<br />
<br />
The proposal is rejected if EITHER<br />
A) the number of NO votes is greater than or equal to the number of active TUs have voted NO OR<br />
B) quorum was established and the number of NO votes is greater than or equal to the number of YES votes<br />
UNLESS otherwise stated in a section of the bylaws pertaining to the proposal.<br />
<br />
A rejected proposal may not be presented again before a waiting period has passed. The duration of the waiting period shall be 3 full months UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. The waiting period begins at the end of the voting period.<br />
<br />
If quorum is not established by the end of the voting period then the proposal is neither accepted nor rejected. A second SVP shall begin to establish the status of the proposal. If the proposal is not accepted at the end of the second SVP then it shall be rejected.</div>Jellyhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:How_to_be_a_packager&diff=664041DeveloperWiki:How to be a packager2021-04-24T20:46:32Z<p>Jelly: /* Helper Scripts (optional) */ add the archlinux-tools script</p>
<hr />
<div>[[Category:DeveloperWiki]]<br />
== Follow Package Guidelines ==<br />
<br />
Package guidelines can be found in the Arch Linux documentation.<br />
Please follow them closely.<br />
<br />
[[Arch packaging standards]]<br />
<br />
== Preparation and Setup ==<br />
<br />
=== Installing the Packages ===<br />
<br />
Make sure you have the packages {{ic|devtools}} and {{ic|namcap}} installed.<br />
<br />
=== SSH Config ===<br />
<br />
If you have multiple SSH keys in your SSH Agent, you will need to make sure that the correct key is being used to contact the Arch servers.<br />
Also, when your local username differs from the one being used on the Arch servers, you need to take care of that too.<br />
<br />
Example {{ic|~/.ssh/config}} excerpt:<br />
{{bc|<br />
host repos.archlinux.org<br />
hostname repos.archlinux.org<br />
port 22<br />
user foobar<br />
IdentityFile ~/.ssh/id_arch<br />
IdentitiesOnly yes<br />
}}<br />
<br />
=== makepkg Config ===<br />
<br />
Make sure to configure your {{ic|~/.makepkg.conf}} with the correct {{ic|PACKAGER}} and {{ic|GPGKEY}} variables.<br />
Wrong signatures or missing {{ic|PACKAGER}} will prevent your packages from entering the repository.<br />
<br />
{{bc|1=<br />
PACKAGER="Foo Bar <foo.bar@archlinux.org>"<br />
GPGKEY="0x0123456789abcdef"<br />
}}<br />
<br />
=== Local SVN Setup using Non-Recursive Checkouts ===<br />
<br />
As SVN provides the ability to do scoped checkouts you can initialize an empty local checkout and later on only fetch the packages that you want.<br />
To setup the local checkouts run the following commands.<br />
<br />
For core, extra, testing and staging repos:<br />
<br />
svn checkout -N svn+ssh://svn-packages@repos.archlinux.org/srv/repos/svn-packages/svn svn-packages<br />
<br />
For community, community-testing, community-staging, multilib, multilib-testing, multilib-staging:<br />
<br />
svn checkout -N svn+ssh://svn-community@repos.archlinux.org/srv/repos/svn-community/svn svn-community<br />
<br />
This creates two directories named {{ic|svn-packages}} and {{ic|svn-community}} which contain nothing but are properly setup as svn repositories.<br />
<br />
=== Helper Scripts (optional) ===<br />
<br />
The packaged helper scripts below can be installed from the "archlinux-tools" group. <br />
<br />
==== {{pkg|arch-rebuild-order}} ====<br />
<br />
List the rebuild order of packages using the local pacman syncdb's.<br />
<br />
==== {{pkg|arch-signoff}} ====<br />
<br />
Signoff packages from [testing] interactively in your terminal.<br />
<br />
==== {{pkg|arch-repro-status}} ====<br />
<br />
List the reproducible status of your packages interactively in your terminal with the ability to see the build logs and diffoscope output per unreproducible package.<br />
<br />
==== {{pkg|archlinux-contrib}} ====<br />
<br />
Collection of contrib scripts used in Arch Linux.<br />
<br />
==== ch ====<br />
<br />
This shell script eases setting up and maintaining the chroots for building the packages immensely.<br />
The script has been developed by [https://archlinux.org/people/developers/#bluewind Bluewind] and can be found here: [https://git.server-speed.net/users/flo/bin/plain/ch ch].<br />
<br />
As this script relies on [[Btrfs]], you have to create a Btrfs volume (20GiB is mostly sufficient), which can either be a file, a logical volume or a dedicated partition.<br />
Furthermore by default this script assumes that the Btrfs for the chroots is mounted at {{ic|/mnt/chroots/arch}}.<br />
<br />
Afterwards you can create a 64bit package using:<br />
<br />
ch build 64<br />
<br />
(automatically and conveniently invokes makechrootpkg with all required arguments)<br />
<br />
For further details please take a look at the head of the script, it provides some explanations and usage examples.<br />
<br />
== The Workflow ==<br />
<br />
=== Checkout/update your Local Repository ===<br />
cd svn-community<br />
# update a specific package<br />
svn update <package_name><br />
# update all packages<br />
svn update<br />
<br />
=== Adding a new Package ===<br />
This step is only required when adding a new package to the repository for the first time.<br />
cd svn-community<br />
mkdir -p new-package/{repos,trunk}<br />
cd new-package<br />
cp /usr/share/pacman/PKGBUILD.proto trunk/PKGBUILD<br />
$EDITOR trunk/PKGBUILD<br />
svn add .<br />
svn commit<br />
<br />
=== Updating the needed Package ===<br />
svn update some-package<br />
<br />
=== Change and build ===<br />
It is '''mandatory''' to build your package using a clean [[DeveloperWiki:Building_in_a_Clean_Chroot|chroot]].<br />
To ensure this, build with the scripts provided by devtools (i.e. {{ic|extra-x86_64-build}} for [[Official_repositories#extra|extra]] and [[Official_repositories#community|community]], {{ic|multilib-build}} for [[Official_repositories#multilib|multilib]], {{ic|multilib-staging-build}} for [[Official_repositories#Staging_repositories|multilib-staging]], {{ic|multilib-testing-build}} for [[Official_repositories#multilib-testing|multilib-testing]], {{ic|staging-x86_64-build}} for [[Official_repositories#Staging_repositories|staging]] and [[Official_repositories#Staging_repositories|community-staging]], {{ic|testing-x86_64-build}} for [[Official_repositories#testing|testing]] and [[Official_repositories#community-testing|community-testing]]).<br />
<br />
cd some-package/trunk/<br />
$EDITOR PKGBUILD<br />
extra-x86_64-build<br />
<br />
Or, if you are using the [[#ch|ch]] helper, simply do:<br />
cd some-package/trunk/<br />
$EDITOR PKGBUILD<br />
ch clean 64<br />
ch update 64<br />
ch build 64<br />
<br />
=== Run namcap on both PKGBUILD and Package ===<br />
{{Note|This is automatically done, when using the devtools build scripts.}}<br />
namcap PKGBUILD<br />
namcap some-package-1.0-1-x86_64.pkg.tar.xz<br />
<br />
=== Run checkpkg on the Package ===<br />
Run in the directory with your freshly built package to get a file list diff compared with the package version currently in the repos.<br />
checkpkg<br />
<br />
{{Note|This can be skipped when adding a new package to the repository for the first time (e.g. by importing it from [[AUR]] to [[Official_repositories#community|community]]).}}<br />
<br />
=== Run sogrep on identified soname change ===<br />
If [[#Run checkpkg on the Package|checkpkg]] identified a shared object name (aka. soname) change in {{ic|package}}'s library {{ic|package.so}}, it is '''required''' to rebuild packages directly depending on it.<br />
<br />
To identify which packages rely on a given library in {{ic|package}} in a repository (e.g. {{ic|extra}} or {{ic|community}}), use sogrep (see {{man|1|sogrep}}).<br />
sogrep <repository> package.so<br />
<br />
Build {{ic|package}} for its respective [[Official_repositories#Staging_repositories|staging]] environment (by following the remaining steps in [[#The Workflow|The Workflow]]) and create a [https://archlinux.org/todo/ TODO] with the identified dependants, so their maintainers can rebuild them against the new version of {{ic|package}}.<br />
<br />
{{Note|First sync with [https://archlinux.org/people/trusted-users/ trusted users] and/ or [https://archlinux.org/people/developers/ developers], if any packages currently in the [[Official_repositories#Staging_repositories|staging]] environment block the rebuilds against {{ic|package}}.}}<br />
<br />
=== Use devtools to sign, upload and commit ===<br />
Once you are satisfied with the package, you need to make sure all your changes are tracked in the repository.<br />
Run:<br />
<br />
svn status<br />
<br />
in the {{ic|some-package/trunk/}} directory and check the output carefully.<br />
If, for example, you have added a new {{ic|some-package.install}} file, you need to tell svn to track that file, e.g.:<br />
<br />
svn add some-package.install<br />
<br />
Make sure to '''never''' add the binary packages, makepkg logs, etc. to the repository!<br />
<br />
When you are ready to proceed, you can run the devtools scripts to sign, upload and commit your work (i.e. {{ic|communitypkg}} for [[Official_repositories#community|community]], {{ic|community-stagingpkg}} for [[Official_repositories#Staging_repositories|community-staging]], {{ic|community-testingpkg}} for [[Official_repositories#community-testing|community-testing]], {{ic|extrapkg}} for [[Official_repositories#extra|extra]], {{ic|gnome-unstablepkg}} for [[Official_repositories#gnome-unstable|gnome-unstable]], {{ic|kde-unstablepkg}} for [[Official_repositories#kde-unstable|kde-unstable]], {{ic|multilibpkg}} for [[Official_repositories#multilib|multilib]], {{ic|multilib-stagingpkg}} for [[Official_repositories#Staging_repositories|multilib-staging]], {{ic|multilib-testingpkg}} for [[Official_repositories#multilib-testing|multilib-testing]], {{ic|stagingpkg}} for [[Official_repositories#Staging_repositories|staging]], {{ic|testingpkg}} for [[Official_repositories#testing|testing]]), e.g.:<br />
<br />
extrapkg "update to 1.2.3, add post_upgrade hook to fix permissions"<br />
<br />
Please try to write concise commit messages.<br />
If the package is simply an upstream change, that is fine, but if anything more complex changes, please inform us by writing an appropriate commit message.<br />
<br />
This will upload the package and its signature to their repository specific location in your user's {{ic|~/staging}} directory on {{ic|repos.archlinux.org}}.<br />
<br />
=== Update the Repository ===<br />
Using {{ic|db-update}} will find new packages for a set of repositories, depending on which is being called.<br />
<br />
To release uploaded packages to [[Official_repositories#core|core]], [[Official_repositories#extra|extra]], [[Official_repositories#gnome-unstable|gnome-unstable]], [[Official_repositories#kde-unstable|kde-unstable]], [[Official_repositories#Staging_repositories|staging]], or [[Official_repositories#testing|testing]] use:<br />
<br />
ssh repos.archlinux.org "/packages/db-update"<br />
<br />
To release uploaded packages to [[Official_repositories#community|community]], [[Official_repositories#Staging_repositories|community-staging]], [[Official_repositories#community-testing|community-testing]], [[Official_repositories#multilib|multilib]], [[Official_repositories#Staging_repositories|multilib-staging]], or [[Official_repositories#multilib-testing|multilib-testing]] use:<br />
<br />
ssh repos.archlinux.org "/community/db-update"<br />
<br />
== Other Operations ==<br />
<br />
=== Removing a Package ===<br />
Using {{ic|db-remove}} will remove a package from a specific binary repository.<br />
<br />
To remove a package from [[Official_repositories#core|core]], [[Official_repositories#extra|extra]], [[Official_repositories#gnome-unstable|gnome-unstable]], [[Official_repositories#kde-unstable|kde-unstable]], [[Official_repositories#Staging_repositories|staging]], or [[Official_repositories#testing|testing]] use:<br />
<br />
ssh repos.archlinux.org "/packages/db-remove <repo> <arch> <package_name>"<br />
<br />
e.g.<br />
<br />
ssh repos.archlinux.org "/packages/db-remove core x86_64 openssh"<br />
<br />
To remove a package from [[Official_repositories#community|community]], [[Official_repositories#Staging_repositories|community-staging]], [[Official_repositories#community-testing|community-testing]], [[Official_repositories#multilib|multilib]], [[Official_repositories#Staging_repositories|multilib-staging]], or [[Official_repositories#multilib-testing|multilib-testing]] use:<br />
<br />
ssh repos.archlinux.org "/community/db-remove <repo> <arch> <package_name>"<br />
<br />
e.g.<br />
<br />
ssh repos.archlinux.org "/community/db-remove community x86_64 jack2"<br />
<br />
If removing the package from the repositories altogether, it is encouraged to remove the entire package directory from version control as well.<br />
<br />
svn update <package_name><br />
svn rm --force <package_name><br />
svn commit <package_name> -m "Deleting <package_name> because of reason."<br />
<br />
Sometime the previous command yields:<br />
svn: E155035: "'/path/to/pkg/<PKG>' is the root of a working copy and cannot be deleted"<br />
<br />
You can remotely remove it with:<br />
svn rm svn+ssh://svn-packages@repos.archlinux.org/srv/repos/svn-packages/svn/<PKG><br />
<br />
=== Moving a package between repos ===<br />
Using {{ic|db-move}} will move a package between two binary repositories.<br />
<br />
To move a package somewhere between [[Official_repositories#core|core]], [[Official_repositories#extra|extra]], [[Official_repositories#gnome-unstable|gnome-unstable]], [[Official_repositories#kde-unstable|kde-unstable]], [[Official_repositories#Staging_repositories|staging]], or [[Official_repositories#testing|testing]] use:<br />
<br />
ssh repos.archlinux.org "/packages/db-move <from_repo> <to_repo> <package_name>"<br />
<br />
e.g.:<br />
<br />
ssh repos.archlinux.org "/packages/db-move testing core openssh"<br />
<br />
To move a package somewhere between [[Official_repositories#community|community]], [[Official_repositories#Staging_repositories|community-staging]], [[Official_repositories#community-testing|community-testing]], [[Official_repositories#multilib|multilib]], [[Official_repositories#Staging_repositories|multilib-staging]], or [[Official_repositories#multilib-testing|multilib-testing]] use:<br />
<br />
ssh repos.archlinux.org "/community/db-move <from_repo> <to_repo> <package_name>"<br />
<br />
e.g.:<br />
<br />
ssh repos.archlinux.org "/community/db-move community-testing community jack2"<br />
<br />
Alternatively, the move from testing is so common, that there are helper scripts:<br />
<br />
/packages/testing2x openssh bzip2 coreutils<br />
/packages/testing2x64 openssh bzip2 coreutils<br />
<br />
These scripts only work if the packages on the commandline are either in ''core'' or ''extra''.<br />
If a package is only in testing, you have to use ''testing2core'', ''testing2core64'', ''testing2extra'' or ''testing2extra64''.<br />
<br />
For the special case of moving a binary package and its version controlled [[PKGBUILD]] (and potentially additional files) between [[Official_repositories#community|community]] and [[Official_repositories#extra|extra]] (either direction), there are the two devtools helper scripts {{ic|community2extra}} and {{ic|extra2community}}.<br />
<br />
E.g. to move a a package from [[Official_repositories#community|community]] to [[Official_repositories#extra|extra]], use:<br />
community2extra <package_name><br />
<br />
=== "Tagging" releases ===<br />
<br />
Fetch the package dir using {{ic|archco}} or {{ic|communityco}} or from an svn checkout.<br />
Then:<br />
cd package-name/trunk<br />
archrelease extra-x86_64<br />
<br />
This makes an svn copy of the trunk entries in a directory named {{ic|extra-x86_64}} indicating that this package is in the extra repository for the ''x86_64'' architecture.<br />
This will be done automatically when using tools such as {{ic|extrapkg}} (see [[#Use devtools to sign, upload and commit|Use devtools to sign, upload and commit]]).<br />
<br />
== Miscellaneous Stuff ==<br />
<br />
=== Cleaning up your checkout ===<br />
<br />
Since you are now maintaining a non-recursive checkout, you may want to get rid of packages that you are no longer tracking:<br />
<br />
svn update package1 package2 --set-depth exclude<br />
<br />
Or if you want an empty toplevel again:<br />
<br />
svn update --set-depth empty<br />
<br />
=== Avoid having to enter your password all the time ===<br />
<br />
When working with {{ic|extrapkg}} and the other devtools, quite a few ssh connections are established, even when using ssh keys and the ssh agent.<br />
You can work around that.<br />
<br />
Add this to your {{ic|~/.ssh/config}}:<br />
<br />
ControlPath ~/.ssh/master-%h-%p-%r<br />
<br />
Host repos.archlinux.org<br />
<br />
Now, before you start working, open a ssh session with<br />
<br />
ssh -M repos.archlinux.org<br />
<br />
Enter your password and leave that session open until you are finished.<br />
All ssh sessions (including scp and svn+ssh) will now be tunneled through this connection.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Pushing to the wrong repository ===<br />
<br />
If you find yourself accidentally having pushed a package to the wrong repository (e.g. running {{ic|communitypkg}} instead of {{ic|extrapkg}} against {{ic|example-1.0.0-any.pkg.tar.zst}}) you can undo it.<br />
<br />
{{Note|This only applies to cases where the [[#Update the Repository|repository update]] has not been done yet. If the repository has been updated already, refer to [[#Moving a package between repos|moving a package between repos]].}}<br />
<br />
Remove the package from the staging location on the repos server:<br />
<br />
ssh repos.archlinux.org "rm staging/community/example-1.0.0-any.pkg.tar.zst*"<br />
<br />
Update your local svn directory and remove the wrong repos entry (assuming you are already in {{ic|svn-packages/example/}}):<br />
<br />
svn update<br />
svn rm repos/community-any<br />
svn commit -m "Cleanup after accidental push to community."<br />
<br />
Afterwards, proceed again with [[#Use devtools to sign, upload and commit|signing, uploading and committing]].</div>Jellyhttps://wiki.archlinux.org/index.php?title=DeveloperWiki:How_to_be_a_packager&diff=664039DeveloperWiki:How to be a packager2021-04-24T20:33:46Z<p>Jelly: /* Helper Scripts (optional) */ Add more arch utilities</p>
<hr />
<div>[[Category:DeveloperWiki]]<br />
== Follow Package Guidelines ==<br />
<br />
Package guidelines can be found in the Arch Linux documentation.<br />
Please follow them closely.<br />
<br />
[[Arch packaging standards]]<br />
<br />
== Preparation and Setup ==<br />
<br />
=== Installing the Packages ===<br />
<br />
Make sure you have the packages {{ic|devtools}} and {{ic|namcap}} installed.<br />
<br />
=== SSH Config ===<br />
<br />
If you have multiple SSH keys in your SSH Agent, you will need to make sure that the correct key is being used to contact the Arch servers.<br />
Also, when your local username differs from the one being used on the Arch servers, you need to take care of that too.<br />
<br />
Example {{ic|~/.ssh/config}} excerpt:<br />
{{bc|<br />
host repos.archlinux.org<br />
hostname repos.archlinux.org<br />
port 22<br />
user foobar<br />
IdentityFile ~/.ssh/id_arch<br />
IdentitiesOnly yes<br />
}}<br />
<br />
=== makepkg Config ===<br />
<br />
Make sure to configure your {{ic|~/.makepkg.conf}} with the correct {{ic|PACKAGER}} and {{ic|GPGKEY}} variables.<br />
Wrong signatures or missing {{ic|PACKAGER}} will prevent your packages from entering the repository.<br />
<br />
{{bc|1=<br />
PACKAGER="Foo Bar <foo.bar@archlinux.org>"<br />
GPGKEY="0x0123456789abcdef"<br />
}}<br />
<br />
=== Local SVN Setup using Non-Recursive Checkouts ===<br />
<br />
As SVN provides the ability to do scoped checkouts you can initialize an empty local checkout and later on only fetch the packages that you want.<br />
To setup the local checkouts run the following commands.<br />
<br />
For core, extra, testing and staging repos:<br />
<br />
svn checkout -N svn+ssh://svn-packages@repos.archlinux.org/srv/repos/svn-packages/svn svn-packages<br />
<br />
For community, community-testing, community-staging, multilib, multilib-testing, multilib-staging:<br />
<br />
svn checkout -N svn+ssh://svn-community@repos.archlinux.org/srv/repos/svn-community/svn svn-community<br />
<br />
This creates two directories named {{ic|svn-packages}} and {{ic|svn-community}} which contain nothing but are properly setup as svn repositories.<br />
<br />
=== Helper Scripts (optional) ===<br />
<br />
==== {{pkg|arch-rebuild-order}} ====<br />
<br />
List the rebuild order of packages using the local pacman syncdb's.<br />
<br />
==== {{pkg|arch-signoff}} ====<br />
<br />
Signoff packages from [testing] interactively in your terminal.<br />
<br />
==== {{pkg|arch-repro-status}} ====<br />
<br />
List the reproducible status of your packages interactively in your terminal with the ability to see the build logs and diffoscope output per unreproducible package.<br />
<br />
==== {{pkg|archlinux-contrib}} ====<br />
<br />
Collection of contrib scripts used in Arch Linux.<br />
<br />
==== ch ====<br />
<br />
This shell script eases setting up and maintaining the chroots for building the packages immensely.<br />
The script has been developed by [https://archlinux.org/people/developers/#bluewind Bluewind] and can be found here: [https://git.server-speed.net/users/flo/bin/plain/ch ch].<br />
<br />
As this script relies on [[Btrfs]], you have to create a Btrfs volume (20GiB is mostly sufficient), which can either be a file, a logical volume or a dedicated partition.<br />
Furthermore by default this script assumes that the Btrfs for the chroots is mounted at {{ic|/mnt/chroots/arch}}.<br />
<br />
Afterwards you can create a 64bit package using:<br />
<br />
ch build 64<br />
<br />
(automatically and conveniently invokes makechrootpkg with all required arguments)<br />
<br />
For further details please take a look at the head of the script, it provides some explanations and usage examples.<br />
<br />
== The Workflow ==<br />
<br />
=== Checkout/update your Local Repository ===<br />
cd svn-community<br />
# update a specific package<br />
svn update <package_name><br />
# update all packages<br />
svn update<br />
<br />
=== Adding a new Package ===<br />
This step is only required when adding a new package to the repository for the first time.<br />
cd svn-community<br />
mkdir -p new-package/{repos,trunk}<br />
cd new-package<br />
cp /usr/share/pacman/PKGBUILD.proto trunk/PKGBUILD<br />
$EDITOR trunk/PKGBUILD<br />
svn add .<br />
svn commit<br />
<br />
=== Updating the needed Package ===<br />
svn update some-package<br />
<br />
=== Change and build ===<br />
It is '''mandatory''' to build your package using a clean [[DeveloperWiki:Building_in_a_Clean_Chroot|chroot]].<br />
To ensure this, build with the scripts provided by devtools (i.e. {{ic|extra-x86_64-build}} for [[Official_repositories#extra|extra]] and [[Official_repositories#community|community]], {{ic|multilib-build}} for [[Official_repositories#multilib|multilib]], {{ic|multilib-staging-build}} for [[Official_repositories#Staging_repositories|multilib-staging]], {{ic|multilib-testing-build}} for [[Official_repositories#multilib-testing|multilib-testing]], {{ic|staging-x86_64-build}} for [[Official_repositories#Staging_repositories|staging]] and [[Official_repositories#Staging_repositories|community-staging]], {{ic|testing-x86_64-build}} for [[Official_repositories#testing|testing]] and [[Official_repositories#community-testing|community-testing]]).<br />
<br />
cd some-package/trunk/<br />
$EDITOR PKGBUILD<br />
extra-x86_64-build<br />
<br />
Or, if you are using the [[#ch|ch]] helper, simply do:<br />
cd some-package/trunk/<br />
$EDITOR PKGBUILD<br />
ch clean 64<br />
ch update 64<br />
ch build 64<br />
<br />
=== Run namcap on both PKGBUILD and Package ===<br />
{{Note|This is automatically done, when using the devtools build scripts.}}<br />
namcap PKGBUILD<br />
namcap some-package-1.0-1-x86_64.pkg.tar.xz<br />
<br />
=== Run checkpkg on the Package ===<br />
Run in the directory with your freshly built package to get a file list diff compared with the package version currently in the repos.<br />
checkpkg<br />
<br />
{{Note|This can be skipped when adding a new package to the repository for the first time (e.g. by importing it from [[AUR]] to [[Official_repositories#community|community]]).}}<br />
<br />
=== Run sogrep on identified soname change ===<br />
If [[#Run checkpkg on the Package|checkpkg]] identified a shared object name (aka. soname) change in {{ic|package}}'s library {{ic|package.so}}, it is '''required''' to rebuild packages directly depending on it.<br />
<br />
To identify which packages rely on a given library in {{ic|package}} in a repository (e.g. {{ic|extra}} or {{ic|community}}), use sogrep (see {{man|1|sogrep}}).<br />
sogrep <repository> package.so<br />
<br />
Build {{ic|package}} for its respective [[Official_repositories#Staging_repositories|staging]] environment (by following the remaining steps in [[#The Workflow|The Workflow]]) and create a [https://archlinux.org/todo/ TODO] with the identified dependants, so their maintainers can rebuild them against the new version of {{ic|package}}.<br />
<br />
{{Note|First sync with [https://archlinux.org/people/trusted-users/ trusted users] and/ or [https://archlinux.org/people/developers/ developers], if any packages currently in the [[Official_repositories#Staging_repositories|staging]] environment block the rebuilds against {{ic|package}}.}}<br />
<br />
=== Use devtools to sign, upload and commit ===<br />
Once you are satisfied with the package, you need to make sure all your changes are tracked in the repository.<br />
Run:<br />
<br />
svn status<br />
<br />
in the {{ic|some-package/trunk/}} directory and check the output carefully.<br />
If, for example, you have added a new {{ic|some-package.install}} file, you need to tell svn to track that file, e.g.:<br />
<br />
svn add some-package.install<br />
<br />
Make sure to '''never''' add the binary packages, makepkg logs, etc. to the repository!<br />
<br />
When you are ready to proceed, you can run the devtools scripts to sign, upload and commit your work (i.e. {{ic|communitypkg}} for [[Official_repositories#community|community]], {{ic|community-stagingpkg}} for [[Official_repositories#Staging_repositories|community-staging]], {{ic|community-testingpkg}} for [[Official_repositories#community-testing|community-testing]], {{ic|extrapkg}} for [[Official_repositories#extra|extra]], {{ic|gnome-unstablepkg}} for [[Official_repositories#gnome-unstable|gnome-unstable]], {{ic|kde-unstablepkg}} for [[Official_repositories#kde-unstable|kde-unstable]], {{ic|multilibpkg}} for [[Official_repositories#multilib|multilib]], {{ic|multilib-stagingpkg}} for [[Official_repositories#Staging_repositories|multilib-staging]], {{ic|multilib-testingpkg}} for [[Official_repositories#multilib-testing|multilib-testing]], {{ic|stagingpkg}} for [[Official_repositories#Staging_repositories|staging]], {{ic|testingpkg}} for [[Official_repositories#testing|testing]]), e.g.:<br />
<br />
extrapkg "update to 1.2.3, add post_upgrade hook to fix permissions"<br />
<br />
Please try to write concise commit messages.<br />
If the package is simply an upstream change, that is fine, but if anything more complex changes, please inform us by writing an appropriate commit message.<br />
<br />
This will upload the package and its signature to their repository specific location in your user's {{ic|~/staging}} directory on {{ic|repos.archlinux.org}}.<br />
<br />
=== Update the Repository ===<br />
Using {{ic|db-update}} will find new packages for a set of repositories, depending on which is being called.<br />
<br />
To release uploaded packages to [[Official_repositories#core|core]], [[Official_repositories#extra|extra]], [[Official_repositories#gnome-unstable|gnome-unstable]], [[Official_repositories#kde-unstable|kde-unstable]], [[Official_repositories#Staging_repositories|staging]], or [[Official_repositories#testing|testing]] use:<br />
<br />
ssh repos.archlinux.org "/packages/db-update"<br />
<br />
To release uploaded packages to [[Official_repositories#community|community]], [[Official_repositories#Staging_repositories|community-staging]], [[Official_repositories#community-testing|community-testing]], [[Official_repositories#multilib|multilib]], [[Official_repositories#Staging_repositories|multilib-staging]], or [[Official_repositories#multilib-testing|multilib-testing]] use:<br />
<br />
ssh repos.archlinux.org "/community/db-update"<br />
<br />
== Other Operations ==<br />
<br />
=== Removing a Package ===<br />
Using {{ic|db-remove}} will remove a package from a specific binary repository.<br />
<br />
To remove a package from [[Official_repositories#core|core]], [[Official_repositories#extra|extra]], [[Official_repositories#gnome-unstable|gnome-unstable]], [[Official_repositories#kde-unstable|kde-unstable]], [[Official_repositories#Staging_repositories|staging]], or [[Official_repositories#testing|testing]] use:<br />
<br />
ssh repos.archlinux.org "/packages/db-remove <repo> <arch> <package_name>"<br />
<br />
e.g.<br />
<br />
ssh repos.archlinux.org "/packages/db-remove core x86_64 openssh"<br />
<br />
To remove a package from [[Official_repositories#community|community]], [[Official_repositories#Staging_repositories|community-staging]], [[Official_repositories#community-testing|community-testing]], [[Official_repositories#multilib|multilib]], [[Official_repositories#Staging_repositories|multilib-staging]], or [[Official_repositories#multilib-testing|multilib-testing]] use:<br />
<br />
ssh repos.archlinux.org "/community/db-remove <repo> <arch> <package_name>"<br />
<br />
e.g.<br />
<br />
ssh repos.archlinux.org "/community/db-remove community x86_64 jack2"<br />
<br />
If removing the package from the repositories altogether, it is encouraged to remove the entire package directory from version control as well.<br />
<br />
svn update <package_name><br />
svn rm --force <package_name><br />
svn commit <package_name> -m "Deleting <package_name> because of reason."<br />
<br />
Sometime the previous command yields:<br />
svn: E155035: "'/path/to/pkg/<PKG>' is the root of a working copy and cannot be deleted"<br />
<br />
You can remotely remove it with:<br />
svn rm svn+ssh://svn-packages@repos.archlinux.org/srv/repos/svn-packages/svn/<PKG><br />
<br />
=== Moving a package between repos ===<br />
Using {{ic|db-move}} will move a package between two binary repositories.<br />
<br />
To move a package somewhere between [[Official_repositories#core|core]], [[Official_repositories#extra|extra]], [[Official_repositories#gnome-unstable|gnome-unstable]], [[Official_repositories#kde-unstable|kde-unstable]], [[Official_repositories#Staging_repositories|staging]], or [[Official_repositories#testing|testing]] use:<br />
<br />
ssh repos.archlinux.org "/packages/db-move <from_repo> <to_repo> <package_name>"<br />
<br />
e.g.:<br />
<br />
ssh repos.archlinux.org "/packages/db-move testing core openssh"<br />
<br />
To move a package somewhere between [[Official_repositories#community|community]], [[Official_repositories#Staging_repositories|community-staging]], [[Official_repositories#community-testing|community-testing]], [[Official_repositories#multilib|multilib]], [[Official_repositories#Staging_repositories|multilib-staging]], or [[Official_repositories#multilib-testing|multilib-testing]] use:<br />
<br />
ssh repos.archlinux.org "/community/db-move <from_repo> <to_repo> <package_name>"<br />
<br />
e.g.:<br />
<br />
ssh repos.archlinux.org "/community/db-move community-testing community jack2"<br />
<br />
Alternatively, the move from testing is so common, that there are helper scripts:<br />
<br />
/packages/testing2x openssh bzip2 coreutils<br />
/packages/testing2x64 openssh bzip2 coreutils<br />
<br />
These scripts only work if the packages on the commandline are either in ''core'' or ''extra''.<br />
If a package is only in testing, you have to use ''testing2core'', ''testing2core64'', ''testing2extra'' or ''testing2extra64''.<br />
<br />
For the special case of moving a binary package and its version controlled [[PKGBUILD]] (and potentially additional files) between [[Official_repositories#community|community]] and [[Official_repositories#extra|extra]] (either direction), there are the two devtools helper scripts {{ic|community2extra}} and {{ic|extra2community}}.<br />
<br />
E.g. to move a a package from [[Official_repositories#community|community]] to [[Official_repositories#extra|extra]], use:<br />
community2extra <package_name><br />
<br />
=== "Tagging" releases ===<br />
<br />
Fetch the package dir using {{ic|archco}} or {{ic|communityco}} or from an svn checkout.<br />
Then:<br />
cd package-name/trunk<br />
archrelease extra-x86_64<br />
<br />
This makes an svn copy of the trunk entries in a directory named {{ic|extra-x86_64}} indicating that this package is in the extra repository for the ''x86_64'' architecture.<br />
This will be done automatically when using tools such as {{ic|extrapkg}} (see [[#Use devtools to sign, upload and commit|Use devtools to sign, upload and commit]]).<br />
<br />
== Miscellaneous Stuff ==<br />
<br />
=== Cleaning up your checkout ===<br />
<br />
Since you are now maintaining a non-recursive checkout, you may want to get rid of packages that you are no longer tracking:<br />
<br />
svn update package1 package2 --set-depth exclude<br />
<br />
Or if you want an empty toplevel again:<br />
<br />
svn update --set-depth empty<br />
<br />
=== Avoid having to enter your password all the time ===<br />
<br />
When working with {{ic|extrapkg}} and the other devtools, quite a few ssh connections are established, even when using ssh keys and the ssh agent.<br />
You can work around that.<br />
<br />
Add this to your {{ic|~/.ssh/config}}:<br />
<br />
ControlPath ~/.ssh/master-%h-%p-%r<br />
<br />
Host repos.archlinux.org<br />
<br />
Now, before you start working, open a ssh session with<br />
<br />
ssh -M repos.archlinux.org<br />
<br />
Enter your password and leave that session open until you are finished.<br />
All ssh sessions (including scp and svn+ssh) will now be tunneled through this connection.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Pushing to the wrong repository ===<br />
<br />
If you find yourself accidentally having pushed a package to the wrong repository (e.g. running {{ic|communitypkg}} instead of {{ic|extrapkg}} against {{ic|example-1.0.0-any.pkg.tar.zst}}) you can undo it.<br />
<br />
{{Note|This only applies to cases where the [[#Update the Repository|repository update]] has not been done yet. If the repository has been updated already, refer to [[#Moving a package between repos|moving a package between repos]].}}<br />
<br />
Remove the package from the staging location on the repos server:<br />
<br />
ssh repos.archlinux.org "rm staging/community/example-1.0.0-any.pkg.tar.zst*"<br />
<br />
Update your local svn directory and remove the wrong repos entry (assuming you are already in {{ic|svn-packages/example/}}):<br />
<br />
svn update<br />
svn rm repos/community-any<br />
svn commit -m "Cleanup after accidental push to community."<br />
<br />
Afterwards, proceed again with [[#Use devtools to sign, upload and commit|signing, uploading and committing]].</div>Jellyhttps://wiki.archlinux.org/index.php?title=Keycloak&diff=656038Keycloak2021-03-25T15:58:39Z<p>Jelly: /* Keycloak Prometheus metrics */ remove whitespace</p>
<hr />
<div>[[Category:Authentication]]<br />
[[Wikipedia:Keycloak|Keycloak]] is an identity management solution implemented in Java that can be used as an authentication backend for many different applications.<br />
<br />
== Installation ==<br />
<br />
Install the {{Pkg|keycloak}} package.<br />
<br />
== Running ==<br />
<br />
[[Start/enable]] {{ic|keycloak.service}}. In the default configuration, it will start in standalone mode which is not recommended for production environments but will be used in this article for the sake of simplicity.<br />
<br />
By default, Keycloak is available on http://127.0.0.1:8080/auth/ and https://127.0.0.1:8443/auth/.<br />
<br />
== Creating an admin user ==<br />
<br />
The recommended way to create a Keycloak admin user is via the included {{ic|add-user-keycloak.sh}} utility as Keycloak does not have to be running for that operation.<br />
<br />
/opt/keycloak/bin/add-user-keycloak.sh -u my-keycloak-user -p my-keycloak-password<br />
<br />
This command creates a file at {{ic|/opt/keycloak/standalone/configuration/keycloak-add-user.json}} that contains your user information.<br />
<br />
== Configuration ==<br />
<br />
The default standalone configuration can be found at {{ic|/etc/keycloak/standalone.xml}}.<br />
<br />
Any changes you make to this file while the server is running will not take effect and may even be overwritten by the server. Either stop the service beforehand, use the command line scripting or use the web console of WildFly.<br />
<br />
The ports used by the service can found in that file, albeit in a slightly unusual format:<br />
<br />
{{hc|/etc/keycloak/standalone.xml|<nowiki><br />
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}"><br />
<socket-binding name="ajp" port="${jboss.ajp.port:8009}"/><br />
<socket-binding name="http" port="${jboss.http.port:8080}"/><br />
<socket-binding name="https" port="${jboss.https.port:8443}"/> <br />
<socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/><br />
<socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/><br />
<socket-binding name="txn-recovery-environment" port="4712"/><br />
<socket-binding name="txn-status-manager" port="4713"/><br />
<outbound-socket-binding name="mail-smtp"><br />
<remote-destination host="localhost" port="25"/><br />
</outbound-socket-binding><br />
</socket-binding-group><br />
</nowiki>}}<br />
<br />
=== H2 configuration ===<br />
<br />
Keycloak's {{ic|standalone.xml}} file is preconfigured with two [https://www.h2database.com/html/main.html h2] datasources. One is "ExampleDS", and can be safely removed. The other is "KeycloakDS" and is used to store Keycloak's configuration. ({{ic|jboss.home.dir}} refers to {{ic|/opt/keycloak}} in the Keycloak package)<br />
<br />
Example configuration parts for the H2 file-based database:<br />
<br />
{{hc|/etc/keycloak/standalone.xml|<nowiki><br />
<subsystem xmlns="urn:jboss:domain:datasources:5.0"><br />
<datasources><br />
<datasource jndi-name="java:jboss/datasources/ExampleDS" pool-name="ExampleDS" enabled="true" use-java-context="true" statistics-enabled="${wildfly.datasources.statistics-enabled:${wildfly.statistics-enabled:false}}"><br />
<connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE</connection-url><br />
<driver>h2</driver><br />
<security><br />
<user-name>sa</user-name><br />
<password>sa</password><br />
</security><br />
</datasource><br />
<datasource jndi-name="java:jboss/datasources/KeycloakDS" pool-name="KeycloakDS" enabled="true" use-java-context="true" statistics-enabled="${wildfly.datasources.statistics-enabled:${wildfly.statistics-enabled:false}}"><br />
<connection-url>jdbc:h2:${jboss.server.data.dir}/keycloak;AUTO_SERVER=TRUE</connection-url><br />
<driver>h2</driver><br />
<security><br />
<user-name>sa</user-name><br />
<password>sa</password><br />
</security><br />
</datasource><br />
<drivers><br />
<driver name="h2" module="com.h2database.h2"><br />
<xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class><br />
</driver><br />
</drivers><br />
</datasources><br />
</subsystem><br />
...<br />
<default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/datasources/KeycloakDS" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/><br />
</nowiki>}}<br />
<br />
=== PostgreSQL configuration ===<br />
<br />
The official Arch Linux Keycloak package already comes with inbuilt PostgreSQL support.<br />
<br />
Example configuration parts for PostgreSQL:<br />
<br />
{{hc|/etc/keycloak/standalone.xml|<nowiki><br />
<subsystem xmlns="urn:jboss:domain:datasources:5.0"><br />
<datasources><br />
<datasource jndi-name="java:jboss/datasources/KeycloakDS" pool-name="KeycloakDS" enabled="true" use-java-context="true" statistics-enabled="${wildfly.datasources.statistics-enabled:${wildfly.statistics-enabled:false}}"><br />
<connection-url>jdbc:postgresql://localhost:5432/keycloak</connection-url><br />
<driver>postgresql</driver><br />
<security><br />
<user-name>keycloak</user-name><br />
<password>keycloak</password><br />
</security><br />
</datasource><br />
<drivers><br />
<driver name="postgresql" module="org.postgresql"><br />
<xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class><br />
</driver><br />
</drivers><br />
</datasources><br />
</subsystem><br />
...<br />
<default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/datasources/KeycloakDS" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/><br />
</nowiki>}}<br />
<br />
=== Keycloak Prometheus metrics ===<br />
<br />
Install the {{Pkg|keycloak-metrics-spi}} package. To enable the metrics listener endpoint<br />
<br />
/opt/keycloak/bin/kcadm.sh config credentials --server http://localhost:8080/auth --realm master --user $KEYCLOAK_ADMIN --password $KEYCLOAK_PASS<br />
/opt/keycloak/bin/kcadm.sh update events/config -s "eventsEnabled=true" -s "adminEventsEnabled=true" -s "eventsListeners+=metrics-listener"<br />
<br />
The config command creates a kcadm.config file in the .keycloak directory of the user who runs the command. As contains an access token, it is recommend to remove the file after <br />
<br />
rm /home/$USER/.keycloak/kcadm.config<br />
<br />
After restarting the metrics are available via http://localhost:8080/auth/realms/master/metrics<br />
<br />
== External links ==<br />
<br />
* [https://devopstales.github.io/sso/keycloak2/ Configuring Keycloak with Postgres]<br />
* [https://www.keycloak.org/docs/ Official Keycloak documentation]</div>Jellyhttps://wiki.archlinux.org/index.php?title=Keycloak&diff=656037Keycloak2021-03-25T15:58:20Z<p>Jelly: add prometheus metrics</p>
<hr />
<div>[[Category:Authentication]]<br />
[[Wikipedia:Keycloak|Keycloak]] is an identity management solution implemented in Java that can be used as an authentication backend for many different applications.<br />
<br />
== Installation ==<br />
<br />
Install the {{Pkg|keycloak}} package.<br />
<br />
== Running ==<br />
<br />
[[Start/enable]] {{ic|keycloak.service}}. In the default configuration, it will start in standalone mode which is not recommended for production environments but will be used in this article for the sake of simplicity.<br />
<br />
By default, Keycloak is available on http://127.0.0.1:8080/auth/ and https://127.0.0.1:8443/auth/.<br />
<br />
== Creating an admin user ==<br />
<br />
The recommended way to create a Keycloak admin user is via the included {{ic|add-user-keycloak.sh}} utility as Keycloak does not have to be running for that operation.<br />
<br />
/opt/keycloak/bin/add-user-keycloak.sh -u my-keycloak-user -p my-keycloak-password<br />
<br />
This command creates a file at {{ic|/opt/keycloak/standalone/configuration/keycloak-add-user.json}} that contains your user information.<br />
<br />
== Configuration ==<br />
<br />
The default standalone configuration can be found at {{ic|/etc/keycloak/standalone.xml}}.<br />
<br />
Any changes you make to this file while the server is running will not take effect and may even be overwritten by the server. Either stop the service beforehand, use the command line scripting or use the web console of WildFly.<br />
<br />
The ports used by the service can found in that file, albeit in a slightly unusual format:<br />
<br />
{{hc|/etc/keycloak/standalone.xml|<nowiki><br />
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}"><br />
<socket-binding name="ajp" port="${jboss.ajp.port:8009}"/><br />
<socket-binding name="http" port="${jboss.http.port:8080}"/><br />
<socket-binding name="https" port="${jboss.https.port:8443}"/> <br />
<socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/><br />
<socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/><br />
<socket-binding name="txn-recovery-environment" port="4712"/><br />
<socket-binding name="txn-status-manager" port="4713"/><br />
<outbound-socket-binding name="mail-smtp"><br />
<remote-destination host="localhost" port="25"/><br />
</outbound-socket-binding><br />
</socket-binding-group><br />
</nowiki>}}<br />
<br />
=== H2 configuration ===<br />
<br />
Keycloak's {{ic|standalone.xml}} file is preconfigured with two [https://www.h2database.com/html/main.html h2] datasources. One is "ExampleDS", and can be safely removed. The other is "KeycloakDS" and is used to store Keycloak's configuration. ({{ic|jboss.home.dir}} refers to {{ic|/opt/keycloak}} in the Keycloak package)<br />
<br />
Example configuration parts for the H2 file-based database:<br />
<br />
{{hc|/etc/keycloak/standalone.xml|<nowiki><br />
<subsystem xmlns="urn:jboss:domain:datasources:5.0"><br />
<datasources><br />
<datasource jndi-name="java:jboss/datasources/ExampleDS" pool-name="ExampleDS" enabled="true" use-java-context="true" statistics-enabled="${wildfly.datasources.statistics-enabled:${wildfly.statistics-enabled:false}}"><br />
<connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE</connection-url><br />
<driver>h2</driver><br />
<security><br />
<user-name>sa</user-name><br />
<password>sa</password><br />
</security><br />
</datasource><br />
<datasource jndi-name="java:jboss/datasources/KeycloakDS" pool-name="KeycloakDS" enabled="true" use-java-context="true" statistics-enabled="${wildfly.datasources.statistics-enabled:${wildfly.statistics-enabled:false}}"><br />
<connection-url>jdbc:h2:${jboss.server.data.dir}/keycloak;AUTO_SERVER=TRUE</connection-url><br />
<driver>h2</driver><br />
<security><br />
<user-name>sa</user-name><br />
<password>sa</password><br />
</security><br />
</datasource><br />
<drivers><br />
<driver name="h2" module="com.h2database.h2"><br />
<xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class><br />
</driver><br />
</drivers><br />
</datasources><br />
</subsystem><br />
...<br />
<default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/datasources/KeycloakDS" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/><br />
</nowiki>}}<br />
<br />
=== PostgreSQL configuration ===<br />
<br />
The official Arch Linux Keycloak package already comes with inbuilt PostgreSQL support.<br />
<br />
Example configuration parts for PostgreSQL:<br />
<br />
{{hc|/etc/keycloak/standalone.xml|<nowiki><br />
<subsystem xmlns="urn:jboss:domain:datasources:5.0"><br />
<datasources><br />
<datasource jndi-name="java:jboss/datasources/KeycloakDS" pool-name="KeycloakDS" enabled="true" use-java-context="true" statistics-enabled="${wildfly.datasources.statistics-enabled:${wildfly.statistics-enabled:false}}"><br />
<connection-url>jdbc:postgresql://localhost:5432/keycloak</connection-url><br />
<driver>postgresql</driver><br />
<security><br />
<user-name>keycloak</user-name><br />
<password>keycloak</password><br />
</security><br />
</datasource><br />
<drivers><br />
<driver name="postgresql" module="org.postgresql"><br />
<xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class><br />
</driver><br />
</drivers><br />
</datasources><br />
</subsystem><br />
...<br />
<default-bindings context-service="java:jboss/ee/concurrency/context/default" datasource="java:jboss/datasources/KeycloakDS" managed-executor-service="java:jboss/ee/concurrency/executor/default" managed-scheduled-executor-service="java:jboss/ee/concurrency/scheduler/default" managed-thread-factory="java:jboss/ee/concurrency/factory/default"/><br />
</nowiki>}}<br />
<br />
=== Keycloak Prometheus metrics ===<br />
<br />
Install the {{Pkg|keycloak-metrics-spi}} package. To enable the metrics listener endpoint<br />
<br />
<br />
/opt/keycloak/bin/kcadm.sh config credentials --server http://localhost:8080/auth --realm master --user $KEYCLOAK_ADMIN --password $KEYCLOAK_PASS<br />
/opt/keycloak/bin/kcadm.sh update events/config -s "eventsEnabled=true" -s "adminEventsEnabled=true" -s "eventsListeners+=metrics-listener"<br />
<br />
The config command creates a kcadm.config file in the .keycloak directory of the user who runs the command. As contains an access token, it is recommend to remove the file after <br />
<br />
rm /home/$USER/.keycloak/kcadm.config<br />
<br />
After restarting the metrics are available via http://localhost:8080/auth/realms/master/metrics<br />
<br />
== External links ==<br />
<br />
* [https://devopstales.github.io/sso/keycloak2/ Configuring Keycloak with Postgres]<br />
* [https://www.keycloak.org/docs/ Official Keycloak documentation]</div>Jellyhttps://wiki.archlinux.org/index.php?title=User:Jelly/nginx_packaging_guidelines&diff=653329User:Jelly/nginx packaging guidelines2021-02-24T21:13:20Z<p>Jelly: initial commit</p>
<hr />
<div>This document covers proposed standards and guidelines on writing [[PKGBUILD]]s for [[nginx]] modules.<br />
<br />
== General guidelines ==<br />
<br />
=== Package naming ===<br />
<br />
* nginx modules should be named {{ic|nginx-mod-''modulename''}}<br />
<br />
{{Note|The package name should be entirely lowercase.}}<br />
<br />
== Package ==<br />
<br />
All nginx modules have to be build with a full checkout of the nginx source code. Therefore Arch Linux packages a<br />
{{Pkg|nginx-src}} package which can be used to build the module as per following snippet:<br />
<br />
{{bc|<nowiki><br />
arch=('x86_64')<br />
depends=('nginx')<br />
makedepends=('nginx-src')<br />
...<br />
<br />
build() {<br />
cp -r /usr/src/nginx .<br />
<br />
cd nginx<br />
./configure --with-compat --add-dynamic-module=../$_modname-$pkgver<br />
make modules<br />
}<br />
<br />
package() {<br />
cd nginx/objs<br />
for mod in *.so; do<br />
install -Dm755 $mod "$pkgdir"/usr/lib/nginx/modules/$mod<br />
done<br />
}<br />
</nowiki>}}<br />
<br />
== Example packages ==<br />
<br />
* {{Pkg|nginx-mod-brotli}}</div>Jellyhttps://wiki.archlinux.org/index.php?title=Conky/Tips_and_tricks&diff=650391Conky/Tips and tricks2021-01-31T21:49:20Z<p>Jelly: Fix rss interval being in seconds not minutes....</p>
<hr />
<div>[[Category:System monitors]]<br />
{{Related articles start}}<br />
{{Related|Conky}}<br />
{{Related articles end}}<br />
<br />
{{Style|Conky's configuration changed and it is unknown if all of these tips migrated from the main article are still working/relevant.}}<br />
<br />
Go back to [[Conky]].<br />
<br />
== Display package update information ==<br />
<br />
{{Pkg|pacman-contrib}} provides a script called {{ic|checkupdates}} which displays package updates from the official repos. Use {{ic|<nowiki>${execi 3600 checkupdates | wc -l}</nowiki>}} to display the total number of packages.<br />
<br />
== Display log files ==<br />
<br />
One of the nice features of ''conky'' is to pipe to your desktop some {{ic|/var/log/}} files to read all kinds of log messages. Most of these files can only be read by {{ic|root}}, but running ''conky'' as {{ic|root}} is not recommended, so you will need to add {{ic|''username''}} to the {{ic|log}} group:<br />
# usermod -aG log ''username''<br />
<br />
== Display weather forecast ==<br />
<br />
See [https://bbs.archlinux.org/viewtopic.php?id=37381 this thread].<br />
<br />
Another weather script in lua: [https://bbs.archlinux.org/viewtopic.php?id=222998 here]<br />
<br />
== Display a countdown timer ==<br />
[https://github.com/orschiro/scriptlets/tree/master/ConkyTimer ConkyTimer] is a simple countdown timer that displays the remaining time of a defined task.<br />
<br />
Start the timer using {{ic|conkytimer "<task description>" <min>}}.<br />
<br />
== Display RSS feeds ==<br />
<br />
''Conky'' has the ability to display RSS feeds natively without the need for an outside script to run and output into Conky. For example, to display the titles of the ten most recent Planet Arch updates and refresh the feed every minute, you would put this into your {{ic|conky.conf}} in the {{ic|TEXT}} section:<br />
<br />
${rss https://planet.archlinux.org/rss20.xml 300 item_titles 10 }<br />
If you want to display Arch Forum rss feed, add this line:<br />
${rss https://bbs.archlinux.org/extern.php?action=feed&type=rss 300 item_titles 4}<br />
where 300 is in seconds the refresh interval (15 minutes is default), 4 the number of items you wish to show.<br />
<br />
== Display a calendar for the current month ==<br />
<br />
You can use the following lua script to display a calendar. It uses {{ic|color1}} and the default color from your configuration. It looks best with a monospace font.<br />
<br />
#!/usr/bin/env lua<br />
<br />
conky_color = "${color1}%2d${color}"<br />
<br />
t = os.date('*t', os.time())<br />
year, month, currentday = t.year, t.month, t.day<br />
<br />
daystart = os.date("*t",os.time{year=year,month=month,day=01}).wday<br />
<br />
month_name = os.date("%B")<br />
<br />
days_in_month = {<br />
31, 28, 31, 30, 31, 30, <br />
31, 31, 30, 31, 30, 31<br />
}<br />
<br />
-- check for leap year<br />
-- Any year that is evenly divisible by 4 is a leap year<br />
-- Any year that is evenly divisible by 100 is a leap year if<br />
-- it is also evenly divisible by 400.<br />
LeapYear = function (year)<br />
return year % 4 == 0 and (year % 100 ~= 0 or year % 400 == 0)<br />
end<br />
<br />
if LeapYear(year) then<br />
days_in_month[2] = 29<br />
end<br />
<br />
title_start = (20 - (string.len(month_name) + 5)) / 2<br />
<br />
title = string.rep(" ", math.floor(title_start+0.5)) .. -- add padding to center the title<br />
(" %s %s\n Su Mo Tu We Th Fr Sa\n"):format(month_name, year)<br />
<br />
io.write(title)<br />
<br />
function seq(a,b)<br />
if a > b then<br />
return<br />
else<br />
return a, seq(a+1,b)<br />
end <br />
end<br />
<br />
days = days_in_month[month]<br />
<br />
io.write(<br />
string.format(<br />
string.rep(" ", daystart-1) ..<br />
string.rep(" %2d", days), seq(1,days)<br />
):gsub(string.rep(".",21),"%0\n")<br />
:gsub(("%2d"):format(currentday),<br />
(conky_color):format(currentday)<br />
) .. "\n"<br />
)<br />
<br />
Inside your {{ic|conky.conf}} you can then place the following, making sure the path matches where you saved the script.<br />
<br />
conky.text = [[<br />
${execpi 3600 ~/.config/conky/cal.lua}<br />
]]<br />
<br />
== Display rTorrent stats ==<br />
<br />
See [https://bbs.archlinux.org/viewtopic.php?id=67304 this thread].<br />
<br />
== Display your WordPress blog stats ==<br />
<br />
This can be achieved by using the in python written extension named [https://evilshit.wordpress.com/2013/04/20/conkypress-a-wordpress-stats-visualization-tool-for-your-desktop/ ConkyPress].<br />
<br />
== Display number of new emails ==<br />
<br />
Conky has built in support for IMAP and POP3, but does not have support for access over ssl. Conky's FAQ recommends using {{Pkg|stunnel}} for this and has an example configuration [http://conky.sourceforge.net/faq.html#Conky's-built-in-IMAP-and-POP3-doesn't-support-SSL-or-TLS/ here].<br />
<br />
Modify {{ic|/etc/stunnel/stunnel.conf}} as follows, and then [[start]] {{ic|stunnel.service}}:<br />
<br />
# Service-level configuration for TLS server<br />
[imap]<br />
client = yes<br />
accept = 143<br />
connect = imap.gmail.com:143<br />
protocol = imap<br />
sslVersion = TLSv1<br />
# Service-level configuration for SSL server<br />
[imaps]<br />
client = yes<br />
accept = 993<br />
connect = imap.gmail.com:993<br />
<br />
Then add the following to {{ic|conky.conf}}:<br />
<br />
conky.config = {<br />
imap = "localhost username password [-i 120] [-f 'inbox'] [-p 993]",<br />
}<br />
<br />
conky.text {<br />
Inbox: ${imap_unseen}/${imap_messages}<br />
}<br />
<br />
=== Gmail ===<br />
If you use 2-factor authentication, you need to use an [https://myaccount.google.com/apppasswords App Password].<br />
<br />
For method 1, 2 and 3:<br />
<br />
Create one of the following files in a convenient location (for example in {{ic|~/.scripts/}}).<br />
<br />
Then add the following string to your {{ic|conky.conf}} in order the check your Gmail account for new email every five minutes (300 seconds) and display:<br />
${execi 300 python ~/.scripts/gmail.py}<br />
<br />
==== method 1 ====<br />
This script uses retrieves the number of new email via Gmail's Atom API.<br />
{{hc|gmail.py|<nowiki><br />
#!/usr/bin/env python3<br />
<br />
import urllib.request<br />
<br />
email = 'your email'<br />
password = 'your password'<br />
<br />
# Set up authentication for gmail<br />
auth_handler = urllib.request.HTTPBasicAuthHandler()<br />
auth_handler.add_password(realm='mail.google.com',<br />
uri='https://mail.google.com/',<br />
user=email,<br />
passwd=password)<br />
opener = urllib.request.build_opener(auth_handler)<br />
# ...and install it globally so it can be used with urlopen.<br />
urllib.request.install_opener(opener)<br />
<br />
gmailurl = 'https://mail.google.com/gmail/feed/atom'<br />
with urllib.request.urlopen(gmailurl) as page:<br />
contents = page.read().decode('utf-8')<br />
<br />
ifrom = contents.index('<fullcount>') + 11<br />
ito = contents.index('</fullcount>')<br />
<br />
fullcount = contents[ifrom:ito]<br />
<br />
print('{} new emails'.format(fullcount))<br />
<br />
</nowiki>}}<br />
<br />
==== method 2 ====<br />
Same as method 1, but does proper XML parsing.<br />
<br />
{{hc|gmail.py|<nowiki><br />
#!/usr/bin/env python3<br />
<br />
import urllib.request<br />
from xml.etree import ElementTree as etree<br />
<br />
email = 'your email'<br />
password = 'your password'<br />
<br />
# Set up authentication for gmail<br />
auth_handler = urllib.request.HTTPBasicAuthHandler()<br />
auth_handler.add_password(realm='mail.google.com',<br />
uri='https://mail.google.com/',<br />
user=email,<br />
passwd=password)<br />
opener = urllib.request.build_opener(auth_handler)<br />
# ...and install it globally so it can be used with urlopen.<br />
urllib.request.install_opener(opener)<br />
<br />
gmailurl = 'https://mail.google.com/gmail/feed/atom'<br />
NS = '{http://purl.org/atom/ns#}'<br />
with urllib.request.urlopen(gmailurl) as source:<br />
tree = etree.parse(source)<br />
fullcount = tree.find(NS + 'fullcount').text<br />
<br />
print('{} new emails'.format(fullcount))<br />
</nowiki>}}<br />
<br />
==== method 3 ====<br />
<br />
The same way, but with using {{ic|curl}}, {{ic|grep}} and {{ic|sed}}:<br />
<br />
{{hc|gmail.sh|<br />
#!/usr/bin/sh<br />
<br />
curl -s -u '''email''':'''password''' <nowiki>https://mail.google.com/mail/feed/atom | grep fullcount | sed 's/<[^0-9]*>//g'</nowiki><br />
}}<br />
<br />
replace ''email'' and ''password'' with your data.<br />
<br />
==== IMAP + SSL using Perl ====<br />
<br />
''Conky'' has built in support for IMAP accounts but does not support SSL. This can be provided using this script from [http://www.unix.com/shell-programming-scripting/115322-perl-conky-gmail-imap-unread-message-count.html this forum post]. This requires the Perl/CPAN Modules Mail::IMAPClient and IO::Socket::SSL which are in the {{Pkg|perl-mail-imapclient}} and {{Pkg|perl-io-socket-ssl}} packages<br />
<br />
Create a file named {{ic|imap.pl}} in a location to be read by ''conky'' (for example in {{ic|~/.scripts/}}). In this file, add (with the appropriate changes):<br />
{{hc|imap.pl|<nowiki><br />
#!/usr/bin/perl<br />
<br />
# by gxmsgx<br />
# description: get the count of unread messages on imap<br />
<br />
use strict;<br />
use Mail::IMAPClient;<br />
use IO::Socket::SSL;<br />
<br />
my $username = 'example.username'; <br />
my $password = 'password123'; <br />
<br />
my $socket = IO::Socket::SSL->new(<br />
PeerAddr => 'imap.server',<br />
PeerPort => 993<br />
)<br />
or die "socket(): $@";<br />
<br />
my $client = Mail::IMAPClient->new(<br />
Socket => $socket,<br />
User => $username,<br />
Password => $password,<br />
)<br />
or die "new(): $@";<br />
<br />
if ($client->IsAuthenticated()) {<br />
my $msgct;<br />
<br />
$client->select("INBOX");<br />
$msgct = $client->unseen_count||'0';<br />
print "$msgct\n";<br />
}<br />
<br />
$client->logout();<br />
</nowiki>}}<br />
<br />
Add to {{ic|conky.conf}}:<br />
${execi 300 ~/.scripts/imap.pl} <br />
or wherever you saved the file.<br />
<br />
If you use Gmail you might need to [http://www.google.com/accounts/IssuedAuthSubTokens?hide_authsub=1 generate] an application specific password.<br />
<br />
Alternatively, you can use stunnel as shown above: [[#Gmail]]<br />
<br />
==== IMAP using PHP ====<br />
Another alternative using PHP. PHP needs to be installed and {{ic|1=extension=imap}} must be uncommented in {{ic|/etc/php/php.ini}}.<br />
<br />
Then create a file named {{ic|imap.php}} in a location to be read by ''conky'' (for example in {{ic|~/.scripts/}}). Make the file executable:<br />
$ chmod +x imap.php<br />
<br />
In this file, add (with the appropriate changes):<br />
<br />
{{hc|imap.php|<nowiki><br />
#!/usr/bin/php<br />
<?php<br />
// See http://php.net/manual/function.imap-open.php for more information about<br />
// the mailbox string in the first parameter of imap_open.<br />
// This example is ready to use with Office 365 Exchange Mails,<br />
// just replace your username (=email address) and the password.<br />
$mbox = imap_open("{outlook.office365.com:993/imap/ssl/novalidate-cert}", "username", "password");<br />
<br />
// Total number of emails<br />
$nrTotal = imap_num_msg($mbox);<br />
<br />
// Number of unseen emails. There are other ways using imap_status to count<br />
// unseen messages, but they don't work with Office 365 Exchange. This one does.<br />
$unseen = imap_search($mbox, 'UNSEEN');<br />
$nrUnseen = $unseen ? count($unseen) : 0;<br />
<br />
// Display the result, format as you like.<br />
echo $nrUnseen.'/'.$nrTotal;<br />
<br />
// Not needed, because the connection is closed after the script end.<br />
// For the sake of clean public available scripts, we are nice to<br />
// the imap server and close the connection manually.<br />
imap_close($mbox);<br />
</nowiki>}}<br />
<br />
Add to {{ic|conky.conf}}:<br />
<br />
${execi 300 ~/.scripts/imap.php} <br />
<br />
or wherever you saved the file.<br />
<br />
This script displays A/B where A is the number of unseen emails and B is the total number of mails in the mailbox. There are a lot of other information available through a lot of PHP functions like with imap_Status (http://php.net/manual/function.imap-status.php). Just see the PHP docs about IMAP: http://php.net/manual/ref.imap.php.<br />
<br />
== Show graphic of active network interface ==<br />
<br />
To test if a network inferface is currently active, you can use the test conky variable {{ic | if_existing}} on the {{ic | operstate}} of the interface. Here's an example for wlo1 :<br />
<br />
{{bc |draw_graph_borders yes <br />
${if_existing /sys/class/net/wlo1/operstate up}<br />
${color #0077ff}Net Down:$color ${downspeed wlo1} ${color #0077ff}Net Up:$color ${upspeed wlo1}<br />
${color #0077ff}${downspeedgraph wlo1 32,155 104E8B 0077ff} $alignr${color #0077ff}${upspeedgraph wlo1 32,155 104E8B 0077ff}<br />
${endif}<br />
}}<br />
<br />
This is the expected result :<br />
<br />
http://i.imgur.com/pQQbsP6.png<br />
<br />
== User-contributed configuration examples ==<br />
<br />
* A sample rings script with nvidia support - [https://gist.github.com/anonymous/85d052c0c23e58bc3666 gist]</div>Jellyhttps://wiki.archlinux.org/index.php?title=User:Jelly&diff=649841User:Jelly2021-01-25T14:19:57Z<p>Jelly: /* Arch projects */</p>
<hr />
<div>== Arch projects ==<br />
<br />
* AUR ansible setup<br />
* Testing ansible setup (how to deploy without secrets)<br />
* Set up Caching for AUR (either varnish or nginx minicache?)<br />
* JSON output for todolists<br />
* Bugzilla integration<br />
* Auto-rebuild service for todolists and rebuilds. Investigate with foutrelis what needs to be done.</div>Jellyhttps://wiki.archlinux.org/index.php?title=Package_Maintainer_guidelines&diff=649290Package Maintainer guidelines2021-01-19T22:21:12Z<p>Jelly: /* The TU and [community], Guidelines for Package Maintenance */ Update no longer existing orion to repos</p>
<hr />
<div>[[Category:Package development]]<br />
[[es:AUR Trusted User Guidelines]]<br />
[[ja:AUR Trusted User ガイドライン]]<br />
[[pt:AUR Trusted User Guidelines]]<br />
[[zh-hans:AUR Trusted User Guidelines]]<br />
{{Related articles start}}<br />
{{Related|Arch User Repository}}<br />
{{Related articles end}}<br />
'''Trusted Users (TU)''' are members of the community charged with keeping the AUR in working order. They maintain popular packages ([https://mailman.archlinux.org/pipermail/aur-general/2010-September/010649.html communicating with and sending patches upstream as needed]), and vote in administrative matters. A TU is elected from active community members by current TUs in a democratic process. TUs are the only members who have a final say in the direction of the AUR.<br />
<br />
The TUs are governed using the [https://aur.archlinux.org/trusted-user/TUbylaws.html TU bylaws]<br />
<br />
== TODO list for new Trusted Users ==<br />
<br />
# Read this entire wiki article.<br />
# Read the [https://aur.archlinux.org/trusted-user/TUbylaws.html TU Bylaws].<br />
# Make sure your account details on the [[AUR]] are up-to-date.<br />
# Add yourself to the [[Trusted Users]] page.<br />
# Remind a [[ArchWiki:Access levels and roles#Access levels|bureaucrat]] to add your wiki account to the {{int:group-archtu}} group.<br />
# Subscribe to the public mailing list for Arch Linux development, [https://lists.archlinux.org/listinfo/arch-dev-public arch-dev-public].<br />
# Request subscription to the internal trusted user mailing list.<br />
# Remind a [https://bbs.archlinux.org/userlist.php?username=&show_group=1&sort_by=username&sort_dir=ASC&search=Submit BBS admin] to change your account on forums.<br />
# Ask some TU for the #archlinux-tu@freenode key and hang out with us in the channel. You do not have to do this, but it would be neat since this is where most dark secrets are spilled and where many new ideas are conceived.<br />
#* If you need a bouncer, ask heftig for a [[Matrix]] invite. <br />
#* Once in the channel, if you want an @archlinux/trusteduser/* cloak ask our [[Arch IRC channels#Freenode group contacts|group contacts]] to get you one.<br />
# Create a PGP key for [[package signing]] or use your existing PGP key. Make sure the key also contains an encryption subkey so you can receive encrypted verification tokens.<br />
# Send a signed email to Jelle van der Waa (jelle@vdwaa.nl):<br />
#* Attach one SSH public key. If you do not have one, use {{ic|ssh-keygen}} to generate one. Check the [[Using SSH Keys]] wiki page for more information about SSH keys.<br />
#* Ask him to whitelist you from arch-dev-public.<br />
#* Tell him if you want an @archlinux.org email.<br />
#* Preferred username and e-mail address which initial password should be sent to in order to access dev interface (archweb). If you already have an account, ask to be added to the Trusted Users group.<br />
#* Ask him to create an account on Arch Linux SSO for you and which username you want on that. He will also add you to the Trusted Users group on SSO. <br />
# Ask your sponsor:<br />
#* to give you TU status on the AUR.<br />
#* to open a new task in the "Keyring" project of the bug tracker following the instructions in [https://lists.archlinux.org/pipermail/arch-dev-public/2013-September/025456.html this message] in order to have your PGP key signed by three master key holders.<br />
# Install the {{pkg|devtools}} package.<br />
# [[AUR submission guidelines#Authentication|Configure your private ssh key]] for {{ic|repos.archlinux.org}}.<br />
# Ssh to yourname@repos.archlinux.org (once you have permissions).<br />
# If you are not upgraded to a Trusted User group on bug tracker in two days, report this as a bug to arch-dev-public.<br />
# Start contributing!<br />
<br />
== The TU and the AUR ==<br />
<br />
The TUs should also make an effort to check package submissions in the [[AUR]] for malicious code and good PKGBUILDing standards. In around 80% of cases the PKGBUILDs in the UNSUPPORTED are very simple and can be quickly checked for sanity and malicious code by the TU team.<br />
<br />
TUs should also check PKGBUILDs for minor mistakes, suggest corrections and improvements. The TU should endeavor to confirm that all pkgs follow the Arch Packaging Guidelines/Standards and in doing so share their skills with other package builders in an effort to raise the standard of package building across the distro.<br />
<br />
TUs are also in an excellent position to document recommended practices.<br />
<br />
=== Rewriting git history ===<br />
<br />
In some cases rewriting the history of an AUR repository is required, for example when a user inadvertently uses their real name in a published commit. This can be automated with {{man|1|git-filter-branch}}. <br />
<br />
To force push the new history, forward the {{ic|1=AUR_OVERWRITE=1}} environment variable to {{man|1|git-push}}. See [https://gitlab.archlinux.org/archlinux/aurweb/-/commit/c5302d3a33028f483cc2e01225226d4ae047dd4a] for details.<br />
<br />
{{Warning|It is recommended to create a backup of the repository before rewriting history.}}<br />
<br />
; Modify committer or author identity<br />
<br />
Use {{ic|git filter-branch --env-filter}} with the {{ic|GIT_AUTHOR_NAME}}, {{ic|GIT_AUTHOR_EMAIL}}, {{ic|GIT_COMMITTER_NAME}} and {{ic|GIT_COMMITTER_EMAIL}} [[environment variables]]. For example:<br />
<br />
{{bc|1=<br />
git filter-branch --env-filter '<br />
if test "$GIT_AUTHOR_EMAIL" = "lepetit@prince.com"; then<br />
GIT_AUTHOR_EMAIL=user@users.noreply.github.com<br />
fi<br />
if test "$GIT_AUTHOR_NAME" = "Antoine de Saint-Exupéry"; then<br />
GIT_AUTHOR_NAME=user<br />
fi'<br />
}}<br />
<br />
{{Note|{{man|1|git-log}} only displays the git ''author'' by default. Use {{ic|1=git log --pretty=fuller}} to display the ''author'' and ''committer''.}}<br />
<br />
== The TU and [community], Guidelines for Package Maintenance ==<br />
<br />
=== Rules for Packages Entering the [community] Repo ===<br />
<br />
* A package must not already exist in any of the Arch Linux repositories. You should take necessary precautions to ensure no other packager is in the process of promoting the same package. Double-check the AUR package comments, read the latest subject headings in [https://mailman.archlinux.org/mailman/listinfo/aur-general aur-general], search [https://bugs.archlinux.org/index.php?project=0&do=index&switch=1 all projects in the bugtracker], [[wikipedia:Grep|grep]] the [http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.log.html Subversion log], and send a quick message to the private TU [[IRC channel]].<br />
* [[AUR helpers#Pacman wrappers|Pacman wrappers]], as a special exception, will never be permitted. If wanting to otherwise add an [[AUR helper]], write an email to {{ic|arch-dev-public}} with the proposed addition, and respect any objections provided by team members.<br />
* Only "popular" packages may enter the repo, as defined by 1% usage from [https://www.archlinux.de/?page=PackageStatistics pkgstats] or 10 votes on the AUR.<br />
* Automatic exceptions to this rule are:<br />
** i18n packages<br />
** accessibility packages<br />
** drivers<br />
** dependencies of packages who satisfy the definition of popular, including makedeps and optdeps<br />
** packages that are part of a collection and are intended to be distributed together, provided a part of this collection satisfies the definition of popular<br />
* Any additions not covered by the above criteria must first be proposed on the aur-general mailing list, explaining the reason for the exemption (e.g. renamed package, new package). The agreement of three other TUs is required for the package to be accepted into [community]. Proposed additions from TUs with large numbers of "non-popular" packages are more likely to be rejected.<br />
* TUs are strongly encouraged to move packages they currently maintain from [community] if they have low usage. No enforcement will be made, although resigning TUs packages may be filtered before adoption can occur.<br />
* It is good practice to always bump the '''pkgrel''' by ''1'' (in other words, set it to ''n + 1'') when promoting a package from AUR. This is to facilitate automatic updates for those who already have the package installed, so that they may continue to receive updates from the official channel. Another positive effect of this is that users are not warned that their local copy is newer, as is the case if a packager does reset the '''pkgrel''' to ''1''.<br />
<br />
=== Accessing and Updating the Repository ===<br />
<br />
{{Merge|DeveloperWiki:HOWTO Be A Packager|Duplicate with some minor differences}}<br />
<br />
The [community] repository now uses '''devtools''' which is the same system used for uploading packages to [core] and [extra], except that it uses another server {{ic|repos.archlinux.org}} instead of {{ic|gerolde.archlinux.org}}. Thus most of the instructions in [[DeveloperWiki:HOWTO Be A Packager|Packager Guide]] work without any change. Information which is specific for the [community] repository (like changed URLs) have been put here. The devtools require packagers to [[Makepkg#Packager_information|set the PACKAGER variable]] in {{ic|makepkg.conf}}.<br />
<br />
Initially you should do a '''non-recursive checkout''' of the [community] repository:<br />
<br />
<nowiki>$ svn checkout -N svn+ssh://svn-community@repos.archlinux.org/srv/repos/svn-community/svn svn-community</nowiki><br />
<br />
This creates a directory named "svn-community" which contains nothing but a ".svn" folder.<br />
<br />
For '''checking''' out, '''updating''' all packages or '''adding''' a package see the [[DeveloperWiki:HOWTO Be A Packager|Packager Guide]].<br />
<br />
To '''remove''' a package:<br />
<br />
$ ssh repos.archlinux.org /community/db-repo-remove community arch pkgname<br />
<br />
Here and in the following text, ''arch'' should be ''x86_64'' which is the only architecture supported by Arch Linux since [https://archlinux.org/news/the-end-of-i686-support/ i686 support has been deprecated].<br />
<br />
{{Note|If you are editing packages of the ''any'' architecture you can simply run the x86_64 scripts which will also work.}}<br />
<br />
When you are done with editing the PKGBUILD, etc., you should '''commit''' the changes ({{ic|svn commit}}).<br />
<br />
Build the package with {{ic|mkarchroot}} or the helper script {{ic|extra-x86_64-build}}. If you want to upload to testing you also need to build with the testing script {{ic|testing-x86_64-build}}.<br />
<br />
Sign the package with {{ic|gpg --detach-sign *.pkg.tar.xz}}. If you are using a different PGP key for package signing you can add it to {{ic|~/.makepkg.conf}} with {{ic|1=GPGKEY=<identifier>}}.<br />
<br />
When you want to '''release''' a package, first copy the package along with its signatures to the ''staging/community'' directory on ''repos.archlinux.org'' using {{ic|scp}} and then '''tag''' the package by going to the ''pkgname/trunk'' directory and issuing {{ic|archrelease community-arch}}. This makes an svn copy of the trunk entries in a directory named ''community-x86_64'' indicating that this package is in the community repository for that architecture. Note that the staging directory is different from the staging repository and every package needs to be uploaded to the staging directory. This process can be automated with the {{ic|communitypkg}} script, see the summary below.<br />
<br />
'''Package update summary:'''<br />
<br />
* '''Update''' the package directory: {{ic|svn update some-package}}.<br />
* '''Change''' to the package trunk directory: {{ic|cd some-package/trunk}}.<br />
* '''Edit''' the PKGBUILD, make necessary changes, update hashes with {{ic|updpkgsums}}.<br />
* '''Build''' the package: {{ic|makechrootpkg}} or {{ic|extra-x86_64-build}}. It is '''mandatory''' to build in a [[DeveloperWiki:Building in a clean chroot|clean chroot]].<br />
* '''[[Namcap]]''' the PKGBUILD and the binary {{ic|pkg.tar.gz}}.<br />
* '''Commit''', '''Sign''', '''Copy''' and '''Tag''' the package using {{ic|communitypkg "commit message"}}. This automates the following:<br />
** '''Commit''' the changes to trunk: {{ic|svn commit}}.<br />
** '''Sign''' the package: {{ic|gpg --detach-sign *.pkg.tar.xz}}.<br />
** '''Copy''' the package and its signature to ''orion.archlinux.org'': {{ic|scp *.pkg.tar.xz *.pkg.tar.xz.sig orion.archlinux.org:staging/community/}}.<br />
** '''Tag''' the package: {{ic|archrelease community-x86_64}}.<br />
* '''Update''' the repository: {{ic|ssh orion.archlinux.org /community/db-update}}.<br />
<br />
Also see the ''Miscellaneous'' section in the [[DeveloperWiki:HOWTO Be A Packager|Packager Guide]] and [[SSH keys#ssh-agent]]. For the section ''Avoid having to enter your password all the time'' use ''orion.archlinux.org'' instead of ''gerolde.archlinux.org''.<br />
<br />
=== Disowning packages ===<br />
<br />
If a TU cannot or does not want to maintain a package any longer, a notice should be posted to the AUR Mailing List, so another TU can<br />
maintain it. A package can still be disowned even if no other TU wants to maintain it, but the TUs should try not to drop many packages (they should not take on more than they have time for). If a package has become obsolete or is not used any longer, it can be removed completely as well.<br />
<br />
If a package has been removed completely, it can be uploaded once again (fresh) to UNSUPPORTED, where a regular user can maintain the package instead of the TU.<br />
<br />
=== Moving packages from unsupported to [community] ===<br />
<br />
Follow the normal procedures for adding a package to community, but remember to delete the corresponding package from unsupported!<br />
<br />
=== Moving packages from [community] to unsupported ===<br />
<br />
Remove the package using the instructions above and upload your source to the AUR.<br />
<br />
=== Moving packages from [community-testing] to [community] ===<br />
<br />
$ ssh repos.archlinux.org /community/db-move community-testing community <package><br />
<br />
=== Deleting packages from unsupported ===<br />
<br />
There is no point in removing dummy packages, because they will be re-created in an attempt to track dependencies. If someone uploads a<br />
real package then all dependents will point to the correct place.<br />
<br />
=== Remote build on PKGBUILD.com ===<br />
<br />
{{Warning|The following procedures defeats the Web Of Trust model: a user with root access to PKGBUILD.com could alter the package and/or the signature before it gets published.}}<br />
<br />
Trusted users and developers can connect to [http://pkgbuild.com/ PKGBUILD.com] via SSH to, among others, build packages using the devtools.<br />
This has numerous advantages over a local setup:<br />
<br />
* Builds are fast and network speed is high.<br />
* The environment needs setup only once.<br />
* Your local system need not be Arch Linux.<br />
<br />
The process is similar to that of a local setup with devtools. Your GnuPG private is required for signing but you do not want to upload it to soyuz for obvious security reasons. As such, you will need to forward the GnuPG agent socket from your local machine to the server: this will allow you to sign packages on soyuz without communicating your key. This also means that we need to disable the agent on the server before we can run anything.<br />
<br />
First, connect to soyuz and disable<br />
<br />
$ ssh soyuz.archlinux.org<br />
$ systemctl --user mask gpg-agent.service<br />
<br />
Make sure gpg-agent is not running ({{ic|systemctl --user stop gpg-agent.service}}). At this point, make sure that no sockets exist in the folder pointed by {{ic|gpgconf --list-dir socketdir}}. If they do, remove them or log out and in again.<br />
If you have a custom $GNUPGHOME (eg. to move it to {{ic|~/.config/gnupg}}), you will need to unset that, as it is not possible in gnupg to set the homedir without setting the socketdir.<br />
On soyuz, ''StreamLocalBindUnlink yes'' is set in ''sshd_config'', therefore removing the sockets manually on logout is not necessary.<br />
<br />
While the PGP private keys remain on your local machine, the public keys '''must''' be on soyuz. Export your public ring to soyuz, e.g. from you local machine<br />
<br />
$ scp ~/.gnupg/pubring.gpg soyuz.archlinux.org:~/.gnupg/pubring.gpg<br />
<br />
SSH is required to checkout and commit to the SVN repository. You can either set up a new SSH key pair on the server (it is highly discouraged to put your local private key on soyuz for security reasons) or reuse your local keys via socket forwarding. If you opt for the latter, make sure to disable ssh-agent on soyuz if you had enabled it previously (it is not running by default).<br />
<br />
Configure you build environment on soyuz:<br />
<br />
{{hc|1=~/.makepkg.conf|2=<br />
PACKAGER="John Doe <john@doe.example>"<br />
## Optional<br />
PKGDEST="/home/johndoe/packages"<br />
SRCDEST="/home/johndoe/sources"<br />
SRCPKGDEST="/home/johndoe/srcpackages"<br />
LOGDEST="/home/johndoe/logs"<br />
## If your PGP key is not the default, specify the right fingerprint:<br />
GPGKEY="ABCD1234..."<br />
}}<br />
<br />
{{Warning|Forwarding your gpg-agent socket to a remote machine makes it possible for anyone with root access to that system to use your unlocked GPG credentials. To circumvent this issue, we need to disable passphrase caching.}}<br />
<br />
Disable passphrase caching with the following settings:<br />
<br />
{{hc|gpg-agent.conf|<br />
default-cache-ttl 0<br />
max-cache-ttl 0<br />
}}<br />
<br />
Because we will want to keep our usual GPG agent running with its current settings, we are going to run another GPG agent dedicated to the task at hand. Create a {{ic|~/.gnupg-archlinux}} folder and symlink everything from {{ic|~/.gnupg}} there, except {{ic|~/.gnupg/gpg-agent.conf}}. Configure the new GPG agent:<br />
<br />
{{hc|~/.gnupg-archlinux|<br />
extra-socket /home/doe/.gnupg-archlinux/S.gpg-agent.extra<br />
default-cache-ttl 0<br />
max-cache-ttl 0<br />
pinentry-program /usr/bin/pinentry-gtk-2<br />
}}<br />
<br />
The {{ic|gpg-agent-extra.socket}} will be forwarded to PKGBUILD.com. <br />
<br />
Start the dedicated agent with<br />
<br />
$ gpg-agent --homedir ~/.gnupg-archlinux --daemon<br />
<br />
Connect with:<br />
<br />
$ ssh -R $REMOTE_SSH_AUTH_SOCK:$SSH_AUTH_SOCK -R /run/user/$REMOTE_UID/gnupg/S.gpg-agent:/home/doe/.gnupg-archlinux/S.gpg-agent.extra soyuz.archlinux.org<br />
<br />
or, if using GnuPG as your SSH agent:<br />
<br />
$ ssh -R /run/user/$REMOTE_UID/gnupg/S.gpg-agent.ssh:/run/user/$LOCAL_UID/gnupg/S.gpg-agent.ssh -R /run/user/$REMOTE_UID/gnupg/S.gpg-agent:/home/doe/.gnupg-archlinux/S.gpg-agent.extra soyuz.archlinux.org<br />
<br />
Replace ''$REMOTE_UID'' and ''$LOCAL_UID'' by your user identifier as returned by {{ic|id -u}} on soyuz and locally, respectively.<br />
If using ssh-agent, replace ''$REMOTE_SSH_AUTH_SOCK'' by the path to the SSH socket on the remote host (it can be anything).<br />
<br />
You can make the forwarding permanent for that host. For instance with gpg-agent.ssh:<br />
<br />
{{hc|~/.ssh/config|<br />
Host soyuz.archlinux.org<br />
RemoteForward /run/user/$REMOTE_UID/gnupg/S.gpg-agent /run/user/$LOCAL_UID/gnupg/S.gpg-agent.extra<br />
RemoteForward /run/user/$REMOTE_UID/gnupg/S.gpg-agent.ssh /run/user/$LOCAL_UID/gnupg/S.gpg-agent.ssh<br />
}}<br />
<br />
Again, replace ''$REMOTE_UID'' and ''$LOCAL_UID'' with their respective values.<br />
<br />
From then on, the procedure should be exactly the same as a local build:<br />
<br />
$ ssh soyuz.archlinux.org<br />
$ svn checkout -N svn+ssh://svn-community@repos.archlinux.org/srv/repos/svn-community/svn svn-community<br />
$ ...<br />
<br />
{{Note|pinentry-curses might not work with socket forwarding. If it fails for you, try using a different pinentry.}}<br />
<br />
== TODO list retiring a Trusted User ==<br />
<br />
When a TU resigns the following list has be followed, these steps do not apply when a TU resigns but is still a Developer.<br />
<br />
# All packages packaged by the retiree should be resigned (so rebuild). Packages packaged by the retiree can be found in Archweb https://archlinux.org/packages/?sort=&q=&packager=$packager&flagged= where packager is the username on Archweb.<br />
# The account of the retiree should be disabled on Archweb and added to the 'Retired Trusted users' group. The retiree should be removed from the 'Trusted Users' and the repository permissions should be reduced to none.<br />
# The shell access to our servers should be disabled. (notably repos.archlinux.org, pkgbuild.com)<br />
# The GPG key should be removed and a new archlinux-keyring package should be pushed to the repos. Create bug reports in the keyring project to remove the keys of the retired Trusted Users.<br />
# Remove the TU group from their AUR account.<br />
# A [[ArchWiki:Access levels and roles#Access levels|bureaucrat]] should remove their wiki account from the {{int:group-archtu}} group.<br />
# A [https://bbs.archlinux.org/userlist.php?username=&show_group=1&sort_by=username&sort_dir=ASC&search=Submit BBS admin] should change their account on forums.<br />
<br />
== See also ==<br />
<br />
* [[DeveloperWiki#Packaging Guidelines]]</div>Jellyhttps://wiki.archlinux.org/index.php?title=Arch_Linux_Archive&diff=648130Arch Linux Archive2021-01-03T13:43:56Z<p>Jelly: Add Archive Mirrors to location</p>
<hr />
<div>[[Category:Package management]]<br />
[[Category:Arch projects]]<br />
[[es:Arch Linux Archive]]<br />
[[fr:Arch Linux Archive]]<br />
[[ja:Arch Linux Archive]]<br />
[[pt:Arch Linux Archive]]<br />
[[zh-hans:Arch Linux Archive]]<br />
{{Related articles start}}<br />
{{Related|Downgrading packages}}<br />
{{Related articles end}}<br />
<br />
The '''Arch Linux Archive''' (a.k.a '''ALA'''), formerly known as '''Arch Linux Rollback Machine''' (a.k.a '''ARM'''), stores ''official repositories snapshots'', ''iso images'' and ''bootstrap tarballs'' across time.<br />
<br />
'''You can use it to:'''<br />
<br />
* Downgrade to a previous version of one package (last version is broken, I want the previous one)<br />
* Restore all your packages at a precise moment (my system is broken, I want to go back 2 months ago)<br />
* Find a previous version of an ISO image<br />
<br />
Packages are only kept for a few years, afterwards they are moved to the [[#Historical Archive|Arch Linux Historical Archive]] on [[Wikipedia:archive.org|archive.org]].<br />
<br />
== Location ==<br />
<br />
The Arch Linux Archive is available at https://archive.archlinux.org/ and [https://gitlab.archlinux.org/archlinux/infrastructure/-/blob/master/docs/servers.md#archive-mirrors mirrors] around the globe.<br />
<br />
The [https://github.com/seblu/archivetools source code] is also available for setting up your own mirror.<br />
<br />
== Directories ==<br />
<br />
The '''Archive''' is split into 3 main directories detailed below.<br />
<br />
├── iso<br />
├── packages<br />
└── repos<br />
<br />
=== /repos ===<br />
<br />
The [https://archive.archlinux.org/repos repos] directory contains daily snapshots of official mirror organized by date like in the following example.<br />
<br />
repos<br />
├── 2013<br />
│ ├── 08<br />
│ │ └── 31<br />
│ │ ├── community<br />
│ │ ├── community-staging<br />
│ │ ├── community-testing<br />
│ │ ├── core<br />
│ │ ├── extra<br />
│ │ ├── gnome-unstable<br />
│ │ ├── kde-unstable<br />
│ │ ├── lastsync<br />
│ │ ├── multilib<br />
│ │ ├── multilib-staging<br />
│ │ ├── multilib-testing<br />
│ │ ├── pool<br />
│ │ ├── staging<br />
│ │ └── testing<br />
│ ├── 09<br />
│ │ ├── 01<br />
│ │ ├── 02<br />
│ │ ├── ...<br />
│ │ ├── 21<br />
│ │ └── 22<br />
│ ├── 10<br />
│ │ ├── 01<br />
│ │ ├── 02<br />
│ │ ├── ...<br />
│ │<br />
│ ├── 11<br />
│ └── 12<br />
├── 2014<br />
│ ├── 01<br />
│ │ ├── 01<br />
│ │ ├── 02<br />
│ │ ├── ...<br />
│ │<br />
│ ├── 02<br />
│ ├── 03<br />
│ ├── ...<br />
│ └── 09<br />
│ ├── 01<br />
│ ├── ...<br />
│ └── 28<br />
├── last<br />
├── month<br />
└── week<br />
<br />
Note: The last 3 special directories ('''last''', '''week''' and '''month''') which links respectively to the last synced repository, to the last Monday and to the first of the current month.<br />
<br />
=== /packages ===<br />
<br />
The [https://archive.archlinux.org/packages packages] directory contains all versions of each package with their signatures. One directory by package and package directories are grouped by their first letter.<br />
<br />
├── packages<br />
│ ├── a<br />
│ │ ├── awesome<br />
│ │ │ ├── awesome-3.5.0-1-i686.pkg.tar.xz<br />
│ │ │ ├── awesome-3.5.0-1-i686.pkg.tar.xz.sig<br />
│ │ │ ├── awesome-3.5.0-1-x86_64.pkg.tar.xz<br />
│ │ │ ├── awesome-3.5.0-1-x86_64.pkg.tar.xz.sig<br />
│ │ │ ├── awesome-3.5.1-1-i686.pkg.tar.xz<br />
│ │ │ ├── awesome-3.5.1-1-i686.pkg.tar.xz.sig<br />
│ │ │ ├── ...<br />
│ │ │<br />
│ │ ├── ...<br />
│ │ ├── awstats<br />
│ │ └── axel<br />
│ │ <br />
│ ├── b<br />
│ ├── ...<br />
│ └── z<br />
<br />
You can use the magic subdirectory [https://archive.archlinux.org/packages/.all .all] to access all packages by their name. It acts as a flat directory containing all versions of every package.<br />
<br />
├── packages<br />
│ ├── .all<br />
│ │ ├── awesome-3.5.1-1-i686.pkg.tar.xz<br />
│ │ ├── ...<br />
│ │ ├── zsh-5.0.2-3-i686.pkg.tar.xz<br />
│ │ ├── zsh-5.0.2-4-i686.pkg.tar.xz<br />
│ │ └── ...<br />
<br />
You can download the full package list (there are over a hundred thousand packages) as a compressed index: [https://archive.archlinux.org/packages/.all/index.0.xz index.0.xz].<br />
<br />
{{hc|$ curl <nowiki>https://archive.archlinux.org/packages/.all/index.0.xz |</nowiki> unxz|<br />
0ad-a14-1-i686<br />
0ad-a14-1-x86_64<br />
0ad-a14-2-i686<br />
...<br />
zziplib-0.13.62-1-x86_64<br />
zziplib-0.13.62-2-i686<br />
zziplib-0.13.62-2-x86_64}}<br />
<br />
=== /iso ===<br />
<br />
The [https://archive.archlinux.org/iso iso] directory contains official ISO images and bootstrap tarballs sorted by release date.<br />
<br />
├── 2014.09.03<br />
├── 2014.10.01<br />
├── 2014.11.01<br />
├── 2014.12.01<br />
├── 2015.07.01<br />
├── 2015.08.01<br />
├── 2015.09.01<br />
└── 2017.04.01<br />
├── arch<br />
├── archlinux-2017.04.01-x86_64.iso<br />
├── archlinux-2017.04.01-x86_64.iso.sig<br />
├── archlinux-2017.04.01-x86_64.iso.torrent<br />
├── archlinux-bootstrap-2017.04.01-x86_64.tar.gz<br />
├── archlinux-bootstrap-2017.04.01-x86_64.tar.gz.sig<br />
├── md5sums.txt<br />
└── sha1sums.txt<br />
<br />
== Frequently asked questions ==<br />
<br />
=== How to downgrade one package ===<br />
<br />
Find the package you want under [[#/packages|/packages]] and let pacman fetch it for installation. For example:<br />
<br />
# pacman -U <nowiki>https://archive.archlinux.org/packages/</nowiki> ... ''packagename''.pkg.tar.xz<br />
<br />
Letting pacman fetch it will automatically download the package's detached ''.sig'' file and verify it according to {{ic|/etc/pacman.conf}} settings.<br />
<br />
Alternatively, download and install the package manually using {{ic|pacman -U}}.<br />
<br />
See also [[Downgrading packages#Automation]] for tools that simplify the process.<br />
<br />
=== How to restore all packages to a specific date ===<br />
<br />
To restore all packages to their version at a specific date, let us say 30 March 2014, you have to direct [[pacman]] to this date, by editing your {{ic|/etc/pacman.conf}} and use the following server directive:<br />
<br />
{{bc|<nowiki><br />
[core]<br />
SigLevel = PackageRequired<br />
Server=https://archive.archlinux.org/repos/2014/03/30/$repo/os/$arch<br />
<br />
[extra]<br />
SigLevel = PackageRequired<br />
Server=https://archive.archlinux.org/repos/2014/03/30/$repo/os/$arch<br />
<br />
[community]<br />
SigLevel = PackageRequired<br />
Server=https://archive.archlinux.org/repos/2014/03/30/$repo/os/$arch<br />
</nowiki>}}<br />
<br />
or by replacing your {{ic|/etc/pacman.d/mirrorlist}} with the following content:<br />
<br />
{{bc|<nowiki><br />
## <br />
## Arch Linux repository mirrorlist <br />
## Generated on 2042-01-01 <br />
##<br />
Server=https://archive.archlinux.org/repos/2014/03/30/$repo/os/$arch<br />
</nowiki>}}<br />
<br />
Then update the database and force downgrade:<br />
<br />
# pacman -Syyuu<br />
<br />
If you get errors complaining about corrupted/invalid packages due to PGP signature, try to first update separately {{Pkg|archlinux-keyring}} and {{Pkg|ca-certificates}}. Alternatively, you can decide to temporarily [[pacman/Package signing#Disabling signature checking|disable signature checking]] altogether.<br />
<br />
{{Note|It is [[partial upgrades|not safe]] to mix Archive and up-to-date mirrors. In case of a download failure, you will fall-back on an upstream package and you will have packages not from the same epoch in the rest of the system.}}<br />
<br />
== Historical Archive ==<br />
<br />
Maintaining the Arch Linux Archive consumes significant amount of resources, so old packages are cleaned up from time to time.<br />
<br />
Before removing them, old packages are uploaded to a [https://archive.org/details/archlinuxarchive dedicated collection "Arch Linux Historical Archive" on archive.org].<br />
<br />
The Historical Archive does not provide a way to access a "snapshot" of Arch packages at a given point in time. However, there is a redirection on {{ic|archive.archlinux.org}} so that downloads for old packages are redirected to the Historical Archive on {{ic|archive.org}}. There should be no visible impact from the user side, except from the fact that {{ic|archive.org}} is generally quite slow for downloading.<br />
<br />
=== Finding packages in the Historical Archive ===<br />
<br />
The '''Arch Linux Historical Archive''' collection has an index of all packages: https://archive.org/details/archlinuxarchive<br />
<br />
It is also possible to directly access a package by its '''identifier'''. The general pattern for identifiers is {{ic|archlinux_pkg_''sanitized_package_name''}}.<br />
<br />
To obtain the '''sanitized''' package name, simply replace any {{ic|@}}, {{ic|+}} or {{ic|.}} character in the package name by an underscore {{ic|_}}.<br />
<br />
For instance, the identifier for {{pkg|lucene++}} is {{ic|archlinux_pkg_lucene__}}.<br />
<br />
You can then access the details page of a package via its identifier, for instance: https://archive.org/details/archlinux_pkg_lucene__.<br />
<br />
It is also possible to run searches with the [https://github.com/jjjake/internetarchive archive.org Python client]:<br />
<br />
{{hc|1=$ ia search subject:"archlinux package" subject:'mysql'|2=<br />
{"identifier": "archlinux_pkg_ejabberd-mod_mysql"}<br />
{"identifier": "archlinux_pkg_ejabberd-mod_mysql-svn"}<br />
{"identifier": "archlinux_pkg_gambas3-gb-db-mysql"}<br />
{"identifier": "archlinux_pkg_gambas3-gb-mysql"}<br />
{"identifier": "archlinux_pkg_libgda-mysql"}<br />
}}<br />
<br />
=== Downloading packages from the Historical Archive ===<br />
<br />
All available package versions (and their signature) can be accessed via the download page of a package: https://archive.org/download/archlinux_pkg_lucene__.<br />
<br />
To download, verify and install a package using [[pacman]]:<br />
<br />
# pacman -U <nowiki>https://archive.org/download/archlinux_pkg_cjdns/cjdns-16.1-3-x86_64.pkg.tar.xz</nowiki><br />
<br />
Package verification is controlled by pacman's {{ic|RemoteFileSigLevel}} option. Note that if you use pacman, you have to figure out the dependencies yourself.<br />
<br />
It is also possible to use the [https://github.com/jjjake/internetarchive archive.org Python client].<br />
<br />
Download a specific version of a package:<br />
<br />
$ ia download archlinux_pkg_cjdns cjdns-16.1-3-x86_64.pkg.tar.xz{,.sig}<br />
<br />
Download all x86_64 versions of a package, with signatures:<br />
<br />
$ ia download archlinux_pkg_cjdns --glob="*x86_64.pkg.tar.xz*"<br />
<br />
== History ==<br />
<br />
* The original ARM (''Archlinux Rollback Machine'') was closed on 2013-08-18.[https://bbs.archlinux.org/viewtopic.php?pid=1313360#p1313360]<br />
* The new one is hosted on [http://seblu.net seblu.net] since 2013-08-31.<br />
* New URL and closing the old ARM hierarchy on 2015-10-13. A new software, {{AUR|agetpkg-git}} was introduced.<br />
* Moved to [https://archive.archlinux.org archive.archlinux.org] on 2015-12-19.[https://lists.archlinux.org/pipermail/arch-dev-public/2015-December/027635.html]<br />
* Old packages from 2013-2016 uploaded to [https://archive.org/details/archlinuxarchive archive.org] on 2018-06-05.</div>Jellyhttps://wiki.archlinux.org/index.php?title=Arch_package_guidelines&diff=644665Arch package guidelines2020-12-11T13:45:14Z<p>Jelly: /* Reproducible Builds */ remove extraneous space</p>
<hr />
<div>[[Category:Arch package guidelines]]<br />
[[es:Arch package guidelines]]<br />
[[fr:Standard paquetage]]<br />
[[it:Arch package guidelines]]<br />
[[ja:Arch パッケージングスタンダード]]<br />
[[pt:Arch package guidelines]]<br />
[[ru:Arch package guidelines]]<br />
[[sr:Arch package guidelines]]<br />
[[zh-hans:Arch package guidelines]]<br />
[[zh-hant:Arch package guidelines]]<br />
{{Related articles start}}<br />
{{Related|Creating packages}}<br />
{{Related|PKGBUILD}}<br />
{{Related|makepkg}}<br />
{{Related|Arch Build System}}<br />
{{Related|Arch User Repository}}<br />
{{Related|/Security}}<br />
{{Related articles end}}<br />
<br />
When building packages for Arch Linux, '''adhere to the package guidelines''' below, especially if the intention is to '''contribute''' a new package to Arch Linux. You should also see the {{man|5|PKGBUILD}} and {{man|8|makepkg}} manpages.<br />
<br />
== PKGBUILD prototype ==<br />
<br />
{{bc|1=<br />
# Maintainer: Your Name <youremail@domain.com><br />
pkgname=NAME<br />
pkgver=VERSION<br />
pkgrel=1<br />
pkgdesc=""<br />
arch=()<br />
url=""<br />
license=('GPL')<br />
groups=()<br />
depends=()<br />
makedepends=()<br />
optdepends=()<br />
provides=()<br />
conflicts=()<br />
replaces=()<br />
backup=()<br />
options=()<br />
install=<br />
changelog=<br />
source=($pkgname-$pkgver.tar.gz)<br />
noextract=()<br />
md5sums=() #autofill using updpkgsums<br />
<br />
build() {<br />
cd "$pkgname-$pkgver"<br />
<br />
./configure --prefix=/usr<br />
make<br />
}<br />
<br />
package() {<br />
cd "$pkgname-$pkgver"<br />
<br />
make DESTDIR="$pkgdir/" install<br />
}<br />
}}<br />
<br />
Other prototypes are found in {{ic|/usr/share/pacman/}} from the pacman and abs packages.<br />
<br />
== Package etiquette ==<br />
<br />
* Packages should '''never''' be installed to {{ic|/usr/local/}}<br />
* '''Do not introduce new variables or functions''' into {{ic|PKGBUILD}} build scripts, unless the package cannot be built without doing so, as these could possibly '''conflict''' with variables and functions used in makepkg itself.<br />
* If a new variable or a new function is absolutely required, '''prefix its name with an underscore''' ({{ic|_}}), e.g. {{bc|1=_customvariable=}}<br />
* '''Avoid''' using {{ic|/usr/libexec/}} for anything. Use {{ic|/usr/lib/$pkgname/}} instead.<br />
* The {{ic|packager}} field from the package meta file can be '''customized''' by the package builder by modifying the appropriate option in the {{ic|/etc/makepkg.conf}} file, or alternatively override it by creating {{ic|~/.makepkg.conf}}.<br />
* '''Do not use makepkg subroutines''' (e.g. {{ic|error}}, {{ic|msg}}, {{ic|msg2}}, {{ic|plain}}, {{ic|warning}}) as they might change at any time. To print data, use {{ic|printf}} or {{ic|echo}}.<br />
* All important messages should be echoed during install using an '''.install file'''. For example, if a package needs extra setup to work, directions should be included.<br />
* '''Dependencies''' are the most common packaging error. Please take the time to verify them carefully, for example by running {{ic|ldd}} on dynamic executables, checking tools required by scripts or looking at the documentation of the software. The [[namcap]] utility can help you in this regard. This tool can analyze both PKGBUILD and the resulting package tarball and will warn you about bad permissions, missing dependencies, redundant dependencies, and other common mistakes.<br />
* Any '''optional dependencies''' that are not needed to run the package or have it generally function should not be included in the '''depends''' array; instead the information should be added to the '''optdepends''' array:<br />
:{{bc|<nowiki><br />
optdepends=('cups: printing support'<br />
'sane: scanners support'<br />
'libgphoto2: digital cameras support'<br />
'alsa-lib: sound support'<br />
'giflib: GIF images support'<br />
'libjpeg: JPEG images support'<br />
'libpng: PNG images support')<br />
</nowiki>}}<br />
:The above example is taken from the '''wine''' package in {{Ic|extra}}. The optdepends information is automatically printed out on installation/upgrade so one should '''not''' keep this kind of information in {{ic|.install}} files.<br />
* When creating a '''package description''' for a package, do not include the package name in a self-referencing way. For example, "Nedit is a text editor for X11" could be simplified to "A text editor for X11". Also try to keep the descriptions to ~80 characters or less.<br />
* Try to keep the '''line length''' in the PKGBUILD below ~100 characters.<br />
* Where possible, '''remove empty lines''' from the {{ic|PKGBUILD}} ({{ic|provides}}, {{ic|replaces}}, etc.)<br />
* It is common practice to '''preserve the order''' of the {{ic|PKGBUILD}} fields as shown above. However, this is not mandatory, as the only requirement in this context is '''correct bash syntax'''.<br />
* '''Quote''' variables which may contain spaces, such as {{ic|"$pkgdir"}} and {{ic|"$srcdir"}}.<br />
* To ensure the '''integrity''' of packages, make sure that the [[PKGBUILD#Integrity|integrity variables]] contain correct values. These can be updated using the {{ic|updpkgsums}} tool.<br />
<br />
== Package naming ==<br />
<br />
* Package names can contain only alphanumeric characters and any of {{ic|@}}, {{ic|.}}, {{ic|_}}, {{ic|+}}, {{ic|-}}. Names are not allowed to start with hyphens or dots. All letters should be lowercase.<br />
* Package names should NOT be suffixed with the upstream major release version number (e.g. we do not want libfoo2 if upstream calls it libfoo v2.3.4) in case the library and its dependencies are expected to be able to keep using the most recent library version with each respective upstream release. However, for some software or dependencies, this can not be assumed. In the past this has been especially true for widget toolkits such as GTK and Qt. Software that depends on such toolkits can usually not be trivially ported to a new major version. As such, in cases where software can not trivially keep rolling alongside its dependencies, package names should carry the major version suffix (e.g. gtk2, gtk3, qt4, qt5). For cases where most dependencies can keep rolling along the newest release but some cannot (for instance closed source that needs libpng12 or similar), a deprecated version of that package might be called libfoo1 while the current version is just libfoo.<br />
<br />
==Package versioning==<br />
<br />
* Package versions (i.e. [[PKGBUILD#pkgver]]) '''should be the same as the version released by the author'''. Versions can include letters if need be (eg, nmap's version is 2.54BETA32). '''Version tags may not include hyphens!''' Letters, numbers, and periods only.<br />
* '''Stable packages package stable releases''': Release candidates (i.e. {{ic|1.0.0-rc1}}), alpha (e.g. {{ic|1.0.0-alpha1}}) and beta (e.g. {{ic|1.0.0-beta1}}) releases are not allowed and are only to be used under the following circumstances:<br />
** The non-stable release holds '''urgent''' security fixes (and backporting is non-trivial).<br />
** The non-stable release allows for the package to be built (e.g. problems introduced due to updated dependencies) and those changes can not otherwise be backported easily.<br />
** The non-stable release allows the distribution to drop an EOL component (e.g. qt4, python2).<br />
* Package releases (i.e. [[PKGBUILD#pkgrel]]) are '''specific to Arch Linux packages'''. These allow users to differentiate between newer and older package builds. When a new package version is first released, the '''release count starts at 1'''. Then as fixes and optimizations are made, the package will be '''re-released''' to the Arch Linux public and the '''release number will increment'''. When a new version comes out, the release count resets to 1. Package release tags follow the '''same naming restrictions as version tags'''.<br />
<br />
==Package dependencies==<br />
<br />
* '''Do not rely on [[Wikipedia:Transitive dependency|transitive dependencies]]''' in any of the [[PKGBUILD#Dependencies]], as they might break, if one of the dependencies is updated.<br />
* List all direct library dependencies. To identify them {{man|1|find-libdeps}} (part of {{pkg|devtools}}) can be used.<br />
<br />
== Package relations ==<br />
<br />
* Do not add {{ic|$pkgname}} to [[PKGBUILD#provides]], as it is always implicitely provided by the package.<br />
* List all external shared libraries of a package in [[PKGBUILD#provides]] (e.g. {{ic|'libsomething.so'}}). To identify them {{man|1|find-libprovides}} (part of {{pkg|devtools}}) can be used.<br />
<br />
== Package sources ==<br />
<br />
* HTTPS sources ({{ic|https://}} for tarballs, {{ic|git+https://}} for git sources) should be used wherever possible<br />
* Sources should be verified using PGP signatures wherever possible (this might entail building from a git tag instead of a source tarball, if upstream signs commits and tags but not the tarballs)<br />
* '''Do not diminish the security or validity of a package''' (e.g. by removing a checksum check or by removing PGP signature verification), because an upstream release is broken or suddenly lacks a certain feature (e.g. PGP signature missing for a new release)<br />
* Sources have to be unique in {{ic|srcdir}} (this might require renaming them when downloading, e.g. {{ic|<nowiki>"${pkgname}-${pkgver}.tar.gz::https://${pkgname}.tld/download/${pkgver}.tar.gz"</nowiki>}})<br />
* Avoid using specific mirrors (e.g. on sourceforge) to download, as they might become unavailable<br />
<br />
== Working with upstream ==<br />
<br />
It is considered best-practice to work closely with upstream wherever possible. This entails reporting problems about building and testing a package.<br />
<br />
* Report problems to upstream right away.<br />
* Upstream patches wherever possible.<br />
* Add comments with links to relevant (upstream) bug tracker tickets in the [[PKGBUILD]] (this is particularly important, as it ensures, that other packagers can understand changes and work with a package as well).<br />
<br />
It is recommended to track upstream with tools such as {{pkg|nvchecker}} or {{pkg|urlwatch}} to be informed about new stable releases.<br />
<br />
== Directories ==<br />
<br />
* '''Configuration files''' should be placed in the {{ic|/etc}} directory. If there is more than one configuration file, it is customary to '''use a subdirectory''' in order to keep the {{ic|/etc}} area as clean as possible. Use {{ic|/etc/{pkgname}/}} where {{ic|<nowiki>{pkgname}</nowiki>}} is the name of the package (or a suitable alternative, eg, apache uses {{ic|/etc/httpd/}}). <br />
* Package files should follow these '''general directory guidelines''':<br />
<br />
:{|<br />
|-<br />
| {{ic|/etc}}<br />
| '''System-essential''' configuration files<br />
|-<br />
| {{ic|/usr/bin}}<br />
| Binaries<br />
|-<br />
| {{ic|/usr/lib}}<br />
| Libraries<br />
|-<br />
| {{ic|/usr/include}}<br />
| Header files<br />
|-<br />
| {{ic|<nowiki>/usr/lib/{pkg}</nowiki>}}<br />
| Modules, plugins, etc.<br />
|-<br />
| {{ic|<nowiki>/usr/share/doc/{pkg}</nowiki>}}<br />
| Application documentation<br />
|-<br />
| {{ic|/usr/share/info}}<br />
| GNU Info system files<br />
|-<br />
| {{ic|/usr/share/man}}<br />
| Manpages<br />
|-<br />
| {{ic|<nowiki>/usr/share/{pkg}</nowiki>}}<br />
| Application data<br />
|-<br />
| {{ic|<nowiki>/var/lib/{pkg}</nowiki>}}<br />
| Persistent application storage<br />
|-<br />
| {{ic|<nowiki>/etc/{pkg}</nowiki>}}<br />
| Configuration files for {{ic|<nowiki>{pkg}</nowiki>}}<br />
|-<br />
| {{ic|<nowiki>/opt/{pkg}</nowiki>}}<br />
| Large self-contained packages<br />
|}<br />
<br />
* Packages should not contain any of the following directories:<br />
** {{ic|/bin}}<br />
** {{ic|/sbin}}<br />
** {{ic|/dev}}<br />
** {{ic|/home}}<br />
** {{ic|/srv}}<br />
** {{ic|/media}}<br />
** {{ic|/mnt}}<br />
** {{ic|/proc}}<br />
** {{ic|/root}}<br />
** {{ic|/selinux}}<br />
** {{ic|/sys}}<br />
** {{ic|/tmp}}<br />
** {{ic|/var/tmp}}<br />
** {{ic|/run}}<br />
<br />
== Makepkg duties ==<br />
<br />
When [[makepkg]] is used to build a package, it does the following automatically:<br />
<br />
# Checks if package '''dependencies''' and '''makedepends''' are installed<br />
# '''Downloads source''' files from servers<br />
# '''Checks the integrity''' of source files<br />
# '''Unpacks''' source files<br />
# Does any necessary '''patching'''<br />
# '''Builds''' the software and installs it in a fake root<br />
# '''Strips''' symbols from binaries<br />
# '''Strips''' debugging symbols from libraries<br />
# '''Compresses''' manual and, or info pages<br />
# Generates the '''package meta file''' which is included with each package<br />
# '''Compresses''' the fake root into the package file<br />
# '''Stores''' the package file in the configured destination directory (<span title="Current Working Directory" style="border-bottom: 1px dotted">cwd</span> by default)<br />
<br />
== Architectures ==<br />
<br />
The {{ic|arch}} array should contain {{ic|'x86_64'}} if the compiled package is architecture-specific. Otherwise, use {{ic|'any'}} for architecture independent packages.<br />
<br />
== Licenses ==<br />
<br />
See [[PKGBUILD#license]].<br />
<br />
== Reproducible Builds ==<br />
<br />
Arch is working on making all packages [https://reproducible-builds.org/ reproducible]. A packager can check if a package is reproducible with {{ic|makerepropkg}} from {{Pkg|devtools}} or {{ic|repro}} from {{Pkg|archlinux-repro}}.<br />
<br />
$ makerepropkg $pkgname-1-1-any.pkg.tar.zst<br />
<br />
Or<br />
<br />
$ repro -f $pkgname-1-1-any.pkg.tar.zst<br />
<br />
== Additional guidelines ==<br />
<br />
Be sure to read the above guidelines first - important points are listed on this page that will not be repeated in the following guideline pages. These specific guidelines are intended as an addition to the standards listed on this page.<br />
<br />
{{Package guidelines}}<br />
<br />
Packages submitted to the AUR must additionally comply with [[AUR submission guidelines]].</div>Jellyhttps://wiki.archlinux.org/index.php?title=Arch_package_guidelines&diff=644664Arch package guidelines2020-12-11T13:44:38Z<p>Jelly: /* Reproducible Builds */ add missing "from" devtools.</p>
<hr />
<div>[[Category:Arch package guidelines]]<br />
[[es:Arch package guidelines]]<br />
[[fr:Standard paquetage]]<br />
[[it:Arch package guidelines]]<br />
[[ja:Arch パッケージングスタンダード]]<br />
[[pt:Arch package guidelines]]<br />
[[ru:Arch package guidelines]]<br />
[[sr:Arch package guidelines]]<br />
[[zh-hans:Arch package guidelines]]<br />
[[zh-hant:Arch package guidelines]]<br />
{{Related articles start}}<br />
{{Related|Creating packages}}<br />
{{Related|PKGBUILD}}<br />
{{Related|makepkg}}<br />
{{Related|Arch Build System}}<br />
{{Related|Arch User Repository}}<br />
{{Related|/Security}}<br />
{{Related articles end}}<br />
<br />
When building packages for Arch Linux, '''adhere to the package guidelines''' below, especially if the intention is to '''contribute''' a new package to Arch Linux. You should also see the {{man|5|PKGBUILD}} and {{man|8|makepkg}} manpages.<br />
<br />
== PKGBUILD prototype ==<br />
<br />
{{bc|1=<br />
# Maintainer: Your Name <youremail@domain.com><br />
pkgname=NAME<br />
pkgver=VERSION<br />
pkgrel=1<br />
pkgdesc=""<br />
arch=()<br />
url=""<br />
license=('GPL')<br />
groups=()<br />
depends=()<br />
makedepends=()<br />
optdepends=()<br />
provides=()<br />
conflicts=()<br />
replaces=()<br />
backup=()<br />
options=()<br />
install=<br />
changelog=<br />
source=($pkgname-$pkgver.tar.gz)<br />
noextract=()<br />
md5sums=() #autofill using updpkgsums<br />
<br />
build() {<br />
cd "$pkgname-$pkgver"<br />
<br />
./configure --prefix=/usr<br />
make<br />
}<br />
<br />
package() {<br />
cd "$pkgname-$pkgver"<br />
<br />
make DESTDIR="$pkgdir/" install<br />
}<br />
}}<br />
<br />
Other prototypes are found in {{ic|/usr/share/pacman/}} from the pacman and abs packages.<br />
<br />
== Package etiquette ==<br />
<br />
* Packages should '''never''' be installed to {{ic|/usr/local/}}<br />
* '''Do not introduce new variables or functions''' into {{ic|PKGBUILD}} build scripts, unless the package cannot be built without doing so, as these could possibly '''conflict''' with variables and functions used in makepkg itself.<br />
* If a new variable or a new function is absolutely required, '''prefix its name with an underscore''' ({{ic|_}}), e.g. {{bc|1=_customvariable=}}<br />
* '''Avoid''' using {{ic|/usr/libexec/}} for anything. Use {{ic|/usr/lib/$pkgname/}} instead.<br />
* The {{ic|packager}} field from the package meta file can be '''customized''' by the package builder by modifying the appropriate option in the {{ic|/etc/makepkg.conf}} file, or alternatively override it by creating {{ic|~/.makepkg.conf}}.<br />
* '''Do not use makepkg subroutines''' (e.g. {{ic|error}}, {{ic|msg}}, {{ic|msg2}}, {{ic|plain}}, {{ic|warning}}) as they might change at any time. To print data, use {{ic|printf}} or {{ic|echo}}.<br />
* All important messages should be echoed during install using an '''.install file'''. For example, if a package needs extra setup to work, directions should be included.<br />
* '''Dependencies''' are the most common packaging error. Please take the time to verify them carefully, for example by running {{ic|ldd}} on dynamic executables, checking tools required by scripts or looking at the documentation of the software. The [[namcap]] utility can help you in this regard. This tool can analyze both PKGBUILD and the resulting package tarball and will warn you about bad permissions, missing dependencies, redundant dependencies, and other common mistakes.<br />
* Any '''optional dependencies''' that are not needed to run the package or have it generally function should not be included in the '''depends''' array; instead the information should be added to the '''optdepends''' array:<br />
:{{bc|<nowiki><br />
optdepends=('cups: printing support'<br />
'sane: scanners support'<br />
'libgphoto2: digital cameras support'<br />
'alsa-lib: sound support'<br />
'giflib: GIF images support'<br />
'libjpeg: JPEG images support'<br />
'libpng: PNG images support')<br />
</nowiki>}}<br />
:The above example is taken from the '''wine''' package in {{Ic|extra}}. The optdepends information is automatically printed out on installation/upgrade so one should '''not''' keep this kind of information in {{ic|.install}} files.<br />
* When creating a '''package description''' for a package, do not include the package name in a self-referencing way. For example, "Nedit is a text editor for X11" could be simplified to "A text editor for X11". Also try to keep the descriptions to ~80 characters or less.<br />
* Try to keep the '''line length''' in the PKGBUILD below ~100 characters.<br />
* Where possible, '''remove empty lines''' from the {{ic|PKGBUILD}} ({{ic|provides}}, {{ic|replaces}}, etc.)<br />
* It is common practice to '''preserve the order''' of the {{ic|PKGBUILD}} fields as shown above. However, this is not mandatory, as the only requirement in this context is '''correct bash syntax'''.<br />
* '''Quote''' variables which may contain spaces, such as {{ic|"$pkgdir"}} and {{ic|"$srcdir"}}.<br />
* To ensure the '''integrity''' of packages, make sure that the [[PKGBUILD#Integrity|integrity variables]] contain correct values. These can be updated using the {{ic|updpkgsums}} tool.<br />
<br />
== Package naming ==<br />
<br />
* Package names can contain only alphanumeric characters and any of {{ic|@}}, {{ic|.}}, {{ic|_}}, {{ic|+}}, {{ic|-}}. Names are not allowed to start with hyphens or dots. All letters should be lowercase.<br />
* Package names should NOT be suffixed with the upstream major release version number (e.g. we do not want libfoo2 if upstream calls it libfoo v2.3.4) in case the library and its dependencies are expected to be able to keep using the most recent library version with each respective upstream release. However, for some software or dependencies, this can not be assumed. In the past this has been especially true for widget toolkits such as GTK and Qt. Software that depends on such toolkits can usually not be trivially ported to a new major version. As such, in cases where software can not trivially keep rolling alongside its dependencies, package names should carry the major version suffix (e.g. gtk2, gtk3, qt4, qt5). For cases where most dependencies can keep rolling along the newest release but some cannot (for instance closed source that needs libpng12 or similar), a deprecated version of that package might be called libfoo1 while the current version is just libfoo.<br />
<br />
==Package versioning==<br />
<br />
* Package versions (i.e. [[PKGBUILD#pkgver]]) '''should be the same as the version released by the author'''. Versions can include letters if need be (eg, nmap's version is 2.54BETA32). '''Version tags may not include hyphens!''' Letters, numbers, and periods only.<br />
* '''Stable packages package stable releases''': Release candidates (i.e. {{ic|1.0.0-rc1}}), alpha (e.g. {{ic|1.0.0-alpha1}}) and beta (e.g. {{ic|1.0.0-beta1}}) releases are not allowed and are only to be used under the following circumstances:<br />
** The non-stable release holds '''urgent''' security fixes (and backporting is non-trivial).<br />
** The non-stable release allows for the package to be built (e.g. problems introduced due to updated dependencies) and those changes can not otherwise be backported easily.<br />
** The non-stable release allows the distribution to drop an EOL component (e.g. qt4, python2).<br />
* Package releases (i.e. [[PKGBUILD#pkgrel]]) are '''specific to Arch Linux packages'''. These allow users to differentiate between newer and older package builds. When a new package version is first released, the '''release count starts at 1'''. Then as fixes and optimizations are made, the package will be '''re-released''' to the Arch Linux public and the '''release number will increment'''. When a new version comes out, the release count resets to 1. Package release tags follow the '''same naming restrictions as version tags'''.<br />
<br />
==Package dependencies==<br />
<br />
* '''Do not rely on [[Wikipedia:Transitive dependency|transitive dependencies]]''' in any of the [[PKGBUILD#Dependencies]], as they might break, if one of the dependencies is updated.<br />
* List all direct library dependencies. To identify them {{man|1|find-libdeps}} (part of {{pkg|devtools}}) can be used.<br />
<br />
== Package relations ==<br />
<br />
* Do not add {{ic|$pkgname}} to [[PKGBUILD#provides]], as it is always implicitely provided by the package.<br />
* List all external shared libraries of a package in [[PKGBUILD#provides]] (e.g. {{ic|'libsomething.so'}}). To identify them {{man|1|find-libprovides}} (part of {{pkg|devtools}}) can be used.<br />
<br />
== Package sources ==<br />
<br />
* HTTPS sources ({{ic|https://}} for tarballs, {{ic|git+https://}} for git sources) should be used wherever possible<br />
* Sources should be verified using PGP signatures wherever possible (this might entail building from a git tag instead of a source tarball, if upstream signs commits and tags but not the tarballs)<br />
* '''Do not diminish the security or validity of a package''' (e.g. by removing a checksum check or by removing PGP signature verification), because an upstream release is broken or suddenly lacks a certain feature (e.g. PGP signature missing for a new release)<br />
* Sources have to be unique in {{ic|srcdir}} (this might require renaming them when downloading, e.g. {{ic|<nowiki>"${pkgname}-${pkgver}.tar.gz::https://${pkgname}.tld/download/${pkgver}.tar.gz"</nowiki>}})<br />
* Avoid using specific mirrors (e.g. on sourceforge) to download, as they might become unavailable<br />
<br />
== Working with upstream ==<br />
<br />
It is considered best-practice to work closely with upstream wherever possible. This entails reporting problems about building and testing a package.<br />
<br />
* Report problems to upstream right away.<br />
* Upstream patches wherever possible.<br />
* Add comments with links to relevant (upstream) bug tracker tickets in the [[PKGBUILD]] (this is particularly important, as it ensures, that other packagers can understand changes and work with a package as well).<br />
<br />
It is recommended to track upstream with tools such as {{pkg|nvchecker}} or {{pkg|urlwatch}} to be informed about new stable releases.<br />
<br />
== Directories ==<br />
<br />
* '''Configuration files''' should be placed in the {{ic|/etc}} directory. If there is more than one configuration file, it is customary to '''use a subdirectory''' in order to keep the {{ic|/etc}} area as clean as possible. Use {{ic|/etc/{pkgname}/}} where {{ic|<nowiki>{pkgname}</nowiki>}} is the name of the package (or a suitable alternative, eg, apache uses {{ic|/etc/httpd/}}). <br />
* Package files should follow these '''general directory guidelines''':<br />
<br />
:{|<br />
|-<br />
| {{ic|/etc}}<br />
| '''System-essential''' configuration files<br />
|-<br />
| {{ic|/usr/bin}}<br />
| Binaries<br />
|-<br />
| {{ic|/usr/lib}}<br />
| Libraries<br />
|-<br />
| {{ic|/usr/include}}<br />
| Header files<br />
|-<br />
| {{ic|<nowiki>/usr/lib/{pkg}</nowiki>}}<br />
| Modules, plugins, etc.<br />
|-<br />
| {{ic|<nowiki>/usr/share/doc/{pkg}</nowiki>}}<br />
| Application documentation<br />
|-<br />
| {{ic|/usr/share/info}}<br />
| GNU Info system files<br />
|-<br />
| {{ic|/usr/share/man}}<br />
| Manpages<br />
|-<br />
| {{ic|<nowiki>/usr/share/{pkg}</nowiki>}}<br />
| Application data<br />
|-<br />
| {{ic|<nowiki>/var/lib/{pkg}</nowiki>}}<br />
| Persistent application storage<br />
|-<br />
| {{ic|<nowiki>/etc/{pkg}</nowiki>}}<br />
| Configuration files for {{ic|<nowiki>{pkg}</nowiki>}}<br />
|-<br />
| {{ic|<nowiki>/opt/{pkg}</nowiki>}}<br />
| Large self-contained packages<br />
|}<br />
<br />
* Packages should not contain any of the following directories:<br />
** {{ic|/bin}}<br />
** {{ic|/sbin}}<br />
** {{ic|/dev}}<br />
** {{ic|/home}}<br />
** {{ic|/srv}}<br />
** {{ic|/media}}<br />
** {{ic|/mnt}}<br />
** {{ic|/proc}}<br />
** {{ic|/root}}<br />
** {{ic|/selinux}}<br />
** {{ic|/sys}}<br />
** {{ic|/tmp}}<br />
** {{ic|/var/tmp}}<br />
** {{ic|/run}}<br />
<br />
== Makepkg duties ==<br />
<br />
When [[makepkg]] is used to build a package, it does the following automatically:<br />
<br />
# Checks if package '''dependencies''' and '''makedepends''' are installed<br />
# '''Downloads source''' files from servers<br />
# '''Checks the integrity''' of source files<br />
# '''Unpacks''' source files<br />
# Does any necessary '''patching'''<br />
# '''Builds''' the software and installs it in a fake root<br />
# '''Strips''' symbols from binaries<br />
# '''Strips''' debugging symbols from libraries<br />
# '''Compresses''' manual and, or info pages<br />
# Generates the '''package meta file''' which is included with each package<br />
# '''Compresses''' the fake root into the package file<br />
# '''Stores''' the package file in the configured destination directory (<span title="Current Working Directory" style="border-bottom: 1px dotted">cwd</span> by default)<br />
<br />
== Architectures ==<br />
<br />
The {{ic|arch}} array should contain {{ic|'x86_64'}} if the compiled package is architecture-specific. Otherwise, use {{ic|'any'}} for architecture independent packages.<br />
<br />
== Licenses ==<br />
<br />
See [[PKGBUILD#license]].<br />
<br />
== Reproducible Builds ==<br />
<br />
Arch is working on making all packages [https://reproducible-builds.org/ reproducible]. A packager can check if a package is reproducible with {{ic|makerepropkg}} from {{Pkg|devtools}} or {{ic|repro}} from {{Pkg|archlinux-repro}}.<br />
<br />
$ makerepropkg $pkgname-1-1-any.pkg.tar.zst<br />
<br />
Or<br />
<br />
$ repro -f $pkgname-1-1-any.pkg.tar.zst<br />
<br />
== Additional guidelines ==<br />
<br />
Be sure to read the above guidelines first - important points are listed on this page that will not be repeated in the following guideline pages. These specific guidelines are intended as an addition to the standards listed on this page.<br />
<br />
{{Package guidelines}}<br />
<br />
Packages submitted to the AUR must additionally comply with [[AUR submission guidelines]].</div>Jelly