Collaborative management
- KISS and comply to standards.
- Build host & mirror.
- SSH key & developer account.
- Mercurial repositories.
- GUI in GTK and CGI/web
- Implementation of iconv().
- Building SliTaz packages.
- Website Management.
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...
Marmite - Build host & mirror
Each contributor may have an account on the project server with secure SSH access (public key only, no password). Marmite is the SliTaz build host and hosts the official package mirror: mirror.slitaz.org — status page on marmite.slitaz.org. It replaces the historical Tank server since 2026.
SSH key & developer account
Accounts are created by an admin from your public SSH key. Generate a modern ed25519 key pair on your machine:
$ ssh-keygen -t ed25519 -C "you@your-machine" $ cat ~/.ssh/id_ed25519.pub
On SliTaz (dropbear) use:
$ dropbearkey -t ed25519 -f ~/.ssh/id_dropbear $ dropbearkey -y -f ~/.ssh/id_dropbear | grep ^ssh-ed25519
Send the single ssh-ed25519 AAAA… line to an admin or to the
developers group (mailing list or forum) — the public key is safe to share,
the private key never leaves your machine. Once your
account exists, add this to your ~/.ssh/config — the servers
ban clients whose SSH agent offers too many keys in a row:
Host hg.slitaz.org marmite.slitaz.org
User yourlogin
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yes
Mercurial repositories
SliTaz Mercurial or Hg repos can be browsed or cloned by anyone using
the URL: https://hg.slitaz.org/.
Write access is SSH only: developers get a personal
account on the project server (SSH public key, no password) created by
an admin — ask on the mailing list or forum. Pushes then go through
ssh://login@hg.slitaz.org//home/slitaz/repos/<repo>.
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.com>
Clone, modify, commit and push
Clone a repo, example for wok (developers should clone through SSH so they can push back directly):
$ hg clone https://hg.slitaz.org/wok Or with write access: $ hg clone ssh://login@hg.slitaz.org//home/slitaz/repos/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
If you cloned over HTTPS, push with the SSH URL:
$ hg push ssh://login@hg.slitaz.org//home/slitaz/repos/wok
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 -u
Useful commands
hg help: Display the full list of commands.hg rollback: Undo the last action performed (commit, pull, push).hg log <package>: Display a package log.hg head: Display the last log.
GUI - Pure C/GTK, Yad, Vala/Genie and CGI/web
There are many ways to create user interfaces in the open source world. From the start of the project until 3.0 we mainly used a tool called Gtkdialog which let us create quite nice and complex interfaces in GTK, but using a scripting language that just ran without having to be compiled. But gtkdialog is unmaintained and lacks many new GTK features, so we switched to Yad for simple GUI boxes. For all the administration, packages and configuration tools we switched to TazPanel, a CGI/web interface with a gui coded in HTML5 and CSS3.
Yad scripts should follow TazYad guidelines: README and example code
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.
Building SliTaz packages
Officially building is done with the Cookutils suite. This package is installed on each SliTaz system as well as documentation about using cook and creating SliTaz packages suitable for the TazPKG packages manager.
The tazpkg packages in SliTaz are automatically created via the Cooker from the Cookutils package and a receipt in the wok. The Cookbook describes the format of receipts. Cookutils and receipt documentation 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.
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
The website is managed via a Mercurial repository, this can be cloned by:
$ hg clone https://hg.slitaz.org/website Or if you have write access: $ hg clone ssh://login@hg.slitaz.org//home/slitaz/repos/website
Coding style
Pages are coded in HTML5 with tabs for indentation. 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 subtitles. Paragraphs are contained in
<p></p> tags. To put code inside a paragraph use
<code>. To display commands or terminal output use
<pre>. Internal links are relative.
Diff and patch
The utilities diff and patch are command-line tools
for creating and implementing a file containing differences between two files.
To create a diff file readable by humans in a simple text editor,
supply the -u option:
$ diff -u file.orig file.new > file.diff
To apply a patch:
$ patch file.orig file.diff