unrpm

Categoria: Linux Publicado: Terça, 19 Agosto 2014 Escrito por Helio Loureiro

unRPM

Apesar de adorar Debian e Ubuntu, o trabalho me exige mexer com pacotes RPM.  Ao contrário do format DEB, os pacotes RPM são mais simples de gerar.  Basta ter um arquivo SPEC, que informa os dados dos pacote como dependência e scripts para instalação, que é possível gerar usando rpmbuild.  Mesmo num Debian/Ubuntu.

Mas cai no caso de uma aplicação de opensaf já compilada.  E precisava gerar um pacote só com versão diferente, pra testar uma campanha de upgrade.  A solução seria desmontar o pacote RPM e montar novamente.  Um "unrpm" por assim dizer.  Eu tentei usar um pacote "rpmrebuild", mas o mesmo é feito pra sistemas já com uso de RPM, e precisa que o pacote esteja instalado pra conseguir reconstuir o mesmo.  Com certeza não o meu caso.

A parte do conteúdo não é difícil de fazer pois o pacote RPM é na verdade um arquivo de CPIO.  Usando como exemplo o pacote aalib-libs do fedora 20, com comandos rpm é possível ver as informações do pacote e seu conteúdo:

helio@debian:~$ rpm -qip aalib-libs-1.4.0-0.23.rc5.fc20.x86_64.rpm
warning: aalib-libs-1.4.0-0.23.rc5.fc20.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 246110c1: NOKEY
Name : aalib-libs
Version : 1.4.0
Release : 0.23.rc5.fc20
Architecture: x86_64
Install Date: (not installed)
Group : System/Libraries
Size : 159154
License : LGPLv2+
Signature : RSA/SHA256, Fri 16 Aug 2013 05:21:44 PM CEST, Key ID 2eb161fa246110c1
Source RPM : aalib-1.4.0-0.23.rc5.fc20.src.rpm
Build Date : Sat 03 Aug 2013 02:17:12 AM CEST
Build Host : buildvm-07.phx2.fedoraproject.org
Relocations : (not relocatable)
Packager : Fedora Project
Vendor : Fedora Project
URL : http://aa-project.sourceforge.net/aalib/
Summary : Library files for aalib
Description :
This package contains library files for aalib.
helio@debian:~$ rpm -qlp aalib-libs-1.4.0-0.23.rc5.fc20.x86_64.rpm
warning: aalib-libs-1.4.0-0.23.rc5.fc20.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 246110c1: NOKEY
/usr/lib64/libaa.so.1
/usr/lib64/libaa.so.1.0.4
/usr/share/doc/aalib-libs
/usr/share/doc/aalib-libs/COPYING
/usr/share/doc/aalib-libs/ChangeLog
/usr/share/doc/aalib-libs/NEWS
/usr/share/doc/aalib-libs/README

Com o comando rpm2cpio seguido de cpio, é possível verificar que o conteúdo é o mesmo, sem perdas.

helio@debian:~$ cat aalib-libs-1.4.0-0.23.rc5.fc20.x86_64.rpm | rpm2cpio - | cpio -itv
lrwxrwxrwx 1 root root 14 Aug 3 2013 ./usr/lib64/libaa.so.1 -> libaa.so.1.0.4
-rwxr-xr-x 1 root root 125872 Aug 3 2013 ./usr/lib64/libaa.so.1.0.4
drwxr-xr-x 2 root root 0 Aug 3 2013 ./usr/share/doc/aalib-libs
-rw-r--r-- 1 root root 25265 Apr 26 2001 ./usr/share/doc/aalib-libs/COPYING
-rw-r--r-- 1 root root 3649 Apr 26 2001 ./usr/share/doc/aalib-libs/ChangeLog
-rw-r--r-- 1 root root 764 Apr 26 2001 ./usr/share/doc/aalib-libs/NEWS
-rw-r--r-- 1 root root 3604 Apr 26 2001 ./usr/share/doc/aalib-libs/README
314 blocks

Para extrair o conteúdo, bastaria usar as opções "-idv" do cpio.

Mas ainda falta os scripts de instalação que fazem a parte de pré-instalação, pós-instalação, pré-remoção e pós-remoção.  Como escolhi um pacote de biblioteca, esses não precisam de algo assim.  Pegando um pacote de servidor, no caso o bind - servidor de dns, é possível ver esses scripts que compões o SPEC.  Basta usar o comando "rpm --scripts -qp <pacote>".

helio@debian:~$ rpm --scripts -qp bind-9.9.4-8.fc20.x86_64.rpm
warning: bind-9.9.4-8.fc20.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 246110c1: NOKEY
preinstall scriptlet (using /bin/sh):
if [ "$1" -eq 1 ]; then
/usr/sbin/groupadd -g 25 -f -r named >/dev/null 2>&1 || :;
/usr/sbin/useradd -u 25 -r -N -M -g named -s /sbin/nologin -d /var/named -c Named named >/dev/null 2>&1 || :;
fi;
:;
postinstall scriptlet (using /bin/sh):
/sbin/ldconfig

if [ $1 -eq 1 ] ; then
# Initial installation
/usr/bin/systemctl preset named.service >/dev/null 2>&1 || :
fi
if [ "$1" -eq 1 ]; then
# Initial installation
[ -x /sbin/restorecon ] && /sbin/restorecon /etc/rndc.* /etc/named.* >/dev/null 2>&1 ;
# rndc.key has to have correct perms and ownership, CVE-2007-6283
[ -e /etc/rndc.key ] && chown root:named /etc/rndc.key
[ -e /etc/rndc.key ] && chmod 0640 /etc/rndc.key
fi
:;
preuninstall scriptlet (using /bin/sh):
# Package removal, not upgrade

if [ $1 -eq 0 ] ; then
# Package removal, not upgrade
/usr/bin/systemctl --no-reload disable named.service > /dev/null 2>&1 || :
/usr/bin/systemctl stop named.service > /dev/null 2>&1 || :
fi
postuninstall scriptlet (using /bin/sh):
/sbin/ldconfig
# Package upgrade, not uninstall

/usr/bin/systemctl daemon-reload >/dev/null 2>&1 || :
if [ $1 -ge 1 ] ; then
# Package upgrade, not uninstall
/usr/bin/systemctl try-restart named.service >/dev/null 2>&1 || :
fi

Com essas informações é possível construir um pacote RPM binário.  Claro que no caso isso não é necessário pois bastaria pegar o pacote SRC e fazer o build novamente.  No meu caso, eu não sabia onde estavam os fontes e essa forma foi muito mais rápida, ainda mais que eu só precisava modificar a informação de versão pra testar upgrade.

GNU e Linux: sem um não existiria o outro. Tem certeza?

Categoria: Linux Publicado: Segunda, 18 Agosto 2014 Escrito por Helio Loureiro

Linux BSD

É comum encontrar em fóruns algumas discussões acaloradas sobre o uso do termo "GNU/Linux" ao invés de "Linux", e que o mesmo não seria o que é, pois é somente um kernel, sem o GNU.

Concordo em número, gênero e grau sobre a importância do GNU na história do software livre, e mesmo na do Linux.  Sem a influência de liberdade, Linus nunca teria pensado em ter um sistema completamente aberto.  Mas será mesmo que ele precisava das ferramentas da GNU, ou de outro modo não conseguiria sair do zero?

BSD para quem ama Unix

Em uma entrevista de 1993, Linus Torvalds comenta que não teria nem tentando criar o Linux se o 386BSD existisse.

The choice of GNU generation

Pra quem não lembra, Linux foi criado em 1991, enquanto que o FreeBSD apareceu somente em 1993.  Onde estava o BSD esse tempo todo?

Em 1991, Berkeley estava sofrendo um processo judicial por parte da AT&T, a dona do código fonte do UNIX, que tinha compartilhado com Berkeley durante sua origem, nos anos 70.  O UNIX BSD sempre fora distribuído gratuitamente, e com códigos fontes abertos e livres, sob a licença BSD.  Enquanto a AT&T tinha o UNIX como um projeto de laboratório, uma brincadeira dos engenheiros, isso não importava muito.  Mas no final da década de 80 o UNIX já era muito difundido e usado tanto nas universidades quanto fora delas.  Quando a AT&T chegou ao fim de seu contrato de monopólio das telecomunicações, ela simplesmente resolveu comercializar seu UNIX.  E como lidar com o seu concorrente livre, o BSD?  Não teria problema se continuasse dentro das universidades, mas existia uma empresa que vendia um UNIX derivado do BSD, o BSDi.  Então entra um processo judicial no meio do caminho.

BSD estava na sua versão 4, que incluia o stack recém criado de redes, o TCP/IP.  O processo terminou em 1992, quando foi feito um acordo em que o código BSD seria re-escrito sem a parte que pertencia à AT&T.  Surgia a especificação 4.4BSD-lite.  Nessa época, a revista Dr.Dobbs iniciou uma série de artigos que vinham com o código pra ter o BSD rodando em computadores com o processador i368.  Era o surgimento do 386BSD.

Mas o 386BSD tinha o problema de ter dono, Lynne Jolitz e William Jolitz.  Apesar do código estar totalmente publicado e permitir qualquer um compilar seu próprio UNIX BSD, era preciso passar quase 2 dias aplicando patches de voluntários pra ter o sistema atualizado e funcional.  Nesse ambiente sugiram os sistemas FreeBSD e NetBSD, como uma forma mais colaborativa de participação e manutenação do código.

E o GNU?

Nesse meio tempo entre 1990 e 1993, pode-se dizer que os UNIX BSDs praticamente pararam seu desenvolvimento.  Eles existiam dentro de máquinas PDP, os mini computadores da época, mas não nos computadores pessoais, que era o que Linus usava em casa pra programar.  Os BSDs precisavam do GNU?  Precisavam mas não do GNU como um todo.  Eles usavam o compilador GCC, que foi um dos marcos mais importantes do software livre.  O restante, dos comandos básicos ao kernel, já tinham em BSD.  Linux é um kernel enquanto que FreeBSD é um sistema operacional completo.  E descendente direto do UNIX.

Se Linus tivesse começado um pouco depois, em 92, ele poderia ter construído o Linux em cima de uma base BSD.  E continuaria um software livre.    Vantagens?  Acho que talvez mudasse o licenciamento pra BSD, mas provavelmente seria muito semelhante com o que temos hoje.

Mudar pra BSD ainda é possível?

Possível, é.  Valeria o esforço?  Eu diria que não.  Linux funciona muito bem com a parte GNU.  Se um dia surgisse algum problema de licenciamento, o que é impossível com softwares da GNU, ele poderia eventualmente ter um esforço pra mudar.  

Benefícios de desempenho?  Acho que também não.  Apesar dos BSDs terem um stack de rede com desempenho superior ao do Linux, isso não é imutável e frequentemente acontece de um passar o desempenho do outro.  Recentemente o Facebook anunciou uma iniciativa de melhorar o stack de rede do Linux pra igualar ao do FreeBSD.  Eu espero que supere, pra assim o grupo do BSD ter um objetivo pra melhorar mais :-)

E os BSDs não estão na frente em tudo.  O próprio "grep" da GNU é muito mais rápido e eficiente que seu semelhante BSD, pra listar apenas alguns.

Então, antes de dizer que Linux não seria nada sem o GNU, lembre dos BSD.  Atualmente nem o compilador é mais o GCC, sendo um sistema operacional totalmente funcional sem precisar necessariamente do GNU.  E 100% software livre.

Atualização: Tue Aug 19 18:30:18 CEST 2014

Eu esqueci completamente de comentar (obrigado pelo lembrete Bruno Máximo) mas o Android é um kernel Linux sem GNU, totalmente feito em cima de BSD.  E sim, o desempenho é muito bom.

nvidia-331 e linux-3.13

Categoria: Linux Publicado: Terça, 21 Janeiro 2014 Escrito por Helio Loureiro

Nada como começar 2014 com um post sobre nvidia.  Não que 2014 tenha começado agora, mas não tive muito assunto pra escrever até o momento (na verdade tive, mas a inércia de 2013 foi mais forte).

Estou trabalhando num ambiente que usa pesadamente linux containers, os lxc, que é uma forma de virtualização.  Pra minha triste surpresa, muitas funcionalidades não ficam ativas no lxc com o kernel-pf.  Então resolvi voltar pro bom e velho kernel Linux padrão, baixado diretamente de https://www.kernel.org

Compilação feita, com parâmetros pra funcionamento dos linux containers (é preciso ativar cgroups em toda sua funcionalidade) e, antes do boot, aparece um upgrade dos drivers da nvidia.  Já que ia fazer um reboot, resolvi fazer tudo de uma vez.

O boot do kernel linux-3.13.0-helio.3 (3ª versão, as outras duas ou eu esqueci algo, ou falhou em algum parâmetro que deixei fora) foi tranquilo mas o Xorg... esse subiu com noveau, bem inferior ao drive da nvidia.  Ao tentar carregar o módulo da nvidia manualmente, pra descobrir qual o problema, surgiu a seguinte mensagem:

[ 89.005614] nvidia: Unknown symbol acpi_os_wait_events_complete (err 0)
[ 386.837191] nvidia: Unknown symbol acpi_os_wait_events_complete (err 0)

Procurando pela Internet, descobri que justamente o pacote novo da nvidia, nvidia-331 (ou nvidia-331_331.38-0ubuntu0.0.1~xedgers~precise2_amd64.deb), tem esse erro com kernels 3.13, pois a função EXPORT_SYMBOL(acpi_os_wait_events_complete) foi removida do mesmo.

A correção não é muito complexa.  Basta aplicar a seguinte correção dentro de "/usr/src/nvidia-331-331.38", que foi criado durante a instalação do pacote:

--- nvidia-331-331.38/nv-acpi.c.orig    2014-01-21 11:44:59.485055493 +0100
+++ nvidia-331-331.38/nv-acpi.c 2014-01-21 11:44:22.664056579 +0100
@@ -301,13 +301,13 @@
             "NVRM: nv_acpi_remove: failed to disable display switch events (%d)!\n", status);
     }
 
-    if (pNvAcpiObject->notify_handler_installed)
+    /* if (pNvAcpiObject->notify_handler_installed)
     {
         NV_ACPI_OS_WAIT_EVENTS_COMPLETE();
 
         // remove event notifier
         status = acpi_remove_notify_handler(device->handle, ACPI_DEVICE_NOTIFY, nv_acpi_event);
-    }
+    }*/
 
     if (pNvAcpiObject->notify_handler_installed &&
         ACPI_FAILURE(status))

É um comentário em toda a parte de código que usa a função problemática.  Uma vez que a chamada de kernel não existe mais, não deve causar grandes impactos.  Então basta atualizar o dkms, que no meu caso fiz com o kernel de nome linux-3.13.0.helio-3.

dkms remove -m nvidia-331 -v 331.38 -k 3.13.0.helio-3
dkms build -m nvidia-331 -v 331.38 -k 3.13.0.helio-3
dkms install -m nvidia-331 -v 331.38 -k 3.13.0.helio-3

Com isso o módulo novo, com o patch acima, é construído.  Então basta rebootar pra ter o kernel novo rodando e correr pro abraço :-)

 

Usando o controle do Xbox pra jogar L4D2 no Linux

Categoria: Linux Publicado: Sábado, 07 Setembro 2013 Escrito por Helio Loureiro

Depois de uma longa batalha pra atualizar meu PC, consegui deixar tudo redondo pra jogar L4D2 (Left for Dead 2) com o pessoal.  E sobre o Ubuntu.

Um dos empecilhos era em relação às configurações de controle do jogo, que por padrão usa o mouse e o teclado.  Eu até tentei usar no início, mas estou acostumado com os consoles, xbox360 e ps3, e com seus respectivos controles.  Então era um sofrimento jogar.

Tentei utilizar os controles dos dois no Linux, mas vi na Internet que o melhor controle é o do xbox, mas não o wireless, o cabeado.  Sem problemas.  Sai caçando um e comprei na loja xing-ling de origem questionável mais próxima (na av. Paulista).

Quando fui jogar, nova decepção: não mapeava corretamente os movimentos.  Mas uma alma caridosa conseguiu fazer o mapeamento usando um driver através do programa xboxdrv (tem pra Ubuntu).

Criei então os seguinte script pra mapear o controle e jogar com os amigos:

#! /bin/sh
# Name: xbox360controler_setup.sh
# Source http://ubuntuforums.org/showthread.php?t=2002622

case `whoami` in
        root) echo "Running as root";;
        *) echo "You must run it as root.  Using sudo for that."
           sudo $0
           exit 0
esac

rmmod xpad
modprobe uinput
modprobe joydev
rmmod xpad

xboxdrv \
        -s \
        --type xbox360 \
        --deadzone 9000 \
        --dpad-as-button \
        --trigger-as-button \
        --ui-axismap "x2=REL_X:10,y2=REL_Y:10,x1=KEY_A:KEY_D,y1=KEY_W:KEY_S" \
        --ui-buttonmap "tl=KEY_LEFTSHIFT,tr=KEY_LEFTCTRL" \
        --ui-buttonmap "a=KEY_SPACE,b=KEY_C,x=KEY_1,y=KEY_R" \
        --ui-buttonmap "lb=KEY_Q,rb=KEY_E" \
        --ui-buttonmap "lt=BTN_RIGHT,rt=BTN_LEFT" \
        --ui-buttonmap "dl=KEY_LEFT,dr=KEY_RIGHT,du=KEY_UP,dd=KEY_DOWN" \
        --ui-buttonmap "back=KEY_ESC,start=KEY_ENTER"

Boa jogatina e lembre-se: se for jogar, pode me chamar.  Não garanto lá um desempenho muito bom, mas a diversão é garantida.

add-apt-repository ppa:helioloureiro

Categoria: Linux Publicado: Domingo, 21 Julho 2013 Escrito por Helio Loureiro

Finalmente resolvi adicionar meu próprio PPA, Personal Package Archive - ou Arquivo de pacote pessoal, no Launchpad do Ubuntu. Isso vai me permitir distribuir facilmente os pacotes que crio. São para uso meu, baseado num Ubuntu LTS 12.04, mas podem ajudar mais pessoas.

Pra começar, fiz um upload do backport do python-twitter 1.0.1, que funciona com a API v1.1.

python-twitter_1.0.1-1_all.deb

Para quem desejar usar meu repositório, deve bastar adicionar o PPA.

sudo add-apt-repository ppa:helioloureiro

Minha chave PGP ainda não foi adicionada, mas isso deve ser corrigido em algum commit do sistema, o que talvez demore 1 dia. Até lá, meu pacote python-twitter não aparecerá como disponível.

Meu próximo upload deve ser dos pf-kernel. Já tenho compilado as versões 3.9.5 e 3.10.0.