Estrutura Do Pacote

A estrutura de um pacote .deb pronto é simples e não tem nada complexo. E um pacote do Slackware não fica atrás. A diferença principal é que os dados do software estão em um tar separado dos arquivos que fazem o controle da instalação. Não são muitos arquivos e em resumo o principal de um pacote .deb é:

debian-binary

Arquivo de texto com a versão do binário do pacote.

control.tar.gz

Meta informação do pacote. Dependências e coisas do tipo.

data.tar ou data.tar.gz ou data.tar.bz2 ou ainda data.tar.lzma

O diretório que contém os arquivos do programa a ser instalado.

Tudo isso comprimido em um pacote ar. Acho que é o mínimo e o máximo necessário para um controle de pacotes com dependencias como no Debian.

No Slackware a estrutura é semelhante mas é basicamente um pacote tar gzip, bzip ou xz que representa o mesmo que o data.tar no pacote Debian, mas com um sub-diretório install onde estão os arquivos de controle da instalação.

Geração do Pacote e a Aberração Debianization

Ok, aqui o bixo pega. Então vou fazer em forma de comparativo entre Slackware e Debian.

No Slackware

É nois que voa bruxão

A geração de pacotes no Slackware é feita usando preferivelmente um script em shell para automatização da compilação e empacotamento chamado SlackBuild Script, é um shell script perfeitamente normal que qualquer pessoa com o mínimo de experiência no mesmo consegue dar manutenção. Em geral o que o slackbuild faz pode ser divido em duas fases:

1. Compilação e instalação do pacote em um diretório temporário
2. Geração do pacote com o facilitador makepkg

A primeira fase é feita usando as ferramentas disponíveis pela aplicação. Pode ser autoconf, ant ou qualquer build system. Até mesmo um chroot se faz necessário em alguns casos. A segunda parte é a normalização do pacote que consiste em compactação de man pages, strip de shared libraries, a inclusão do próprio build script como doc e dos arquivos para o diretório install/ e por fim a compactação do diretório e criação do t?z.

É importante ressaltar que nos pacotes Slackware o código fonte original não é mexido e sequer distribuido junto com os SlackBuilds na maioria dos casos. Alguns casos existem onde patches são necessários para que o pacote funcione corretamente mas estes são aconselhados somente se o programa não puder funcionar sem este ou isso representar um risco grave de segurança e estabilidade. A politica pura e simples é: Desenvolvimento é papel dos desenvolvedores e não dos empacotadores.

No Debian

Coididoido esse debian.

O documento de política de desenvolvimento do Debian é um monstro de 10 sessões com mais 10 sub-sessões cada e 7 anexos. Recomendo a leitura se quiser confirmar o que eu digo aqui. Vou resumir a forma de criação padrão de pacotes.

A mudança na forma de pensar já começa na nomenclatura do indivíduo que empacota. No Slackware é um empacotador. No Debian é um desenvolvedor.

Primeiro salva-se o código fonte original em um .orig e então pode se começar a Debianização do aplicativo. Um pacote é feito geralmente usando de 2 a 4 aplicativos facilitadores e geralmente o autoconf é o responsável pela geração do pacote. Tudo isso fica dentro do código fonte em um diretório debian/. A estrutura é complexa e é necessário um longo periodo e leitura da documentação para a compreensão do sistema de empacotamento e criação de um pacote seguindo todas as guidelines.

Na documentação em vários trechos é recomendado a edição do código fonte original para debianização do aplicativo. O que ao meu ver só maximiza as possibilidades de problema como aquele infame warning no openssl que foi silenciado por um Debian desenvolver e fez com que as chaves de milhares de servidores fossem geradas de forma previsível.

Também há uma preocupação grande mas parcialmente justificável de separar os cabeçalhos de bibliotecas em pacotes adicionais e usar a mesma estrutura para gerar mais de um pacote elevando a complexidade do sistema.

Pensamentos Finais

Não muitos, eu não gosto desse sistema e as guidelines do Debian são uma aberração pra mim. Vou tentar criar um DebBuild script para gerar pacotes Debian no estilo Slackware e posto aqui se o fizer.

Meu chefe certo dia falou que o sistema do Slackware dependia do “artista” e não era processual o suficiente. Mas lendo a guideline do Debian eu descobri que ele está errado nisso, pois a inversa é verdadeira. O sistema do Debian é justamente isso, um sistema com sub-sistemas e macro-sistemas usados para gerar coisas que no final das contas são simples, uma arquitetura digna de um arteiro e não artista.

PS IMPORTANTE

Eu falo aqui da forma de geração de pacotes recomendada e ensinada pelo documento abaixo. NÃO estou considerando outras formas, se existirem, de gerar pacotes Debian. Como por exemplo a utilização de um script sh ou CDBS.

Referências

deb (file format) From Wikipedia, the free encyclopedia

Debian Policy Manual From Debian.org

PS.  gentil correção do caio:

[11:39] <caio1982> guax: debian-binary nao eh a versao do pacote, seu animal, eh a versao dos binarios do debian (.debs em geral distribuidos em “formato debian”, nao sao backward compatible pra sempre)

PS2. adição do caio: http://build-common.alioth.debian.org/cdbs-doc.html

Have fun.

Nota mental: tenho que lembrar de modificar os slackbuilds e submeter no slackbuilds.org

O produto é chinês, fabricado por uma empresa chamada MyGica. A embalagem é simples, não mostra nem o nome da empresa que fabrica, informação essa que só consta no manual. É bem montado e acabamento aceitável para o preço (algo em torno de $50).

O controle remoto fica na parte de trás da embalagem.

O conteúdo da embalagem é tão completo quanto parece, só vem o essencial:

• O receptor em formato “dongle”
• Antena VHF/UHF de alto ganho (diz ela)
• Adaptador para ligar uma antena externa
• Controle remoto desenhado para o software Total Media que vem no CD
• Manual
• Cd com driver e software de media

Nada mais que o suficiente

Um detalhe estranho, o driver para windows que vem no CD não é o driver correto para o chip de captura. Encontrei o driver correto em um fórum chileno e deixo aqui caso alguém precise.

Não vou cobrir a instalação dele no windows, então vamos ao que interessa, ao plugar ele no seu computador você não vai ter muitas informações.

usb 1-1: new high speed USB device using ehci_hcd and address 6
usb 1-1: configuration #1 chosen from 1 choice
usb 1-1: New USB device found, idVendor=10b8, idProduct=1fa0
usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1: Product: STK8096GP
usb 1-1: Manufacturer: DiBcom
usb 1-1: SerialNumber: 1

Isso não colabora muito mas nos dá o fabricante e o modelo do chip. Com isso é fácil dar uma googlada sobre o funcionamento dele no Linux. A boa notícia é que o fabricante é bonzinho e colaborou com a confecção do driver. Temos por tanto um suporte ainda inicial ao ISDB-T no v4l-dvb. Uma questão de fazer o download, um make, make install e tudo pronto. Para isso basta pegar o trunk (já que é experimental vamos viver perigosamente).

$ hg clone http://www.linuxtv.org/hg/v4l-dvb
$ cd v4l-dvb
$ make
$ su
# make rmmod
# make install

Você pode substituir o su com sudo se preferir. Após instalar os driver ainda precisamos do firmware do dispositivo. Basta fazer o download e colocá-lo em /lib/firmware/ que tudo estará bem. A resposta do dmesg após replugar o dispositivo agora deverá ser algo como:

dib0700: loaded with support for 14 different device-types
dvb-usb: found a 'DiBcom STK8096GP reference design' in cold state, will try to load
a firmware
firmware: requesting dvb-usb-dib0700-1.20.fw
dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw'
dib0700: firmware started successfully.
dvb-usb: found a 'DiBcom STK8096GP reference design' in warm state.
dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
DVB: registering new adapter (DiBcom STK8096GP reference design)
DVB: registering adapter 0 frontend 0 (DiBcom 8000 ISDB-T)...
DiB0090: successfully identified
input: IR-receiver inside an USB DVB receiver as /devices/...
dvb-usb: schedule remote query interval to 50 msecs.
dvb-usb: DiBcom STK8096GP reference design successfully initialized and connected.
usbcore: registered new interface driver dvb_usb_dib0700

Não é lindo?

Com isso nos temos o dispositivo funcionando mas ainda falta o pedaço que me fez perder algumas horas. Escanear os canais para poder ver o Faustão na telinha do seu PC (ele cabe agora que emagreceu). Para isso nos vamos usar as ferramentas que o driver ali em cima já instalou antes junto com os módulos. A aplicação scan fará isso mas ela precisa de informações para fazer seu trabalho, ela precisa de uma lista de freqüências e ranges para poder escanear por recepção. Essa lista eu consegui primeiramente no blog de dougsland (que não parece ter o nome real divulgado no site). Sabendo o que eu estava procurando (frequency table) eu consegui encontrar no excelente wiki do linuxtv.org em http://www.linuxtv.org/wiki/index.php/ISDB-T_Frequency_Table

Copie o conteúdo e cole em um ch.conf então rode o comando scan para gerar a lista de canais disponíveis:

$ scan ch.conf > channels.conf

Isso gerará um monte de erros como:

>>> tune to: 503142857:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_3_4:FEC_AUTO:QAM_
AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_NONE

Mas não se preocupe, são normais. Se você tem recepção no meio desse monte de erros você verá um:

Network Name 'RBS TV FLOPS'
0x0000 0xdc60: pmt_pid 0x0101 (null) -- RBS TV HD (???)
0x0000 0xdc78: pmt_pid 0x1fc8 (null) -- RBS TV 1seg (???)

E então seu arquivo channels.conf terá as informações de canais para que você possa vê-los. Se você está em Florianópolis Santa Catarina Brasil por volta do ano de 2009 você terá somente dois canais, um 1 seg e outro full seg que são, infelizmente:

RBS TV HD:587142857:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_3_4:FEC_AUTO:QAM
_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_NONE:273:274:
56416
RBS TV 1seg:587142857:INVERSION_AUTO:BANDWIDTH_6_MHZ:FEC_3_4:FEC_AUTO:QAM
_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_NONE:529:530:
56440

Afinal a Band ainda tem as madrugadas de sábado pra animar a garotada. Com isso nós ficamos no ultimo passo: assistir televisão. Mas antes, uma explicação rápida antes sobre a zona toda de TV digital (não achou que eu ia te liberar agora né?).

O mundo todo usa os tais dos DVB-S, DVB-T, DVB-S, DVB-C e ATSC, o Japão  criou e usa o ISDB-T, o Brasil adotou ele e o usa para transmissão, inclusive usa o mesmo range de freqüências, se as tabelas não são iguais elas são muito parecidas. A transmissão digital usa 13 segmentos, 1 deles esse padrão deixou reservado para transmissão de baixa qualidade para dispositivos móveis, com telas pequenas, ou baixa capacidade. Sim, esse é o tal do 1seg que você vai ver bastante. O resto é transmitido em 12 segmentos (full-seg) e nesses estão as transmissões standard e hd. O codec de audio usado é o AAC e o de vídeo e o H264.

Toda a parte anterior está resolvida pelo driver, linda e funcional, um charme tecnológico. Mas… a questão do codec ainda não. Apesar do MPlayer ter colocado suporte por agora ainda não está bom até a redação desse texto. A unica alternativa viável por agora é o VLC que tem suporte a h264 e AAC. Além de se entender com o DVB.

Para fazer funcionar basta você clicar em Exibir > Lista de Reprodução, clicar no mais, adicionar o channels.conf que você criou, dar dois cliques e pronto, simples assim.

No fantástico =)

Mas vamos ao que interessa, e o HD??? Bom, veja bem. O h264 garante uma alta compressão com pouca perda de qualidade, mas isso tem um custo, um rim. Digo, um processador, você precisa ter uma máquina BOA para descodificar o vídeo em HD 1080p. Tanto que no linux eu não consegui tocar direito por conta da implementação do h264, no áudio é perfeito sem nenhum problema, vídeo vai travando, inclusive no poderoso windows (por conta do meu proc dai). Pra ser sincero, no VLC eu não consegui visualizar nem o 1seg direito por conta da descodificação do h264 o vídeo fica com frames repetidos (falha na interpolação ou algo por ai). Você pode ter mais sorte em uma versão mais nova ou melhor do VLC (não desista padawan).

Quero ver você pegar momento melhor pro screenshot.

Sobre o controle remoto, ele funciona e o driver reconhece mas eu não tive tempo de fazer ele fazer algo útil. A prova são as mensagens que o driver põe no kernel. Basta tratá-las e usar, mas não é algo que um usuário comum faria, então fica pra outra hora (talvez nunca ).

dib0700: Unknown remote controller key: 0000 20 df
dib0700: Unknown remote controller key: 0000 20 df

Todo o processo acima foi feito em cima de um Slackware Linux com versão entre 12.2 e current pré 13.1. (sim, uma zona).

Ps. Gostaria de agradecer a Douglas Conrad que me deixou ficar com o equipamento por uns dias para testes. Foi divertido

UPDATE (15/06/2010): Aparentemente o kernel 2.6.33.3 já inclui os drivers para dvb-usb e para o dibcom 0700. Você ainda precisa do firmware do dispositivo que está linkado nesse artigo e também é necessário o dvb-apps instalado para ter a ferramenta scan.

Finalmente após anos de tortura tendo que aguentar as travadas do Firefox chegou o momento de ter um browser leve, rápido e com renderização de fontes decente no linux. Chegou a vez do Chromium, projeto open source do Google que é a fonte do browser Chrome. Um amigo meu estava usando ele no ubuntu eu resolvi rodar ele no Slackware. Descreverei o processo de instalação e a minha análise sobre esse beta.

Primeiro instale o mozilla-nss a provável unica dependência que você vai precisar.

Eu não criei um pacote para o chromium, talvez eu o faça no futuro. Até lá baixe o ultimo tarball e rode só pro seu usuário, caso você tenha problemas com os nomes estranhos criados pelo pessoal que empacota para o debian (alguém faz ideia de por que o .d??) faça o seguinte que tirei daqui.

ln -s /usr/lib/libplds4.so /usr/lib/libplds4.so.1d
ln -s /usr/lib/libnss3.so /usr/lib/libnss3.so.1d
ln -s /usr/lib/libsmime3.so /usr/lib/libsmime3.so.1d
ln -s /usr/lib/libssl3.so /usr/lib/libssl3.so.1d
ln -s /usr/lib/libnssutil3.so /usr/lib/libnssutil3.so.1d
ln -s /usr/lib/libnspr4.so /usr/lib/libnspr4.so.0d
ln -s /usr/lib/libplc4.so /usr/lib/libplc4.so.0d
ln -s /usr/lib/libplds4.so /usr/lib/libplds4.so.0d

Tente rodar o chrome primeiro, pode ser que tenha mudado no ultimo build. And there you go.

Usando um tema escuro pra ficar mais discreto.

A análise: é rápido, muito rápido. Tem corretor ortográfico . E tudo que tem na versão windows. Ainda não tem sua ferramenta que substitui o Firebug madura o suficiente para ser usada ao invés do inseto flamejante mas da pro gasto em toda a parte de navegação. Outro contra é a falta de gears mas dizem que o próprio html 5 terá suporte para armazenagem, aguardaremo então até o Chromium e o GMail darem suporte para isso. :/

1. Edite seu /etc/slackpkg/mirrors e coloque o repositório do 13.0
2. slackpkg update

Aqui vem o macete. Primeiro atualize esses dois indivíduos e instale esse outro:

1. slackpkg install xz
2. slackpkg upgrade pkgtools
3. slackpkg upgrade slackpkg

Por fim, é só executar o de sempre:

1. slackpkg install-new
2. slackpkg upgrade-all

Have fun com seu Slackware 13.0

Está no ar o incrível diretório pub/ do guax.net. Disponível em www.guax.net/pub ele contém alguns arquivos que eu quero compartilhar com esse mundão velho sem porteiras.

Esses arquivos são SlackBuilds de softwares e seus pacotes gerados assim como mirrors para meus próprios projetos.

Lá vocês já vão encontrar um README (duh!) e o primeiro slackbuild (asterisk) que eu modifiquei e estou redisponibilizado para quem quiser. Em outro post eu explico ao certo qual é a desse slackbuild.

Ps. Lembrando a piadinha infame do cd pub/; more beer;

Slackware Linux

Sexta a noite a nerdeada do dia é gerar um cd do Slackware Linux usando um mirror próprio .

A dica vem da ultima edição do Slackware Zine.