El Demonio Negro

Hello fellows.
My latest adventure was about moving a project (unmaintained) from its public subversion repository which of course I was not admin (which means no admin access) over to my own server.

Usually, to do this you’d dump the whole thing with svnadmin into one file (svnadmin dump > file_dump) and load it again at the new location (svnadmin load file_dump). After searching for any similar command without admin access into documentation I figured that something similar might exist for plain svn to svn migration.
I founded a ruby version and a python. I chose python one because it’s recent, it’s python and it’s under google code site.
There was other cause, the ruby version went through all revisions, from 1 till infinity, although many of them didn’t have any change. In the other hand, python version uses subversion logs and made a efficient use of it.

The real action

Create a repository in my server was easy:

root@aristoteles:/var/lib/svn$ rm -rf MY-PROJECT-PATH
root@aristoteles:/var/lib/svn$ svnadmin create MY-PROJECT-PATH
root@aristoteles:/var/lib/svn$ chgrp svn-user MY-PROJECT-PATH/ -R
root@aristoteles:/var/lib/svn$ chmod g+ws MY-PROJECT-PATH/ -R
root@aristoteles:/var/lib/svn$ chmod o-rx MY-PROJECT-PATH/ -R

After solving the problems I talk about, duplicating the repo was not so difficult.

user@othermachine:~$ mkdir tmp
user@othermachine:~$ cd tmp
user@othermachine:~$ svn co URL-DEST-MY-PROJECT-PATH
user@othermachine:~$ python svn2svn-0.1.1.py -r 7382 URL-ORIG URL-DEST-MY-PROJECT-PATH

This process took a while but the new directory was now ready for action.

Be careful with your subversion config files. It may cause conflicts with file in repositories.
As an example, I had some troubles because I use to ignore files like Makefile.in and so. The project I was trying to import did have files like that and svn2svn did bring svn errors because those files were not under revision. When I realized I modified my subversion config without that rules for a while.

References and links

• svn2svn

A simple command line tool called mpy-svn-stats give us nice graphics using svn XML output.

You can see an example GLKM project statistics

It’s quite easy to use, see:

user@machine:/var/www/svn-stats$ mpy-svn-stats -o ./ svn+ssh://localhost/var/lib/svn/glkm/
Will generate PIL graphs.
getting data
running command: “svn -v –XML log svn+ssh://localhost/var/lib/svn/glkm/”
[...ssh stuff...]
done
parsing data
done
calculating stats
done
writing data
done
Have 13 stats objects, 13 of them are wanted.
user@machine:/var/www/svn-stats$ ll
total 48
-rw-r–r– 1 user user 10379 2008-02-06 17:06 changed_paths_multi_author_graph.png
-rw-r–r– 1 user user 10268 2008-02-06 17:06 commits_group_multi_author_graph.png
-rw-r–r– 1 user user 11762 2008-02-06 17:06 index.html
-rw-r–r– 1 user user 10265 2008-02-06 17:06 log_message_length_group_multi_author_graph.png
user@machine:/var/www/svn-stats$

References and links

• project web page mpy-svn-stats

En esta entrada sólo me limito a escribir las principales funcionalidades/objetivos que ya pensé de dotar a mi PFC. Son un poco datos que debí haber publicado hace ya algún tiempo (para variar).
A priori no tengo porque implementarlo todo para poder terminar, ya que como se puede observar, terminan siendo muchas cosas.

Este futuro monitor gráfico de procesos del kernel LINUX será útil para depurar procesos tanto de la propia máquina como de una máquina remota.
La información monitorizada corresponde a las estructuras internas del sistema operativo, más concretamente, del sistema de ficheros con respecto a los procesos.

• Orientado a una interfaz gráfica.
• Monitorización en red.
• Monitorización de procesos. Específicamente atributos de ficheros Reiser. Por supuesto la arquitectura va encaminada a extensiones que permitan ampliar las estructuras a monitorizar
• Visualizar/Monitorizar grupos de procesos simultáneamente.
• Estadísticas del uso de ficheros (opcional)
• Tipos de monitorización: Tiempo real o asíncrona. En tiempo real se toman datos cada intervalo X de tiempo de forma constante. En el caso de monitorización asíncrona se toman datos en los instantes que se indiquen.
• Integración con DBUS/HAL. En la medida de lo posible quiero llevar la comunicación entre la interfaz gráfica y el módulo del kernel por DBUS. A ver como sale.

No cabe duda que no quiero perder de vista al dtrace para LINUX, systemtap. Systemtap realiza labores similares al fin y al cabo.
Para quien no conozca estas herramientas en los siguiente párrafos hago un breve resumen.
Dtrace y systemtap son muy similares, sólo que una está ligada a Solaris y la otra a LINUX. Como en mi caso, monitorizar el núcleo del sistema operativo te cierne (un poco por definición) a ser una herramienta monoplataforma. Ambas proveen unos “lenguajes” propios que permiten extraer/monitorizar variables del sistema operativo.
Con dicha información se pueden realizar estadísticas y depuración como objetivo primordial.

Minutes ago I was trying to compile hal++ a wrapper for libhal developed by beep-media-player team.
While executing configure I’ve got this error:

./configure: line XXXXX: PKG_PROG_PKG_CONFIG: command not found

It was not expected because I did have autotools and pkg-config already installed. And as incredible as I had compiled without any error hal++ in other Debian testing/unstable machine (I was in a Debian testing).
So I have investigated a bit with half success. I’ve found a peace of autotools code which have been useful:

# Check for pkg-config manually first, as if its not installed the
# PKG_PROG_PKG_CONFIG macro won’t be defined.
#
AC_CHECK_PROG(have_pkg_config, pkg-config, yes, no)
#
if test x”$have_pkg_config” == xno; then
AC_MSG_ERROR(pkg-config is required to install this program)
fi
#
PKG_PROG_PKG_CONFIG

It’s only a couple of verifications, which are not introducing anything new, but it was incredibly worked.

Now, I’ll try libhal++ to see if I can do what I want in C++.

Un pequeño problema para el que no he encontrado la solución por más que he buscado.
El problema ha surgido ahora que estoy usando las autotools para automatizar toda la compilación, linkado y distribución de GLKM.

El caso es que al ejecutar el autogen.sh que tengo preparado me salía un mensaje, entre la maraña que sueltan estas herramientas, del tipo:

user@einstein:~/svn/pfc/trunk/gui$ ./autogen.sh
…
cp: no se puede crear el fichero regular «po/Makefile.in.in»: No existe el fichero o el directorio
…

Acotando el comando que fallaba lo ejecuté en modo depuración, para saber que hacía exactamente.

user@einstein:~/svn/pfc/trunk/gui$ intltoolize –copy –force –automake –debug
intltoolize: enabling shell trace mode
+ test -f configure.ac
+ configure=configure.ac
+ files=’intltool-extract.in intltool-merge.in intltool-update.in po/Makefile.in.in’
+ auxdir=.
++ egrep ‘^AC_CONFIG_AUX_DIR’ configure.ac
+ auxdirline=’AC_CONFIG_AUX_DIR([build-aux])’
+ test -n ‘AC_CONFIG_AUX_DIR([build-aux])’
++ echo ‘AC_CONFIG_AUX_DIR([build-aux])’
++ sed ’s/^AC_CONFIG_AUX_DIR(\([^)]*\)).*$/\1/’
+ auxdir=’[build-aux]‘
+ test ‘[build-aux]‘ = ‘AC_CONFIG_AUX_DIR([build-aux])’
++ echo ‘[build-aux]‘
++ sed ’s/^\[\(.*\)\]$/\1/g’
+ auxdir=build-aux
+ case “$auxdir” in
+ test -z yes
++ pwd
+ cur=/home/user/svn/pfc/trunk/gui
+ test build-aux ‘!=’ .
+ test -z yes
+ cd build-aux
+ for file in ‘$files’
+ test -f intltool-extract.in
+ test -z yes
+ rm -f intltool-extract.in
+ test -n ”
++ basename intltool-extract.in
+ cp -f /usr/share/intltool/intltool-extract.in intltool-extract.in
+ :
+ for file in ‘$files’
+ test -f intltool-merge.in
+ test -z yes
+ rm -f intltool-merge.in
+ test -n ”
++ basename intltool-merge.in
+ cp -f /usr/share/intltool/intltool-merge.in intltool-merge.in
+ :
+ for file in ‘$files’
+ test -f intltool-update.in
+ test -z yes
+ rm -f intltool-update.in
+ test -n ”
++ basename intltool-update.in
+ cp -f /usr/share/intltool/intltool-update.in intltool-update.in
+ :
+ for file in ‘$files’
+ test -f po/Makefile.in.in
+ rm -f po/Makefile.in.in
+ test -n ”
++ basename po/Makefile.in.in
+ cp -f /usr/share/intltool/Makefile.in.in po/Makefile.in.in
cp: no se puede crear el fichero regular «po/Makefile.in.in»: No existe el fichero o el directorio
++ basename po/Makefile.in.in
+ echo ‘intltoolize: cannot copy ‘\”/usr/share/intltool/Makefile.in.in’\” to ‘\”po/Makefile.in.in’\”’
intltoolize: cannot copy ‘/usr/share/intltool/Makefile.in.in’ to ‘po/Makefile.in.in’
+ status=1
+ exit 1
+ exit 1

Estoy usando un directorio para guardar los archivos de autoconf (config-aux) y tener la estructura de directorios y archivos ordenadita.
Ahí radicaba el problema. Así que con crear un directorio llamado po bajo ese directorio ha desaparecido el error.

user@einstein:~/svn/pfc/trunk/gui$ cd config-aux/
user@einstein:~/svn/pfc/trunk/gui/config-aux$ mkdir po
user@einstein:~/svn/pfc/trunk/gui/config-aux$ ll
total 412K
-rwxr-xr-x 1 user user 44K 2007-04-20 04:09 config.guess*
-rwxr-xr-x 1 user user 32K 2007-04-20 04:09 config.sub*
-rwxr-xr-x 1 user user 18K 2007-06-07 21:28 depcomp*
-rwxr-xr-x 1 user user 13K 2007-06-07 21:28 install-sh*
-rw-r–r– 1 user user 23K 2007-06-14 16:53 intltool-extract.in
-rw-r–r– 1 user user 36K 2007-06-14 16:53 intltool-merge.in
-rw-r–r– 1 user user 28K 2007-06-14 16:53 intltool-update.in
-rw-r–r– 1 user user 193K 2006-03-11 19:49 ltmain.sh
-rwxr-xr-x 1 user user 11K 2007-06-07 21:28 missing*
-rwxr-xr-x 1 user user 2,0K 2007-06-14 16:52 mkinstalldirs*
drwxr-xr-x 2 user user 48 2007-06-14 17:51 po/

Si tras ejecutar subversion con un svn co, o un svn update el resultado de la operación os luce con un bonito:

user@machine:~/svn/pfc/trunk/gui/src$ svn update
svn: No se pudo leer el archivo ‘/var/lib/svn/glkm/db/revprops/5′: End of file found

El problema es que el archivo en cuestión, llamémosle forunculo, contiene algún error.
Hasta aquí todo esto lo puede haber pensado cualquier hijo de vecino.

En mi caso salía porque había tocado a mano ese archivo para modificar el log de subversion en ese commit/revision, número 5. Le había quitado algunas letras y lo había dejado tal cual.
Cuando intenté posteriormente obtener esa versión para hacer unas pruebas me encontré con el fallo.

Estos archivos de propiedades de cada versión (eso deduzco por el nombre) contienen unos campos de control de longitud, algo muy cutre, pero muy sencillo. Para arreglar el problema hay que contar de manera exacta los caracteres ocupados (yo resté, menos mal que eran pocos).

Un ejemplo similar al caso real (Ojo, antes del END deberían aparecer 2 líneas vacías, en el ejemplo no se muestran):

user@machine-svnserver:/var/lib/svn/glkm/db# cat revprops/5
K 10
K 10
svn:author
V 9
wodofredo
K 8
svn:date
V 27
2007-05-11T17:44:13.460401Z
K 7
svn:log
V 19
2007-05-11 Enrique
END

aristoteles:/var/lib/svn/glkm/db# diff revprops/5 revprops/5~
< V 24
< 2007-05-11 Enrique jdfgj
---
> V 19
> 2007-05-11 Enrique

Para que un proyecto software se lleve a cabo siempre van a hacer falta los mismos pasos. Quizás, según la experiencia o profesionalidad del equipo que lo lleve a cabo, se puedan omitir algunos pasos.

Los primeros pasos van encaminados a encontrar un problema a solucionar. A buscar una necesidad que necesita ser resuelta.
Es decir, lo que hay que hacer es definir que va a hacer el proyecto.

Otra parte que se da es la de documentación. Porque casi siempre que llevas a cabo un proyecto vas a necesitar saber cosas que desconoces. Tienes que

Ojo, muy importante, en el software, como en la vida, estamos sometidos continuamente a cambios, nuestros o del entorno y tienen una incidencia importantísima en el proyecto.
De nuevo, quiero decir que llevar a cabo un proyecto software no es lineal. No es:

1. escabar
2. cimientos
3. cemento
4. ladrillo
5. tubos
6. luz
7. ventanas
8. puertas
9. …

Se trata de:

• Documentarse. Adquirir conocimientos que no posees
• Definir funcionalidades
• Planificar proyecto
• Diseñar
• Implementar
• Probar
• Documentar. Que consiste en describir lo que estas haciendo.

Y cualquiera de estas directrices se puede tener que realizar, y se realizan, en mayor o menor medida, en cualquier momento del proyecto.

Concretamente estoy en fase de documentación desde hace unos cuantos meses ya. Pero es que me es muy fácil esparcirme y de repente ponerme a hacer otra cosa. Lo que se llama falta de concentración (o motivación, ni yo lo se).
Me estoy documentando para ver cómo se escriben interfaces gráficos usando las librerías GTK/GNOME. Además estoy intentado usar un IDE para GNOME llamado anjuta, pero entre que estoy usando la versión que esta en fase de desarrollo (y falla) y que no se manejarlo muy bien, me está costando. Es que no me apetece escribirlo yo todo.
Además me facilita el código para poder hacer la aplicación fácilmente traducible a cualquier idioma.
También me estoy leyendo un manual de C++, que casi no me acordaba de la última vez, a parte de que estoy aprendiendo cosas sobre las que no tenía ni idea de su existencia.

A la vez que me documento (y me disperso), me he ido informando de las herramientas con similares cometidos que ya existen, para ver que me podían aportar cada una de ellas.
Según sabía y descubría más o menos que quería hacer e ido indagando que cosas podía o no usar. Por ejemplo, si usar DBUS para comunicar ciertos eventos. Por ejemplo, si permitir trabajo en red.

Algunas de las características las busco porque un proyecto fin de carrera requiere manejar distintas tecnologías (o debería).
Por otra parte busco que las tecnologías del proyecto encajen y tengan sentido en el programa de forma que lo hagan más usable y útil.

Como veis todo este X se encuentra bajo que yo llamo el caos ordenado o el orden caótico. Muchas ideas y actividades aparentemente inconexas pero a su vez interrelacionadas y que se respetan mucho.

Con esta entrada anuncio el lanzamiento público del que va a ser mi proyecto Fin de Carrera.
El título es provisional.
Muchos estaban deseando obtener información sobre él. Pues ahora lo vais a poder seguir de cerca.

En las últimas dos semanas he estado configurando la página web y algunos de los servicios necesarios para tener en marcha la infraestructura mínima necesaria para llevar a cabo un proyecto de software libre.
De acuerdo con mi tutor no habría problema en que hiciera todo esto.

Lo que he hecho en concreto ha sido instalar y configurar un software para web que suministra herramientas muy útiles para el desarrollo de un proyecto software. En concreto trac, muy usado en proyectos de software libre.
Trac incluye wiki, navegador de código fuente, gestor de tickets. Además permite extender sus funcionalidades mediante un sistema de plugins.
Con el wiki puedo crear páginas web con la información que crea necesaria.
Con el navegador de código permito a cualquiera ojear el desarrollo del código fuente.
El gestor de tickets es una idea sencillamente genial. En base a esto puedes reportar fallos (bugs) y sugerir funcionalidades (features). Mezclando un poco todo esto puedes seguir cuánto falta para alcanzar cierta meta del proyecto (Roadmap).
El apartado de evolución (Timeline) también es muy útil porque en base a todo (repositorio de código, edición de wiki, gestión de tickets) puedes ver toda la evolución que tiene el proyecto. Es información útil para un desarrollador, para un aquel que no le interesen esto detalles iré narrando en la bitácora la evolución de todo.

La única cosa que me falta para cubrir todos los aspectos de un proyecto de software libre es una lista de correo o foro, pero cómo de momento el único desarrollador voy a ser yo, lo dejo para más adelante. El tiempo dirá.

Lo podéis seguir todo desde:

GNOME LINUX Kernel Monitor