Development

SliTaz Developers corner

SliTaz is an open source and community driven distribution. Everyone is welcome to join and contribute, from users, to hackers and developers, there is always something to do, ie. Proofreading or writing documentation, sending bugs or patches to the Mailing list, gaining access to the wok and pushing some new packages or simply to help others on the Mailing list or forum. SliTaz has got Mercurial repositories hosted on a SliTaz system, developers can ask for a new repo if needed and contributors have write access to correct typos, scripts, etc.

SliTaz is a tiny community and listens to its users. There are several developers who are active on the forum and the Mailing List.

For artists there is a dedicated website, simply create an account and post your graphics or pictures. The site is managed by the community. If you want to lend a hand to administer the site, please contact a contributor or e-mail the discussion list. The website art.slitaz.org: SliTaz Community Art

KISS and comply to standards

Keep it simple: follow the best standards, carefully draft and write high quality documentation, provide a stable and robust system and keep the rootfs on the LiveCD light enough to run on machines with at least 128 MB RAM. It's also possible to use GTK+2, Dialog, SHell scripts, or PHP coding tools on the distribution. The idea is not to duplicate and to think small...

Tank - Build host & home

Each contributor may have an account on the project server with secure access, disk space, a public directory and all development tools. Developers can compile packages and maintainers of the mirror can handle sychronization. Tank also hosts the website, web boot and mercurial repositories: tank.slitaz.org

Instructions on using the build host are described in the Cookbook: SliTaz Build Host (tank).

Mercurial repositories

SliTaz Mercurial or Hg repos can be browsed or cloned by anyone using the URL: http://hg.slitaz.org/. People with write access can directly use repos.slitaz.org which requires authentication. Mercurial uses Python and is installable with: tazpkg get-install mercurial

~/.hgrc

Before you push your first commit onto the server, be sure that you have a correct Hg configuration file with your name and email address, and remember to check that you are not root. Personal ~/.hgrc file example:

[ui]
username = FirstName LastName <you@example.org>

Clone, modify, commit and push

Clone a repo, example for wok:

 $ hg clone http://repos.slitaz.org/wok

Change directory to wok, note you must be in the repository to be able to use 'hg' commands. To check all logs or just the last log:

 $ hg log
 $ hg head

Add or modify one or more files and commit:

 $ hg add
 $ hg status
 $ hg commit -m "Log message..."
 $ hg log

Note that you can use the command rollback to roll back to the last transaction. Before pushing changes to the server, it is safe to pull once:

 $ hg pull
 $ hg push

Done, your changes, code or corrections are now on the server.

Updating a local wok

To update your wok with the local server (pull to pull the changes):

 $ hg pull
 $ hg update

Useful commands

Hg commands that can be used.

Implementation of iconv()

SliTaz uses iconv() provided by GNU glibc - any packages that offer libiconv must use the library contained in glibc-locale. There is therefore no longer a libiconv package (1.2 MB) in SliTaz.

Tazpkg Packages

The tazpkg packages in SliTaz are automatically created via Tazwok and a receipt in the wok. The Cookbook describes the use of tools and the format of receipts. These are required reading before we begin.

In terms of choice of package, the idea is to offer a package by task or functionality, ie. the lightest application in the field and not duplicated. Note that the current packages are not immutable, if you find an alternative that is lighter, with more features or more sexy for a few extra KB, you can suggest it on the Mailing List. Particular attention is given to packages for the LiveCD, these should be stripped, removing unnecesary dependancies and compiler options. In general candidate packages for the core LiveCD are discussed on the Mailing List.

Before you begin to compile and create packages for SliTaz, be sure that the work doesn't already exist in the undigest wok provided by the primary SliTaz mirror. Don't forget that the members of the list are there to help you and that the documentation of the wok and tools exists to help you get started.

Naming of packages

In most cases the package name is the same as the source, except for Python, Perl, PHP, Ruby and Lua modules. For example, the package providing a Kid template system written in Python and XML is named: python-kid.

Website Management and Books

The website and books (Handbook and Cookbook) are managed via a mercurial repository, they can be cloned by:

 $ hg clone http://hg.slitaz.org/website
  Or if you have the proper permissions:
 $ hg clone http://repos.slitaz.org/website

xHTML coding style

The pages and different books are coded in xHTML 1.0 transitional. The colors for the body and the titles are placed directly on the page so the links are easy to follow. The title of level 1 is used only once (at the top), level 2 is the title of the document and levels 3 and 4 are then used for the subtitles. If a list is used instead using smart anchors; then that starts at the top, just after the title of level 2. Paragraphs are contained in the tags <p></p>. For indentation, we use tabs - the reason being semantics and to take up less space in terms of octets (bytes). To put code, like the name of a command inside a paragraph: <code> is the preferred method. To view commands or to utilize a terminal, the web pages use <pre> to display the formatted text. Example:

 $ command

To view text that can be copied and pasted, such as scripts, bits of code, sample configuration files, etc - we also use <pre>, but with a CSS class named "script". Example:

<pre class="script">

code...

</pre>

The emphasized words put themselves in the tag <em> and internal links are relative. Remember to check the validity of the code via the online validator of the W3C.

Diff and patch

The utilities diff and patch are command-line tools for creating and implementing a file containing differences between two files. This technique is often used for collaboration and the changes made to the original file can be clearly extracted. To create a diff file readable by humans in a simple text editor, you must supply the -u option:

 $ diff -u file.orig file.new > file.diff

To apply a patch:

 $ patch file.orig file.diff

Last modification : 2009-06-13 21:15:00 - Top of the page

Copyright © 2009 SliTaz - GNU General Public License

Valid XHTML 1.0