Collaborative 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.

With OpenSSH, 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

With dropbear, the default ssh on SliTaz, there is nothing to configure: it does not read ~/.ssh/config, it uses ~/.ssh/id_dropbear by itself, and your login is given in the URL (ssh://yourlogin@hg.slitaz.org/...).

Mercurial repositories

SliTaz Mercurial (Hg) repositories can be browsed and cloned by anyone at https://hg.slitaz.org/. Mercurial is installed with: tazpkg get-install mercurial

Since 2026 write access is SSH only: the old push over HTTPS with a password no longer works. To push you need a developer account and your SSH key (see SSH key & developer account). The SSH URL of a repository is: 

ssh://yourlogin@hg.slitaz.org//home/slitaz/repos/<repo>

Replace yourlogin with your account name and <repo> with the repository name (wok, website, cookutils...). Note the double slash after the host name: the path on the server is absolute.

~/.hgrc

Before your first commit, set your name and email address in your personal ~/.hgrc, and never work as root: 

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

New clone: pull over HTTPS, push over SSH

This is the setup of the core developers: pulls stay fast and anonymous over HTTPS, pushes go over SSH with your key. Clone, example for the wok: 

 $ hg clone https://hg.slitaz.org/wok

Then open wok/.hg/hgrc in a text editor and add the default-push line under [paths]: 

[paths]
default = https://hg.slitaz.org/wok
default-push = ssh://yourlogin@hg.slitaz.org//home/slitaz/repos/wok

Or clone directly over SSH: pulls and pushes then both go over SSH and there is nothing to add: 

 $ hg clone ssh://yourlogin@hg.slitaz.org//home/slitaz/repos/wok

Existing clone: switch the push to SSH

A clone made before the move to SSH does not need to be cloned again. Open its .hg/hgrc in a text editor:

Also remove from your ~/.hgrc any [auth] section or password written for hg.slitaz.org: they are no longer used.

Check before the first push

 $ hg paths
 $ hg outgoing

hg paths shows the pull URL (default) and the push URL (default-push). hg outgoing connects over SSH and lists the commits that would be pushed, without pushing anything. On the first connection SSH asks you to confirm the server key: answer yes. If the server refuses your key, your account or key is not set up yet: see SSH key & developer account.

Optional: the schemes shortcut

The schemes extension ships with Mercurial and shortens the SSH URL. Add to your ~/.hgrc: 

[extensions]
schemes =

[schemes]
slitaz = ssh://yourlogin@hg.slitaz.org//home/slitaz/repos/

slitaz://wok then stands for the full SSH URL of the wok. When cloning, always give the destination directory: without it Mercurial stops with "empty destination path is not valid". 

 $ hg clone slitaz://wok wok

Such a clone records slitaz://wok/ as its URL and needs the extension to keep working. In an HTTPS clone, default-push = slitaz://wok works too.

Modify, commit and push

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 log -l 1

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 undo your last local commit, as long as it is not pushed. Before pushing, always pull: 

 $ hg pull
 $ hg push

If someone pushed in the meantime, the pull says "run 'hg merge' to merge" and a push without merging stops with "push creates new remote head". Merge, commit the merge, then push: 

 $ hg merge
 $ hg commit -m "Merge"
 $ 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 -u

Useful commands

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, by 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

To push, add default-push = ssh://yourlogin@hg.slitaz.org//home/slitaz/repos/website under [paths] in website/.hg/hgrc, as for the wok (see Mercurial repositories).

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