cookutils view doc/cookutils.en.html @ rev 197

Update docs and tiny edits
author Paul Issott <paul@slitaz.org>
date Sat May 21 18:17:58 2011 +0100 (2011-05-21)
parents 51706736c5f8
children 77037ae33127
line source
1 <!DOCTYPE html>
2 <html xmlns="http://www.w3.org/1999/xhtml">
3 <head>
4 <title>Cookutils Documentation</title>
5 <meta charset="utf-8" />
6 <link rel="stylesheet" type="text/css" href="style.css" />
7 </head>
8 <body>
10 <div id="header">
11 <h1>Cookutils Documentation</h1>
12 </div>
14 <!-- Start content -->
15 <div id="content">
17 <h2>SliTaz Cook &amp; Cooker</h2>
19 <p>
20 The SliTaz Cookutils provide tools and utils to help build SliTaz packages. They
21 are easy to use and learn, fast and light. You will be able to create SliTaz
22 packages in a few commands. The cookutils provide the 'cook' utility and the
23 <a href="#cooker">Cooker</a>.
24 </p>
25 <p>
26 Cook lets you compile and create a package, provide a log file and check the
27 receipt/package quality. The Cooker is a build bot with more automation
28 and can be used as a frontend to cook since it provides a CGI/web interface
29 which lets you view cook logs in a nice and colored way. Cook and the Cooker
30 use the same DB files and wok, they both share <a href="#blocked">blocked</a>
31 and broken packages as well as any activity.
32 </p>
34 <h3>Cook usage</h3>
35 <p>
36 Cook provides a small built-in help usage that you can display with the
37 command 'usage'. It also has some options to perform special tasks on
38 a package before cooking it or afterwards. To get help and usage:
39 </p>
40 <pre>
41 # cook usage
42 </pre>
44 <h3>Howto</h3>
45 <p>
46 The first thing you will have to do before building packages is setup
47 your environment. The 2 recommended ways of working: cook directly on host
48 or cook in chroot to protect your host. In the case you want to work in a
49 chroot you can install and use Tazdev to create one and chroot into it:
50 </p>
51 <pre>
52 # tazdev gen-chroot &amp;&amp; tazdev chroot
53 </pre>
54 <p>
55 By default Tazdev creates a chroot in /home/slitaz/cooking/chroot but you
56 can specify a custom path in the argument. The chroot location is not
57 important, when you will be in the chroot you will use standard SliTaz
58 paths such as /home/slitaz/wok for the wok directory or /home/slitaz/log
59 for all the cook logs. As usual you can display tazdev help usage with:
60 tazdev usage.
61 </p>
62 <p>
63 When you use a chroot there are 2 special directories mounted with the bind
64 option: src and packages. The sources for all packages are stored by default
65 in /home/slitaz/src, this directory is mounted into the chroot so the utils
66 can use them. This method lets you share sources between many chroots such
67 as one for cooking and one for stable. The packages directory default
68 location is: /home/slitaz/[version]/packages so they are not in the chroot
69 and are safe in case the chroot is removed by error.
70 </p>
72 <h3>Getting started</h3>
73 <p>
74 So you have decided the way you want to work, so lets prepare the cook environment.
75 Cook uses the cook.conf configuration file, if you want to use custom paths for
76 SliTaz directories and files, you'll have to modify it. The setup will create
77 some directories and files to keep trace of activity and errors, all files
78 are pure plain text files that you can open in a text editor. To prepare
79 your environment:
80 </p>
81 <pre>
82 # cook setup
83 </pre>
84 <p>
85 The setup command has a --wok option which lets you clone a SliTaz wok while
86 setting up your cook environment. Even if you are not yet an official developer
87 you can clone it and use existing packages as an example to create your own.
88 To setup and clone the wok:
89 </p>
90 <pre>
91 # cook setup --wok
92 </pre>
94 <h3>Test your environment</h3>
95 <p>
96 Cook provides a test command which will create a package and cook it. This lets
97 you see if your environment is working and it provides an example package with
98 a receipt. The dummy package is named 'cooktest' and can be removed after
99 testing. To cook the test package:
100 </p>
101 <pre>
102 # cook test
103 </pre>
105 <h3>Create and cook</h3>
106 <p>
107 If your environment is setup correctly you can start creating and compiling
108 SliTaz packages from your wok. To create a new package with an empty receipt
109 (you can also create a receipt interactively):
110 </p>
111 <pre>
112 # cook new pkgname
113 # cook new pkgname --interactive
114 </pre>
115 <p>
116 If you have just created a new package, you'll have to edit the receipt with your
117 favorite text editor. When the receipt is ready or if you have an existing
118 package, you can cook it:
119 </p>
120 <pre>
121 # cook pkgname
122 </pre>
123 <p>
124 If all went well you will find your package in the $SLITAZ/packages
125 directory and any produced files in $SLITAZ/wok/pkgname.
126 </p>
128 <h3>Cook and install</h3>
129 <p>
130 If you want to cook and install the package in one command:
131 </p>
132 <pre>
133 # cook pkgname --install
134 </pre>
136 <h3>Get sources</h3>
137 <p>
138 If you want or need to download only the source of a package without
139 building it, you can use the option --getsrc as below:
140 </p>
141 <pre>
142 # cook pkgname --getsrc
143 </pre>
145 <h3>Clean packages</h3>
146 <p>
147 After compilation and packaging there are several files in the wok that take up
148 disk space. To clean a single package:
149 </p>
150 <pre>
151 # cook pkgname --clean
152 </pre>
153 <p>
154 You can also clean the full wok at once or you can choose to keep SliTaz
155 related files and just remove the source:
156 </p>
157 <pre>
158 # cook clean-wok
159 # cook clean-src
160 </pre>
162 <h3>Search</h3>
163 <p>
164 Cook provides a simple search function to quickly find a package in the
165 wok. It uses grep and so supports regular expressions:
166 </p>
167 <pre>
168 # cook search busybox
169 </pre>
171 <h3>Packages list</h3>
172 <p>
173 Cook can list packages in the wok and also create a suitable packages list
174 for Tazpkg. This lets you create a local packages repository quite easily
175 and is used to create the official SliTaz packages list found on the mirrors.
176 To list the current wok used by cook (you don't need to be root):
177 </p>
178 <pre>
179 $ cook list-wok
180 </pre>
181 <p>
182 To create a packages list:
183 </p>
184 <pre>
185 # cook pkglist
186 </pre>
188 <a name="cooker"></a>
189 <h3>The Cooker</h3>
190 <p>
191 The Cooker is a Build Bot, its first function is to check for commits in a wok,
192 create an ordered cooklist and cook all modified packages. It can also be
193 used as a frontend to cook since they both use the same files. The Cooker can
194 also be used to cook a big list of packages at once such as all the packages
195 in a flavor. The Cooker provides a nice CGI/Web interface that works by
196 default on any SliTaz system since it provides CGI support via the Busybox httpd
197 web server.
198 </p>
199 <p>
200 The Cooker provides a small built-in help usage and short command switch.
201 For example to display usage you can use:
202 </p>
203 <pre>
204 # cooker usage
205 # cooker -u
206 </pre>
208 <h3>Cooker setup</h3>
209 <p>
210 Like cook, the Cooker needs a working environment before starting to use it.
211 The main difference with the cook environment is that the Cooker needs 2 woks.
212 One Hg and clean wok as a reference and one build wok. In this way it is easy
213 to compare both woks and get modifications. If you already have a cook
214 environment, you must move your wok before setting up the Cooker or it
215 will complain. Setup will also install a set of development packages that
216 can be configured in the cook.conf configuration file and the variable
217 SETUP_PKGS. To setup your cooker environment:
218 </p>
219 <pre>
220 # cooker setup
221 </pre>
222 <p>
223 If all went well you now have 2 woks, base development packages installed
224 and all needed files created. The default behavior is to check for commits,
225 you can run a test:
226 </p>
227 <pre>
228 # cooker
229 </pre>
231 <h3>Cooker cook</h3>
232 <p>
233 Again, 2 ways to work now: make changes in the clean Hg wok and launch the
234 cooker without any arguments or cook packages manually. The cooker lets you
235 cook a single package or all packages of a category or a flavor. You can also
236 try to build all unbuilt packages, but be aware the Cooker was not designed
237 to handle thousands of packages.
238 </p>
239 <p>
240 To cook a single package which is the same as 'cook pkgname' but with more
241 logs:
242 </p>
243 <pre>
244 # cooker pkg pkgname
245 </pre>
246 <p>
247 To cook more than one package at once you have different kind of choices.
248 You can use an existing package such as used for Live flavors, you can also
249 use a custom list using the package names listed line by line. Finally you can
250 build all packages of a category.
251 </p>
252 <pre>
253 # cooker flavor [name]
254 # cooker list [/path/to/cooklist]
255 # cooker cat [category]
256 </pre>
257 <p>
258 The Cooker lets you also recook a specific Hg revision. It's useful in
259 production so that if the Build Bot was interrupted while cooking commits, you
260 can then cook packages manually:
261 </p>
262 <pre>
263 # cooker rev 9496
264 </pre>
266 <a name="blocked"></a>
267 <h3>Blocked packages</h3>
268 <p>
269 Cook and the Cooker handle a file with a list of blocked package so they will
270 not cook when commits happen or if a cooklist is used. This is very useful
271 for a Cooker Build Bot in production. When you block or unblock a package
272 you can add a note to the cooknotes. Blocking packages example:
273 </p>
274 <pre>
275 # cook pkgname --block
276 # cooker block pkgname
277 # cooker -n "Blocked pkgname note"
278 </pre>
279 <p>
280 The list of blocked packages are also displayed on the Cooker web interface.
281 To unblock a package you have to use the unblock command or cook --unblock
282 option:
283 </p>
284 <pre>
285 # cook pkgname --unblock
286 # cooker unblock pkgname
287 </pre>
289 <h3>Cooker CGI/Web</h3>
290 <p>
291 To let you view log files in a nice way, keep trace of activity and help find
292 errors, you can use the Cooker Web interface located by default in the folder
293 /var/www/cgi-bin/cooker. If you don't use a chroot and the Busybox httpd
294 web server is running, the web interface will work without configuration and
295 should be reachable at: <a href="http://localhost/cgi-bin/cooker/cooker.cgi">
296 http://localhost/cgi-bin/cooker/cooker.cgi</a>
297 </p>
298 <p>
299 If you used a chroot environment, you should also install cookutils on your
300 host and modify the SLITAZ path variable. A standard working way is to have
301 a chroot in:
302 </p>
303 <pre>
304 /home/slitaz/cooking/chroot
305 </pre>
306 <p>
307 With /etc/slitaz/cook.conf modified as below:
308 </p>
309 <pre>
310 SLITAZ="/home/slitaz/cooking/chroot/home/slitaz"
311 </pre>
312 <p>
313 Note: It's not obligatory to install the cookutils on your host to use the
314 web interface, you can also copy the cooker.cgi and style.css files for
315 example into your ~/Public directory and use a custom cook.conf with it. The
316 advantage of installing cookutils on the host is to get regular updates via
317 the Tazpkg packages manager. Say you have cloned or downloaded the cookutils:
318 </p>
319 <pre>
320 $ cp -a cookutils/web ~/Public/cgi-bin/cooker
321 $ cp -f cookutils/cook.conf ~/Public/cgi-bin/cooker
322 </pre>
323 <p>
324 Edit the configuration file: ~/Public/cgi-bin/cooker/cook.conf to set your
325 SLITAZ path and you're all done!
326 </p>
328 <h3>Cooknotes</h3>
329 <p>
330 The cooknotes feature lets you write small personal notes about packaging
331 and is useful for collaboration. The cooknotes was coded to let the SliTaz
332 Cooker bot maintainers share notes between themselves and other contributors.
333 The Cooker can block a package's build or recook packages manually, for example
334 it's nice to make a note if a package is blocked so that the maintainer knows why
335 admin did that. Cooknotes are displayed on the web interface and can be
336 checked from a cmdline:
337 </p>
338 <pre>
339 # cooker note "Blocked pkgname due to heavy CPU load"
340 # cooker notes
341 </pre>
343 <h3>Cooker as a Build Bot</h3>
344 <p>
345 The Cooker is designed to be a Built Bot for SliTaz, this means it monitors
346 2 woks, updates the Hg wok, gets the differences and cooks all packages that
347 have been committed. The safer and cleaner way to run the Cooker as a Build
348 Bot with cron is to use a chroot environment, but it can run directly on the
349 host if you want.
350 </p>
351 <p>
352 To run The Cooker automatically you must use cron from the chroot and add a
353 single line to root crontabs in /var/spool/cron/crontabs. Say you would like
354 to run the Cooker every 2 hours:
355 </p>
356 <pre>
357 * */2 * * * /usr/bin/cooker
358 </pre>
360 <h3>Cooker BB started at boot</h3>
361 <p>
362 The Cooker environment and cron task can automatically be started at boot time.
363 You must have the cookutils-daemon installed on the host and use a standard SliTaz
364 installation to make it work properly (cooking goes in /home/slitaz/cooking). The
365 daemon script will mount any virtual filesystems if needed as well as source and
366 packages. Source files are in /home/slitaz/src and bound into the chroot
367 so you can share package's sources between several versions (stable, cooking,
368 undigest). If the package is not yet installed:
369 </p>
370 <pre>
371 # tazpkg get-install cookutils-daemon
372 </pre>
373 <p>
374 To start the daemon you must have a cron file definition for
375 root in the chroot, the daemon script works like all other system daemons
376 and can be handled with:
377 </p>
378 <pre>
379 # /etc/init.d/cooker [start|stop|restart]
380 </pre>
382 <!-- End content -->
383 </div>
385 <div id="footer">
386 Copyright &copy; 2011 SliTaz contributors
387 </div>
389 </body>
390 </html>