New TORCS with GNU autotools fun and even d-i manual work
So far after almost a whole week dealing with the joy of the funky set of tools for programs building that are automake, autoconf, libtool, aclocal working together (sanely) with cdbs and the tarball/makefile class, I've managed to get a sane new TORCS package for version 1.2.3 ready, although had to do nasty hacks to rules, evil me, anyway they were kindly uploaded to experimental by Anibal.
It was fun to deal with automake and the others, although kinda painful, but
fun at the end! (yeah call me sadistic). Still working on a complete new set
of automake files for generating TORCS Makefile's since upstream ones are
hand made and not so sane. I'm glad upstream is able to cooperate and was
most likely to accept the contribs I've sent, very sexy and warming feeling!
Well if you want to test the new packages from experimental, just
type # apt-get install torcs -t experimental, of course you'll
need to have an experimental entry on your /etc/apt/sources.list.
d-i manual ... one more time, well joeyh did it again :) so we started as crazy after Frans Pop call for revision/update of spanish translation for d-i manual, good news are that some people from the spanish l10n list were starting to review the manual and their work was/is very helpful, so far I've managed to sanitize some documents and also found how bad were some translations I've made (shame on me), it seems that re-reading them after a while does help to produce a better and clear wording, also proofread it. So, I'm still working on them since, as joeyh said, they are most likely the ones to be shipped with sarge. Did I said sarge? :)
...
sufro de lagunas mentales
producto de excesos de alcohol
abuso de algunos calmantes
porque me olvido el mañana
...
- Fuckin Sombreros
Contribuir con el software libre
Hace unos días Antonio menciono sobre el hecho de informar a los desarrolladores acerca de fallos en los programas de software libre que utilizamos.
Ciertamente parte importante de lo que es la comunidad de software libre, es justamente la retroalimentación que existe entre usuarios, desarrolladores y personas involucradas en los proyectos, tal es el caso del proyecto Debian donde muchos desarrolladores principales (término para no confundir con «desarrollador de Debian») muestran su agrado y gusto de trabajar o tener un proyecto de software libre como es Debian, de cual sus desarrolladores envían informes de fallos, parches, traducciones, etc, de esta forma se establece una interacción productiva entre ambos. Para los desarrolladores de software libre este tipo de cosas o hechos son los que los animan a mejorar y seguir desarrollando el proyecto en el cual han puesto su esfuerzo, y muy gustosos en recibir este tipo de contribuciones. Es por eso que muchos de ellos manifiestan su gusto por Debian, tanto como proyecto y sistema operativo, tal vez esto sea una de las razones por la que algunos, erróneamente, piensan que Debian GNU/Linux es una distribución solo para desarrolladores.
El informar fallos, ya sea en software, traducciones, erratas, e incluso el simplemente solicitar añadir una nueva característica o funcionalidad a un determinado proyecto de software libre va a repercutir finalmente en que éste mejore. Muchas personas usuarios de software libre (no digo comunidad todavía, ver más adelante) muchas veces efectúan modificaciones y cambios a los programas para adaptarlos a sus necesidades o solucionar un asunto en particular, pero no reparan de que este caso (aunque parezca único, irrelevante, ridículo, sui-generis, etc.) puede servir a otra persona quien también necesite esta funcionalidad, aprender como se hacer, o simplemente para evitar la duplicidad de esfuerzos, puesto que si uno informa de una anomalía los otros usuarios sabrán que el software tiene tal problema y así se evita el que cada uno de ellos pierda tiempo en identificar el problema, cuando en el mejor de los casos podría enfocarse en buscar la solución y enviar el parche o corrección al desarrollador principal o proyecto.
Pienso que si un usuario de software libre esta en la posibilidad de enviar o efectuar cualquiera de las acciones para contribuir a mejorar el software que utiliza y no lo hace pues, en mi opinión personal, no es parte de la comunidad de software libre, no está contribuyendo a su desarrollo y simplemente ha cambiado de un modelo donde no podía hacer los cambios directamente pero igual guardaba para si el conocimiento de como efectuar tal o cual acción, a un modelo donde los puede hacer pero igual no comparte el conocimiento de como hacerlo, por consiguiente la cultura del egoísmo y falsa idea de que ocultando cierta información lo convertirá en un «guru» al ser el «único» que sabe como hacerlo, es totalmente equivocada y que este tipo de personas no ha entendido la idea del software libre.
Probablemente algunos podrán alegar que el tiempo invertido en aprender y encontrar la solución al fallo o problema ameritan el que tengan esta actitud, bueno, los desarrolladores del software en cuestión invierten mucho más tiempo (y recursos) en crearlo y ponerlo a funcionar, y además, mucho más importante, entregarlo libremente para cualquiera. Creo que el analizar cual de los tiempos es más valioso es irrelevante, aunque la respuesta sea obvia.
En nuestro medio todavía no he visto una cultura sobre el tema, precisamente por eso que escribo al respecto, si he visto algunas iniciativas individuales esporádicas, espero que esto mejore. A propósito, una de las ideas principales para la creación del grupo Debian Peru fue el incentivar este tipo de contribuciones hacia la comunidad, pues realmente muchas de ellas son demasiado triviales como para no hacerlas.
Y como tenemos que ser útiles y contribuir, aquí un minicomo de
como efectuar este tipo de contribuciones.
¿Cómo contribuir con el software que utilizo?
Primero tenemos que definir que podemos contribuir al proyecto o
software que utilizamos. Las áreas usuales son:
- informar fallos: esto es obvio, se trata de informar sobre algún defecto o problema encontrado al momento de instalar, usar o modificar el software.
- parches: se refiere a envío de mejoras, que pueden ser en el código mismo, añadir una funcionalidad (por ejm. soporte de internacionalización), o corregir algún fallo encontrado o que ha sido informado.
- traducciones: efectuar la traducción para el idioma que uno domine
- corrección de erratas (traducciones): esto es algo que realiza muy poco pero es importantísimo, se trata de enviar las erratas (errores de traducción) a los traductores para que puedan ser incluidos en la próxima versión del documento o software.
- informes de éxito: esto es algo que tampoco se acostumbra pero es útil, se refiere a informa sobre el éxito al instalar/usar una nueva versión del software, efectuar una migración desde una versión anterior, o simplemente algo como informar sobre el éxito al configurar el software con un nuevo dispositivo oficialmente no soportado.
- confirmación o nuevos datos sobre un fallo en particular: esto es similar al anterior con la diferencia de que se trata de confirmar la existencia de un fallo que ha sido informado, y ofrecer más datos los cuales puedan servir a los desarrolladores para identificar y corregir el problema.
Ahora, como efectuar cada una o alguna de ellas si se da el caso. Los proyectos de software libre usualmente tienen hasta 4 vías para recibir contribuciones, siendo el correo electrónico el más usual, seguidamente están las herramientas o sistemas de seguimiento de fallos, formularios en sitio web y finalmente canales de IRC.
Es preciso entonces identificar cual de éstas ofrece el proyecto o software que utilizamos, generalmente cuando instalamos un software determinado éste incorpora un fichero «README» o similares, en éste podemos encontrar la forma de contactar con los desarrolladores o el método para informar fallos o contribuir; en algunos casos solamente tendremos la dirección electrónica del desarrollador la cual puede estar en el fichero «AUTHORS», «INSTALL» o «ChangeLog». Por último el sitio web donde se descarga el software usualmente tiene referencias al respecto.
Identificado esto, simplemente debemos escribir el informe o directamente enviar la contribución al proyecto o desarrollador. Hay que notar que el idioma comúnmente usado para esto es el inglés, aunque esto puede significar una barrera, no es muy complicado tampoco pues los datos son en mayoría información técnica. Proyectos como Debian o GNOME tienen una infraestructura para este tema, la cual cuenta con clientes que ayudan a recolectar información pertinente respecto al problema o programa afectado y la adjuntan al informe que se envía. Si no sabia de ésto, puede hacer inmediatamente
# apt-get install reportbug bugbuddy en su
sistema Debian GNU/Linux ;)
Como recomendación final, aunque este ha sido bastante resumido y he intentado ser breve, es importante identificar y enviar la contribución al canal adecuado, me refiero a que en algunos casos una corrección de errata de una traducción se debe enviar a la última persona que revisó o efectuó la traducción y no al desarrollador(es) del proyecto.
Así que ya lo saben: «Join us now and share the software (and patches), you will be free hackers, you will be free!» / «Únetenos y comparte el software (y parches), serán libres hackers, serán libres!»
Antonio, por cierto: aspell existe desde varios años y
puede ser usado como aplicación o incorporado (empotrado) dentro de otros
programas. Creo que tendrías que haberlo activado en tu cliente de correo ;)
Rudy en modo BOFH hubiese cerrado el fallo, con respuesta: «plz» :D (j/k)
angelito
Rudy fue al XII CONEIS, conocio un angelito, se enamoro ...
Quiero decirte que es maravilloso el haberte encontrado y nuevamente seamos uno, te amo.
cdbs
xfce4-goodies, estuve usando mucho dos herramientas que me han
parecido sumamente útiles y me he quedado encantado con ellas. Una de ellas,
de la cual hablare ahora, es
cdbs, la otra es
svn-buildpackage, pero lo dejo para después.
¿Qué es CDBS?
CDBS (common build system
for Debian packages), es un sistema de construcción de paquetes basado en
Makfiles, el cual es extensible y permite modificar los valores
predeterminados que se requieran para adaptarlos a la necesidad específica.
En términos más concretos, es una serie de reglas comunes predeterminadas
y adecuadas para el fichero debian/rules con los cuales
se construiran los paquetes, como por ejemplo las de debhelper.
Un fichero debian/rules, además de ser un Makefile, tiene una
serie de objetivos los cuales tienen ordenes que son ejecutadas por
dpkg-buildpackage para construir el paquete. Usualmente las
reglas son similares para la mayoría de los paquetes, es justamente por esto
que fue creado, la reglas de CDBS se pueden modificar en caso se
requiera especificar una orden en particular para construir nuestro paquete.
Como ejemplo, un fichero debian/rules usando CDBS, es simplemente:
#!/usr/bin/make -f include /usr/share/cdbs/1/rules/debhelper.mk include /usr/share/cdbs/1/rules/autotools.mkMientras que un fichero similar usando el método tradicional es:
#!/usr/bin/make -f
package=foo
export DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
export DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
build: build-stamp
build-stamp:
dh_testdir
./configure --prefix=/usr
$(MAKE)
touch build-stamp
clean:
dh_testdir
dh_testroot
rm -f build-stamp install-stamp
$(MAKE) distclean
(continúa ...)
Como ven la diferencia es notable, aunque parezca intrigante al
principio. Obviamente el paquete debe tener cdbs como
dependencia para construir (Build-Depends:)
Lo interesante de CDBS y por lo que me ha atraido bastante es que permite tener un control y mantener el paquete fuente bastante limpio y ordenado. Por ejemplo los parches se pueden aplicar al momento de la construcción del paquete, con lo que uno sabe cuales han sido efectuados y tiene mejor control sobre éstos para posteriormente enviarlos al desarrollador principal (de ser el caso).
Ya he adaptado TORCS (nueva versión) a CDBS con muy
buenos resultados, de hecho la regla tarball.mk me sirve mucho
puesto que el desarrollador principal entrega ficheros fuente de una forma
"peculiar" los cuales anteriormente reempaquetaba en forma manual, con la
posible duda sobre su confiabilidad, puesto que estaba generando otro paquete
fuente .orig y no habia forma de comprobar si el md5sum es el
mismo que el de los fuentes originales. Ahora, solamente creo un fichero tar
conteniendo los fuentes de desarrollador principal en su formato original
(también tar comprimido con gzip) y la regla se encarga de hacer el trabajo
de desempaquetar estos al momento de construir el paquete Debian.
CDBS es usado para construir los paquetes de GNOME, Xfce y otros.
Hasta donde lo he usado he encontrado las siguientes pros y contras:
Pros:
- Orden en gestión de paquete fuente
- Simplicidad en creación y mantenimiento de fichero
debian/rules - Excelente para gestión de parches
- Se integra muy bien con
svn-builpackage
Contras:
- El proceso de aprendizaje inicial puede resultar desalentador, pues ...
- No existe mucha documentación obvia, uno tiene que deducir muchas cosas
- Requiere un conocimiento mas o menos bueno de como funcionan los ficheros Make
Es posible que cambie todos mis paquetes a este sistema, pues me resulta mas cómodo, práctico y sobre todo ordenado de trabajar.
categorías
- /FreeSoftware (26)
- /chicha (13)
- /culture (1)
- /debian (41)
- /dump (13)
- /es-debian (12)
- /inspiracion (25)
- /life (23)
- /music (13)
- /vegan (5)
tag cloud
archivos
» 2008Apr (1)
Mar (1)
Jan (2)
» 2007
Oct (2)
Aug (2)
Jul (1)
Jun (4)
May (3)
Apr (1)
Feb (3)
Jan (3)
» 2006
Oct (2)
Sep (2)
Jul (2)
Jun (7)
May (8)
Apr (4)
Mar (11)
Feb (4)
Jan (2)
» 2005
Dec (8)
Nov (4)
Oct (8)
Sep (7)
Aug (9)
Jul (6)
Jun (3)
May (3)
Apr (6)
Mar (4)
Feb (4)
Jan (6)
» 2004
Dec (8)
Nov (9)
Oct (14)
Sep (5)
Aug (10)
May (1)
Apr (10)
Mar (14)
Feb (25)
» 2003
Dec (3)
Nov (4)
Oct (3)
Aug (2)
Jul (3)
Jun (4)
May (8)
Apr (4)
Mar (7)
Feb (5)
