Project

General

Profile

DeveloperGuide » History » Version 99

dl lud, 12/07/2019 02:29 AM
Grammar fixes.

1 31 Paul Kocialkowski
h1. Developer guide
2 1 Paul Kocialkowski
3 15 Paul Kocialkowski
{{>toc}}
4
5 3 Paul Kocialkowski
h2. Prerequisites
6
7 8 Paul Kocialkowski
Developing on Replicant isn't much harder than developing on any other free software project as it doesn't require specific knowledge. In fact, you'll probably learn a lot along the way regarding how hardware works, how the Android system is composed, how the kernel works, etc, but you don't need to know all of this to start. However a basic set of skills is required, among which:
8 83 Denis 'GNUtoo' Carikli
* C language programming skills and the ability to understand other languages such as C++, Java and shell scripts.
9 82 Denis 'GNUtoo' Carikli
* Makefile skills (no need to know every detail about it, a general idea of how Makefiles work is enough). If you don't know how Makefiles work, Wikipedia has "an good article on make":https://en.wikipedia.org/wiki/Make_(software)#Makefile that has some examples Makefiles.
10
* Git skills (basically, how to commit changes, send them to our repos, dealing with branches without making a mess, etc). If you don't know git yet, you can find some documentation about Git at: https://git-scm.com/documentation to learn it.
11 3 Paul Kocialkowski
12
If you think you can cope with the requirements, then developing on Replicant should cause you no particular issue.
13
14 70 Wolfgang Wiedmeyer
The [[Index#Replicant-porting-guides|porting guides]] provide instructions for porting a new device to Replicant and also offer some tips for developing on Replicant.
15 3 Paul Kocialkowski
16 70 Wolfgang Wiedmeyer
Have a look at the [[Tasks]] page and feel free to [[Index#Contact|ask around]] for help to get started.
17 40 Wolfgang Wiedmeyer
18 70 Wolfgang Wiedmeyer
h3. Notes on writing free software replacements
19 59 Wolfgang Wiedmeyer
20 70 Wolfgang Wiedmeyer
Writing free software replacements for non-free components may require more skills depending on what you're trying to achieve, though there may be people with the adequate knowledge to help you and from whom you will likely learn a lot.
21 50 Wolfgang Wiedmeyer
22 88 Denis 'GNUtoo' Carikli
h2. Code hosting
23 40 Wolfgang Wiedmeyer
24 99 dl lud
Replicant's source code is hosted at "git.replicant.us":https://git.replicant.us/replicant. If you plan to contribute to Replicant, you are welcome to host your Replicant-related projects there under your own username. You only need to [[People#Active-developers|contact one of Replicant's developers]] and ask for an account. Please include the name, username and email address that should be used to create your account. Your repos will then show up on the "contributor repos":https://git.replicant.us/contrib page.
25 88 Denis 'GNUtoo' Carikli
26 89 Denis 'GNUtoo' Carikli
h2. Requirements for submitting patches
27 1 Paul Kocialkowski
28 89 Denis 'GNUtoo' Carikli
There are two ways to get your patches included:
29
* You can either send them directly to the "mailing list":https://lists.osuosl.org/mailman/listinfo/replicant
30 98 dl lud
* You can also open an issue on the "issue tracker":/projects/replicant/issues and attach the patches to the issue. At some point the patch will need to be sent to the mailing list by someone.
31 1 Paul Kocialkowski
32 89 Denis 'GNUtoo' Carikli
Replicant developers will then review your changes on the mailing list.
33
34
There are many ways to send patches to the mailing list
35
* You can simply attach the patch to a mail
36
* If you like the command line, git has a tool called "@git send-email@":https://git-scm.com/docs/git-send-email to send patches directly from it . If it's too much hassle for you to set up @git send-email@, sending the patches with your favorite mail client should be fine, too.
37
* If you want to send the patch from your command line to your mail client, git's "@git imap-send@":https://git-scm.com/docs/git-imap-send can do that
38 3 Paul Kocialkowski
39 93 Denis 'GNUtoo' Carikli
As there are many git repositories in Replicant, it's also best if you indicate in one way or in another to which repository the patch applies, and for which Replicant version the patch is. This can also be done in many ways:
40
* If you attach your patch in a mail you could simply mention it in the mail.
41 95 Denis 'GNUtoo' Carikli
* If you use git-format-patch and send your patch through the command line you could use the subject prefix in git-format-patch to add the required information. For instance when sending a third version of a patch for "vendor_replicant":https://git.replicant.us/replicant/vendor_replicant only for Replicant 6, it could look like that: 
42 93 Denis 'GNUtoo' Carikli
<pre>
43 95 Denis 'GNUtoo' Carikli
git format-patch -1 --subject-prefix="PATCH][v3][Replicant 6.0][vendor_replicant"
44 93 Denis 'GNUtoo' Carikli
</pre>
45 95 Denis 'GNUtoo' Carikli
The mail would then have a subject that looks like that:
46 93 Denis 'GNUtoo' Carikli
<pre>
47 95 Denis 'GNUtoo' Carikli
Subject: [PATCH][v3][Replicant 6.0][vendor_replicant] Add build script to simplify the build procedure.
48 93 Denis 'GNUtoo' Carikli
</pre>
49
50 90 Denis 'GNUtoo' Carikli
h2. How to make patches
51
52
Creating and sending patches can be hard the first time. 
53
54
While there is a "recording of talk on the topic":https://video.fosdem.org/2010/maintracks/kernelpatch.xvid.avi on how to do it right, for Replicant you don't need to do it right the first time.
55
56
When you have done some modification that you want to be integrated in Replicant, if you're not confident enough with git, make a copy of the repository with the changes in some safe place.
57
58
59
We will take a real example on how to do a modification. For that we will use the Replicant website git repository.
60
61
The replicant.us website source code and content is in git. It contains the following:
62
* The "main page of the https://replicant.us website":https://replicant.us
63
* The "freedom-privacy-security-issues page":https://replicant.us/freedom-privacy-security-issues.php
64
* The "supported-devices page":https://replicant.us/supported-devices.php
65
* The "about page":https://replicant.us/about.php
66
* "A page about javascript licenses used on replicant.us":https://replicant.us/javascript.php
67
* "A page with screenshots of Replicant":https://replicant.us/screenshots.php
68
69
Let's suppose that a new Replicant 6.0 release is out but that everybody forgot to send a patch to the website and that the website has the following:
70
> Latest images: Replicant 6.0 0003. Replicant supports up to 13 different devices!
71
and that instead we want to have the following:
72
> Latest images: Replicant 6.0 0004. Replicant supports up to 13 different devices!
73
74
So the first thing to do would be to verify both on the bug tracker and on the mailing list that there isn't already a patch for that. If there isn't any we can safely go on.
75
76
To do the patch, we need to get the source code. This can be done with the following command:
77
<pre>
78
git clone https://git.replicant.us/replicant/website.git
79
</pre>
80
81
We then go into the website directory that has all the source code:
82
<pre>
83
cd website
84
</pre>
85
86
We then look where the text we want to modify is:
87
<pre>
88
git grep "Replicant 6.0 0003."
89
</pre>
90
91
It can potentially return many lines, but it will have somewhere a line that looks like this one:
92
<pre>
93
index.php:      <div class="alert alert-success" role="alert">Latest images: <strong>Replicant 6.0 0003</strong>. Replicant supports up to <strong>13</strong> different devices!</div>
94
</pre>
95
96
We can open this index.php file with a text editor and change "Replicant 6.0 0003" to "Replicant 6.0 0004".
97
98
99
We can see that git know that we modified the index.php file:
100
<pre>
101
git diff
102
</pre>
103
104
It will then have something like that:
105
<pre>
106
diff --git a/index.php b/index.php
107
index 080510a..fd6a8c9 100644
108
--- a/index.php
109
+++ b/index.php
110
@@ -2,7 +2,7 @@
111
 <?php include_once("include/autoloader.php"); ?>
112
 
113
 <div class="container" role="main">
114
-       <div class="alert alert-success" role="alert">Latest images: <strong>Replicant 6.0 0003</strong>. Replicant supports up to <strong>13</strong> different devices!</div>
115
+       <div class="alert alert-success" role="alert">Latest images: <strong>Replicant 6.0 0004</strong>. Replicant supports up to <strong>13</strong> different devices!</div>
116
        <div class="row">
117
                <div class="col-md-8">
118
                        <div class="panel panel-default">
119
</pre>
120
121
However even if git know about it, we still need to make it record the modification in what is called a commit.
122
123
A commit contains a record of what has been changed, along with an explanation of why the change was necessary.
124
125
To create a commit, the 'git commit' command can be used, however since we're going to write an explanation of why the change was necessary we will first need to tell git which text editor to use for that.
126
127
To do that you can do something like that in the command line:
128
<pre>
129
export GIT_EDITOR=your-favorite-editor
130
</pre>
131
132
For instance if you like gedit, you can do something like that to make git use gedit in the current shell:
133
<pre>
134
export GIT_EDITOR=gedit
135
</pre>
136
137
We also need to give git a valid email and a name. Both will appear in the commit.
138
139
Else git will refuse to create the commit message and will output an error that looks like this one:
140
<pre>
141
*** Please tell me who you are.
142
143
Run
144
145
  git config --global user.email "you@example.com"
146
  git config --global user.name "Your Name"
147
148
to set your account's default identity.
149
Omit --global to set the identity only in this repository.
150
</pre>
151
152
So we then need to run something like that:
153
<pre>
154
  git config --global user.email "you@example.com"
155
  git config --global user.name "Your Name"
156
</pre>
157
158
Then in the same shell you can run the following command:
159
<pre>
160
git commit -s
161
</pre>
162
163
It will then open the text editor you choose and let you write text that describes why the change was necessary.
164
165
The convention is to have a first line that is not too long which summarize why that change is needed.
166
167
Then you can write longer text to describe the change details or have more in depth argumentation of why the change is needed.
168
169
Since here Replicant releases have already been made in the past, it's very likely that similar changes have already been made before.
170
171
We will take advantage of that and look what message the previous contributor wrote.
172
173
To do that, we can open a new shell, and go in the website directory and run the 'git log' command in there:
174
<pre>
175
git log
176
</pre>
177
178
This will show many commits. You can navigate with the keyboard arrows and quit by pressing the 'q' key.
179
180
Among the many commits you can see this one:
181
<pre>
182
commit 526edccd8d688544602ae3da1c4d9c5ffdc058ca
183 92 Denis 'GNUtoo' Carikli
Author: Denis 'GNUtoo' Carikli <GNUtoo@no log.org>
184 90 Denis 'GNUtoo' Carikli
Date:   Thu Dec 14 12:37:21 2017 +0100
185
186
    index: Replicant 6.0 0003 images have been released
187
    
188 92 Denis 'GNUtoo' Carikli
    Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no log.org>
189 90 Denis 'GNUtoo' Carikli
</pre>
190
191
The sumarry is this line:
192
<pre>
193
index: Replicant 6.0 0003 images have been released
194
</pre>
195
196
And it doesn't contain a more in depth explanation because it was not deemed necessary.
197
198 92 Denis 'GNUtoo' Carikli
The line with "Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no log.org>" has been automatically generated by git when using '-s' in the 'git commit -s' command.
199 90 Denis 'GNUtoo' Carikli
200
It means that you certify that you have the (legal) right to publish the patch. 
201
202
For more details on it, you can see the "Developer's Certificate of Origin" in "the Linux kernel documentation on submirting patches":https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v5.3-rc7#n418
203
204
So you can write something like "index: Replicant 6.0 0004 images have been released" to tell that the change is needed because new images have been released.
205
206
After saving and closing your text editor, git has now a new commit.
207
208
You can now generate a file from it with
209
<pre>
210
git send-email -1
211
</pre>
212
213
The easiest way is then to write an email to the mailing list and attaching the patch in it.
214
215
As Replicant has many many git repository it's also good not to forget to mention for which repository is the patch. Here the patch is for the website git repository.
216
217
An email like that would be good enough for that:
218
<pre>
219
Hi,
220
221
I've here's a patch that I attached for the website repository.
222
</pre>
223 93 Denis 'GNUtoo' Carikli
224
As there are sometimes different versions of Replicant being worked on in parallel it's also a good idea to also mention the version it is meant for, when it is relevant.
225
226
For instance here as there isn't one website per Replicant version it's not relevant here.
227 90 Denis 'GNUtoo' Carikli
228 96 Denis 'GNUtoo' Carikli
h3. What happens after sending the patch?
229
230
Once the patch has been sent you will need to wait for people to review it. You can also try to find people on IRC that are willing to review your patch to speed things up.
231
232
As Replicant contributors are sometime very busy it can take some time.
233
234
If you get no response in one week, you can try to respond to your patch asking again people to review it.
235
236
If you get some response, you will typically get some comments on the patch.
237
238
This usually mean that your patch is good and that people are interested in it, but that you still need to fixes some things before it can be integrated in Replicant.
239
240
Once you fixed what needed to be fixed, you then need to send a second version of the patch with the fixes inside.
241
242
When doing that it's best to try to indicate in some way that the patch you send is the second version.
243
244
You could for instance mention it in the mail subject for instance.
245
246
The patch will then need to be reviewed again, and if everything is good it will be merged. If not you will probably get some more comments that you need to address in a third version of the patch.
247
248 81 Denis 'GNUtoo' Carikli
h2. Pushing patches
249
250
If you already have the ability to push patches into the main Replicant repositories, you still need to send your patches to the mailing list if they are to be applied on a Replicant version that is currently supported, or if they apply to the Replicant website.
251
252
You will then need to wait either for:
253
* One other developer to review the patch and add "per's":https://stallman.org/articles/genderless-pronouns.html Acknowledgement.
254
* One week if no other developer did review your patches.
255
256 71 Wolfgang Wiedmeyer
h2. Writing free software replacements
257 1 Paul Kocialkowski
258 71 Wolfgang Wiedmeyer
Here are some tips that may help you achieving a free software replacement for a specific component (some may be more or less relevant regarding the nature of what the component does):
259
* Look for interested people from other projects: LineageOS people are constantly fighting with non-free blobs and are sometimes happy to help replacing one.
260 1 Paul Kocialkowski
* Try to make the non-free binary as verbose as possible by enabling all the possible debug options on the config file or such.
261 85 Denis 'GNUtoo' Carikli
* You can use @string@ to try to find out the command line debug options, list of commands, etc.
262 71 Wolfgang Wiedmeyer
* Run the program in @strace@ and analyze the trace to understand what the program does.
263
* Add verbose debug prints in the concerned kernel driver (with @printk@ and show them via the @dmesg@ tool).
264
* Read the corresponding kernel driver: you can sometimes learn a lot by reading comments or headers.
265
* Collect data out of the kernel driver (via debug prints) and out of the non-free binary (via debug prints on the upper-layer).
266
* If there is a mathematical algorithm involved, force the values returned by the kernel to the non-free binary and analyze how it reacts, for instance with spreadsheet software.
267 1 Paul Kocialkowski
* If you're directly dealing with a hardware component, try to find a datasheet for the chip, it may hold precious details. In the best case, you may also be able to find a reference software implementation!
268 84 Denis 'GNUtoo' Carikli
* Make sure that the methods you use are legal where you live, and that the Replicant project is able to legally redistribute your work. In doubt, you could ask the Replicant developers in the mailing list and/or at the private contact address. The Replicant project has also access to legal advise through the FSF.
269 2 Paul Kocialkowski
270
h2. Upstreaming work
271
272 1 Paul Kocialkowski
It is generally a good idea to send some changes back to upstream, assuming that they will benefit from it as well.
273 2 Paul Kocialkowski
274 1 Paul Kocialkowski
When it is about the replacement of a non-free component present in the upstream systems, make sure that your replacement is reliable and complete.
275
Contact the interested developers on the upstream projects before attempting to send your replacement.
276
277
h3. LineageOS
278
279 86 Denis 'GNUtoo' Carikli
The LineageOS project has a "checklist":https://github.com/LineageOS/charter/blob/master/device-support-requirements.md of requirements for adding support for a device.
280
281
As the LineageOS developers have to make sure that the checklist requirements are met, make sure that your replacement is complete enough to either meet the checklist requirements, or that the LineageOS developers are interested in working together with you to make sure that the free software replacement meets such requirements.
282
283 1 Paul Kocialkowski
The LineageOS team uses Gerrit to manage patch submissions. The process to get your patch included in LineageOS repos is explained on their wiki: "Gerrit":http://wiki.lineageos.org/usinggerrit-howto.html#submitting-to-gerrit
284 2 Paul Kocialkowski
285
You can also push directly using git using the following scheme (untested):
286
<pre>
287
git push ssh://<sshusername>@review.lineageos.org:29418/LineageOS/<projectname> HEAD:refs/for/<branchname>
288
</pre>
289 25 Paul Kocialkowski
290
h3. AOSP
291
292
The Android Open Source Project uses Gerrit to manage patch submissions. Some information about submitting patches to AOSP is available: https://source.android.com/source/submit-patches.html
293
294
You can push to AOSP's review using:
295 3 Paul Kocialkowski
<pre>
296
git push https://android-review.googlesource.com/platform/system/core HEAD:refs/for/master
297
</pre>
298 43 Wolfgang Wiedmeyer
299 71 Wolfgang Wiedmeyer
h2. Commonly-used terminology
300 3 Paul Kocialkowski
301 71 Wolfgang Wiedmeyer
In order to keep everything clear and consistent, we use the following terms with a precise meaning in mind:
302
* *Driver*: Software that is part of the *kernel* (builtin or as a module) and deals with communicating with the hardware
303
* *Hardware Abstraction Layer (HAL)*: Software that runs in *user-space* and deals with communicating with the hardware (usually through a kernel driver)
304
* *module*: Android HALs are also often called modules, so we may referrer to e.g. the @audio HAL@ as the @audio module@
305
* *blob*: Proprietary HAL
306
* *firmware*: Software that does not run on the main processor (the CPU) but rather in a separate chip (e.g. the Wi-Fi firmwares runs on the Wi-Fi chip)
307 1 Paul Kocialkowski
308
h2. Wiki guidelines
309
310
In order the keep the wiki simple and consistent, a few guidelines must be followed when editing.
311
312
Regarding the content:
313
* Only Replicant-specific topics should be covered by the wiki: there is no point in writing usage guides for generic Android aspects, such as the user interface.
314
* The content on each page should *only* be relevant to the latest Replicant version: make sure to update the content with newer Replicant versions.
315
* Substantial changes must be discussed before modifying the wiki.
316
* A comment should be added in the comment field at the bottom that shortly describes the change.
317 72 Wolfgang Wiedmeyer
* Make use of the wiki formatting possibilities: "quick reference":/help/en/wiki_syntax_textile.html and "detailed syntax overview":/help/en/wiki_syntax_detailed_textile.html
318 1 Paul Kocialkowski
  By using @[[Index]]@, it's possible to link to the start page of the wiki.
319 6 Paul Kocialkowski
320 3 Paul Kocialkowski
Regarding the writing style:
321
* Every page in the wiki has to be written in correct English, we do not aim to provide information in any other language.
322 17 Paul Kocialkowski
* Addressing readers directly should be avoided when possible: Instead, what is described should always be the subject of sentences.
323 97 Denis 'GNUtoo' Carikli
* Links to pages should be incorporated in text (Instructions to [[ToolsInstallation|install the tools]] shouldn't be: Instructions to install the tools: [[ToolsInstallation]]).
324 14 Paul Kocialkowski
325
Regarding the naming of pages:
326 34 Paul Kocialkowski
* Pages must be named in a consistent manner ([[NexusSI902xFirmwares]] is not to be called [[FirmwaresOnTheI902xNexusS]]).
327 1 Paul Kocialkowski
* Common prefixes and suffixes should be used for naming new pages ([[BuildDependenciesInstallation]] is not to be called [[InstallationOfBuildDependencies]]).
328 34 Paul Kocialkowski
* Page and section names should always be named using nouns, not verbs, either active or not ([[DeveloperGuide]] is not to be called [[DevelopingGuide]]).
329
* Page titles shouldn't contain space or any delimiter character (such as - or_) but use upper-case characters as word delimiters ([[BuildDependenciesInstallation]] is not to be called [[Build_dependencies_installation]]).
330
* Page titles *as shown on the page* should use lower-case when upper-case is not needed, even if the page name uses upper-case as word delimiters.
331
332 49 Wolfgang Wiedmeyer
Regarding the naming of devices:
333 53 Wolfgang Wiedmeyer
* Devices should be named after their model number and codename, without mention of the manufacturer.
334 49 Wolfgang Wiedmeyer
* Common device naming conventions should be followed consistently (the @Galaxy S 3 (I9300)@ is not to be called @Samsung S3 GT-I9300@ or @Galaxy S III@).
335 34 Paul Kocialkowski
336 71 Wolfgang Wiedmeyer
h2. Repositories
337 34 Paul Kocialkowski
338 71 Wolfgang Wiedmeyer
When working with Replicant repos, make sure to avoid breaking things. For instance, if you push a commit introducing a compilation error, it will break the whole build process.
339
It is better to create separate branches (that are not used by the official manifest branches) when your work is still in progress.
340
Creating branches that add debug infos on a particular topic is usually a good idea since it will save you time next time you want to debug the same component.
341
342 80 Denis 'GNUtoo' Carikli
See [[SourceCodeRepositories]] for more details about how to create or mirror repositories on Replicant server.
343 71 Wolfgang Wiedmeyer
344
h3. When creating a repository
345 78 Denis 'GNUtoo' Carikli
346 71 Wolfgang Wiedmeyer
In order to keep repo naming consistent, please name repositories by their name on the tree, replacing the @/@ by @_@.
347
For instance, when forking the LineageOS repo: @android_device_samsung_crespo@, rename it to @device_samsung_crespo@ on the Replicant repos.
348
This creates a more consistent way of naming repositories and makes it easier when pushing: just look at the location in the source tree and replace @/@ by @_@.
349
350
h3. When creating a branch
351
352
Official Replicant branches are named the following way:
353
* The @replicant-@ prefix
354
* The Replicant version
355
356
Such as: @replicant-2.3@ This should be used on the projects repositories as well as the manifest repository.
357
Any other branch should be considered as Work In Progress (WIP) and thus not be part of any official branch of the manifest.
358
359
There is although one exception, with the @master@ branch, that can be used by any project and be in any manifest given that the code held in the @master@ branch will work on any Replicant version.
360 16 Paul Kocialkowski
361 33 Paul Kocialkowski
h2. New images release
362 1 Paul Kocialkowski
363 33 Paul Kocialkowski
# Modify the changelog in the vendor files:
364
<pre>
365 54 Wolfgang Wiedmeyer
cd path/to/replicant-6.0/vendor/replicant
366 33 Paul Kocialkowski
edit CHANGELOG.mkdn
367
git add CHANGELOG.mkdn
368 54 Wolfgang Wiedmeyer
git commit -sS -m "Replicant 6.0 0001 images release"
369
git push git@git.replicant.us:replicant/vendor_replicant.git replicant-6.0
370 33 Paul Kocialkowski
</pre>
371 65 Wolfgang Wiedmeyer
# Increment the release in the "release scripts":https://git.replicant.us/replicant/release-scripts:
372 33 Paul Kocialkowski
<pre>
373
cd path/to/release-scripts
374 58 Wolfgang Wiedmeyer
edit releasevars.sh
375
git add releasevars.sh
376 1 Paul Kocialkowski
git commit -sS -m "Replicant 6.0 0001 images release"
377
git push git@git.replicant.us:replicant/release-scripts.git replicant-6.0
378 58 Wolfgang Wiedmeyer
</pre>
379 63 Wolfgang Wiedmeyer
# Tag all the repositories with the release tag script:
380
<pre>
381
path/to/release-scripts/releasetag.sh path/to/replicant-6.0
382
</pre>
383 58 Wolfgang Wiedmeyer
# In the manifest repo, merge the replicant-6.0-dev branch into the replicant-6.0 branch and increment the release in the manifest:
384
<pre>
385
cd path/to/manifest
386
git checkout replicant-6.0
387
git merge replicant-6.0-dev
388
edit default.xml
389
git add default.xml
390
git commit -sS -m "Replicant 6.0 0001 images release"
391
git push git@git.replicant.us:replicant/manifest.git replicant-6.0
392 33 Paul Kocialkowski
</pre>
393
# Tag the manifest:
394 61 Wolfgang Wiedmeyer
<pre>
395
git tag -u 5816A24C10757FC4 replicant-6.0-0001 -m "Replicant 6.0 0001 images release"
396
git push git@git.replicant.us:replicant/manifest.git replicant-6.0-0001
397
</pre>
398 64 Wolfgang Wiedmeyer
# Verify all tags:
399
<pre>
400
cd .repo/manifests
401
git verify-tag $(git describe)
402
cd ../..
403 68 Wolfgang Wiedmeyer
repo forall -ec ' { echo "Verifying $REPO_PROJECT" && git verify-tag $(git describe) 2>/dev/null; } || { echo "Error: verification failed!" && exit 1; } '
404 64 Wolfgang Wiedmeyer
</pre>
405 56 Wolfgang Wiedmeyer
# Update prebuilts and start the build (in a newly opened shell with the Replicant keys and certificates installed):
406
<pre>
407
path/to/release-scripts/releasebuild.sh path/to/replicant-6.0
408
</pre>
409 33 Paul Kocialkowski
# Release the images with the release script:
410
<pre>
411 55 Wolfgang Wiedmeyer
rm -rf path/to/images/replicant-6.0/0001
412 54 Wolfgang Wiedmeyer
mkdir -p path/to/images/replicant-6.0/0001
413
path/to/release-scripts/release.sh path/to/replicant-6.0 path/to/images/replicant-6.0/0001
414 1 Paul Kocialkowski
</pre>
415 33 Paul Kocialkowski
# Sign the binaries with the release script:
416
<pre>
417 54 Wolfgang Wiedmeyer
path/to/release-scripts/release.sh path/to/replicant-6.0 path/to/images/replicant-6.0/0001 signatures
418 1 Paul Kocialkowski
</pre>
419 33 Paul Kocialkowski
# Compress the release files
420
<pre>
421 54 Wolfgang Wiedmeyer
cd path/to/images/replicant-6.0
422
tar -cjf 0001.tar.bz2 0001
423 1 Paul Kocialkowski
</pre>
424 33 Paul Kocialkowski
# Upload the release to OSUOSL:
425
<pre>
426 66 Wolfgang Wiedmeyer
rsync -P -4 -ze ssh 0001.tar.bz2 replicant@ftp-osl.osuosl.org:/home/replicant/data/images/replicant-6.0/
427 54 Wolfgang Wiedmeyer
</pre>
428 67 Wolfgang Wiedmeyer
# Unpack the release on OSUOSL, ensure permissions are correct and run the @trigger-replicant@ script
429 33 Paul Kocialkowski
# Update [[ReplicantImages]] with the release
430
# Update each device's page with the release
431
# Update [[ReplicantStatus]] with the latest status
432 62 Wolfgang Wiedmeyer
# Verify if other wiki pages need to be updated due to changes introduced by the release (e.g. [[Index#Replicant-build|build pages]] or [[ToolsInstallation]])
433 33 Paul Kocialkowski
# Announce the release on the blog
434
# Update the release on the website and IRC topic
435 5 Paul Kocialkowski
436 33 Paul Kocialkowski
h2. New device documentation
437 22 Paul Kocialkowski
438 19 Paul Kocialkowski
1. Create the device main page, following the naming guidelines applied to other devices (e.g. the Samsung Galaxy S II GT-I9100 is called *Galaxy S 2 (I9100)* and its page is [[GalaxyS2I9100]])
439 74 Wolfgang Wiedmeyer
2. Create all the related sub-pages (build guide, install guide and firmwares list at least), following the naming guidelines applied to other devices (e.g. [[GalaxyS2I9100Build]], [[GalaxyS2I9100Installation]] and [[GalaxyS2I9100LoadedFirmwares]])
440 5 Paul Kocialkowski
3. Link the sub-pages to the main page in the index
441
4. Update the [[ReplicantStatus]] page of the wiki with the current status of the device
442 47 Wolfgang Wiedmeyer
5. Modify the [[Index]] page of the wiki and add the new device in the following sections:
443
* [[Index#Replicant-status|Replicant status]]
444
* [[Index#Replicant-installation|Replicant installation]]
445
* [[Index#Replicant-build|Replicant build]]
446
* [[Index#Supported-devices|Supported devices]]
447 24 Paul Kocialkowski
448 43 Wolfgang Wiedmeyer
6. Add new issues categories to the Replicant project Redmine
449 73 Wolfgang Wiedmeyer
450
7. Add the device to the "Supported devices page":https://www.replicant.us/supported-devices.php on the website