|
|
|
|
|
Crónica de un hacker insatisfecho. El gran final.Sandino Flores, "Tigrux"Correo electrónico: tigrux arroba yahoo com ICQ 45507615 http://www.geocities.com/sandino_flores/ Creative Commons Reconocimiento-NoComercial-CompartirIgual 2.1
Sumario
Motivación.A menudo hemos descubierto programas muy interesantes o útiles para nuestra labor, y generalmente su interfaz de usuario está en idioma inglés. Y seguro hemos deseado verlo traducido al español, pero no sabemos cómo traducirlo porque pensamos que es muy difícil hacerlo. Así también, más de una vez encontramos programas muy interesantes pero que sólo se distribuyen como código fuente y nos sentimos intimidados, o bien quisiéramos hacer nuestros propios RPMs para facilitar el compartir esos programas o incluso programas nuestros. Traducir software no es algo a la ligera. No podemos dar por hecho que todos leen inglés. Piensen en los países españoles cuyo idioma bien puede ser el euskero, vasco o catalán. Y no vayamos tan lejos, aquí mismo en México hay comunidades que sólo hablan náhuatl,la segunda lengua más hablada en México, con más de un millón de parlantes. En comunidades y municipios latinoamericanos donde no se habla español, ya no digo inglés, el software libre se reviste de sus virtudes y el software propietario exhibe sus deficiencias. ¿Cuánto cobraría una empresa monopólica por crear versiones en náhuatl, zapoteco o quechua de sus productos? ¿Cuánto tardaría en entregarlo? ¿Pueden estas pequeñas comunidades darse el lujo de pagar por éso? Coincidirán conmigo que la economía de nuestros países no está como para desperdiciarse en enriquecer monopolios. ¿Y con el software libre? En este caso veremos que con el software libre, gracias a que disponemos del código fuente, la traducción a cuanto idioma se nos ocurra es muy sencilla, y no necesita sofisticados conocimientos de informática. A lo largo de este artículo seguiremos la senda típica de un hacker entusiasta, que partirá de evaluar un programa de su elección, y culminará con la incorporación de la traducción realizada al la versión oficial del programa en cuestión, de modo que todo el mundo se beneficie con nuestro esfuerzo. El equipoLas prácticas efectuadas para este artículo fueron llevadas fueron llevadas a cabo en la TigruXtatioN, la cual cuenta con Mandrake 8.1 con sus herramientas de desarrollo completas (gcc, autoconf, automake, make, etc) las cuales acompañan a una instalación típica de Mandrake, Ximian Gnome 1.4 con sus respectivas bibliotecas de desarrollo, y XFree 4.2 con sus respectivas bibliotecas de desarrollo. El escenario.Los pasos y situaciones se irán sucediendo en pasos, tal que cada uno de ellos representa una acción bien definida que nos vaya guiando en compilación o la traducción de algún programa GNU en particular. La fecha es febrero del año 2002. Asumiremos el papel de un hacker ordinario, apasionado de las computadoras y que vagabundea en la red en busca de material interesante. Nuestro hacker es muy amigo de estudiantes universitarios que cursan las típicas materias de química y física. Pero los amigos de nuestro amigo hacker saben muy poco de inglés y apenas se inician en linux. Nuestro hacker está deseoso de ayudarles a ellos y a su universidad, así que su búsqueda comienza, e inicia también nuestro camino a aprender a compilar, empaquetar, compartir y traducir aplicaciones. ¿Por qué he situado al hacker en un ámbito universitario? Por qué son las universidades las que más pueden beneficiarse de contribuciones como ésta, y el impacto de las universidades en la sociedad es enorme. La crónica
Nuestro aventurero hacker encuentra un programa interesante. Se ha interesado por Gnome Crystal , un programa de edición de modelos moleculares creado por Jean Bréfort, y las capturas de pantalla le muestran que es justamente lo que necesita para sus amigos. Las capturas están en inglés y francés, sospechamos que la barrera del idioma está presente y es nuestra intención derribarla, al menos en este caso. Lo siguiente que hacemos es descargar el código fuente: http://jean.brefort.free.fr/info/gc/gnome-crystal-0.4.1.tar.gz
Revisamos a fondo la página de gnome-crystal, y no encontramos que halla rpm, así que nos conformamos con el código fuente empaquetado con tar gz. Una vez que hemos descargado el código fuente, lo descomprimimos:
Entramos al directorio recién creado y miramos el contenido:
El contenido del directorio es el típico de un programa GNU. Leemos el archivo README y allí se listan las dependencias que requiere:
Entonces nos aseguramos de instalar estas bibliotecas así como sus respectivos devel. Leemos también el archivo INSTALL y y allí leemos que la compilación es de la manera usual. Entonces simplemente seguimos los pasos que allí se indican.
Dado que tenemos las bibliotecas de desarrollo necesarias, entonces esperamos una compilación satisfactoria y tras algunos minutos de compilación, estaremos ya listos para instalar. Pero en lugar de una instalación ordinaria, ejecutaremos una técnica que suele usarse en los programas GNU: redirigir la instalación. La finalidad de esta técnica aparentemente extraña es supervisar qué archivos son creados durante la instalación, a fin de que podamos crear un rpm como veremos más adelante.
Entramos al directorio donde redirigimos la instalación, y listamos su contenido íntegro de los archivos en ello contenidos, y enviamos la salida a un archivo para analizar posteriormente su contenido. Nota que al erchivo lo enviamos directamente al directorio anterior (/tmp en ste caso) para que no sea incluído dentro del listado.
Sin lugar a dudas, es más fácil para un usuario novel el instalar un paquete en rpm que seguir los pasos que vimos anteriormente. Pues bien, estamos cerca de crear un rpm. No pierdan de vista que la tarea de nuestro hacker es facilidar a sus compañeros químicos el usar este excelente programa. Y qué mejor manera de facilitar su distribución que distruibuírlo en forma de rpm. Sigamos entonces. Anteriormente creamos un archivo files.list, es hora de analizarlo. Mira dentro del contenido de este archivo y verás que contiene algo como lo siguiente:
Como te habrás dado cuenta, cada línea del listado comienza ya sea con /usr/ o con /etc. Pero lo más correcto es que no demos por hecho la ubicación de estos archivos, de modo que el rpm que crearemos sea lo más general posible. Entonces, la lista de archivos que pondremos en el rpm debe ser relativa a ciertos directorios de referencias. Esos directorios de referencia se obtendrán dentro del rpm mediante las variables %{_prefix} y %{_sysconfdir} . En realidad hay muchas más variables pero son ésas las más elementales a conocer. La primera de estas variables, %{_prefix} , se refiere a la ruta a partir de la cual se instalarán los programas y sus datos (imagenes, manuales,etc), y en los sistema compatibles con RedHat generalmente apunta a /usr . La segunda de estas variables, %{_sysconfdir} , se refiere a la ruta a partir de la cual se instalarán las configuraciones de sólo lectura, y en los sistemas compatibles con RedHat generalmente apunta a /etc. Podemos hacer las sustituciones, de /usr/ por %{_prefix} y /etc/ por %{_sysconfdir}, de manera manual con un editor de texto pero los linuxeros nos distinguimos por contar con herramientas para casi todo y ésta no será la excepción. La herramienta a usar es sed . sed es un editor de flujos, y tiene características muy poderosas pero explicarlas todas daría material para otro artículo. La forma más sencilla de usar sed es de la forma: sed -e s/sustuir_esto/por_esto_otro/ donde tomará como flujo de entrada la entrada estándar y el flujo de salida será enviado a la salida estándar. Por ejemplo:
Observen que tuve que separarlo en varias líneas para fines de presentación, pero pueden combinar las últimas tres líneas en una sola. Pueden leer más de sed en su respectiva página de manual con man sed. Revisamos de nuevo el archivo generado, y comprobamos que todo está en orden: los archivos están acomodados en rutas relativas a las variables que arriba quedaron explicadas.
Tenemos la lista de archivos que instalará el rpm, ahora falta un archivo que lleve la specificación del rpm. A éstos archivos de especificación de le llama specs. A continuación se muestra el spec que usaremos, y explicaremos sus partes
Ahora, la siguiente tabla explica términos del spec que tenemos tenemos que suministrar. En realidad un spec tiene muchísimos más términos que no usamos, pero la idea es mantener las cosas simples y nuestro hacker no es un gurú, es sólo un apasionado del software libre.
Ya tenemos el spec y lo guardamos como gnome-crystal.spec, y tenemos también el archivo files.list con los archivos que instala el rpm. Siendo superusuario, copiamos estos archivos dentro del directorio con el fuente del programa. Acto seguido comprimimos de nuevo el directorio del fuente. Una vez comprimido ya podemos proceder a generar el rpm con rpm -ta. Abajo ilustramos ésto.
Al final, nos creará dos archivos rpms, uno es un rpm con el fuente y el otro es un binario que ya podemos redistribuir. La ruta donde los genera depende de la distribución. Pero éso no es problema porque las últimas líneas de la compilación mostrarán donde son guardados esos rpms que generamos. En particular, en un sistema mandrake:
Hasta aquí, hemos creado el rpm del programa. Y aunque el método que usamos es muy sencillo, la verdad es que tiene algunas deficiencias: Luego, perfeccionaremos nuestro método para que deje de ser intrusivo. Lo que haremos será añadir un paso adicional en el que buscaremos expresar la lista de archivos usando comodines. Para ello, editamos el archivo files.list con algún editor de tu preferencia, por ejemplo gedit. Y simplificaremos su contenido usando comodines y nombres de directorio. El archivo original antes de hacer esas simplificaciones es el siguiente:
Después de la simplificación usando comodines, el nuevo contenido es:
Se ha enfatizado el uso del comodín * para mostrar que todo lo que hay dentro de %{_prefix}/share/ se expresa simplemente como %{_prefix}/share/*. Ya que tenemos la lista simplificada, la ponemos directamente en el
spec, de modo que ya no necesitaremos el archivo files.list,
ésto se hace simplemente editando el archivo gnome-crystal.spec
y sustituyendo la línea:
%filese incluso estaríamos tentados a sustituírlo por: %filespero ésto último no es recomendable porque es preferible tener los archivos binarios y los archivos de datos por separado. Compilar de esta manera es también muy sencillo. Primero tienes que localizar en dónde se localiza el directorio de fuentes de rpm para tu distribución. En mandrake la ruta está en /usr/src/RPM/SOURCES y en RedHat está ubicada en /usr/src/redhat/SOURCES . Darnos cuenta de ésto es muy sencillo. Simplemente entra al directorio donde está el spec ya corregido y trata de recompilar con rpm -ba , consulta la página de manual de rpm con man rpm para consultar más opciones. Asegúrate primero de que el propietario del spec y del fuente sea el usuario root, o de otro modo te marcará errores de propietario equivocado. Veamos ésto en detalle.
De ver el mensaje de error, entonces sabemos dónde copiar el archivo, y lo copiamos para luego compilar. Casi hemos concluído con el tema del empaquetado. Sólo resta recordarles que los rpms binarios se instalan con rpm -Uvh archivo.i686.rpm y los rpms de código fuente se recompilan con rpm --rebuild archivo.src.rpm.
Ya instalado, buscamos el ejecutable. Es fácil encontrarlo porque generalmente se instalan en el directorio de binarios. Ya identificado, simplemente lo ejecutamos y lo veremos en acción.
Si he escrito i686 es porque la máquina de las pruebas es un Pentium3. Lo más común es que los paquetes oficiales de RedHat estén compilados para i386 y que los de mandrake estén compilados para i586. Si algún paquete o biblioteca requerido no está instalado, entonces se le indicará. Por supuesto, no pueden instalar un rpm binario de una arquitectura que no sea compatible con otra; por ejemplo, no pueden instalar un paquete compilado para ia64 (Itanium) en un i586 (compatibles con Pentium). Algunas veces verán rpms para la arquitectura noarch , ésto es porque no son independientes de la arquiotectura. Es muy común que programas interpretados como los escritos en Perl, Java ó Python se presenten de esta manera. Pero no nos olvidemos del contexto. Nuestro hacker ya tiene los ansiados rpms que suministrará a sus amigos, y ya sabe cómo generarlos, recompilarlos e instalarlos. Pero aun está presente la barrera del idioma. Aun hay camino por recorrer.
El siguiente paso de nuestro amigo, que más que hacker ya parece fakir, es hacer la traducción. Ya vimos lo importante que son las traducciones, y ahora aprenderemos a realizarlas. Pero para ello necesitas saber exactamente qué es lo que vas a traducir. ¿Piensas que tendrás que sumergirte en un mar de código fuente y estar reemplazando, cadena por cadena del fuente, con paciencia de relojero? Te equivocas, y como verás, realizar una traducción es algo sumamente sencillo, y cualquiera puede hacerlo. Lo primero es localizar la plantilla o patrón de cadenas que vas a traducir, ésta se encuentra, generalmente, en el subdirectorio po/ del código fuente y lleva el mismo nombre que el programa y lleva la extensión .pot. Así, sabemos que debemos buscar gnome-crystal.pot.
Si revisas este archivo con algún visor de texto, verás que es simple texto con un cierto formato: una cabecera con información del proyecto, autor y traductor(es) y después una larga suceción de identificadores y cadenas a manera de diccionario. Por ejemplo, un par de estas entradas son:
Como te darás cuenta, la entrada msgid se refiere a la cadena que buscas traducir, mientras que la entrada msgstr se refiere a la cadena traducida al idioma en cuestión. Hay varias opciones para hacer estas traducciones: Procedemos a descargar gtranslator y lo instalamos. En la página de descarga ya se suministran rpms o bien pueden contruir el suyo desde las fuente usando la técnica ya vista antes de empaquetado . Copiamos la plantilla a un archivo que tenga el mismo nombre que el código del idioma que deseamos y su extensión será .po, entonces para nuestro caso el archivo será es.po . Ahora ejecutamos gtranslator para editarlo.
El resto es fácil, sólo tienes que rellenar los formularios y traducir los mensajes al español. Advertirás que gtranslator te muestra cuales son los mensajes sin traducir,  El diálogo de informacion general de la traducción  GTranslator en acción Al cabo de algunas consultas al diccionario, preguntarle a amigos, revisar foros, y algunos cientos de palabras traducidas, por fin habremos finalizado la traducción de todas las cadenas. Para un programa relativamente pequeño como gnome-crystal, esta traduccion se hace en cosa de unas 4 horas o menos si sabemos teclear muy rápido. Ahora hay que incorporar al programa estos cambios. Dentro del directorio con el fuente, edita el archivo configure.in y déjate guiar por el instinto para buscar una cadena que intuyas que contiene la lista de traducciones. Excelente, el instinto te ha guiado e identificas la cadena en la línea 29. Modifica esta cadena para que le añadas es. Entonces la cadena debe decir:
Hecho éso, ahora tienes que regenerar el configure, es muy fácil y sólo tienes que ejecutar autoconf. autoconf lee los archivos de especificación que distingue porque tienen extensión .in, esta información le sirve para construir el famoso configure, el cual lleva a cabo la comprobación de programas y bibliotecas necesarios para compilar, detección del tipo y configuración del sistema, sólo mencionar algo de lo mucho que puede hacer. Regenerar el configure es necesario porque has modificado uno de los archivos de configuración. Ahora puedes revisar que todo haya salido bien. Regenera el rpm como hemos visto y comprueba que la traducción está bien realizada. No es de extrañar que tengas que revisar algunas cadenas porque algunas cosas no siempre quedan bien al disponerse en la interfaz de usuario.
Una vez que estés conforme con la traducción, aun hay un detalle desagradable: hemos modificado el árbol con código fuente, lo cual sabemos que no es correcto. Por lo general, las modificaciones a los códigos fuentes se almacenan en archivos a los que se denomina parches. Un parche no es otra cosa que un archivo conteniendo listas de cambios al código fuente, su contenido se puede expresar coloquialamente con la siguiente frase: De este archivo, quítale estas línea y ponle estas otras; y así para cada archivo que hallas modificado.Puede parecer graciosa esta metáfora, pero un parche realmente contiene la informacion en una forma muy parecida a la expresión coloquial anterior. Procedamos a contruir el parche. El código fuente que has modificado yace en un directorio, entonces muévelo a otro directorio con un nombre parecido. Ahora, nuevamente descomprime el fuente original tal que ambos directorios de fuentes estén en el mismo directorio padre. La utilería que usaremos para este caso se llama diff. diff , como indica su nombre, analiza las diferencias entre archivos o directorios y envía las diferencias a la salida estándar. Como todo programa GNU, tiene muchas opciones pero nosotros sólo ocuparemos-r que es para buscar diferencias recursivamente dentro de directorios, -u que presenta la salida en un formato común a otros programas similares, y -N para que además considere diferencias en la estructura de directorios. Es común comprimir los parches con el habitual gzip porque éstos suelen ser muy grandes pero fáciles de comprimir. Menos palabras y más acción:
Ya tenemos el parche, aplicar un parche es muy sencillo. Basta con colocarte en el directorio con el fuente original, ejecutar un simple comando y con éso tendrás dos directorios idénticos. En el siguiente ejemplo, parcharemos el directorio fuente original para hacer que tome nuestros cambios. Consulta la documentación de patch para saber qué opciones tiene y cómo usarlas.
Ya sabemos usar parches. Ahora tenemos que modificar un poco el spec para adecuarlo a los nuevos cambios. Como te darás cuenta, ahora nuestro spec depende de dos archivos fuente: uno con el fuente original y otro con el parche nuestras modificaciones.
Hubo cambios, en la siguiente tabla los explicamos:.
Regeneramos el rpm como ya sabemos, y obtendremos:
Lo instalamos y ejecutamos:
La aplicación está ya compilada, traducida y empaquetada en rpm. ¿Entonces qué es lo que molesta a nuestro valiente amigo? Le incomoda pensar que su trabajo sea en vano, y desea compartirlo con el mundo para que así sucesivas versiones de gnome-crystal incorporen su contribución. Respiren tranquilos, esto es muy breve. Tenemos los frutos de nuestro trabajo: un spec para hacer el rpm y el parche. El resto es sencillamente contactar a los autores. Los programas GNU más grandes constan de una estructura de desarrollo concurrente de versiones, y en esos casos lo que debe hacerse es entrar a la página del proyecto, suscribirse a la lista de desarrolladores y enviar a esa lista el parche y demás contribuciones que hayamos hecho. Dependiendo de la ocupación de los jefes de proyecto y del tráfico de la lista, ésto puede demorar desde unas cuantas horas hasta varios días. Y en los programas más pequeños como gnome-crystal, basta con contactar directamente al autor por correo, avisarle de los cambios y hacerle llegar los parches de algún modo acordado. Para concluirésto que les he narrado fue escrito por su servidor El Tigrux. Todo transcurrió en algunos días de febrero y en realidad el trabajo duro fue la traducción, pues el resto de los puntos explicados son muy fáciles y rápidos de llevarse a cabo. En esos días de febrero, la versión actual de gnome-crystal era la 0.4.1, y al momento de escribir este artículo va ya en la versión 0.4.3. La traducción al español ha sido ya incorporada al código fuente oficial y felizmente ya tenemos gnome-crystal en español para todo aquel que lo descargue. Realmente aprendimos muchas cosas en este artículo. Vimos desde la elemental compilación, pasando por utilerías GNU hasta la traducción, que realmente siempre fue el fin. Concluímos que si bien modificar programas GNU es muy fácil, en realidad hay un gran acervo de conocimiento necesario, pero es bastante fácil de adquirir, recurriendo a las páginas de manual, foros de desarrolladores e incluso husmeando en el código fuente de tantos programas GNU de que disponemos. gnome-crystal fue elegido para ser traducido porque su código fuente es pequeño y aun tiene todas las características de un buen programa GNU y sobre todo de un buen programa Gnome. Además de ser enormemente útil para fines didácticos. Pero en realidad lo visto aplica a cualquier programa GNU/Gnome y el escenario es por supuesto a libre elección. Como habrán advertido, no programamos ni una sola línea de código. Ésto demuestra que no es necesario ser experto programador para hacer importantes contribuciones. Acerca del autorEl Tigrux es editor de LinuxParaTodos y pueden contactarle en <tigrux arroba linuxparatodos punto com> ó directamente en ICQ 45507615 |
 |
 |
|
| Derechos de autor © 2005 Linux Para Todos Todas las marcas y derechos en esta página son de sus respectivos dueños. Puede sindicar nuestros titulares a través de nuestro fichero RSS. |
|
