diff options
Diffstat (limited to 'documentation/toaster-manual')
5 files changed, 1165 insertions, 0 deletions
diff --git a/documentation/toaster-manual/toaster-manual-intro.rst b/documentation/toaster-manual/toaster-manual-intro.rst new file mode 100644 index 0000000000..92d8c94c52 --- /dev/null +++ b/documentation/toaster-manual/toaster-manual-intro.rst | |||
@@ -0,0 +1,97 @@ | |||
1 | ************ | ||
2 | Introduction | ||
3 | ************ | ||
4 | |||
5 | Toaster is a web interface to the Yocto Project's `OpenEmbedded build | ||
6 | system <&YOCTO_DOCS_REF_URL;#build-system-term>`__. The interface | ||
7 | enables you to configure and run your builds. Information about builds | ||
8 | is collected and stored in a database. You can use Toaster to configure | ||
9 | and start builds on multiple remote build servers. | ||
10 | |||
11 | .. _intro-features: | ||
12 | |||
13 | Toaster Features | ||
14 | ================ | ||
15 | |||
16 | Toaster allows you to configure and run builds, and it provides | ||
17 | extensive information about the build process. | ||
18 | |||
19 | - *Configure and Run Builds:* You can use the Toaster web interface to | ||
20 | configure and start your builds. Builds started using the Toaster web | ||
21 | interface are organized into projects. When you create a project, you | ||
22 | are asked to select a release, or version of the build system you | ||
23 | want to use for the project builds. As shipped, Toaster supports | ||
24 | Yocto Project releases 1.8 and beyond. With the Toaster web | ||
25 | interface, you can: | ||
26 | |||
27 | - Browse layers listed in the various `layer | ||
28 | sources <#layer-source>`__ that are available in your project | ||
29 | (e.g. the OpenEmbedded Layer Index at | ||
30 | ` <http://layers.openembedded.org/layerindex/>`__). | ||
31 | |||
32 | - Browse images, recipes, and machines provided by those layers. | ||
33 | |||
34 | - Import your own layers for building. | ||
35 | |||
36 | - Add and remove layers from your configuration. | ||
37 | |||
38 | - Set configuration variables. | ||
39 | |||
40 | - Select a target or multiple targets to build. | ||
41 | |||
42 | - Start your builds. | ||
43 | |||
44 | Toaster also allows you to configure and run your builds from the | ||
45 | command line, and switch between the command line and the web | ||
46 | interface at any time. Builds started from the command line appear | ||
47 | within a special Toaster project called "Command line builds". | ||
48 | |||
49 | - *Information About the Build Process:* Toaster also records extensive | ||
50 | information about your builds. Toaster collects data for builds you | ||
51 | start from the web interface and from the command line as long as | ||
52 | Toaster is running. | ||
53 | |||
54 | .. note:: | ||
55 | |||
56 | You must start Toaster before the build or it will not collect | ||
57 | build data. | ||
58 | |||
59 | With Toaster you can: | ||
60 | |||
61 | - See what was built (recipes and packages) and what packages were | ||
62 | installed into your final image. | ||
63 | |||
64 | - Browse the directory structure of your image. | ||
65 | |||
66 | - See the value of all variables in your build configuration, and | ||
67 | which files set each value. | ||
68 | |||
69 | - Examine error, warning, and trace messages to aid in debugging. | ||
70 | |||
71 | - See information about the BitBake tasks executed and reused during | ||
72 | your build, including those that used shared state. | ||
73 | |||
74 | - See dependency relationships between recipes, packages, and tasks. | ||
75 | |||
76 | - See performance information such as build time, task time, CPU | ||
77 | usage, and disk I/O. | ||
78 | |||
79 | For an overview of Toaster shipped with the Yocto Project DISTRO | ||
80 | Release, see the "`Toaster - Yocto Project | ||
81 | 2.2 <https://youtu.be/BlXdOYLgPxA>`__" video. | ||
82 | |||
83 | .. _toaster-installation-options: | ||
84 | |||
85 | Installation Options | ||
86 | ==================== | ||
87 | |||
88 | You can set Toaster up to run as a local instance or as a shared hosted | ||
89 | service. | ||
90 | |||
91 | When Toaster is set up as a local instance, all the components reside on | ||
92 | a single build host. Fundamentally, a local instance of Toaster is | ||
93 | suited for a single user developing on a single build host. | ||
94 | |||
95 | Toaster as a hosted service is suited for multiple users developing | ||
96 | across several build hosts. When Toaster is set up as a hosted service, | ||
97 | its components can be spread across several machines: | ||
diff --git a/documentation/toaster-manual/toaster-manual-reference.rst b/documentation/toaster-manual/toaster-manual-reference.rst new file mode 100644 index 0000000000..bc39903adf --- /dev/null +++ b/documentation/toaster-manual/toaster-manual-reference.rst | |||
@@ -0,0 +1,515 @@ | |||
1 | ********************** | ||
2 | Concepts and Reference | ||
3 | ********************** | ||
4 | |||
5 | In order to configure and use Toaster, you should understand some | ||
6 | concepts and have some basic command reference material available. This | ||
7 | final chapter provides conceptual information on layer sources, | ||
8 | releases, and JSON configuration files. Also provided is a quick look at | ||
9 | some useful ``manage.py`` commands that are Toaster-specific. | ||
10 | Information on ``manage.py`` commands does exist across the Web and the | ||
11 | information in this manual by no means attempts to provide a command | ||
12 | comprehensive reference. | ||
13 | |||
14 | Layer Source | ||
15 | ============ | ||
16 | |||
17 | In general, a "layer source" is a source of information about existing | ||
18 | layers. In particular, we are concerned with layers that you can use | ||
19 | with the Yocto Project and Toaster. This chapter describes a particular | ||
20 | type of layer source called a "layer index." | ||
21 | |||
22 | A layer index is a web application that contains information about a set | ||
23 | of custom layers. A good example of an existing layer index is the | ||
24 | OpenEmbedded Layer Index. A public instance of this layer index exists | ||
25 | at ` <http://layers.openembedded.org>`__. You can find the code for this | ||
26 | layer index's web application at | ||
27 | ` <http://git.yoctoproject.org/cgit/cgit.cgi/layerindex-web/>`__. | ||
28 | |||
29 | When you tie a layer source into Toaster, it can query the layer source | ||
30 | through a | ||
31 | `REST <http://en.wikipedia.org/wiki/Representational_state_transfer>`__ | ||
32 | API, store the information about the layers in the Toaster database, and | ||
33 | then show the information to users. Users are then able to view that | ||
34 | information and build layers from Toaster itself without worrying about | ||
35 | cloning or editing the BitBake layers configuration file | ||
36 | ``bblayers.conf``. | ||
37 | |||
38 | Tying a layer source into Toaster is convenient when you have many | ||
39 | custom layers that need to be built on a regular basis by a community of | ||
40 | developers. In fact, Toaster comes pre-configured with the OpenEmbedded | ||
41 | Metadata Index. | ||
42 | |||
43 | .. note:: | ||
44 | |||
45 | You do not have to use a layer source to use Toaster. Tying into a | ||
46 | layer source is optional. | ||
47 | |||
48 | .. _layer-source-using-with-toaster: | ||
49 | |||
50 | Setting Up and Using a Layer Source | ||
51 | ----------------------------------- | ||
52 | |||
53 | To use your own layer source, you need to set up the layer source and | ||
54 | then tie it into Toaster. This section describes how to tie into a layer | ||
55 | index in a manner similar to the way Toaster ties into the OpenEmbedded | ||
56 | Metadata Index. | ||
57 | |||
58 | Understanding Your Layers | ||
59 | ~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
60 | |||
61 | The obvious first step for using a layer index is to have several custom | ||
62 | layers that developers build and access using the Yocto Project on a | ||
63 | regular basis. This set of layers needs to exist and you need to be | ||
64 | familiar with where they reside. You will need that information when you | ||
65 | set up the code for the web application that "hooks" into your set of | ||
66 | layers. | ||
67 | |||
68 | For general information on layers, see the "`The Yocto Project Layer | ||
69 | Model <&YOCTO_DOCS_OM_URL;#the-yocto-project-layer-model>`__" section in | ||
70 | the Yocto Project Overview and Concepts Manual. For information on how | ||
71 | to create layers, see the "`Understanding and Creating | ||
72 | Layers <&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers>`__" | ||
73 | section in the Yocto Project Development Tasks Manual. | ||
74 | |||
75 | .. _configuring-toaster-to-hook-into-your-layer-source: | ||
76 | |||
77 | Configuring Toaster to Hook Into Your Layer Index | ||
78 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
79 | |||
80 | If you want Toaster to use your layer index, you must host the web | ||
81 | application in a server to which Toaster can connect. You also need to | ||
82 | give Toaster the information about your layer index. In other words, you | ||
83 | have to configure Toaster to use your layer index. This section | ||
84 | describes two methods by which you can configure and use your layer | ||
85 | index. | ||
86 | |||
87 | In the previous section, the code for the OpenEmbedded Metadata Index | ||
88 | (i.e. ` <http://layers.openembedded.org>`__) was referenced. You can use | ||
89 | this code, which is at | ||
90 | ` <http://git.yoctoproject.org/cgit/cgit.cgi/layerindex-web/>`__, as a | ||
91 | base to create your own layer index. | ||
92 | |||
93 | Use the Administration Interface | ||
94 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||
95 | |||
96 | Access the administration interface through a browser by entering the | ||
97 | URL of your Toaster instance and adding "``/admin``" to the end of the | ||
98 | URL. As an example, if you are running Toaster locally, use the | ||
99 | following URL: http://127.0.0.1:8000/admin | ||
100 | |||
101 | The administration interface has a "Layer sources" section that includes | ||
102 | an "Add layer source" button. Click that button and provide the required | ||
103 | information. Make sure you select "layerindex" as the layer source type. | ||
104 | |||
105 | Use the Fixture Feature | ||
106 | ^^^^^^^^^^^^^^^^^^^^^^^ | ||
107 | |||
108 | The Django fixture feature overrides the default layer server when you | ||
109 | use it to specify a custom URL. To use the fixture feature, create (or | ||
110 | edit) the file ``bitbake/lib/toaster.orm/fixtures/custom.xml``, and then | ||
111 | set the following Toaster setting to your custom URL: <?xml | ||
112 | version="1.0" ?> <django-objects version="1.0"> <object | ||
113 | model="orm.toastersetting" pk="100"> <field name="name" | ||
114 | type="CharField">CUSTOM_LAYERINDEX_SERVER</field> <field name="value" | ||
115 | type="CharField">https://layers.my_organization.org/layerindex/branch/master/layers/</field> | ||
116 | </object> <django-objects> When you start Toaster for the first time, or | ||
117 | if you delete the file ``toaster.sqlite`` and restart, the database will | ||
118 | populate cleanly from this layer index server. | ||
119 | |||
120 | Once the information has been updated, verify the new layer information | ||
121 | is available by using the Toaster web interface. To do that, visit the | ||
122 | "All compatible layers" page inside a Toaster project. The layers from | ||
123 | your layer source should be listed there. | ||
124 | |||
125 | If you change the information in your layer index server, refresh the | ||
126 | Toaster database by running the following command: $ | ||
127 | bitbake/lib/toaster/manage.py lsupdates If Toaster can reach the API | ||
128 | URL, you should see a message telling you that Toaster is updating the | ||
129 | layer source information. | ||
130 | |||
131 | .. _toaster-releases: | ||
132 | |||
133 | Releases | ||
134 | ======== | ||
135 | |||
136 | When you create a Toaster project using the web interface, you are asked | ||
137 | to choose a "Release." In the context of Toaster, the term "Release" | ||
138 | refers to a set of layers and a BitBake version the OpenEmbedded build | ||
139 | system uses to build something. As shipped, Toaster is pre-configured | ||
140 | with releases that correspond to Yocto Project release branches. | ||
141 | However, you can modify, delete, and create new releases according to | ||
142 | your needs. This section provides some background information on | ||
143 | releases. | ||
144 | |||
145 | .. _toaster-releases-supported: | ||
146 | |||
147 | Pre-Configured Releases | ||
148 | ----------------------- | ||
149 | |||
150 | As shipped, Toaster is configured to use a specific set of releases. Of | ||
151 | course, you can always configure Toaster to use any release. For | ||
152 | example, you might want your project to build against a specific commit | ||
153 | of any of the "out-of-the-box" releases. Or, you might want your project | ||
154 | to build against different revisions of OpenEmbedded and BitBake. | ||
155 | |||
156 | As shipped, Toaster is configured to work with the following releases: | ||
157 | |||
158 | - *Yocto Project DISTRO "DISTRO_NAME" or OpenEmbedded "DISTRO_NAME":* | ||
159 | This release causes your Toaster projects to build against the head | ||
160 | of the DISTRO_NAME_NO_CAP branch at | ||
161 | ` <&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/log/?h=rocko>`__ or | ||
162 | ` <http://git.openembedded.org/openembedded-core/commit/?h=rocko>`__. | ||
163 | |||
164 | - *Yocto Project "Master" or OpenEmbedded "Master":* This release | ||
165 | causes your Toaster Projects to build against the head of the master | ||
166 | branch, which is where active development takes place, at | ||
167 | ` <&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/log/>`__ or | ||
168 | ` <http://git.openembedded.org/openembedded-core/log/>`__. | ||
169 | |||
170 | - *Local Yocto Project or Local OpenEmbedded:* This release causes your | ||
171 | Toaster Projects to build against the head of the ``poky`` or | ||
172 | ``openembedded-core`` clone you have local to the machine running | ||
173 | Toaster. | ||
174 | |||
175 | Configuring Toaster | ||
176 | =================== | ||
177 | |||
178 | In order to use Toaster, you must configure the database with the | ||
179 | default content. The following subsections describe various aspects of | ||
180 | Toaster configuration. | ||
181 | |||
182 | Configuring the Workflow | ||
183 | ------------------------ | ||
184 | |||
185 | The ``bldcontrol/management/commands/checksettings.py`` file controls | ||
186 | workflow configuration. The following steps outline the process to | ||
187 | initially populate this database. | ||
188 | |||
189 | 1. The default project settings are set from | ||
190 | ``orm/fixtures/settings.xml``. | ||
191 | |||
192 | 2. The default project distro and layers are added from | ||
193 | ``orm/fixtures/poky.xml`` if poky is installed. If poky is not | ||
194 | installed, they are added from ``orm/fixtures/oe-core.xml``. | ||
195 | |||
196 | 3. If the ``orm/fixtures/custom.xml`` file exists, then its values are | ||
197 | added. | ||
198 | |||
199 | 4. The layer index is then scanned and added to the database. | ||
200 | |||
201 | Once these steps complete, Toaster is set up and ready to use. | ||
202 | |||
203 | Customizing Pre-Set Data | ||
204 | ------------------------ | ||
205 | |||
206 | The pre-set data for Toaster is easily customizable. You can create the | ||
207 | ``orm/fixtures/custom.xml`` file to customize the values that go into to | ||
208 | the database. Customization is additive, and can either extend or | ||
209 | completely replace the existing values. | ||
210 | |||
211 | You use the ``orm/fixtures/custom.xml`` file to change the default | ||
212 | project settings for the machine, distro, file images, and layers. When | ||
213 | creating a new project, you can use the file to define the offered | ||
214 | alternate project release selections. For example, you can add one or | ||
215 | more additional selections that present custom layer sets or distros, | ||
216 | and any other local or proprietary content. | ||
217 | |||
218 | Additionally, you can completely disable the content from the | ||
219 | ``oe-core.xml`` and ``poky.xml`` files by defining the section shown | ||
220 | below in the ``settings.xml`` file. For example, this option is | ||
221 | particularly useful if your custom configuration defines fewer releases | ||
222 | or layers than the default fixture files. | ||
223 | |||
224 | The following example sets "name" to "CUSTOM_XML_ONLY" and its value to | ||
225 | "True". <object model="orm.toastersetting" pk="99"> <field | ||
226 | type="CharField" name="name">CUSTOM_XML_ONLY</field> <field | ||
227 | type="CharField" name="value">True</field> </object> | ||
228 | |||
229 | Understanding Fixture File Format | ||
230 | --------------------------------- | ||
231 | |||
232 | The following is an overview of the file format used by the | ||
233 | ``oe-core.xml``, ``poky.xml``, and ``custom.xml`` files. | ||
234 | |||
235 | The following subsections describe each of the sections in the fixture | ||
236 | files, and outline an example section of the XML code. you can use to | ||
237 | help understand this information and create a local ``custom.xml`` file. | ||
238 | |||
239 | Defining the Default Distro and Other Values | ||
240 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
241 | |||
242 | This section defines the default distro value for new projects. By | ||
243 | default, it reserves the first Toaster Setting record "1". The following | ||
244 | demonstrates how to set the project default value for | ||
245 | ```DISTRO`` <&YOCTO_DOCS_REF_URL;#var-DISTRO>`__: <!-- Set the project | ||
246 | default value for DISTRO --> <object model="orm.toastersetting" pk="1"> | ||
247 | <field type="CharField" name="name">DEFCONF_DISTRO</field> <field | ||
248 | type="CharField" name="value">poky</field> </object> You can override | ||
249 | other default project values by adding additional Toaster Setting | ||
250 | sections such as any of the settings coming from the ``settings.xml`` | ||
251 | file. Also, you can add custom values that are included in the BitBake | ||
252 | environment. The "pk" values must be unique. By convention, values that | ||
253 | set default project values have a "DEFCONF" prefix. | ||
254 | |||
255 | Defining BitBake Version | ||
256 | ~~~~~~~~~~~~~~~~~~~~~~~~ | ||
257 | |||
258 | The following defines which version of BitBake is used for the following | ||
259 | release selection: <!-- Bitbake versions which correspond to the | ||
260 | metadata release --> <object model="orm.bitbakeversion" pk="1"> <field | ||
261 | type="CharField" name="name">rocko</field> <field type="CharField" | ||
262 | name="giturl">git://git.yoctoproject.org/poky</field> <field | ||
263 | type="CharField" name="branch">rocko</field> <field type="CharField" | ||
264 | name="dirpath">bitbake</field> </object> | ||
265 | |||
266 | .. _defining-releases: | ||
267 | |||
268 | Defining Release | ||
269 | ~~~~~~~~~~~~~~~~ | ||
270 | |||
271 | The following defines the releases when you create a new project. <!-- | ||
272 | Releases available --> <object model="orm.release" pk="1"> <field | ||
273 | type="CharField" name="name">rocko</field> <field type="CharField" | ||
274 | name="description">Yocto Project 2.4 "Rocko"</field> <field | ||
275 | rel="ManyToOneRel" to="orm.bitbakeversion" | ||
276 | name="bitbake_version">1</field> <field type="CharField" | ||
277 | name="branch_name">rocko</field> <field type="TextField" | ||
278 | name="helptext">Toaster will run your builds using the tip of the <a | ||
279 | href="http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=rocko">Yocto | ||
280 | Project Rocko branch</a>.</field> </object> The "pk" value must match | ||
281 | the above respective BitBake version record. | ||
282 | |||
283 | Defining the Release Default Layer Names | ||
284 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
285 | |||
286 | The following defines the default layers for each release: <!-- Default | ||
287 | project layers for each release --> <object | ||
288 | model="orm.releasedefaultlayer" pk="1"> <field rel="ManyToOneRel" | ||
289 | to="orm.release" name="release">1</field> <field type="CharField" | ||
290 | name="layer_name">openembedded-core</field> </object> The 'pk' values in | ||
291 | the example above should start at "1" and increment uniquely. You can | ||
292 | use the same layer name in multiple releases. | ||
293 | |||
294 | Defining Layer Definitions | ||
295 | ~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
296 | |||
297 | Layer definitions are the most complex. The following defines each of | ||
298 | the layers, and then defines the exact layer version of the layer used | ||
299 | for each respective release. You must have one ``orm.layer`` entry for | ||
300 | each layer. Then, with each entry you need a set of | ||
301 | ``orm.layer_version`` entries that connects the layer with each release | ||
302 | that includes the layer. In general all releases include the layer. | ||
303 | <object model="orm.layer" pk="1"> <field type="CharField" | ||
304 | name="name">openembedded-core</field> <field type="CharField" | ||
305 | name="layer_index_url"></field> <field type="CharField" | ||
306 | name="vcs_url">git://git.yoctoproject.org/poky</field> <field | ||
307 | type="CharField" | ||
308 | name="vcs_web_url">http://git.yoctoproject.org/cgit/cgit.cgi/poky</field> | ||
309 | <field type="CharField" | ||
310 | name="vcs_web_tree_base_url">http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/%path%?h=%branch%</field> | ||
311 | <field type="CharField" | ||
312 | name="vcs_web_file_base_url">http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/%path%?h=%branch%</field> | ||
313 | </object> <object model="orm.layer_version" pk="1"> <field | ||
314 | rel="ManyToOneRel" to="orm.layer" name="layer">1</field> <field | ||
315 | type="IntegerField" name="layer_source">0</field> <field | ||
316 | rel="ManyToOneRel" to="orm.release" name="release">1</field> <field | ||
317 | type="CharField" name="branch">rocko</field> <field type="CharField" | ||
318 | name="dirpath">meta</field> </object> <object model="orm.layer_version" | ||
319 | pk="2"> <field rel="ManyToOneRel" to="orm.layer" name="layer">1</field> | ||
320 | <field type="IntegerField" name="layer_source">0</field> <field | ||
321 | rel="ManyToOneRel" to="orm.release" name="release">2</field> <field | ||
322 | type="CharField" name="branch">HEAD</field> <field type="CharField" | ||
323 | name="commit">HEAD</field> <field type="CharField" | ||
324 | name="dirpath">meta</field> </object> <object model="orm.layer_version" | ||
325 | pk="3"> <field rel="ManyToOneRel" to="orm.layer" name="layer">1</field> | ||
326 | <field type="IntegerField" name="layer_source">0</field> <field | ||
327 | rel="ManyToOneRel" to="orm.release" name="release">3</field> <field | ||
328 | type="CharField" name="branch">master</field> <field type="CharField" | ||
329 | name="dirpath">meta</field> </object> The layer "pk" values above must | ||
330 | be unique, and typically start at "1". The layer version "pk" values | ||
331 | must also be unique across all layers, and typically start at "1". | ||
332 | |||
333 | Remote Toaster Monitoring | ||
334 | ========================= | ||
335 | |||
336 | Toaster has an API that allows remote management applications to | ||
337 | directly query the state of the Toaster server and its builds in a | ||
338 | machine-to-machine manner. This API uses the | ||
339 | `REST <http://en.wikipedia.org/wiki/Representational_state_transfer>`__ | ||
340 | interface and the transfer of JSON files. For example, you might monitor | ||
341 | a build inside a container through well supported known HTTP ports in | ||
342 | order to easily access a Toaster server inside the container. In this | ||
343 | example, when you use this direct JSON API, you avoid having web page | ||
344 | parsing against the display the user sees. | ||
345 | |||
346 | Checking Health | ||
347 | --------------- | ||
348 | |||
349 | Before you use remote Toaster monitoring, you should do a health check. | ||
350 | To do this, ping the Toaster server using the following call to see if | ||
351 | it is still alive: http://host:port/health Be sure to provide values for | ||
352 | host and port. If the server is alive, you will get the response HTML: | ||
353 | <!DOCTYPE html> <html lang="en"> <head><title>Toaster | ||
354 | Health</title></head> <body>Ok</body> </html> | ||
355 | |||
356 | Determining Status of Builds in Progress | ||
357 | ---------------------------------------- | ||
358 | |||
359 | Sometimes it is useful to determine the status of a build in progress. | ||
360 | To get the status of pending builds, use the following call: | ||
361 | http://host:port/toastergui/api/building Be sure to provide values for | ||
362 | host and port. The output is a JSON file that itemizes all builds in | ||
363 | progress. This file includes the time in seconds since each respective | ||
364 | build started as well as the progress of the cloning, parsing, and task | ||
365 | execution. The following is sample output for a build in progress: | ||
366 | {"count": 1, "building": [ {"machine": "beaglebone", "seconds": | ||
367 | "463.869", "task": "927:2384", "distro": "poky", "clone": "1:1", "id": | ||
368 | 2, "start": "2017-09-22T09:31:44.887Z", "name": "20170922093200", | ||
369 | "parse": "818:818", "project": "my_rocko", "target": | ||
370 | "core-image-minimal" }] } The JSON data for this query is returned in a | ||
371 | single line. In the previous example the line has been artificially | ||
372 | split for readability. | ||
373 | |||
374 | Checking Status of Builds Completed | ||
375 | ----------------------------------- | ||
376 | |||
377 | Once a build is completed, you get the status when you use the following | ||
378 | call: http://host:port/toastergui/api/builds Be sure to provide values | ||
379 | for host and port. The output is a JSON file that itemizes all complete | ||
380 | builds, and includes build summary information. The following is sample | ||
381 | output for a completed build: {"count": 1, "builds": [ {"distro": | ||
382 | "poky", "errors": 0, "machine": "beaglebone", "project": "my_rocko", | ||
383 | "stop": "2017-09-22T09:26:36.017Z", "target": "quilt-native", "seconds": | ||
384 | "78.193", "outcome": "Succeeded", "id": 1, "start": | ||
385 | "2017-09-22T09:25:17.824Z", "warnings": 1, "name": "20170922092618" }] } | ||
386 | The JSON data for this query is returned in a single line. In the | ||
387 | previous example the line has been artificially split for readability. | ||
388 | |||
389 | Determining Status of a Specific Build | ||
390 | -------------------------------------- | ||
391 | |||
392 | Sometimes it is useful to determine the status of a specific build. To | ||
393 | get the status of a specific build, use the following call: | ||
394 | http://host:port/toastergui/api/build/ID Be sure to provide values for | ||
395 | host, port, and ID. You can find the value for ID from the Builds | ||
396 | Completed query. See the "`Checking Status of Builds | ||
397 | Completed <#checking-status-of-builds-completed>`__" section for more | ||
398 | information. | ||
399 | |||
400 | The output is a JSON file that itemizes the specific build and includes | ||
401 | build summary information. The following is sample output for a specific | ||
402 | build: {"build": {"distro": "poky", "errors": 0, "machine": | ||
403 | "beaglebone", "project": "my_rocko", "stop": "2017-09-22T09:26:36.017Z", | ||
404 | "target": "quilt-native", "seconds": "78.193", "outcome": "Succeeded", | ||
405 | "id": 1, "start": "2017-09-22T09:25:17.824Z", "warnings": 1, "name": | ||
406 | "20170922092618", "cooker_log": | ||
407 | "/opt/user/poky/build-toaster-2/tmp/log/cooker/beaglebone/build_20170922_022607.991.log" | ||
408 | } } The JSON data for this query is returned in a single line. In the | ||
409 | previous example the line has been artificially split for readability. | ||
410 | |||
411 | .. _toaster-useful-commands: | ||
412 | |||
413 | Useful Commands | ||
414 | =============== | ||
415 | |||
416 | In addition to the web user interface and the scripts that start and | ||
417 | stop Toaster, command-line commands exist through the ``manage.py`` | ||
418 | management script. You can find general documentation on ``manage.py`` | ||
419 | at the | ||
420 | `Django <https://docs.djangoproject.com/en/1.7/topics/settings/>`__ | ||
421 | site. However, several ``manage.py`` commands have been created that are | ||
422 | specific to Toaster and are used to control configuration and back-end | ||
423 | tasks. You can locate these commands in the `Source | ||
424 | Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. ``poky``) at | ||
425 | ``bitbake/lib/manage.py``. This section documents those commands. | ||
426 | |||
427 | .. note:: | ||
428 | |||
429 | - When using ``manage.py`` commands given a default configuration, | ||
430 | you must be sure that your working directory is set to the `Build | ||
431 | Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. Using | ||
432 | ``manage.py`` commands from the Build Directory allows Toaster to | ||
433 | find the ``toaster.sqlite`` file, which is located in the Build | ||
434 | Directory. | ||
435 | |||
436 | - For non-default database configurations, it is possible that you | ||
437 | can use ``manage.py`` commands from a directory other than the | ||
438 | Build Directory. To do so, the ``toastermain/settings.py`` file | ||
439 | must be configured to point to the correct database backend. | ||
440 | |||
441 | .. _toaster-command-buildslist: | ||
442 | |||
443 | ``buildslist`` | ||
444 | -------------- | ||
445 | |||
446 | The ``buildslist`` command lists all builds that Toaster has recorded. | ||
447 | Access the command as follows: $ bitbake/lib/toaster/manage.py | ||
448 | buildslist The command returns a list, which includes numeric | ||
449 | identifications, of the builds that Toaster has recorded in the current | ||
450 | database. | ||
451 | |||
452 | You need to run the ``buildslist`` command first to identify existing | ||
453 | builds in the database before using the | ||
454 | ```builddelete`` <#toaster-command-builddelete>`__ command. Here is an | ||
455 | example that assumes default repository and build directory names: $ cd | ||
456 | ~/poky/build $ python ../bitbake/lib/toaster/manage.py buildslist If | ||
457 | your Toaster database had only one build, the above ``buildslist`` | ||
458 | command would return something like the following: 1: qemux86 poky | ||
459 | core-image-minimal | ||
460 | |||
461 | .. _toaster-command-builddelete: | ||
462 | |||
463 | ``builddelete`` | ||
464 | --------------- | ||
465 | |||
466 | The ``builddelete`` command deletes data associated with a build. Access | ||
467 | the command as follows: $ bitbake/lib/toaster/manage.py builddelete | ||
468 | build_id The command deletes all the build data for the specified | ||
469 | build_id. This command is useful for removing old and unused data from | ||
470 | the database. | ||
471 | |||
472 | Prior to running the ``builddelete`` command, you need to get the ID | ||
473 | associated with builds by using the | ||
474 | ```buildslist`` <#toaster-command-buildslist>`__ command. | ||
475 | |||
476 | .. _toaster-command-perf: | ||
477 | |||
478 | ``perf`` | ||
479 | -------- | ||
480 | |||
481 | The ``perf`` command measures Toaster performance. Access the command as | ||
482 | follows: $ bitbake/lib/toaster/manage.py perf The command is a sanity | ||
483 | check that returns page loading times in order to identify performance | ||
484 | problems. | ||
485 | |||
486 | .. _toaster-command-checksettings: | ||
487 | |||
488 | ``checksettings`` | ||
489 | ----------------- | ||
490 | |||
491 | The ``checksettings`` command verifies existing Toaster settings. Access | ||
492 | the command as follows: $ bitbake/lib/toaster/manage.py checksettings | ||
493 | Toaster uses settings that are based on the database to configure the | ||
494 | building tasks. The ``checksettings`` command verifies that the database | ||
495 | settings are valid in the sense that they have the minimal information | ||
496 | needed to start a build. | ||
497 | |||
498 | In order for the ``checksettings`` command to work, the database must be | ||
499 | correctly set up and not have existing data. To be sure the database is | ||
500 | ready, you can run the following: $ bitbake/lib/toaster/manage.py | ||
501 | syncdb $ bitbake/lib/toaster/manage.py migrate orm $ | ||
502 | bitbake/lib/toaster/manage.py migrate bldcontrol After running these | ||
503 | commands, you can run the ``checksettings`` command. | ||
504 | |||
505 | .. _toaster-command-runbuilds: | ||
506 | |||
507 | ``runbuilds`` | ||
508 | ------------- | ||
509 | |||
510 | The ``runbuilds`` command launches scheduled builds. Access the command | ||
511 | as follows: $ bitbake/lib/toaster/manage.py runbuilds The ``runbuilds`` | ||
512 | command checks if scheduled builds exist in the database and then | ||
513 | launches them per schedule. The command returns after the builds start | ||
514 | but before they complete. The Toaster Logging Interface records and | ||
515 | updates the database when the builds complete. | ||
diff --git a/documentation/toaster-manual/toaster-manual-setup-and-use.rst b/documentation/toaster-manual/toaster-manual-setup-and-use.rst new file mode 100644 index 0000000000..b36160b697 --- /dev/null +++ b/documentation/toaster-manual/toaster-manual-setup-and-use.rst | |||
@@ -0,0 +1,495 @@ | |||
1 | **************************** | ||
2 | Setting Up and Using Toaster | ||
3 | **************************** | ||
4 | |||
5 | Starting Toaster for Local Development | ||
6 | ====================================== | ||
7 | |||
8 | Once you have set up the Yocto Project and installed the Toaster system | ||
9 | dependencies as described in the "`Preparing to Use | ||
10 | Toaster <#toaster-manual-start>`__" chapter, you are ready to start | ||
11 | Toaster. | ||
12 | |||
13 | Navigate to the root of your `Source | ||
14 | Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. ``poky``): $ | ||
15 | cd poky Once in that directory, source the build environment script: $ | ||
16 | source oe-init-build-env Next, from the build directory (e.g. | ||
17 | ``poky/build``), start Toaster using this command: $ source toaster | ||
18 | start You can now run your builds from the command line, or with Toaster | ||
19 | as explained in section "`Using the Toaster Web | ||
20 | Interface <#using-the-toaster-web-interface>`__". | ||
21 | |||
22 | To access the Toaster web interface, open your favorite browser and | ||
23 | enter the following: http://127.0.0.1:8000 | ||
24 | |||
25 | Setting a Different Port | ||
26 | ======================== | ||
27 | |||
28 | By default, Toaster starts on port 8000. You can use the ``WEBPORT`` | ||
29 | parameter to set a different port. For example, the following command | ||
30 | sets the port to "8400": $ source toaster start webport=8400 | ||
31 | |||
32 | Setting Up Toaster Without a Web Server | ||
33 | ======================================= | ||
34 | |||
35 | You can start a Toaster environment without starting its web server. | ||
36 | This is useful for the following: | ||
37 | |||
38 | - Capturing a command-line build’s statistics into the Toaster database | ||
39 | for examination later. | ||
40 | |||
41 | - Capturing a command-line build’s statistics when the Toaster server | ||
42 | is already running. | ||
43 | |||
44 | - Having one instance of the Toaster web server track and capture | ||
45 | multiple command-line builds, where each build is started in its own | ||
46 | “noweb” Toaster environment. | ||
47 | |||
48 | The following commands show how to start a Toaster environment without | ||
49 | starting its web server, perform BitBake operations, and then shut down | ||
50 | the Toaster environment. Once the build is complete, you can close the | ||
51 | Toaster environment. Before closing the environment, however, you should | ||
52 | allow a few minutes to ensure the complete transfer of its BitBake build | ||
53 | statistics to the Toaster database. If you have a separate Toaster web | ||
54 | server instance running, you can watch this command-line build’s | ||
55 | progress and examine the results as soon as they are posted: $ source | ||
56 | toaster start noweb $ bitbake target $ source toaster stop | ||
57 | |||
58 | Setting Up Toaster Without a Build Server | ||
59 | ========================================= | ||
60 | |||
61 | You can start a Toaster environment with the “New Projects” feature | ||
62 | disabled. Doing so is useful for the following: | ||
63 | |||
64 | - Sharing your build results over the web server while blocking others | ||
65 | from starting builds on your host. | ||
66 | |||
67 | - Allowing only local command-line builds to be captured into the | ||
68 | Toaster database. | ||
69 | |||
70 | Use the following command to set up Toaster without a build server: $ | ||
71 | source toaster start nobuild webport=port | ||
72 | |||
73 | Setting up External Access | ||
74 | ========================== | ||
75 | |||
76 | By default, Toaster binds to the loop back address (i.e. localhost), | ||
77 | which does not allow access from external hosts. To allow external | ||
78 | access, use the ``WEBPORT`` parameter to open an address that connects | ||
79 | to the network, specifically the IP address that your NIC uses to | ||
80 | connect to the network. You can also bind to all IP addresses the | ||
81 | computer supports by using the shortcut "0.0.0.0:port". | ||
82 | |||
83 | The following example binds to all IP addresses on the host: $ source | ||
84 | toaster start webport=0.0.0.0:8400 This example binds to a specific IP | ||
85 | address on the host's NIC: $ source toaster start | ||
86 | webport=192.168.1.1:8400 | ||
87 | |||
88 | The Directory for Cloning Layers | ||
89 | ================================ | ||
90 | |||
91 | Toaster creates a ``_toaster_clones`` directory inside your Source | ||
92 | Directory (i.e. ``poky``) to clone any layers needed for your builds. | ||
93 | |||
94 | Alternatively, if you would like all of your Toaster related files and | ||
95 | directories to be in a particular location other than the default, you | ||
96 | can set the ``TOASTER_DIR`` environment variable, which takes precedence | ||
97 | over your current working directory. Setting this environment variable | ||
98 | causes Toaster to create and use ``$TOASTER_DIR./_toaster_clones``. | ||
99 | |||
100 | .. _toaster-the-build-directory: | ||
101 | |||
102 | The Build Directory | ||
103 | =================== | ||
104 | |||
105 | Toaster creates a build directory within your Source Directory (e.g. | ||
106 | ``poky``) to execute the builds. | ||
107 | |||
108 | Alternatively, if you would like all of your Toaster related files and | ||
109 | directories to be in a particular location, you can set the | ||
110 | ``TOASTER_DIR`` environment variable, which takes precedence over your | ||
111 | current working directory. Setting this environment variable causes | ||
112 | Toaster to use ``$TOASTER_DIR/build`` as the build directory. | ||
113 | |||
114 | .. _toaster-creating-a-django-super-user: | ||
115 | |||
116 | Creating a Django Superuser | ||
117 | =========================== | ||
118 | |||
119 | Toaster is built on the `Django | ||
120 | framework <https://www.djangoproject.com/>`__. Django provides an | ||
121 | administration interface you can use to edit Toaster configuration | ||
122 | parameters. | ||
123 | |||
124 | To access the Django administration interface, you must create a | ||
125 | superuser by following these steps: | ||
126 | |||
127 | 1. If you used ``pip3``, which is recommended, to set up the Toaster | ||
128 | system dependencies, you need be sure the local user path is in your | ||
129 | ``PATH`` list. To append the pip3 local user path, use the following | ||
130 | command: $ export PATH=$PATH:$HOME/.local/bin | ||
131 | |||
132 | 2. From the directory containing the Toaster database, which by default | ||
133 | is the `Build Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, | ||
134 | invoke the ``createsuperuser`` command from ``manage.py``: $ cd | ||
135 | ~/poky/build $ ../bitbake/lib/toaster/manage.py createsuperuser | ||
136 | |||
137 | 3. Django prompts you for the username, which you need to provide. | ||
138 | |||
139 | 4. Django prompts you for an email address, which is optional. | ||
140 | |||
141 | 5. Django prompts you for a password, which you must provide. | ||
142 | |||
143 | 6. Django prompts you to re-enter your password for verification. | ||
144 | |||
145 | After completing these steps, the following confirmation message | ||
146 | appears: Superuser created successfully. | ||
147 | |||
148 | Creating a superuser allows you to access the Django administration | ||
149 | interface through a browser. The URL for this interface is the same as | ||
150 | the URL used for the Toaster instance with "/admin" on the end. For | ||
151 | example, if you are running Toaster locally, use the following URL: | ||
152 | http://127.0.0.1:8000/admin You can use the Django administration | ||
153 | interface to set Toaster configuration parameters such as the build | ||
154 | directory, layer sources, default variable values, and BitBake versions. | ||
155 | |||
156 | .. _toaster-setting-up-a-production-instance-of-toaster: | ||
157 | |||
158 | Setting Up a Production Instance of Toaster | ||
159 | =========================================== | ||
160 | |||
161 | You can use a production instance of Toaster to share the Toaster | ||
162 | instance with remote users, multiple users, or both. The production | ||
163 | instance is also the setup that can handle heavier loads on the web | ||
164 | service. Use the instructions in the following sections to set up | ||
165 | Toaster to run builds through the Toaster web interface. | ||
166 | |||
167 | .. _toaster-production-instance-requirements: | ||
168 | |||
169 | Requirements | ||
170 | ------------ | ||
171 | |||
172 | Be sure you meet the following requirements: | ||
173 | |||
174 | .. note:: | ||
175 | |||
176 | You must comply with all Apache, | ||
177 | mod-wsgi | ||
178 | , and Mysql requirements. | ||
179 | |||
180 | - Have all the build requirements as described in the "`Preparing to | ||
181 | Use Toaster <#toaster-manual-start>`__" chapter. | ||
182 | |||
183 | - Have an Apache webserver. | ||
184 | |||
185 | - Have ``mod-wsgi`` for the Apache webserver. | ||
186 | |||
187 | - Use the Mysql database server. | ||
188 | |||
189 | - If you are using Ubuntu 16.04, run the following: $ sudo apt-get | ||
190 | install apache2 libapache2-mod-wsgi-py3 mysql-server python3-pip | ||
191 | libmysqlclient-dev | ||
192 | |||
193 | - If you are using Fedora 24 or a RedHat distribution, run the | ||
194 | following: $ sudo dnf install httpd python3-mod_wsgi python3-pip | ||
195 | mariadb-server mariadb-devel python3-devel | ||
196 | |||
197 | - If you are using openSUSE Leap 42.1, run the following: $ sudo zypper | ||
198 | install apache2 apache2-mod_wsgi-python3 python3-pip mariadb | ||
199 | mariadb-client python3-devel | ||
200 | |||
201 | .. _toaster-installation-steps: | ||
202 | |||
203 | Installation | ||
204 | ------------ | ||
205 | |||
206 | Perform the following steps to install Toaster: | ||
207 | |||
208 | 1. Create toaster user and set its home directory to | ||
209 | ``/var/www/toaster``: $ sudo /usr/sbin/useradd toaster -md | ||
210 | /var/www/toaster -s /bin/false $ sudo su - toaster -s /bin/bash | ||
211 | |||
212 | 2. Checkout a copy of ``poky`` into the web server directory. You will | ||
213 | be using ``/var/www/toaster``: $ git clone | ||
214 | git://git.yoctoproject.org/poky $ git checkout DISTRO_NAME_NO_CAP | ||
215 | |||
216 | 3. Install Toaster dependencies using the --user flag which keeps the | ||
217 | Python packages isolated from your system-provided packages: $ cd | ||
218 | /var/www/toaster/ $ pip3 install --user -r | ||
219 | ./poky/bitbake/toaster-requirements.txt $ pip3 install --user | ||
220 | mysqlclient | ||
221 | |||
222 | .. note:: | ||
223 | |||
224 | Isolating these packages is not required but is recommended. | ||
225 | Alternatively, you can use your operating system's package | ||
226 | manager to install the packages. | ||
227 | |||
228 | 4. Configure Toaster by editing | ||
229 | ``/var/www/toaster/poky/bitbake/lib/toaster/toastermain/settings.py`` | ||
230 | as follows: | ||
231 | |||
232 | - Edit the | ||
233 | `DATABASES <https://docs.djangoproject.com/en/1.11/ref/settings/#databases>`__ | ||
234 | settings: DATABASES = { 'default': { 'ENGINE': | ||
235 | 'django.db.backends.mysql', 'NAME': 'toaster_data', 'USER': | ||
236 | 'toaster', 'PASSWORD': 'yourpasswordhere', 'HOST': 'localhost', | ||
237 | 'PORT': '3306', } } | ||
238 | |||
239 | - Edit the | ||
240 | `SECRET_KEY <https://docs.djangoproject.com/en/1.11/ref/settings/#std:setting-SECRET_KEY>`__: | ||
241 | SECRET_KEY = 'your_secret_key' | ||
242 | |||
243 | - Edit the | ||
244 | `STATIC_ROOT <https://docs.djangoproject.com/en/1.11/ref/settings/#std:setting-STATIC_ROOT>`__: | ||
245 | STATIC_ROOT = '/var/www/toaster/static_files/' | ||
246 | |||
247 | 5. Add the database and user to the ``mysql`` server defined earlier: $ | ||
248 | mysql -u root -p mysql> CREATE DATABASE toaster_data; mysql> CREATE | ||
249 | USER 'toaster'@'localhost' identified by 'yourpasswordhere'; mysql> | ||
250 | GRANT all on toaster_data.\* to 'toaster'@'localhost'; mysql> quit | ||
251 | |||
252 | 6. Get Toaster to create the database schema, default data, and gather | ||
253 | the statically-served files: $ cd /var/www/toaster/poky/ $ | ||
254 | ./bitbake/lib/toaster/manage.py migrate $ TOASTER_DIR=`pwd\` | ||
255 | TEMPLATECONF='poky' \\ ./bitbake/lib/toaster/manage.py checksettings | ||
256 | $ ./bitbake/lib/toaster/manage.py collectstatic In the previous | ||
257 | example, from the ``poky`` directory, the ``migrate`` command | ||
258 | ensures the database schema changes have propagated correctly (i.e. | ||
259 | migrations). The next line sets the Toaster root directory | ||
260 | ``TOASTER_DIR`` and the location of the Toaster configuration file | ||
261 | ``TOASTER_CONF``, which is relative to ``TOASTER_DIR``. The | ||
262 | ``TEMPLATECONF`` value reflects the contents of | ||
263 | ``poky/.templateconf``, and by default, should include the string | ||
264 | "poky". For more information on the Toaster configuration file, see | ||
265 | the "`Configuring Toaster <#configuring-toaster>`__" section. | ||
266 | |||
267 | This line also runs the ``checksettings`` command, which configures | ||
268 | the location of the Toaster `Build | ||
269 | Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. The Toaster | ||
270 | root directory ``TOASTER_DIR`` determines where the Toaster build | ||
271 | directory is created on the file system. In the example above, | ||
272 | ``TOASTER_DIR`` is set as follows: /var/www/toaster/poky This | ||
273 | setting causes the Toaster build directory to be: | ||
274 | /var/www/toaster/poky/build | ||
275 | |||
276 | Finally, the ``collectstatic`` command is a Django framework command | ||
277 | that collects all the statically served files into a designated | ||
278 | directory to be served up by the Apache web server as defined by | ||
279 | ``STATIC_ROOT``. | ||
280 | |||
281 | 7. Test and/or use the Mysql integration with Toaster’s Django web | ||
282 | server. At this point, you can start up the normal Toaster Django | ||
283 | web server with the Toaster database in Mysql. You can use this web | ||
284 | server to confirm that the database migration and data population | ||
285 | from the Layer Index is complete. | ||
286 | |||
287 | To start the default Toaster Django web server with the Toaster | ||
288 | database now in Mysql, use the standard start commands: $ source | ||
289 | oe-init-build-env $ source toaster start Additionally, if Django is | ||
290 | sufficient for your requirements, you can use it for your release | ||
291 | system and migrate later to Apache as your requirements change. | ||
292 | |||
293 | 8. Add an Apache configuration file for Toaster to your Apache web | ||
294 | server's configuration directory. If you are using Ubuntu or Debian, | ||
295 | put the file here: /etc/apache2/conf-available/toaster.conf If you | ||
296 | are using Fedora or RedHat, put it here: | ||
297 | /etc/httpd/conf.d/toaster.conf If you are using OpenSUSE, put it | ||
298 | here: /etc/apache2/conf.d/toaster.conf Following is a sample Apache | ||
299 | configuration for Toaster you can follow: Alias /static | ||
300 | /var/www/toaster/static_files <Directory | ||
301 | /var/www/toaster/static_files> <IfModule mod_access_compat.c> Order | ||
302 | allow,deny Allow from all </IfModule> <IfModule | ||
303 | !mod_access_compat.c> Require all granted </IfModule> </Directory> | ||
304 | <Directory /var/www/toaster/poky/bitbake/lib/toaster/toastermain> | ||
305 | <Files "wsgi.py"> Require all granted </Files> </Directory> | ||
306 | WSGIDaemonProcess toaster_wsgi | ||
307 | python-path=/var/www/toaster/poky/bitbake/lib/toaster:/var/www/toaster/.local/lib/python3.4/site-packages | ||
308 | WSGIScriptAlias / | ||
309 | "/var/www/toaster/poky/bitbake/lib/toaster/toastermain/wsgi.py" | ||
310 | <Location /> WSGIProcessGroup toaster_wsgi </Location> If you are | ||
311 | using Ubuntu or Debian, you will need to enable the config and | ||
312 | module for Apache: $ sudo a2enmod wsgi $ sudo a2enconf toaster $ | ||
313 | chmod +x bitbake/lib/toaster/toastermain/wsgi.py Finally, restart | ||
314 | Apache to make sure all new configuration is loaded. For Ubuntu, | ||
315 | Debian, and OpenSUSE use: $ sudo service apache2 restart For Fedora | ||
316 | and RedHat use: $ sudo service httpd restart | ||
317 | |||
318 | 9. Prepare the systemd service to run Toaster builds. Here is a sample | ||
319 | configuration file for the service: [Unit] Description=Toaster | ||
320 | runbuilds [Service] Type=forking User=toaster | ||
321 | ExecStart=/usr/bin/screen -d -m -S runbuilds | ||
322 | /var/www/toaster/poky/bitbake/lib/toaster/runbuilds-service.sh start | ||
323 | ExecStop=/usr/bin/screen -S runbuilds -X quit | ||
324 | WorkingDirectory=/var/www/toaster/poky [Install] | ||
325 | WantedBy=multi-user.target Prepare the ``runbuilds-service.sh`` | ||
326 | script that you need to place in the | ||
327 | ``/var/www/toaster/poky/bitbake/lib/toaster/`` directory by setting | ||
328 | up executable permissions: #!/bin/bash #export | ||
329 | http_proxy=http://proxy.host.com:8080 #export | ||
330 | https_proxy=http://proxy.host.com:8080 #export | ||
331 | GIT_PROXY_COMMAND=$HOME/bin/gitproxy cd ~/poky/ source | ||
332 | ./oe-init-build-env build source ../bitbake/bin/toaster $1 noweb [ | ||
333 | "$1" == 'start' ] && /bin/bash | ||
334 | |||
335 | 10. Run the service: # service runbuilds start Since the service is | ||
336 | running in a detached screen session, you can attach to it using | ||
337 | this command: $ sudo su - toaster $ screen -rS runbuilds You can | ||
338 | detach from the service again using "Ctrl-a" followed by "d" key | ||
339 | combination. | ||
340 | |||
341 | You can now open up a browser and start using Toaster. | ||
342 | |||
343 | Using the Toaster Web Interface | ||
344 | =============================== | ||
345 | |||
346 | The Toaster web interface allows you to do the following: | ||
347 | |||
348 | - Browse published layers in the `OpenEmbedded Layer | ||
349 | Index <http://layers.openembedded.org>`__ that are available for your | ||
350 | selected version of the build system. | ||
351 | |||
352 | - Import your own layers for building. | ||
353 | |||
354 | - Add and remove layers from your configuration. | ||
355 | |||
356 | - Set configuration variables. | ||
357 | |||
358 | - Select a target or multiple targets to build. | ||
359 | |||
360 | - Start your builds. | ||
361 | |||
362 | - See what was built (recipes and packages) and what packages were | ||
363 | installed into your final image. | ||
364 | |||
365 | - Browse the directory structure of your image. | ||
366 | |||
367 | - See the value of all variables in your build configuration, and which | ||
368 | files set each value. | ||
369 | |||
370 | - Examine error, warning and trace messages to aid in debugging. | ||
371 | |||
372 | - See information about the BitBake tasks executed and reused during | ||
373 | your build, including those that used shared state. | ||
374 | |||
375 | - See dependency relationships between recipes, packages and tasks. | ||
376 | |||
377 | - See performance information such as build time, task time, CPU usage, | ||
378 | and disk I/O. | ||
379 | |||
380 | .. _web-interface-videos: | ||
381 | |||
382 | Toaster Web Interface Videos | ||
383 | ---------------------------- | ||
384 | |||
385 | Following are several videos that show how to use the Toaster GUI: | ||
386 | |||
387 | - *Build Configuration:* This | ||
388 | `video <https://www.youtube.com/watch?v=qYgDZ8YzV6w>`__ overviews and | ||
389 | demonstrates build configuration for Toaster. | ||
390 | |||
391 | - *Build Custom Layers:* This | ||
392 | `video <https://www.youtube.com/watch?v=QJzaE_XjX5c>`__ shows you how | ||
393 | to build custom layers that are used with Toaster. | ||
394 | |||
395 | - *Toaster Homepage and Table Controls:* This | ||
396 | `video <https://www.youtube.com/watch?v=QEARDnrR1Xw>`__ goes over the | ||
397 | Toaster entry page, and provides an overview of the data manipulation | ||
398 | capabilities of Toaster, which include search, sorting and filtering | ||
399 | by different criteria. | ||
400 | |||
401 | - *Build Dashboard:* This | ||
402 | `video <https://www.youtube.com/watch?v=KKqHYcnp2gE>`__ shows you the | ||
403 | build dashboard, a page providing an overview of the information | ||
404 | available for a selected build. | ||
405 | |||
406 | - *Image Information:* This | ||
407 | `video <https://www.youtube.com/watch?v=XqYGFsmA0Rw>`__ walks through | ||
408 | the information Toaster provides about images: packages installed and | ||
409 | root file system. | ||
410 | |||
411 | - *Configuration:* This | ||
412 | `video <https://www.youtube.com/watch?v=UW-j-T2TzIg>`__ provides | ||
413 | Toaster build configuration information. | ||
414 | |||
415 | - *Tasks:* This `video <https://www.youtube.com/watch?v=D4-9vGSxQtw>`__ | ||
416 | shows the information Toaster provides about the tasks run by the | ||
417 | build system. | ||
418 | |||
419 | - *Recipes and Packages Built:* This | ||
420 | `video <https://www.youtube.com/watch?v=x-6dx4huNnw>`__ shows the | ||
421 | information Toaster provides about recipes and packages built. | ||
422 | |||
423 | - *Performance Data:* This | ||
424 | `video <https://www.youtube.com/watch?v=qWGMrJoqusQ>`__ shows the | ||
425 | build performance data provided by Toaster. | ||
426 | |||
427 | .. _a-note-on-the-local-yocto-project-release: | ||
428 | |||
429 | Additional Information About the Local Yocto Project Release | ||
430 | ------------------------------------------------------------ | ||
431 | |||
432 | This section only applies if you have set up Toaster for local | ||
433 | development, as explained in the "`Starting Toaster for Local | ||
434 | Development <#starting-toaster-for-local-development>`__" section. | ||
435 | |||
436 | When you create a project in Toaster, you will be asked to provide a | ||
437 | name and to select a Yocto Project release. One of the release options | ||
438 | you will find is called "Local Yocto Project". | ||
439 | |||
440 | When you select the "Local Yocto Project" release, Toaster will run your | ||
441 | builds using the local Yocto Project clone you have in your computer: | ||
442 | the same clone you are using to run Toaster. Unless you manually update | ||
443 | this clone, your builds will always use the same Git revision. | ||
444 | |||
445 | If you select any of the other release options, Toaster will fetch the | ||
446 | tip of your selected release from the upstream `Yocto Project | ||
447 | repository <https://git.yoctoproject.org>`__ every time you run a build. | ||
448 | Fetching this tip effectively means that if your selected release is | ||
449 | updated upstream, the Git revision you are using for your builds will | ||
450 | change. If you are doing development locally, you might not want this | ||
451 | change to happen. In that case, the "Local Yocto Project" release might | ||
452 | be the right choice. | ||
453 | |||
454 | However, the "Local Yocto Project" release will not provide you with any | ||
455 | compatible layers, other than the three core layers that come with the | ||
456 | Yocto Project: | ||
457 | |||
458 | - `openembedded-core <http://layers.openembedded.org/layerindex/branch/master/layer/openembedded-core/>`__ | ||
459 | |||
460 | - `meta-poky <http://layers.openembedded.org/layerindex/branch/master/layer/meta-poky/>`__ | ||
461 | |||
462 | - `meta-yocto-bsp <http://layers.openembedded.org/layerindex/branch/master/layer/meta-yocto-bsp/>`__ | ||
463 | |||
464 | If you want to build any other layers, you will need to manually import | ||
465 | them into your Toaster project, using the "Import layer" page. | ||
466 | |||
467 | .. _toaster-web-interface-preferred-version: | ||
468 | |||
469 | Building a Specific Recipe Given Multiple Versions | ||
470 | -------------------------------------------------- | ||
471 | |||
472 | Occasionally, a layer might provide more than one version of the same | ||
473 | recipe. For example, the ``openembedded-core`` layer provides two | ||
474 | versions of the ``bash`` recipe (i.e. 3.2.48 and 4.3.30-r0) and two | ||
475 | versions of the ``which`` recipe (i.e. 2.21 and 2.18). The following | ||
476 | figure shows this exact scenario: | ||
477 | |||
478 | By default, the OpenEmbedded build system builds one of the two recipes. | ||
479 | For the ``bash`` case, version 4.3.30-r0 is built by default. | ||
480 | Unfortunately, Toaster as it exists, is not able to override the default | ||
481 | recipe version. If you would like to build bash 3.2.48, you need to set | ||
482 | the | ||
483 | ```PREFERRED_VERSION`` <&YOCTO_DOCS_REF_URL;#var-PREFERRED_VERSION>`__ | ||
484 | variable. You can do so from Toaster, using the "Add variable" form, | ||
485 | which is available in the "BitBake variables" page of the project | ||
486 | configuration section as shown in the following screen: | ||
487 | |||
488 | To specify ``bash`` 3.2.48 as the version to build, enter | ||
489 | "PREFERRED_VERSION_bash" in the "Variable" field, and "3.2.48" in the | ||
490 | "Value" field. Next, click the "Add variable" button: | ||
491 | |||
492 | After clicking the "Add variable" button, the settings for | ||
493 | ``PREFERRED_VERSION`` are added to the bottom of the BitBake variables | ||
494 | list. With these settings, the OpenEmbedded build system builds the | ||
495 | desired version of the recipe rather than the default version: | ||
diff --git a/documentation/toaster-manual/toaster-manual-start.rst b/documentation/toaster-manual/toaster-manual-start.rst new file mode 100644 index 0000000000..54f290590b --- /dev/null +++ b/documentation/toaster-manual/toaster-manual-start.rst | |||
@@ -0,0 +1,46 @@ | |||
1 | ************************ | ||
2 | Preparing to Use Toaster | ||
3 | ************************ | ||
4 | |||
5 | This chapter describes how you need to prepare your system in order to | ||
6 | use Toaster. | ||
7 | |||
8 | .. _toaster-setting-up-the-basic-system-requirements: | ||
9 | |||
10 | Setting Up the Basic System Requirements | ||
11 | ======================================== | ||
12 | |||
13 | Before you can use Toaster, you need to first set up your build system | ||
14 | to run the Yocto Project. To do this, follow the instructions in the | ||
15 | "`Preparing the Build | ||
16 | Host <&YOCTO_DOCS_DEV_URL;#dev-preparing-the-build-host>`__" section of | ||
17 | the Yocto Project Development Tasks Manual. For Ubuntu/Debian, you might | ||
18 | also need to do an additional install of pip3. $ sudo apt-get install | ||
19 | python3-pip | ||
20 | |||
21 | .. _toaster-establishing-toaster-system-dependencies: | ||
22 | |||
23 | Establishing Toaster System Dependencies | ||
24 | ======================================== | ||
25 | |||
26 | Toaster requires extra Python dependencies in order to run. A Toaster | ||
27 | requirements file named ``toaster-requirements.txt`` defines the Python | ||
28 | dependencies. The requirements file is located in the ``bitbake`` | ||
29 | directory, which is located in the root directory of the `Source | ||
30 | Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. | ||
31 | ``poky/bitbake/toaster-requirements.txt``). The dependencies appear in a | ||
32 | ``pip``, install-compatible format. | ||
33 | |||
34 | .. _toaster-load-packages: | ||
35 | |||
36 | Install Toaster Packages | ||
37 | ------------------------ | ||
38 | |||
39 | You need to install the packages that Toaster requires. Use this | ||
40 | command: $ pip3 install --user -r bitbake/toaster-requirements.txt The | ||
41 | previous command installs the necessary Toaster modules into a local | ||
42 | python 3 cache in your ``$HOME`` directory. The caches is actually | ||
43 | located in ``$HOME/.local``. To see what packages have been installed | ||
44 | into your ``$HOME`` directory, do the following: $ pip3 list installed | ||
45 | --local If you need to remove something, the following works: $ pip3 | ||
46 | uninstall PackageNameToUninstall | ||
diff --git a/documentation/toaster-manual/toaster-manual.rst b/documentation/toaster-manual/toaster-manual.rst new file mode 100644 index 0000000000..4b0342c578 --- /dev/null +++ b/documentation/toaster-manual/toaster-manual.rst | |||
@@ -0,0 +1,12 @@ | |||
1 | =================== | ||
2 | Toaster User Manual | ||
3 | =================== | ||
4 | |||
5 | .. toctree:: | ||
6 | :caption: Table of Contents | ||
7 | :numbered: | ||
8 | |||
9 | toaster-manual-intro | ||
10 | toaster-manual-start | ||
11 | toaster-manual-setup-and-use | ||
12 | toaster-manual-reference | ||