How to import a package from the Arch Linux repositories or the AUR to the CCR

totte · 2018-02-22 13:04:46 UTC

The CCR web application is a fork of the AUR web application, and both Chakra and Arch Linux use the same package manager, pacman, and backend, libalpm. This means that importing packages from the Arch Linux repositories or the AUR to the CCR is usually easy.

Search the Arch Linux repositories or the AUR, and open the page of the package you want to upload to the CCR. On the right side of the webpage there is a box titled Package Actions.
- If in the AUR, click Download Snapshot and extract the file.
- If in the Arch Linux repositories, click Source Files. You will see a list of the files to be included in the package, such as the PKGBUILD, and sometimes other files such as .patch, .install, .desktop etc. For each of the files listed, right click on plain (as in plain text) and then click Save Link As. Download them to a directory of your liking.
At the bottom of the webpage there is a listing of Dependencies. If there are dependencies not provided in the Chakra repositories or the CCR, you will need to submit those to the CCR as well. Keep in mind that the names for some packages are different in Chakra from those in Arch Linux - adjust the PKGBUILD accordingly in the next step.
Open Konsole, cd to the directory in which you saved your files, and open the PKGBUILD with the text editor of your choice.
- Edit the # Maintainer line at the beginning of the PKGBUILD file with your name and e-mail, and add a # Contributor line for any and all other contributors.
- Edit the names of potential dependencies, if necessary.
- Ensure that the PKGBUILD has the correct checksums of the required files (.patch, .desktop etc). The list of checksums follows the order in the source array of the PKGBUILD.
  Shortcut to update checksums
  
  To download the sources, generate the checksums, and insert them into the PKGBUILD in one go:
```
$ updpkgsums
```
  Signature checking with PGP keys
  
  The signature checking implemented in makepkg does not use pacman's keyring, instead relying on the user’s keyring. If a signature file in the form of .sig or .asc is part of the PKGBUILD source array, makepkg automatically attempts to verify it. In case the user’s keyring does not contain the needed public key for signature verification, makepkg will abort the installation with a message that the PGP key could not be verified, like so:
```
==> Verifying source file signatures with gpg…
KeePass-2.37-Source.zip … FAILED (unknown public key A4F762DC58C6F98E)
==> ERROR: One or more PGP signatures could not be verified!
```
  If a needed public key for a package is missing, the PKGBUILD will most likely contain a validpgpkeys entry with the required key IDs. You can import the key manually, or you can find it on a keyserver and import it from there. To import the key from a keyserver using gpg, search for the key by its key ID like so:
```
$ gpg --search-keys A4F762DC58C6F98E
gpg: data source: https://18.9.60.141:443
(1)     Dominik Reichl <dominik.reichl@gmx.de>
4096 bit RSA key A4F762DC58C6F98E, created: 2016-06-08
```
  As you can see it is the same as the one listed on keepass website. You can now import it like so:
```
$ gpg --receive-keys A4F762DC58C6F98E
```
  If you want to disable signature checking, you can remove the related references. Using Arch Linux’ keepass PKGBUILD as an example; lines 20, 39 and 44 should be removed.
Build and install the package (makepkg -si) to ensure that it works as intended, then create the .src.tar.gz file that is to be submitted to the CCR:
```
$ makepkg --source
```
Submit this file to the CCR (you’ll need to register an account first, if you haven’t already).

To update a package when a new version is released you’ll usually only need to update the pkgver to the new version and the checksum array in the PKGBUILD, followed by repeating step 3 and 4.

brikler · 2017-09-29 12:34:56 UTC

imo is this the second step or step 1.1 before download something

AlmAck · 2017-09-29 21:43:42 UTC

You have to sadify all the external dependencies before preparing your main pkg. So you have to repeat this procedure for all of them and only at the end build your desired package. You can consider it as step 0., or when on step 3. you will understand which pkg is missing.

totte · 2017-10-25 18:09:26 UTC

2 posts were split to a new topic: I flagged some CCR entries which hasn’t been updated for some time as “out of date”, but the maintainer hasn’t updated them, what should I do?