index.md - sites - public wiki contents of suckless.org
HTML git clone git://git.suckless.org/sites
DIR Log
DIR Files
DIR Refs
---
index.md (3190B)
---
1 Hacking
2 =======
3
4 Copying/license
5 ---------------
6 We only accept contributions from individuals, not corporate entities. See the
7 project LICENSE file you're contributing to.
8
9 Debugging
10 ---------
11 If you find any crashes, please send a full backtrace to the dedicated mailing
12 list. You can create backtraces with `gdb`:
13
14 Before starting a program, you may have to allow core file creation. It is
15 recommended that you put this in your profile:
16
17 $ ulimit -c unlimited
18
19 Then start the program as usual.
20
21 After the program crashes, do the following:
22
23 $ gdb -q `which program` /path/to/core
24 gdb> bt full
25
26 If you encounter freezes (no crash at all) of the program, you can debug as
27 follows:
28
29 $ gdb -q `which program` --attach `pgrep -o program`
30 gdb> bt full
31
32 Send the output of that command to the mailing list along with the output of
33 `program -v`! Thank you!
34
35 Patches
36 -------
37 There are two types of patches: The ones that fit to your personal taste and
38 the ones you think should be included in mainline.
39
40 For patches that fit your personal taste and you want to share with the
41 community, please follow the instructions on the [wiki](//suckless.org/wiki)
42 page on how to edit the pages you see here.
43
44 For patches that should be included in mainline see the
45 [community](//suckless.org/community) page and the hackers@ mailing list.
46 Please note that only patches to be included in mainline repos are to be
47 submitted to this list, customisation patches are to be submitted to the wiki!
48
49 Please provide a clear concise "commit message" for your patches.
50
51 The following instructions are a general guide on how to generate and apply
52 patches posted on this wiki:
53
54 patch filename format
55 ---------------------
56 The expected format for patches is:
57
58 For git revisions:
59
60 toolname-patchname-YYYYMMDD-SHORTHASH.diff
61 dwm-allyourbase-20160617-3465bed.diff
62
63 The YYYYMMDD date should correspond to the last time the patch has been
64 modified. The SHORTHASH here is the seven chars git commit short hash
65 corresponding to the last commit of the tool on which the patch can be applied
66 correctly and is working with. You can get it by taking the first seven chars
67 of the full hash or for example:
68
69 git rev-parse --short <commit-id> (with commit-id: HEAD, commit hash, etc.)
70
71 For release versions:
72
73 toolname-patchname-RELEASE.diff
74 dwm-allyourbase-6.1.diff
75
76 The RELEASE should correspond to the tool release version, ie 6.1 for dwm-6.1.
77
78 diff generation
79 ---------------
80 For git users:
81
82 cd program-directory
83 git add filechanges...
84 git commit (write a clear patch description)
85 git format-patch --stdout HEAD^ > toolname-patchname-YYYYMMDD-SHORTHASH.diff
86
87 For tarballs:
88
89 cd modified-program-directory/..
90 diff -up original-program-directory modified-program-directory > \
91 toolname-patchname-RELEASE.diff
92
93 Don't push multiple commits patchsets. A single patch should apply all changes
94 using `patch -p1`.
95
96 patch program
97 -------------
98 For git users, use -3 to fix the conflict easily:
99
100 cd program-directory
101 git apply path/to/patch.diff
102
103 For patches formatted with git format-patch:
104
105 cd program-directory
106 git am path/to/patch.diff
107
108 For tarballs:
109
110 cd program-directory
111 patch -p1 < path/to/patch.diff