Configure gmail less secure app
Setup gitconfig
file = ~/.gitconfig
[user]
email = <your-mail-address>
name = <Name Surname>
[core]
editor = vim
whitespace = fix,-indent-with-non-tab,trailing-space,cr-at-eol
excludesfile = ~/.gitignore
[sendemail]
smtpuser = <your-mail-address>
smtpserver = smtp.gmail.com
smtpencryption = tls
smtpserverPort = 587
smtppass = <pwd generated for app by gmail>
Setup ~/.vimrc
filetype plugin indent on
syntax on
set title
set tabstop=8
set softtabstop=8
set shiftwidth=8
set noexpandtab
Once you configure mail account, you can subscribe to a Kernel topic mailing list using majordomo list.
Majordomo lists at VGER.KERNEL.ORG
Subscribe by sending subscribe linux-rtc in the message body to majordomo@vger.kernel.org Wait one day to be acepted.
E.g.
subscribe linux-rtc
unsubscribe linux-rtc
In order to build entire Linux Kernel the commands steps are needed
$ make mrproper
$ make allmodconfig
$ make -j20 all
- Staging directory
$ cd drivers/staging
- Check for the source code modification command:
$ find drivers/staging/ -iname "TODO"
- Check for the source code modifications tool:
$ scripts/checkpatch.pl drivers/staging/*/*
$ scripts/checkpatch.pl -f drivers/staging/*/*
- Check Maintainers
Check mainteners mails:
$ scripts/get_maintainer.pl -norolestats <your-patch>
- Commit message
$ git log drivers/staging/android/ashmem.c
$ git log --pretty=oneline drivers/staging/android/ashmem.c
$ git commit -s -v
$ git format-patch -1
- Send Mail
$ git send-email --cc-cmd='./scripts/get_maintainer.pl --norolestats <patch>' --cc <your-mail-address> <patch>
After send you can see your mail on:
Kernel: https://lkml.org/
U-Boot: https://patchwork.ozlabs.org/project/uboot/list/
First of all clone Linus Torvalds Mainline Linux Kernel:
$ git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
List of Linux Kernel Mainteners Tree
For example setup Alexandre Belloni Kernel Tree:
$ git remote add abelloni https://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git/
$ git fetch abelloni
$ git fetch --tags abelloni
$ git branch -a
- https://drm.pages.freedesktop.org/maintainer-tools/repositories.html
- page: https://cgit.freedesktop.org/drm/drm
$ git remote add drm-misc git://anongit.freedesktop.org/drm/drm
$ git fetch drm-misc
$ git fetch --tags drm-misc
$ git branch -a
remotes/abelloni/rtc-fixes
remotes/abelloni/rtc-next
remotes/abelloni/rtc/irqf_no_autoen
Create first a series:
$ git format-patch HEAD -N --subject-prefix="PATCH" --cover-letter -o patches/
If you are fixing first patch resend using v2..vN:
$ git format-patch HEAD -N --subject-prefix="PATCH vN" --cover-letter -o patches/
Then send the series using:
git send-email --cc-cmd='./scripts/get_maintainer.pl --norolestats <patch>' --cc <mail> ./patches/*.patch
If you receive feedback on a patch, and were asked to update the patch, you need to version the patches that you re-send. A new version number lets reviewers know you made changes to the patch, and they should review it again.
An example of what this would look like is:
[PATCH] Foo: Fix these things
And the updated versioning for a second revision:
[PATCH v2] Foo: Fix these things better
In case of more than 2 versions, make sure to include what has changed in each version below the -- so that there is a logical flow and the maintainers do not have to dig up previous versions. The most recently changed version should be described first followed by the subsequent changes. Have a look at this patch example with 3 versions to get a better idea.
Example:
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
Changes since v2:
- Change to build-in this driver.
Changes since v1:
- Add remove interface.
- Add regmap checking when probing the driver.
- Add MODULE_ALIAS()
---
#tag
T → ~C "tommaso merciai" + enter
#untag
ctrl + t → . → enter
#find
l → ~C "tommaso merciai" + enter
#Copy all tagged and save
;C → folder
;s → folder
#Send patch
mainteiners=$(./scripts/get_maintainer.pl --norolestats <.patch>)
mutt -H <.patch> -c "$mainteiners"
#Select and save
t for select message
;
s
#Delete selected
t
;
d
then switch mailbox to sync
#Apply patch from mutt
L
Follow:
Then add in ~/.gitconfig:
[pw]
server = https://patchwork.ozlabs.org/api/1.1
project = <project>
username = <userename>
password = <pwd>
token = <token>
Test it using the following cmd:
git-pw --project <project-name> series list
Always increase the version number, no matter how small the change is. The maintainers focus on the latest version and ignore the older versions. Make sure that the maintainers don't need to guess what version he should take, that just creates problems.
Then sending a new version of the patch always add a change log, either after the --- line (three dashes) or in the cover letter.
If a patch in a bigger patchset changes resubmit the whole patchset, even the patches which have not changes. The maintainers look at patchsets as a complete unit, usually they do not want to take patches individually from a patchset.
Subject lines, like commit messages (see below) should be written in imperative voice (“fix foo and optimize bar”), not in any other way such as past tense (“fixed foo and optimized bar”).
Git includes some "hooks" for scripts that can be run before or after specific git commands are executed. The "post-commit" hook is run after you make a git commit with the git commit command.
Linux kernel developers have very stringent guidelines for coding style. They're so picky, they created a script called checkpatch.pl that you can run over your patches to make sure the patch complies with the kernel coding style.
To ensure that you create good commits that comply with the coding style, you can run checkpatch.pl over your commit with the "post-commit" hook. Note that running checkpatch after the commit, checks the patch file you've created - not just the source code diff. Therefore it will catch more issues - spelling errors in log messages, spacing in log messages, warnings about adding/removing files, etc.
If you already have a .git/hooks/post-commit file, move it to .git/hooks/post-commit.sample. git will not execute files with the .sample extension.
If you already have a .git/hooks/post-applypatch file, move it to ..git/hooks/post-applypatch.sample. git will not execute files with the .sample extension.
Then edit the .git/hooks/post-commit and .git/hooks/post-applypatch files to contain only the following two lines:
#!/bin/sh
exec git show --format=email HEAD | ./scripts/checkpatch.pl --strict --codespell
Make sure the file is executable:
chmod a+x .git/hooks/post-applypatch
chmod a+x .git/hooks/post-commit
If you don't already have /usr/share/codespell/dictionary.txt, get it:
sudo apt-get install codespell
The following Python's libraries are required by checkpatch.
sudo apt-get install python3-ply python3-git
After you commit, this hook will output any checkpatch errors or warnings that your patch creates. If you see warnings or errors that you know you added, you can amend the commit by changing the file, using git add to add the changes, and then using git commit --amend to commit the changes.
References: