slitaz-doc-wiki-data rev 15
Updated pages on 2011-03-11.
| author | Christopher Rogers <slaxemulator@gmail.com> |
|---|---|
| date | Fri Mar 11 14:19:17 2011 +0000 (2011-03-11) |
| parents | 9f452fb2a9f5 |
| children | e5e969fb9e04 |
| files | pages/en/devnotes/ash-benchmarks.txt pages/en/devnotes/new-tazwok-illustrated.txt pages/en/guides/conspy.txt pages/en/guides/uncommoninst.txt pages/pt/guides/pclistaz.txt |
line diff
1.1 --- a/pages/en/devnotes/ash-benchmarks.txt Mon Feb 28 08:27:54 2011 +0000 1.2 +++ b/pages/en/devnotes/ash-benchmarks.txt Fri Mar 11 14:19:17 2011 +0000 1.3 @@ -1,10 +1,10 @@ 1.4 -Some tips to speed-up scripts... Add yours, and put the better ones on the top of page :) 1.5 +Some tips to speed-up scripts... Add yours, and put the better ones on the top of the page :) 1.6 1.7 ==== Sed substitution vs Variable substitution ==== 1.8 1.9 **Information** 1.10 1.11 -In some case, both tools can do the same job. As a build-in ash/bash command, variable substitution is a faster. 1.12 +In some cases, both tools can do the same job. As a built-in ash/bash command, variable substitution is faster. 1.13 Note: this is always true - you can compare each type of variable substitution with an equivalent using an external tool. 1.14 1.15 **Benchmark** 1.16 @@ -29,9 +29,9 @@ 1.17 1.18 **Information** 1.19 1.20 -Group command "{}" group several commands into one (as a function). So, output can be grouped too: "{ com1; com2; } | com3". Sub-process "()" achieve something similar, but create a shell sub-process; which cost a lot more resources. Another difference is that, when you kill an application using CTRL^C, sub-process is killed instead of main application - while CTRL^C on grouped commands kill the application itself. Finally, changing directory or variables into sub-process will not affect main script while it does with grouped commands. Conclusion: always use group command instead of sub-processes, and take care ;D 1.21 +Group command "{}" groups several commands into one (as a function). So, output can be grouped too: "{ com1; com2; } | com3". Sub-process "()" achieves something similar, but creates a shell sub-process; which costs a lot more resources. Another difference is that when you kill an application using CTRL^C, a sub-process is killed instead of a main application - while CTRL^C on grouped commands kills the application itself. Finally, changing directory or variables into sub-processes will not affect the main script which it does with grouped commands. Conclusion: always use group commands instead of sub-processes, and take care ;D 1.22 1.23 -//Note:// group command need a newline before closing - or "; }". 1.24 +//Note:// group commands need a newline before closing - or "; }". 1.25 1.26 **Benchmark** 1.27 <code> 1.28 @@ -54,7 +54,7 @@ 1.29 1.30 **Information** 1.31 1.32 -fgrep is exactly the same thing that grep if you don't use patterns (^,$,*,etc.). Fgrep is optimized to handle such case, particularly when you look for several different plain patterns. A difference can be found even if you look of only one pattern. 1.33 +fgrep is exactly the same thing as grep if you don't use patterns (^,$,*,etc.). Fgrep is optimized to handle such cases, particularly when you look for several different plain patterns. A difference can be found even if you look in only one pattern. 1.34 1.35 **Benchmark** 1.36 <code> 1.37 @@ -78,7 +78,7 @@ 1.38 1.39 **Information** 1.40 1.41 -The two commands test if "text" exists. Using -n slow the process a little and weight the script a little too. 1.42 +The two commands test if "text" exists. Using -n slows the process and weighs down the script a little too. 1.43 1.44 **Benchmark** 1.45 <code> 1.46 @@ -101,7 +101,7 @@ 1.47 1.48 **Information** 1.49 1.50 -Theses three commands test if text doesn't exist. [ ! "text" ] and [ -z "text" ] have a similar processing time, while ! [ "text" ] is speeder. 1.51 +These three commands test if text **doesn't** exist. [ ! "text" ] and [ -z "text" ] have a similar processing time, while ! [ "text" ] is speedier. 1.52 1.53 **Benchmark** 1.54 <code> 1.55 @@ -154,7 +154,7 @@ 1.56 1.57 **Information** 1.58 1.59 -While && is a fast built-in function, in this case it uses two process (two test functions) instead one. So, using -a is a little faster, as the "AND" function itself is slower but make possible to use only one process. 1.60 +While && is a fast built-in function, in this case it uses two processes (two test functions) instead of one. So, using -a is a little faster, as the "AND" function itself is slower but makes it possible to use only one process. 1.61 1.62 **Benchmark** 1.63 <code>
2.1 --- a/pages/en/devnotes/new-tazwok-illustrated.txt Mon Feb 28 08:27:54 2011 +0000 2.2 +++ b/pages/en/devnotes/new-tazwok-illustrated.txt Fri Mar 11 14:19:17 2011 +0000 2.3 @@ -1,48 +1,47 @@ 2.4 ====== The new tazwok illustrated! ====== 2.5 2.6 -Some items in revenue no longer needed with the new version of tazwok. During migration, a number of problems appear.The information on these two points are available below, with examples. 2.7 +Certain elements present in the receipts are not necessary any more with the new version of tazwok. During migration, a certain number of problems appear. Information concerning these points are available below, with examples. 2.8 2.9 -By simplifying the writing of recipes, we simplify the work and contribution that benefits everyone! 2.10 +By simplifying the writing of the receipts, we simplify any contributions and that benefits all! 2.11 2.12 ==== DEPENDS/BUILD_DEPENDS : ==== 2.13 -Tazwok now uses the dependent variable for finding the necessary compilation dependencies. 2.14 -Here's how it works: 2.15 +Tazwok uses from now on the variable DEPENDS to find the necessary dependencies of compilation. Here's how that functions: 2.16 2.17 - * Tazwok tree list of all dependencies from the dependent variable 2.18 - * For each package, if there is a shareholder *-dev package, it adds it to the dependencies 2.19 - * Tazwok done the same for BUILD_DEPENDS. 2.20 + * Tazwok lists the tree of all dependencies starting with the variable DEPENDS 2.21 + * For each package, if there exists an associated -dev package, it adds to the dependencies 2.22 + * Tazwok does the same for BUILD_DEPENDS 2.23 2.24 -So far, when a packet was both dependency and build dependency, the recipe looked like this: 2.25 +Up to now, when a package had both a dependency and build dependency, the receipt looked like this: 2.26 2.27 <file> 2.28 DEPENDS="pkgX" 2.29 BUILD_DEPENDS="pkgX pkgX-dev" 2.30 </file> 2.31 -Now that is enough: 2.32 +Now this is enough: 2.33 <file> 2.34 DEPENDS="pkgX" 2.35 </file> 2.36 -Where there were trees more complex dependencies, the recipe looked like this: 2.37 +Where there were trees of more complex dependencies, the receipt looked like this: 2.38 <file> 2.39 # pkgY depend's on pkgX 2.40 DEPENDS="pkgY" 2.41 BUILD_DEPENDS="pkgY pkgY-dev pkgX pkgX-dev" 2.42 </file> 2.43 -Now that is enough: 2.44 +Now this is enough: 2.45 <file> 2.46 DEPENDS="pkgY" 2.47 </file> 2.48 2.49 -The recipes also contain many redundancies in the definition of addiction, for example: 2.50 +The receipts also contain many redundancies in the definition of the dependencies, for example: 2.51 <file> 2.52 # pkgY depend's on pkgX 2.53 DEPENDS="pkgY pkgX" 2.54 </file> 2.55 -Here, needless to say since pkgX will be installed along pkgY anyway (Tazpkg manages dependencies automatically!). 2.56 +Here, needless to say pkgX will be installed alongside pkgY anyway (Tazpkg manages dependencies automatically!). 2.57 2.58 -By following these three councils, it appears that about half the packages in DEPENDS / BUILD_DEPENDS can be removed without changing the revenue system behavior, it is not nothing! 2.59 +While taking these three examples, it appears that about half of the packages in DEPENDS/BUILD_DEPENDS can be withdrawn from the receipts without modifying the behavior of the system. 2.60 2.61 -<note tip>An automated cleaning using some scripts is expected, after all recipes have been compiled at least once successfully using the new version of tazwok; In the meantime, these tips can be applied to writing new recipe for simplicity or manually with existing revenues when updating / corrections.</note> 2.62 +<note tip>An automated cleaning using some scripts is envisaged, after all the receipts were compiled at least once successfully by using the new version of tazwok. In the meantime, these tips can be applied to writing new receipts for simplicity or manually when updating/correcting.</note> 2.63 2.64 **Examples:** 2.65 * graveman: http://hg.slitaz.org/wok/rev/7f0604e0bde0 2.66 @@ -50,45 +49,45 @@ 2.67 2.68 ==== TARBALL/WGET_URL/SOURCE/download from the VCS ==== 2.69 2.70 -This is important: always put the necessary tools to download / decompression sources in DEPENDS or BUILD_DEPENDS. This allows to define tazwok right firing order (do not try to cook a package that needs wget wget before himself). 2.71 +This is important: always put the necessary tools to download/decompress sources in DEPENDS or BUILD_DEPENDS. This makes it possible for tazwok to define a correct order of cooking (try not to cook a package which needs wget before wget itself). 2.72 2.73 -//The packets affected by this:// 2.74 +//The packages affected by this are:// 2.75 * wget url for https, ftps and some URLs that busybox does not include 2.76 - * mercurial/subversion/git: they are used to obtain the source 2.77 - * tar/unzip: sometimes necessary to unpack the sources. 2.78 + * mercurial/subversion/git: these are used to obtain the source 2.79 + * tar/unzip: sometimes necessary to unpack the sources 2.80 2.81 -By default, tazwok re-sources in compact format .tar.lzma. He calls PACKAGE-VERSION.tar.lzma or SOURCE-VERSION.tar.lzma if SOURCE is defined. Note: Choose the name of the archive is now the only function of the variable SOURCE! 2.82 +By default, tazwok re-compresses sources with the format .tar .lzma. It names them PACKAGE-VERSION.tar .lzma, or SOURCE-VERSION.tar .lzma if the SOURCE is defined. Note: choosing the name of the archive is now the only function of the SOURCE variable! 2.83 2.84 -Tazwok now supports files or "weird" URL (download.php?version=foo&blah=Idontknowwhat). The logic is: if WGET_URL does not end with tarball, then names the file downloaded tarball. 2.85 +Tazwok now supports files or "weird" URLs (download.php?version=foo&blah=Idontknowwhat). The logic is: if WGET_URL does not end with tarball, then it names the downloaded file as tarball. 2.86 2.87 -Tazwok also supports the use of mercurial/subversion/git in WGET_URL. The syntax is: 2.88 +Tazwok also supports the use of mercurial/subversion/git in the WGET_URL. The syntax is: 2.89 <file>WGET_URL="subversion|svn://svn.mplayerhq.hu/mplayer/trunk</file> 2.90 -An optional variable is BRANCH: it allows to specify the revision /tag/branch to use (see examples below). Where BRANCH is used, it is important that $VERSION is part of its definition. 2.91 +An optional variable is BRANCH: it allows you to specify the revision /tag/branch to use (see examples below). Where BRANCH is used, it is important that the $VERSION is also part of its definition. 2.92 2.93 -Note that the sources will be obtained through the requested tool, then packaged in .tar.lzma. The archive will be named as explained above. This means that the variable source can be used to ensure that many recipes use the same repository without creating multiple archives. 2.94 +Note that the sources will be obtained through the requested tool, then packaged in .tar.lzma. The archive will be named as explained above. This means that the variable source can be used to ensure that many receipts use the same repository without creating multiple archives. 2.95 2.96 -First, it helps to know what revision is installed when using the package manager. Second, it allows to differentiate tazwok compressed sources. Indeed, if the archive keeps the same name, it will not be re-downloaded, which is undesirable when trying to update the package. 2.97 +First, it helps to know what revision is installed when using the package manager. Second, it allows you to differentiate between tazwok compressed sources. Indeed, if the archive keeps the same name, it will not be re-downloaded, which is undesirable when trying to update the package. 2.98 2.99 **Examples:** 2.100 - * Here was necessary wget: http://hg.slitaz.org/wok/rev/012847ddd0cb 2.101 - * Tinyproxy did not report the URL of its source code is corrected: http://hg.slitaz.org/wok/rev/25967da0e1af 2.102 + * Here wget was necessary: http://hg.slitaz.org/wok/rev/012847ddd0cb 2.103 + * Tinyproxy did not report the URL of its source code and is corrected: http://hg.slitaz.org/wok/rev/25967da0e1af 2.104 * WGET_URL now supports xpi: http://hg.slitaz.org/wok/rev/37738b3ee08f 2.105 * WGET_URL with a "weird" URL: http://hg.slitaz.org/wok/rev/102de15fea8d 2.106 * WGET_URL using git: http://hg.slitaz.org/wok/rev/e06d60ae03eb 2.107 * WGET_URL using subversion: http://hg.slitaz.org/wok/rev/c4c54646489a 2.108 * WGET_URL using mercurial: http://hg.slitaz.org/wok/rev/756ed4b1daac 2.109 * It was difficult to choose how to define BRANCH and VERSION for aufs: http://hg.slitaz.org/wok/rev/67231cfc5475 2.110 - * Here are two sources of records were in conflict, resolved by SOURCE: http://hg.slitaz.org/wok/rev/b891cba4f48e 2.111 - * slitaz-dev-tools contains the sources for SliTaz tools that contain very little code, using SOURCE="slitaz-dev-tools" in recipes that use this deposit to avoid having duplicate tarballs: http://hg.slitaz.org/wok/rev/808826645cc2 2.112 + * Here two sources of records were in conflict and resolved by SOURCE: http://hg.slitaz.org/wok/rev/b891cba4f48e 2.113 + * slitaz-dev-tools contains the sources for SliTaz tools that contain very little code. Use SOURCE="slitaz-dev-tools" in receipts that use this method to avoid having duplicate tarballs: http://hg.slitaz.org/wok/rev/808826645cc2 2.114 2.115 -==== Exceptions dependencies cooking ==== 2.116 -In some cases, no dependence cooking is installed: 2.117 - * For recipes with WANTED 2.118 - * For recipes without compile_rules() 2.119 +==== Exceptions concerning cooking dependencies ==== 2.120 +In some cases, no cooking dependencies are installed: 2.121 + * For receipts with WANTED 2.122 + * For receipts without compile_rules() 2.123 2.124 -Note that packets may be required to obtain / decompressing the source code will still be installed if they are in DEPENDS / BUILD_DEPENDS. These are wget, mercurial, subversion, git, tar and unzip. 2.125 +Note that packages may be required to obtain/decompress the source code and will still be installed if they are in DEPENDS/BUILD_DEPENDS. These are wget, mercurial, subversion, git, tar and unzip. 2.126 2.127 -If you do not compile_rules() but want to force the installation of all dependencies of cooking, there is a little hack: 2.128 +If you don't want to use compile_rules() but want to force the installation of all cooking dependencies, there's a little hack: 2.129 <file> 2.130 compiles_rules() 2.131 { 2.132 @@ -97,81 +96,80 @@ 2.133 </file> 2.134 2.135 **Examples:** 2.136 - * Removal of compiles_rules() to avoid installing unnecessary dependencies Cooking: http://hg.slitaz.org/wok/rev/f579356b437f 2.137 - * Remove a hack with fake compiles_rules was useless ... http://hg.slitaz.org/wok/rev/5b4581f8e476 2.138 + * Removal of compiles_rules() to avoid installing unnecessary cooking dependencies: http://hg.slitaz.org/wok/rev/f579356b437f 2.139 + * Removing a hack with fake compiles_rules which was useless ... http://hg.slitaz.org/wok/rev/5b4581f8e476 2.140 2.141 -==== Define src/_pkg & move in the right place (hacks in the recipe) ==== 2.142 +==== Define src/_pkg & move to the right place (hacks in the receipt) ==== 2.143 2.144 -By default, the new sources in place tazwok $WOK/$PACKAGES/$PACKAGE-$VERSION: it renames the parent directory of sources if necessary. So far, $src was not properly defined for recipes using both SOURCE and WANTED. Many recipes implement their own solution in different ways, which is difficult to consider a standardized way and can cause compatibility problems. 2.145 +By default, the new sources in tazwok are placed in $WOK/$PACKAGES/$PACKAGE-$VERSION: it renames the parent directory of sources if necessary. Up to now, $src was not properly defined for receipts using both SOURCE and WANTED. Many receipts implement their own solution in different ways, which is difficult to consider a standardized way and can cause compatibility problems. 2.146 2.147 -If tazwok detects src=/_pkg= in a recipe, it continues to use the old behavior to ensure compatibility (this produces errors in some cases). It is no longer necessary and not ideal. 2.148 +If tazwok detects src=/_pkg= in a receipt, it continues to use the old behavior to ensure compatibility (this produces errors in some cases). It is no longer necessary and not ideal. 2.149 2.150 -The hacks in the recipe source that move in the right place are no longer needed either, and can also cause problems. 2.151 +The hacks in the receipt that move the source to the right place are no longer needed either and can also cause problems. 2.152 2.153 -In conclusion, it is better to consider that $src/$_pkg are defined by default and try to rely as much as possible. 2.154 +In conclusion, it is better to consider that $src/$_pkg are defined by default and try to rely on it as much as possible. 2.155 2.156 ** Examples: ** 2.157 * Removing src= by Godane: http://hg.slitaz.org/wok/rev/a1c1d35d9f92 2.158 - * src=/_pkg= can / should also be removed from WANTED: http://hg.slitaz.org/wok/rev/07adb7cbd0c8 2.159 + * src=/_pkg= can/should also be removed from WANTED: http://hg.slitaz.org/wok/rev/07adb7cbd0c8 2.160 * Here, an old hack was the problem: http://hg.slitaz.org/wok/rev/62f6142d9fb3 2.161 * Sources are now //always// placed in a sub-directory $src http://hg.slitaz.org/wok/rev/e64069568fe7 2.162 - * Another case: call the configure script from a folder separate compilation (*-build): http://hg.slitaz.org/wok/rev/7461a0c31d62 2.163 + * Another case: call the configure script from a separate compilation folder (*-build): http://hg.slitaz.org/wok/rev/7461a0c31d62 2.164 * Fixed dmraid: http://hg.slitaz.org/wok/rev/f5b7e0c47763 http://hg.slitaz.org/wok/rev/59ea9409ad8a 2.165 2.166 ==== Set the default paths in configure: ==== 2.167 -<note tip>See /etc/slitaz/slitaz.conf, /etc/config.site and the new revenue model in place by New tazwok tree</note> 2.168 +<note tip>See /etc/slitaz/slitaz.conf, /etc/config.site and the new review model in place in the new tazwok tree</note> 2.169 2.170 -The new version of tazwok attempts to pass the default paths to configure using the environment variable CONFIG_SITE calling /etc/config.site, which works in most cases. Nevertheless configure scripts are specific to each source and sometimes CONFIG_SITE not be supported. For this reason, the best way to remove the definitions of paths is unnecessary to do so on a case by case, when the updated recipe, and make sure everything works. 2.171 +The new version of tazwok attempts to pass the default paths to configure using the environment variable CONFIG_SITE calling /etc/config.site, which works in most cases. Nevertheless configure scripts are specific to each source and sometimes CONFIG_SITE may not be supported. For this reason, it's best to remove the definitions of paths if necessary and do so on a case by case basis when updating the receipt and making sure everything works. 2.172 2.173 -In rare cases, this new product functionality problems. It happens that some recipes that did not use the default paths used by CONFIG_SITE now, and an update function genpkg_rules() is then mandatory. 2.174 +In rare cases, this produces functionality problems. It happens that some receipts did not use the default paths used by CONFIG_SITE and an update function genpkg_rules() is then mandatory. 2.175 2.176 ** Examples: ** 2.177 - * A file or did not install properly in acl is corrected by CONFIG_SITE: http://hg.slitaz.org/wok/rev/f831ecb652a6 2.178 + * A file did not install properly in acl and is corrected by CONFIG_SITE: http://hg.slitaz.org/wok/rev/f831ecb652a6 2.179 * Another example: http://hg.slitaz.org/wok/rev/259214792e30 2.180 2.181 -<note tip>CONFIG_SITE= can be used in recipes to use a different file than the default (can be useful for packages gnome or something like that ...)</note> 2.182 +<note tip>CONFIG_SITE= can be used in receipts to use a different file other than the default (can be useful for gnome packages or something like that ...)</note> 2.183 2.184 ==== DESTDIR=$PWD/_pkg ==== 2.185 2.186 -DESTDIR is passed to make install using the environment variable of the same name. The new path for installation is $ WOK/$PACKAGE/install. This will remove the source folder after packaging, it does not contain any file used by a recipe in his genpkg_rules(). 2.187 +DESTDIR is passed to make install using the environment variable of the same name. The new path for installation is $ WOK/$PACKAGE/install. This will remove the source folder after packaging, it does not contain any file used by a receipt in its genpkg_rules(). 2.188 2.189 -Most recipes still use DESTDIR=$PWD/_pkg. However, if no revenue is redefining the variables src/_pkg, automatically move to the tazwok $WOK/$PACKAGE/install. 2.190 +The majority of the receipts still use DESTDIR=$PWD/_pkg. However, if no receipt redefines the variables src/_pkg, tazwok will automatically move it to $WOK/$PACKAGE/install. 2.191 2.192 -In some cases, as with other variables, DESTDIR is not taken into account or the package is not installed by make. In these cases, the variable $DESTDIR is available to define the installation directory in the recipe. 2.193 +In some cases, as with other variables, DESTDIR is not taken into account or the package is not installed by make. In these cases, the variable $DESTDIR is available to define the installation directory in the receipt. 2.194 2.195 -In rare cases, this behavior causes incompatibilities. This happens when revenues define the path to the installation folder without using src/_pkg. The solution is not to set these paths in revenue (that calling the main recipe with WANTED included), make sure the installation is done well in $WOK/$PACKAGE/install and trust the variables provided by tazwok. 2.196 +In rare cases, this behavior causes incompatibilities. This happens when receipts define the path to the installation folder without using src/_pkg. The solution is not to set these paths in the receipt (calling the main receipt with WANTED included), make sure the installation is done well in $WOK/$PACKAGE/install and trust the variables provided by tazwok. 2.197 2.198 ** Examples: ** 2.199 - * Remove _pkg= & DESTDIR= same time for this to work: http://hg.slitaz.org/wok/rev/cf088243a4a5 2.200 - * Remove references "useless" to $src to the sources are withdrawn: http://hg.slitaz.org/wok/rev/0731792c3994 http://hg.slitaz.org/wok/rev/5d6340961543 2.201 - * Bash does not take into account DESTDIR environment variable: http://hg.slitaz.org/wok/rev/fa7b7514e1d8 2.202 - * acl attr does not include DESTDIR (in this installation the destination was still $PWD/_pkg): http://hg.slitaz.org/wok/rev/fa7b7514e1d8 2.203 + * Removing _pkg= & DESTDIR= at the same time for this to work: http://hg.slitaz.org/wok/rev/cf088243a4a5 2.204 + * Withdrawal of “useless” references to $src so that the sources are withdrawn http://hg.slitaz.org/wok/rev/0731792c3994 http://hg.slitaz.org/wok/rev/5d6340961543 2.205 + * Bash does not take into account the DESTDIR environment variable: http://hg.slitaz.org/wok/rev/fa7b7514e1d8 2.206 + * acl attr does not include DESTDIR (in this installation the destination was still $PWD/_pkg): http://hg.slitaz.org/wok/rev/fa7b7514e1d8 2.207 2.208 ==== MAKEFLAGS ==== 2.209 2.210 -MAKEFLAGS also increased to make using environment variables, and again this does not always work. In most cases, -j4 can be removed. In some cases it is necessary to use MAKEFLAGS directly to make the recipe: 2.211 -make $MAKEFLAGS 2.212 +MAKEFLAGS is also passed to make using the environment variables; once again this does not always function. In the majority of the cases, then - J 4 can be removed. In certain cases, it is necessary to pass MAKEFLAGS to make directly in the receipt: make $MAKEFLAGS 2.213 2.214 -Tazwok automatically sets the value for $MAKEFLAGS in the number of heart that contains the processor -j4 should be removed from all the recipes can be compiled on computers that have more resources (4 cores can use -j5) 2.215 +Tazwok automatically defines the value for $MAKEFLAGS according to the number of cores which the processor contains, - j4 should thus be removed from all the receipts to make it possible to compile on computers that have more resources (4 cores can use - j5) 2.216 2.217 -**Problems MAKEFLAGS:** 2.218 +**Problems with MAKEFLAGS:** 2.219 2.220 -So far, only recipes with-j4 compiled using the multi-threaded, whereas now all make and make install use. This behavior can cause errors. Some sources do not support multi-threaded compilation but do not disable. This is the most common problem associated with the changes explained here. 2.221 +So far, only receipts with-j4 were using multi-threaded compilation, whereas now all make and make install commands use it. This behavior can cause errors. Some sources do not support multi-threaded compilation but do not disable it. This is the most common problem associated with the changes explained here. 2.222 2.223 -//Problem in compiling:// 2.224 +//Problems in compiling:// 2.225 2.226 -During compilation, it happens that rely on other libraries compiled with the same sources. If they are compiled at the same time, this causes an error about a missing library. In this case, we see in the compilation text that the library in question has begun to be built few lines earlier, but that this process was not finished yet. To resolve this problem, add -j1 to make. It is the most common mistake, there are other more rare that take a similar form. 2.227 +During compilation, it happens that libraries are based on others compiled with the same sources. If they are compiled at the same time, that causes an error in connection with a missing library. In this case, one sees in the compilation text which library in question started to be compiled some lines earlier, but that this process was not yet finished. To solve this problem, just add - j1 to make. It is the most common error, but there are others that are different or rarer which take a similar form. 2.228 2.229 -//Problem in installation:// 2.230 +//Problems in installation:// 2.231 2.232 -The characteristic of this error is that the installation stops and an error message says that it is impossible to create a folder because it already exists: a parallel process is actually creating it. In this case, add-j1 to make install. 2.233 +The characteristic of this error is that the installation stops and an error message says that it is impossible to create a folder because it already exists: a parallel process is actually creating it. In this case, just add -j1 to make install. 2.234 2.235 -** Examples: ** 2.236 - * Several changes explained here in the recipe for gettext: http://hg.slitaz.org/wok/rev/9411655af0e2 2.237 +** Example: ** 2.238 + * Several changes are explained here in the receipt for gettext: http://hg.slitaz.org/wok/rev/9411655af0e2 2.239 2.240 ==== Variables $stuff, $wanted_stuff and $fs ==== 2.241 2.242 -Now the variable $stuff is available and returns the record stuff in the recipe, it uses an absolute path. The variable $wanted_stuff refers to the file defined in the package stuff WANTED, if any. The variable $fs refers to the future content of the package in taz/*/fs, as before, the difference is that now $fs uses an absolute path 2.243 +From now on, the variable $stuff is available and returns the stuff recorded in the receipt, it uses an absolute path. The variable $wanted_stuff returns to the file stuff in the package defined in WANTED, if any. The variable $fs refers to the future contents of the package in taz/*/fs, as before, the difference is that now $fs uses an absolute path. 2.244 2.245 ** Examples: ** 2.246 * A commit with several changes regarding the variable $stuff: http://hg.slitaz.org/wok/rev/be13f25e790b 2.247 @@ -179,41 +177,41 @@ 2.248 2.249 ==== Do not use 'exit' but 'return' ==== 2.250 2.251 -Now when cooking several packages with a list tazwok does not call for new tazwok cook. There is only one session tazwok so that the execution is faster. If a recipe uses exit, it leaves tazwok and following list is not cooked. 2.252 +Now when cooking several packages with a list: tazwok does not call for a new tazwok cook. There is only one tazwok session so the execution is faster. If a receipt uses exit, it leaves the tazwok session and the following list is not cooked. 2.253 2.254 **Example:** 2.255 - * Removing all exit the wok recipes: http://hg.slitaz.org/wok/rev/0b4cf0d9e1b5 2.256 + * Removing all exits from the wok receipts: http://hg.slitaz.org/wok/rev/0b4cf0d9e1b5 2.257 2.258 -==== Conclusion - What to do when updating a recipe: ==== 2.259 +==== Conclusion - What to do when updating a receipt: ==== 2.260 2.261 - * Remove src=/_pkg= recipe and those who declare as WANTED. 2.262 - * Remove DESTDIR=$PWD/_pkg and if it does not work, or if the means to define the installation directory is not + make DESTDIR, rather than using $ DESTDIR $PWD/_pkg. 2.263 + * Remove src=/_pkg= from the receipts and those which declare it as WANTED. 2.264 + * Remove DESTDIR=$PWD/_pkg; if it doesn't function, or if the means to define the repository of installation is not make+DESTDIR, use $DESTDIR rather than $PWD/_pkg. 2.265 * Remove the definition of default paths and see if it works, otherwise leave. 2.266 - * Remove-j4 and see if it works; If the mutli-threaded does not work, re-activate using $MAKEFLAGS; if multi-threading causes problems, add-j1 to the right place. 2.267 - * Remove BUILD_DEPENDS / DEPENDS redundant. 2.268 + * Remove -j4 and see if it works; If multi-threaded does not work, re-activate it using $MAKEFLAGS; if multi-threading causes problems, add -j1 to the right place. 2.269 + * Remove the redundant BUILD_DEPENDS / DEPENDS. 2.270 * Check that packages are created correctly, otherwise update the paths in genpkg_rules(). 2.271 - * Try to declare all sources of revenue in that SliTaz can be compiled without internet connection (requires to download any source before). 2.272 - * Check that the package needed to download / extract the source code are defined in BUILD_DEPENDS. 2.273 - * Check as EXIT is not used in the recipe. 2.274 + * Try to declare all sources in the receipt so that SliTaz can be compiled without an internet connection (requires downloading any sources beforehand). 2.275 + * Check that the packages needed to download/extract the source code are defined in BUILD_DEPENDS. 2.276 + * Check that EXIT is not used in the receipt. 2.277 2.278 ==== Some more complex cases ... ==== 2.279 2.280 -I put them there in the end because there are already too many to be integrated:) 2.281 +I put these at the end because there are already too many to be integrated:) 2.282 The items below correspond to specific cases. 2.283 2.284 == Variable COOK_OPT == 2.285 2.286 -This new variable can contain options that alter the behavior of tazwok. They are useful in very special cases. 2.287 +This new variable contains options that alter the behavior of tazwok. These are useful in very special cases. 2.288 2.289 **genpkg=** 2.290 2.291 -In the recipe PACKAGE defines a priority order for the revenue package containing WANTED="PACKAGES" (and only them!). If you include multiple packages, separate them with double points ':'. If packets are not defined in this option, they will be packaged later, in alphabetical order (default) 2.292 +In the receipt, PACKAGE defines a set of priorities to pack up the receipts which contain WANTED= “PACKAGES" (and only them!). If you include multiple packages, separate them with double points ':'. If packages are not defined in this option, they will be packaged later, in alphabetical order (default) 2.293 2.294 Used in glibc: http://hg.slitaz.org/wok/file/tip/glibc/receipt 2.295 2.296 **!repack_src** 2.297 2.298 -Disable re-compression format sources .tar.lzma. 2.299 +Disables re-compressing sources format .tar.lzma. 2.300 2.301 Ruby-pkgconfig used for the sources remain in gem: http://hg.slitaz.org/wok/file/tip/ruby-pkgconfig/receipt 2.302 2.303 @@ -227,11 +225,11 @@ 2.304 2.305 ==== Cooking the toolchain ==== 2.306 2.307 -To cook the toolchain SliTaz, we use a temporary toolchain. Some recipes use specific rules in this step. When cooking this toolchain temporarily affected software packaged but are not directly installed in the chroot purpose built. The affected packages are listed in the variable SLITAZ_TOOLCHAIN configuration file /etc/slitaz/slitaz.conf 2.308 +To cook the SliTaz toolchain, we use a temporary toolchain. Some receipts use specific rules in this step. During the cooking of this temporary toolchain, the software concerned is not packed up but installed directly in the chroot built for this purpose. The packages concerned are listed in the variable SLITAZ_TOOLCHAIN in the configuration file /etc/slitaz/slitaz.conf 2.309 2.310 Additional features are: 2.311 * Precook_tmp_toolchain() - Used only by gcc & binutils for the moment, because they are cooked twice during the preparation of the temporary toolchain. 2.312 - * Cook_tmp_toolchain() - Used by the most packets SLITAZ_TOOLCHAIN to define how they should be compiled for the temporary toolchain. When cook_tmp_toolchain() is absent, compile_rules() is used instead. This avoids writing two identical functions. Note that in this case. ./configure does not set the default paths in the recipe, because the temporary toolchain must be able to do it via the environment variable CONFIG_SITE. Indeed, packets compiled during this stage are not installed in the usual place but in /tools. 2.313 + * Cook_tmp_toolchain() - Used mostly by SLITAZ_TOOLCHAIN packages to define how they should be compiled for the temporary toolchain. When cook_tmp_toolchain() is absent, compile_rules() is used instead. This avoids writing two identical functions. Note that in this case. ./configure does not set the default paths in the receipt, because the temporary toolchain must be able to do it via the environment variable CONFIG_SITE. Indeed, packages compiled during this stage are not installed in the usual place but in /tools. 2.314 2.315 ** Examples: ** 2.316 * Binutils: http://hg.slitaz.org/wok/file/tip/binutils/receipt 2.317 @@ -240,31 +238,31 @@ 2.318 * Patch does not need cook_tmp_toolchain(): http://hg.slitaz.org/wok/file/tip/patch/receipt 2.319 * Autoconf either: http://hg.slitaz.org/wok/file/tip/autoconf/receipt 2.320 2.321 -== tazwok get-src / report in recipes == 2.322 +== tazwok get-src / report in receipt == 2.323 2.324 -Report is a module libtaz for organizing the display commands in the terminal and create logs available including http://bb.slitaz.org interface. It can be used in recipes, as follows (that is abstract, the following examples of actual application): 2.325 +Report is a libtaz module for organizing the display commands in the terminal and making logs available including the http://bb.slitaz.org interface. It can also be used in receipts, as follows (this is abstract, examples of actual applications follow): 2.326 2.327 <file> 2.328 -compile_rules() # Per example 2.329 +compile_rules() # For example 2.330 { 2.331 - report open-bloc #compiles_rules is a step, declaring that there will substeps 2.332 - report step "Action machin" 2.333 + report open-bloc # compiles_rules is a step, declaring that there will substeps 2.334 + report step "Action machine" 2.335 ... 2.336 - report step "Action truc" 2.337 + report step "Action true" 2.338 .. 2.339 - report close-bloc #Close the open block previously 2.340 + report close-bloc # Close the previously open block 2.341 } 2.342 </file> 2.343 2.344 -Specifically, there is one case where we use it: when using get-src tazwok PACKAGE --target=... . This command creates a new step (postponement step). We need to open a block before and after the close, as well as adding several other deferral step "..." to log and display in the terminal is correct. Each farm deferral step the previous step, if we do not open the block, get-src shut tazwok step "Executing compiles rules" 2.345 +Specifically, there is one case where we use it: when using get-src tazwok PACKAGE --target=... . This command creates a new step (postponement step). We need to open a block and close it afterwards, as well as adding several other deferral steps "..." so the log and display in the terminal is correct. Each step defers the previous step, if we do not open a block, tazwok get-src would close the stage “Executing compiles rules” 2.346 2.347 -Delaying closed block must be completely executed, otherwise the log/display will be broken. That's why we use { report-block closed; return 1; } return rather than alone. 2.348 +Note that report close-bloc must be completely executed, otherwise the log/display will be broken. That's why we use { report-block closed; return 1; } rather than return nothing at all. 2.349 2.350 -The practical use of this tazwok get-src is that you can unpack the sources of designated PACKAGE at target. 2.351 +The practical use of this get-src in tazwok is that you can unpack the sources of a designated PACKAGE at target. 2.352 2.353 -In the examples below, observe the correlation between the delay step and displayed in the log. Observe also the correlation between tazwok get-src and the message "Checking for source tarball ..." in the log. You learn how to carry report open-bloc/closed block create a subset in genpkg_rules (named "Executing compile_rules" in the log). If it were not for open-bloc/close-bloc, the new steps would be posted to the result of "Executing compile_rules" This is not what we wanted. 2.354 +In the examples below, observe the correlation between the delay step and that displayed in the log. Observe also the correlation between tazwok get-src and the message "Checking for source tarball ..." in the log. You learn how the report open-bloc/closed block creates a subset in genpkg_rules (named "Executing compile_rules" in the log). If it were not for this open-bloc/close-bloc, these new steps would be posted to the result of "Executing compile_rules" This is not what we wanted. 2.355 2.356 -** Examples (recipe + log): ** 2.357 - * Linux needs patches contained in the sources of aufs, Godane took the opportunity to improve the log. Recipe: http://hg.slitaz.org/wok/file/tip/linux/receipt; log: http://bb.slitaz.org/log.php?version=cooking&package=linux 2.358 - * Gcc uses several other sources of packages during the cooking of the temporary toolchain. Recipe: http://hg.slitaz.org/wok/file/tip/gcc/receipt; log: http://bb.slitaz.org/log.php?version=cooking&package=tmp-toolchain-gcc 2.359 - * mingw32-gcc was corrected using this approach, it also allowed to declare all sources used. Commit: http://hg.slitaz.org/wok/rev/fd43246b4613; log: http://bb.slitaz.org/log.php?version=cooking&package=mingw32-gcc 2.360 \ No newline at end of file 2.361 +** Examples (receipt + log): ** 2.362 + * Linux needs patches contained in the sources of aufs, Godane took the opportunity to improve the log. Receipt: http://hg.slitaz.org/wok/file/tip/linux/receipt; log: http://bb.slitaz.org/log.php?version=cooking&package=linux 2.363 + * Gcc uses several other sources of packages during the cooking of the temporary toolchain. Receipt: http://hg.slitaz.org/wok/file/tip/gcc/receipt; log: http://bb.slitaz.org/log.php?version=cooking&package=tmp-toolchain-gcc 2.364 + * mingw32-gcc was corrected using this approach, it also allowed us to declare all sources used. Commit: http://hg.slitaz.org/wok/rev/fd43246b4613; log: http://bb.slitaz.org/log.php?version=cooking&package=mingw32-gcc 2.365 \ No newline at end of file
3.1 --- a/pages/en/guides/conspy.txt Mon Feb 28 08:27:54 2011 +0000 3.2 +++ b/pages/en/guides/conspy.txt Fri Mar 11 14:19:17 2011 +0000 3.3 @@ -80,7 +80,7 @@ 3.4 3.5 ===== Conspy and slow connections ===== 3.6 3.7 -Launch a very verbose command into a conspy and the output is displayed at full speed in the virtual console what ever your connection speed to the remote box is, even if your connection is broken. 3.8 +Launch a very verbose command into a conspy and the output is displayed at full speed in the virtual console whatever your connection speed to the remote box is (even if your connection is broken). 3.9 ===== Conspy and Busybox ===== 3.10 3.11 Conspy is a busybox applet since busybox 1.17.0. It adds 2.5Kb to busybox, has better terminal support and supports some new options:
4.1 --- a/pages/en/guides/uncommoninst.txt Mon Feb 28 08:27:54 2011 +0000 4.2 +++ b/pages/en/guides/uncommoninst.txt Fri Mar 11 14:19:17 2011 +0000 4.3 @@ -58,7 +58,7 @@ 4.4 4.5 Copy files from the rootfs.gz archive of a cdrom into the loopfile: 4.6 # mount /dev/cdrom /media/cdrom 4.7 - # mount -o loop,ro slitaz.fs /media 4.8 + # mount -o loop,rw slitaz.fs /mnt 4.9 # unlzma -c /media/cdrom/boot/rootfs.gz | ( cd /mnt; cpio -idmu ) 4.10 # umount -d /mnt 4.11 # umount /media/cdrom
5.1 --- a/pages/pt/guides/pclistaz.txt Mon Feb 28 08:27:54 2011 +0000 5.2 +++ b/pages/pt/guides/pclistaz.txt Fri Mar 11 14:19:17 2011 +0000 5.3 @@ -52,6 +52,20 @@ 5.4 ^ Desempenho | Bom desempenho, inclusive aceleração gráfica usando o driver SiS do Xorg. Fica lento com Firefox, por isso uso o Midori.| 5.5 ^ Problemas | Nenhum relacionado à distribuição, alguma lentidão ocorre devido ao hardware obsoleto.| 5.6 5.7 +^ Configuração 00000000003 ^^ 5.8 +^ Configuração PC | IBM ThinkPad T41, Pentium M 1700MHz, 1033Mb Ram, Video ATI 7500. | 5.9 +^ Versão do SliTaz | 2.0 | 5.10 +^ Tempo de instalação | 10 minutos | 5.11 +^ Desempenho | Muito bom, com Firefox, aMsn, CUPS (problemas com impressora samsung ML-1710), e todos os programas que fazem falta no dia a dia.| 5.12 +^ Problemas | O unico problema encontrado foi com a versão 3.0 que não se conseguia trabalhar com o rato do proprio portatil, a versão 2.0 para min é a mais estavel.| 5.13 + 5.14 +^ Configuração 00000000004 ^^ 5.15 +^ Configuração PC | AMD Duron 1500, 512Mb Ram, video NVIDIA GeForce2 MX/MX 400, rede SIS 900.| 5.16 +^ Versão do SliTaz | 3.0 | 5.17 +^ Tempo de instalação | 2 horas | 5.18 +^ Desempenho | Servidor SSH-Dropbear, Pure-FTP, MySql, PHP5, lighttpd, DynDNS e CUPS, tudo serviços que estão nos pacotes do slitaz.| 5.19 +^ Problemas | Algum tempo a configurar o Slitaz a mão como eu gosto de fazer, para aprender.| 5.20 + 5.21 \\ 5.22 * Edição : //Copie o código da tabela acima e essa frase e cole abaixo, e adicione suas novas informações, apague essa frase. Preserve este texto para o próximo usuário e assim sucessivamente. Seja ético, preserve o trabalho anterior. Grato !// 5.23