Build Próprio a partir do Source (Sem Telemetria)

Definição curta: Tutorial sobre como compilar o Tenacity a partir do código-fonte no Linux, para quem quer controle total sobre o binário e a certeza de que nenhum código não auditado foi adicionado.

Antes de começar

Ter feito ao menos um tutorial desta seção de tutoriais
Noção do que é uma faixa e do que é um efeito no Tenacity

O que você vai aprender

Explicar Por que compilar o próprio binário com suas palavras
Explicar Pré-requisitos com suas palavras
Explicar Passo a passo do build com suas palavras
Reconhecer, no seu próprio material, onde o assunto desta página se aplica

O que é

O Tenacity nasceu em 2021 como fork do Audacity, motivado justamente por mudanças na política de coleta de dados do projeto original. Parte da comunidade que migrou para o Tenacity leva a privacidade a sério o suficiente para não confiar nem em binários pré-compilados de terceiros — preferindo compilar o próprio executável a partir do código publicado no Codeberg, auditando o que entra no build.

Compilar a partir do source é um cenário que só faz sentido para um projeto com essa cultura: o Tenacity é GPL v2+, o código está aberto, e a comunidade mantém o build reprodutível em distribuições Linux comuns. Este tutorial cobre o processo básico de build em Linux e como verificar, na prática, que o binário resultante não faz chamadas de rede inesperadas.

Índice de sub-tópicos

Por que compilar o próprio binário

Motivo	Explicação
Confiança na cadeia de build	Você compila diretamente do código publicado, sem depender de um terceiro empacotando o binário
Auditoria possível	É possível ler o código-fonte completo antes de compilar
Customização	Dá para desabilitar módulos opcionais (ex.: certas bibliotecas de rede) na configuração do CMake
Consistência com a filosofia do projeto	O Tenacity existe justamente por causa de decisões de telemetria do Audacity; compilar do zero é a forma mais extrema de garantir esse compromisso

Pré-requisitos

Em uma distribuição Linux baseada em Debian/Ubuntu, os pacotes de desenvolvimento típicos necessários incluem compilador C++, CMake, Git e as dependências de desenvolvimento do wxWidgets (toolkit de interface gráfica usado pelo Tenacity). Nomes exatos dos pacotes variam por distribuição — consulte o README do repositório para a lista atualizada, já que dependências podem mudar entre versões.

Instalar ferramentas básicas de build (compilador, make, cmake, git)
Instalar as bibliotecas de desenvolvimento do wxWidgets pelo gerenciador de pacotes da distribuição
Garantir espaço em disco suficiente (o build de um projeto C++ deste porte pode consumir alguns gigabytes em objetos intermediários)

Passo a passo do build

Passo 1: Clonar o repositório

git clone https://codeberg.org/tenacityteam/tenacity.git
cd tenacity

Passo 2: Criar diretório de build

mkdir build
cd build

Passo 3: Configurar com CMake

cmake .. -DCMAKE_BUILD_TYPE=Release

O CMake detecta as dependências instaladas no sistema e prepara os arquivos de build. Se alguma biblioteca estiver faltando, o comando falha com uma mensagem indicando o que precisa ser instalado.

Passo 4: Compilar

cmake --build . -j$(nproc)

A flag -j$(nproc) paraleliza a compilação usando todos os núcleos disponíveis. O tempo de build varia bastante conforme o hardware.

Passo 5: Executar o binário compilado

Após a compilação, o executável fica disponível dentro do diretório de build (o caminho exato depende da estrutura de saída do CMake usada no projeto). Execute-o diretamente a partir do terminal para testar, sem instalar no sistema.

Verificando ausência de phone-home

Uma das motivações centrais de quem compila o próprio binário é confirmar, na prática, que não há tráfego de rede não solicitado. Duas abordagens simples no Linux:

Com uma regra de firewall temporária

Criar uma regra iptables/nftables que bloqueia todo tráfego de saída do usuário que vai rodar o Tenacity, exceto o necessário para o sistema
Rodar o Tenacity normalmente (abrir, gravar, exportar)
Se nada quebrar visivelmente e nenhum log de bloqueio disparar, é um bom indício de que o binário não tentou se conectar à rede

Com monitoramento de chamadas de sistema

strace -f -e trace=network ./tenacity 2>&1 | tee tenacity-network.log

Esse comando roda o Tenacity sob strace, filtrando apenas chamadas de sistema relacionadas a rede (socket, connect, etc.), e salva a saída em um arquivo de log para inspeção posterior. Se o log ficar vazio durante uma sessão típica de uso (abrir projeto, gravar, editar, exportar), é evidência de comportamento offline-first.

Nota: ferramentas como strace têm overhead de performance perceptível — use apenas para verificação pontual, não para uso diário.

Cuidados e limitações

Compilar do zero exige familiaridade básica com ferramentas de build C++; erros de dependência são a causa mais comum de falha
Um build sem otimizações de produção (Debug em vez de Release) pode rodar perceptivelmente mais lento
Verificar ausência de tráfego de rede com strace ou firewall não é uma auditoria de segurança completa — é uma checagem de sanidade, não uma garantia formal
Builds próprios não recebem atualizações automáticas; é responsabilidade do usuário acompanhar novas versões e recompilar
Diferenças de versão de bibliotecas do sistema (como wxWidgets) podem gerar binários com comportamento sutilmente diferente de um release oficial

Você aprendeu

Por que compilar o próprio binário
Pré-requisitos
Passo a passo do build
Verificando ausência de phone-home
Cuidados e limitações

Perguntas para reflexão

O que Por que compilar o próprio binário resolve, e o que se perde sem isso?
O que Pré-requisitos resolve, e o que se perde sem isso?
O que Passo a passo do build resolve, e o que se perde sem isso?
Que parte desta página você conseguiria executar sem consultar o texto?

Veja também

Referências

Tenacity no Codeberg — Repositório oficial do código-fonte
Tenacity Audio — Site oficial do projeto