Creating patches
This page documents the ways to propose changes to packages in Alpine Linux aports as a patch. Patches can be currently submitted via Gitlab only. Creating and submitting patches is one of the most effective way to contribute to Alpine Linux.
If you want to create a new package, refer Creating an Alpine package page.
Submitting patches via Gitlab
- Setup gitlab account first, if not already done.
- Fork the aports repository, if you want to open a merge request for aports.
- After forking clone the forked repository.
Creating a merge request
- Change to another branch for e.g. the name of the package you want to edit.
- Do your changes now and then push with:
git push -u origin $branchname
- Gitlab will print an URL to create a merge request in your terminal.
Amending changes to a merge request
If reviewers requested changes or if you noticed that something should be changed about your merge request's change you can simply amend your changes to the right commit and force push. So if you want to change the commit at the tip of your branch you can simply do:
git commit --amend
If you want to change a commit that's not at the tip of your branch you can do:
git commit --fixup $SHA1_OF_COMMIT_YOU_WANT_TO_FIX
Afterwards you have to force-push in order to update your merge request:
git push -f origin
Submitting patches via the mailing list
Patches should be created with git and submitted to alpine-aports mailing list with git send-email (which needs the git-email Alpine package).
Only the last commit with 'git send-email'
To submit the last commit as a patch to alpine-aports mailing list:
git send-email --to alpine-aports@lists.alpinelinux.org -1
git config sendemail.to alpine-aports@lists.alpinelinux.org
The first line in commit message will be subject and the long description (separated with empty line) will be the body in the email. The example below shows
testing/packagename: new aport <- header https://example.com/packagename <- body wonderful package
See Development using git#Email_configuration on how configure SMTP Auth.
Multiple commits with 'git send-email'
If you have many commits you can create a directory with patches and send them with git send-email.
rm -Rf patches mkdir patches git format-patch -o patches origin git send-email patches --compose --no-chain-reply-to --to alpine-aports@lists.alpinelinux.org
You can also format patches for the last x number of commits with:
git format-patch -x -o patches
This will produce the patches for each local commit in the directory "patches" and send them. Use --no-chain-reply-to to avoid that each patch is sent as a reply to the previous patch.
Eg.
- [PATCH 0/m]
- [PATCH 1/m]
- [PATCH 2/m]
- ...
- [PATCH 2/m]
- [PATCH 1/m]
With the option --no-chain-reply-to the patches will be sent as a reply to the first email, the cover letter (the [PATCH 0/m]) and will make the email thread nicer. Like this:
- [PATCH 0/m]
- [PATCH 1/m]
- [PATCH 2/m]
- ..
Resend an updated patch
Sometimes patches are rejected due to minor issues in the patch. Do not send an incremental patch on top of your initial, bad, patch. Instead, recreate the patch and send a new, fixed version of your patch. (use git commit --amend to edit a local commit).
When you sending a second version of the patch use --subject-prefix "PATCH v2" to indicate that this is a new version of a previously sent patch. You may also use --in-reply-to <message-id> where <message-id> the the id of email requesting the resend.
You should also write a note on what was changed. Use --annotate for this and write the comment under the three dashes "---" so the note is not included in the commit message. For example:
... Subject: [PATCH v2] testing/mypackage: new aport https://example.com Example package --- Changes v1 -> v2: - removed depends - added zlib-dev to makedepends testing/mypackage/APKBUILD | 41 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 testing/mypackage/APKBUILD ...
Note that the notes that are below the "---" will not be included in the commit message.