Freak, as in freakdom

Um blag sobre cultura, política, memes e… software livre!

Arquivo da tag ‘gnu/linux’

Maldito ć

Não é a primeira vez que me deparo com um GNOME com língua padrão inglês em que, após configurar o teclado como US International, a combinação de teclas ‘ (acento agudo) e c gera um ć. Isso ocorre porque o GNOME (em inglês) não sabe em qual língua seu suposto usuário irá escrever. Por decisão de alguém que com certeza não fala português, a opção padrão ficou ć.

Para habilitar o ç, basta dizer para o GNOME que o inglês deve estar no grupo das línguas que o utilizam como padrão. No gNewSense (a distribuição 100% software livre que utilizo em meu lemote), basta editar o arquivo /usr/lib/gtk-2.0/2.10.0/immodule-files.d/libgtk2.0-0.immodules (ou algo que o valha, a versão da GTK pode mudar em seu sistema) com qualquer editor de texto, como o gedit. Nesse arquivo, no segundo bloco de configurações (ou outro, basta atentar para o im-cedilla.so), adicione :en ao final da linha, dentro das aspas:

“/usr/lib/gtk-2.0/2.10.0/immodules/im-cedilla.so”
“cedilla” “Cedilla” “gtk20″ “/usr/share/locale” “az:ca:co:fr:gv:oc:pt:sq:tr:wa:en

Encerre sua sessão e logue novamente. Divirta-se com seu ç. Ah, e se alguém souber como fazer o ć depois disso por favor me avise, pois deu o maior trabalho fazer esse post… er… acho que não vou mais precisar do ć!

Obs: não testei, mas isso deve funcionar em qualquer outra distro, como Ubuntu e Debian. Também não descobri como fazer isso na interface gráfica (mudar a língua padrão do sistema com certeza resolve, mas queria ficar com a interface em inglês).

nenhum comentário

Escrito por Rodrigo R. Silva

abril 30th, 2010 at 7:36 pm

Compilando o OpenOffice

Hoje à noite, em um momento iluminado (depois de ler um e-mail do Juca entitulado “algumas coisas demandam coragem”, sugerindo o que se segue), pensei: bom, se eu já uso as versões de desenvolvimento do Firefox e do Thunderbird cotidianamente, por que não o OpenOffice? Afinal, qual a graça de usar um OpenOffice 3.1 estável?!

Há cerca de dois anos eu tentei completar esse rito de passagem: na época ainda usavam CVS. Um grande problema de CVS em tutoriais é que sempre colocam umas linhas de comando do tipo:

cvs -d :pserver:anoncvs@anoncvs.services.openoffice.org:/cvs checkout [modulename]

e nunca nos dizem o que colocar em [modulename], o que acaba por custar ao benevolente hacker mais duas horas varrendo o repositório em busca do módulo correto. Além disso, era necessário baixar e compilar separadamente todo o build system do open office.

A boa notícia é que a cada major version o OpenOffice.org tem refeito o seu build system, para melhor. Além disso, descobri que nesses dois anos eles passaram o repositório de código pelo svn e finalmente adotaram o mercurial em outubro de 2009.

Fazer um checkout de todo o repositório mercurial seria muito demorado, e por isso eles disponibilizam um bundle diário do repositório, isto é, um arquivo com todo o repositório empacotado.

Hora de se sujar: baixe o bundle , “unbundle” e “update”:

sudo apt-get install mercurial (caso não tenha o mercurial instalado)
mkdir devel && cd devel (ou como vc quiser chamar o seu parque de diversões hacker, caso ainda não o tenha)
wget http://hg.services.openoffice.org/bundle/DEV300.hg
mkdir openoffice
cd openoffice
hg init
hg unbundle ../DEV300.hg
hg pull http://hg.services.openoffice.org/DEV300
hg update

Além do tempo de baixar o bundle, que tem quase 1GB, o resto do processo demora cerca de 30 minutos.

De agora em diante, você é livre para compilar como quiser, com os itens opcionais que quiser (ou não). Vou apenas reproduzir o que eu fiz para executar um full build padrão, já que os tutoriais oficiais nunca são suficientes. Tudo isso foi executado em um Ubuntu GNU/Linux 9.04 (jaunty) 64bits, e pode mudar ligeiramente de distribuição para distribuição. Caso você use uma distribuição que não seja derivada do Debian (isto é, sem apt), use o gerenciador de pacotes padrão da sua distribuição. Os pacotes devem ter nomes iguais ou parecidos.

Dependências

No tutorial disponível no wiki eles sugerem algumas dependências:

  • glibc:
    for OOo<=3.1: 2.2.x or higher for OOo>3.1: 2.3.2 or higher
  • C/C++ Compiler:
    gcc >= 3.3
    gcc 4.2.3 is the current reference compiler
  • The X11 development libraries and header files
  • PAM including the development headers
  • bash
  • gtk2 and libtiff including the development headers

Se você não estiver usando um Debian Sarge da vida, ignore e prossiga. Ah, caso você não tenha o gcc instalado, 1. você não devia estar aqui (bazzinga!) 2. já que está aqui, rode um sudo apt-get install build-essential e seus problemas acabaram.

Isso é uma mão na roda para instalar a maioria das (infinitas) dependências:

sudo apt-get build-dep openoffice.org

Como de praxe, há coisas novas em relação à versão estável que obviamente o build-dep não pegou:

sudo apt-get install mingw32 libgraphite3 libgraphite-dev

De volta ao seu diretório openoffice:

./configure --with-use-shell=bash --with-system-libs --without-system-jars --without-system-icu --without-system-agg --without-system-lpsolve --without-system-mspack --disable-mozilla --with-mingwin=/usr/bin/i586-mingw32msvc-g++

Isso diz aos scripts de compilação para utilizarem o maior número possível de libs do sistema e evitar incompatibilidades. O palavrão /usr/bin/i586-mingw32msvc-g++ é para o cross-compilador mingw32, necessário para cross-compilar algo que não sei o que é. Ao final, veja se não ocorreram muitos warnings e se aparece a seguinte mensagem:

Configure completed
You may now run ./bootstrap in [pasta onde estão os sources]

Agora, com as variáveis de sistema configuradas, precisamos gerar os scripts de compilação (Makefiles):

./bootstrap
source LinuxX86-64Env.Set.sh

(ou source LinuxX86Env.Set.sh se seu processador for 32 bits)

Agora, aos finalmentes

Tendo configurado as variáveis de ambiente e gerado os build scripts, vamos à compilação:
time make

# vá tomar um chá que vai demorar (eu fui!). O time antes do make vai marcar o tempo gasto na compilação.

Depois do chá

Se tudo correr bem, depois do seu chá e mais algumas horas você chegará em algo assim:

***********************************************************
Successful packaging process!
***********************************************************
... creating log file log_DEV300_en-US.log
Fri Feb 5 12:30:15 2010 (00:07 min.)
real 357m1.283s
user 274m55.902s
sys 42m31.595s
rodrigo@snowball2:~/devel/openoffice$

Sim, foram 6 horas mesmo. Isso num Intel Core2 Duo T7250 2.00GHz com 4M de cache, mas utilizando apenas um núcleo. Coloque aí nos comentários os seus resultados para compararmos.

Caso você tenha um processador com dois ou mais núcleos, é possível fazer um build paralelo, que teoricamente iria mais rápido. Eu estava fazendo outras coisas no computador, então me contentei com um único core compilando o bichinho. No link ao final da página há instruções sobre como fazer isso, entre outros hacks.

Como executamos um full build, o processo gerou pacotes prontos para instalação. Os pacotes para GNU/Linux 64bit ficam em ~/devel/openoffice/instsetoo_native/unxlngx6.pro/OpenOffice/deb/install/ (para 32bits é unxlngi6.pro ou algo que o valha). Na pasta en-US_download há um tar.gz que pode ser distribuído. A pasta en-US possui o mesmo conteúdo, porém não compactado.

Instalação

Como executamos um build padrão, o configure gerou os pacotes nativos da distribuição: .deb. Caso você queira instalar o OO que compilou (óbvio que quer!) será necessário remover o OpenOffice que vem com a distribuição (se souber como gerar o build desempacotado e evitar isso, por favor faça um comentário).

sudo apt-get remove openoffice.org-common
(Caso você não remova o open office atual, pode haver conflito de pacotes. Remova!)

cd ~/devel/openoffice/instsetoo_native/unxlngx6.pro/OpenOffice/deb/install/en-US/DEBS
sudo dpkg -i *.deb (pacotes do OO.org)
cd destop-integration
sudo dpkg -i *.deb (ícones no menu do KDE/GNOME)

Lembre-se de autalizar o código (hg pull && hg update) e recompilar (make) de tempos em tempos. A linha de desenvolvimento está em constante… desenvolvimento (!), e se sua intenção vai além de fazer uma graça é importante estar com o código em dia. Vale lembrar que, a princípio, os rebuilds devem demorar muito menos, pois apenas os arquivos modificados (e os dependentes deles) são recompilados. Veja o link abaixo para maiores informações.

Agora, se suas intenções são realmente corajosas e vão além de testar e reportar bugs, entre na lista de e-mails dev@openoffice.org, dê uma olhada no bugtracker e na página de TODO’s. O wiki também é um ótimo ponto de partida.

happy hacking!

Referência:
http://wiki.services.openoffice.org/wiki/Documentation/Building_Guide/Building_on_Linux

© 2010 Rodrigo Rodrigues da Silva. Este texto pode ser compartilhado sob os termos da licença Creative Commons By-Sa

nenhum comentário

Escrito por Rodrigo R. Silva

fevereiro 5th, 2010 at 7:24 am

Criptografando arquivos com GNU GPG


Hoje eu precisei enviar um arquivo com informações confidenciais através da Internet. Como a única alternativa para o envio era deixá-lo em um servidor público para que o receptor fizesse o download posteriormente, a solução simples e óbvia era criptografá-lo. Em alguns milissegundos o oráculo me mostrou um resultado já esperado:  The GNU Privacy Guard ou, simplesmente, GPG. O GPG é um Pacote GNU que implementa o padrão OpenPGP.

Para criptografar um arquivo com uma chave simétrica (isto é, uma chave que deve ser compartilhada (por um meio seguro) entre remetente e destinatário), é simples:

gpg -c nomedoarquivo

Será requisitada uma senha. Um novo arquivo, nomedoarquivo.gpg, criptografado, será criado no mesmo diretório. Para descritpografá-lo,

gpg nomedoarquivo

O GPG, que é apenas uma interface de linha de comando, possui muito mais recursos, entre eles criptografia assimétrica. No entanto, diversas aplicações gráficas fazem o uso dele como backend.

nenhum comentário

Escrito por Rodrigo R. Silva

dezembro 23rd, 2009 at 7:16 pm