Espaço dos Desenvolvedores do SliTaz

KISS e respeito aos padrões

"Keep it Simple", ou seja, tentamos manter as coisas simples: respeito aos padrões, planejamento cuidadoso e documentação escrita de alta qualidade, fornecimento de um sistema robusto e estável e um sistema de arquivos (rootfs) no LiveCD leve o suficiente para ser executado em máquinas que tenham ao menos 128 mb de memória RAM. Também usamos aplicativos baseados em GTK+2, Dialog, scripts SHell ou PHP. A idéia é não nos repetirmos e deixar o sistema básico leve e pequeno.

Marmite - Build host & mirror

Cada participante do projeto pode obter uma conta no servidor do projeto, com acesso SSH seguro (somente chave pública, sem senha). O Marmite é o build host do SliTaz e hospeda o mirror oficial dos pacotes: mirror.slitaz.org, com a página de estado em marmite.slitaz.org. Ele substitui desde 2026 o antigo servidor Tank.

Repositórios Mercurial

Os repositórios Mercurial (Hg) do SliTaz podem ser navegados e clonados por qualquer um em https://hg.slitaz.org/. O Mercurial é instalado com: tazpkg get-install mercurial

Desde 2026 o acesso de escrita é somente por SSH: o antigo push por HTTPS com senha não funciona mais. Para enviar (push) você precisa de uma conta de desenvolvedor e da sua chave SSH (veja abaixo). A URL SSH de um repositório é: 

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

Substitua seulogin pelo nome da sua conta e <repo> pelo nome do repositório (wok, website, cookutils...). Atenção à barra dupla depois do nome do servidor: o caminho no servidor é absoluto.

Chave SSH e conta de desenvolvedor

As contas são criadas por um administrador a partir da sua chave SSH pública. Gere um par de chaves ed25519 na sua máquina: 

 $ ssh-keygen -t ed25519 -C "voce@sua-maquina"
 $ cat ~/.ssh/id_ed25519.pub

No SliTaz (dropbear): 

 $ dropbearkey -t ed25519 -f ~/.ssh/id_dropbear
 $ dropbearkey -y -f ~/.ssh/id_dropbear | grep ^ssh-ed25519

Envie a linha ssh-ed25519 AAAA… para um administrador ou para o grupo de desenvolvedores (lista de discussão ou fórum). A chave pública pode ser compartilhada sem risco, a chave privada nunca sai da sua máquina.

Com o OpenSSH, depois que a conta existir, adicione isto ao seu ~/.ssh/config: os servidores banem clientes cujo agente SSH oferece chaves demais em sequência. 

Host hg.slitaz.org marmite.slitaz.org
    User seulogin
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Com o dropbear, o ssh padrão do SliTaz, não há nada a configurar: ele não lê o ~/.ssh/config, usa sozinho a chave ~/.ssh/id_dropbear, e o seu login vai na URL (ssh://seulogin@hg.slitaz.org/...).

~/.hgrc

Antes do seu primeiro commit, coloque o seu nome e endereço de e-mail no seu ~/.hgrc pessoal, e nunca trabalhe como root: 

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

Novo clone: pull por HTTPS, push por SSH

Esta é a configuração dos desenvolvedores do projeto: o pull continua rápido e anônimo por HTTPS, o push passa por SSH com a sua chave. Para clonar, por exemplo o wok: 

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

Depois abra wok/.hg/hgrc num editor de texto e adicione a linha default-push abaixo de [paths]: 

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

Ou clone diretamente por SSH: pull e push passam então os dois por SSH e não há nada a adicionar: 

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

Clone existente: passar o push para SSH

Um clone feito antes da mudança para SSH não precisa ser refeito. Abra o seu .hg/hgrc num editor de texto:

Remova também do seu ~/.hgrc qualquer seção [auth] ou senha escrita para hg.slitaz.org: elas não são mais usadas.

Verificar antes do primeiro push

 $ hg paths
 $ hg outgoing

hg paths mostra a URL de pull (default) e a de push (default-push). hg outgoing conecta por SSH e lista os commits que seriam enviados, sem enviar nada. Na primeira conexão o SSH pede para confirmar a chave do servidor: responda sim (yes). Se o servidor recusar a sua chave, a sua conta ou chave ainda não está pronta: veja Chave SSH e conta de desenvolvedor.

Opcional: o atalho schemes

A extensão schemes vem com o Mercurial e encurta a URL SSH. Adicione ao seu ~/.hgrc: 

[extensions]
schemes =

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

slitaz://wok passa então a valer pela URL SSH completa do wok. Ao clonar, indique sempre o diretório de destino: sem ele o Mercurial para com "empty destination path is not valid". 

 $ hg clone slitaz://wok wok

Um clone assim grava slitaz://wok/ como URL e precisa da extensão para continuar funcionando. Num clone HTTPS, default-push = slitaz://wok também funciona.

Modificar, fazer commit e enviar

Mude de diretório para o wok, note que você deve estar no repositório para poder utilizar os comandos "hg". Para ver todos os logs ou somente o último: 

 $ hg log
 $ hg log -l 1

Modifique um ou mais arquivos e faça o commit: 

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

Note que você pode usar o comando rollback para desfazer o seu último commit local, enquanto ele não for enviado. Antes de enviar (push), sempre faça o pull: 

 $ hg pull
 $ hg push

Se alguém enviou algo nesse meio tempo, o pull mostra "run 'hg merge' to merge" e um push sem merge para com "push creates new remote head". Faça o merge, o commit do merge, e depois o push: 

 $ hg merge
 $ hg commit -m "Merge"
 $ hg push

Está feito, suas mudanças, código ou correções estão agora no servidor.

Atualizar um wok local

 $ hg pull -u

Comandos úteis

Interface Gráfica - C/GTK, Yad, Vala/Genie e WEB/GCI

Há várias maneiras de criar interfáces gráficas para o usuário para a distribuição. No início do projeto até a versão 3.0, usamos principalmente o GTKDialog, o que nos permitia criar interfaces razoavelmente complexas em GTK, ao mesmo tempo que pudemos usar uma linguagem de script que era executada sem a necessidade de ser compilada. Porém, o GTKDialog não é mais mantido pelos desenvolvedores, e está desatualizado, então tivemos que mudar para o Yad para criar algumas caixas de diálogo simples. Para todos as ferramentas de administração, pacotes e configuração próprias da distribuição, agora usamos o TazPanel, que é uma interface WEB/CGI escrita em xHTML5 e CSS3.

O Yad é simples, porém não nos permite criar interfaces muito complexas, então outra maneira teve de ser abordada. A vantagem de uma linguagem de script é o fato de não precisar ser compilada e ser codificada em tempo real, porém isso significa em programas que rodam com um pouco menos de performance. Escrever programas na Linguagem C é complexo e atrai menos desenvolvedores, porque linguagens de script são mais atrativas para aqueles que desejam contribuir, tal como o SHell Script, que é fácil de compreender e manter. Deste modo, com uma linguagem de programação script uma interface WEB/CGI ou em GTK, podemos manter nossas linhas mestras e atrair desenvolvedores.

Há muitas linguagens que usam GTK, como Genie, Vala ou GTKaml. Mas é preciso manter em mente que elas não são tão populares quanto o C ou GTK e não são tão fáceis de aprender e usar (para interfaces simples, melhor é utilizar scripts SHell para tarefas corriqueiras). Pode-se usar o Vala, porém note o seguinte exemplo, que é o código necessário para criar uma simples caixa de diálogo, e possui 14 linhas de código: 

#include <gtk/gtk.h>;
int main(int argc, char *argv[])
{
    GtkWidget *window;

    gtk_init(&argc, &argv);
    window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
    g_signal_connect (G_OBJETCT (window), "destroy",
            G_CALLBACK (gtk_main_quit), NULL);

    gtk_widget_show(window);
    gtk_main();
    return 0;'
}

Caso queira contribuir, e não está certo qual linguagem usar, mande uma mensagem para a lista de discussão. Para pequenas interface gráficas, utilize o TazBox como exemplo, que pode ser encontrado no repositório slitaz-tools, que também possui pequenas interfaces gráficas, como a responsável pelo logout do usuário. O primeiro utilitário do SliTaz a ser escrito em Linguagem C pura, com GTK, é o TazWeb, e ele pode ser utilizado como exemplo na utilização da função system() para incluir comandos do sistema em uma interface. Esta ferramente utiliza wget para downloads e sed para adicionar favoritos.

Scripts em Yad devem seguir as linhas mestras de codificação para a distribuição: README e o código de exemplo.

Implementação da função iconv()

O SliTaz utiliza a função iconv() fornecida pela biblioteca glibc do projeto GNU - alguns pacotes que necessitam da função libiconv devem usar a versão fornecida pela glibc (glibc-locale). Note que já não há mais um pacote libiconv (1.2 MB) no SliTaz.

Pacotes Tazpkg

Os pacotes tazpkg no SliTaz são automaticamente criados via o robô de compilação e receitas no wok. O Livro de Receitas descreve o uso das ferramentas e o formato das receitas. Informações sobre o comando cook e sobre criação de arquivos receipt são necessários para a criação de pacotes.

Em termos de escolha de pacote, a idéia é oferecer o pacote por tarefa ou funcionalidade, isto é, a mais leve aplicação em seu campo e sem duplicações. Note que a atual seleção de pacotes não é imutável, se você souber de uma alternativa mais leve, com mais funcionalidades ou mais sexy por apenas alguns KB a mais, sugira na lista de discussão. Atenção redobrada é prestada aos pacotes do LiveCD: eles devem ser "limpos", removendo-se dependências desnecessárias e opções do compilador. Em geral os pacotes candidatos a fazer parte do LiveCD são discutidos na lista.

Antes de você começar a compilar e a criar pacotes para o SliTaz, certifique-se que o trabalho ainda não existe na relação do wok disponível no mirror principal do SliTaz. Não se esqueça que os membros da lista podem te ajudar e que a documentação do wok e ferramentas existe para te guiar nos primeiros passos.

Nomes de Pacotes

Na maioria dos casos o nome do pacote é o mesmo do código fonte, exceto para os módulos das linguagens Python, Perl, PHP, Ruby e Lua. Por exemplo, o pacote que fornece o sistema de templates Kid, escrito em Python e XML, é nomeado: python-kid.

Gerenciamento do website e manuais

O website e os manuais (Manual do SliTaz, Livro de Receitas) são gerenciados pelo repositório mercurial, podendo ser clonados da seguinte maneira: 

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

Para enviar, adicione default-push = ssh://seulogin@hg.slitaz.org//home/slitaz/repos/website abaixo de [paths] em website/.hg/hgrc, como para o wok (veja Repositórios Mercurial).

Estilo para codificação de xHTML

As páginas nos diferentes manuais são codificadas em xHTML 1.0 transitional. As cores para o corpo da página (body) e para os títulos são definidas diretamente de forma a permitir que os links sejam facilmente identificáveis. Os títulos de primeiro nível são usados apenas uma vez, no topo da página, os de segundo nível são usados para nomear as seções e os de terceiro e quarto nível para as subseções. Se uma lista é usada para os tópicos, usando âncoras para as diferentes seções, é posta logo no início da página, após o título da mesma. Parágrafos são colocados dentro das tags <p></p>. Para indentação, usa-se tabulações (tabs), de forma a manter-se a semântica e para diminuir espaço em termos de octetos (bytes). Para mostrar trechos de código, como o nome de um comando dentro de um parágrafo, <code> é o método recomendado. Para mostrar a saida de comandos ou comandos a serem digitados em um terminal, usa-se <pre>. Exemplo: 

 $ comando

Para mostrar texto que pode ser copiado e colado, como scripts, peças de código, arquivos de configuração, etc, também se usa a tag <pre>, em conjunto com a classe CSS chamada "script". Exemplo: 

<pre class="script">

code...

</pre>

Texto enfatizado é colocado dentro da tag <em> e links internos são relativos. É recomendável checar a validade do código xHTML por meio do validador online da W3C.

Diff e patch

As utilidades diff e patch são ferramentas de linha de comando para criação e implementação de diferenças entre dois arquivos. Esta técnica é freqüentemente usada para colaboração e as mudanças feitas no arquivo original podem ser extraídas facilmente. Para criar um arquivo diff legível aos humanos em um simples editor de textos, você deve fornecer a opção -u : 

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

Para aplicar um patch: 

 $ patch file.orig file.diff