diciembre 2007


He estado peleando un buen par de horas con intentar hacer un servidor y cliente TCP de ejemplo para pyqt, no he encontrado ninguna documentación interesante, así que lo cuelgo aquí por si a alguien lo esta buscando, o si algún dia me hace falta.

(más…)

Anuncios

Voy a iniciar una categoría de posts con todas las cosas raras que a veces descubro que se pueden hacer en bash. Esto me vale porque no tengo que estar luego buscando como se hacia tal o cual cosa.

El primer post tratará sobre el manejo de los atributos de los terminales. Comenzaremos con algo sencillo, y vistoso para tus scripts: una barra de progreso, que espero pueda servirte de inspiracion para otras cosas

(más…)

Hoy ha comenzado el congreso de Hispalinux en Cáceres. Llegamos anoche, el jefe y yo. Después de hacerle caso a google y comenzar el camino desde Sevilla a Cáceres en el sentido contrario, parar en un bar a cenar en el que salimos vivos de milagro llegamos al hotel.

En el hotel tienen la wifi esa de telefónica, una mierda, 6€ 1 hora de conexión, 12€ 12 horas continuas de uso. Total, no tenemos wifi en el hotel. Más allá de eso, el hotel está bastante bien, estuvimos trabajando algo por la noche y alrededor de la una de la mañana acabé en el sobre.

Hoy nos levantamos temprano para poder perdernos antes de llegar a la Facultad de Derecho. Así que eso hicimos, nos perdimos, dimos un par de vueltas, pero al final llegamos a la facultad. Nos acreditamos e inmediatamente después fuimos a la presentación de CENATIC.

Aburrido, no dijeron nada nuevo, sólo que hay que entender que su labor es muy grande y que todavía están aterrizando. Luego hubo una micro reunión de trabajo con el CENATIC en la que no dio tiempo a mucho, prácticamente presentarse todos los de la mesa y hacer unas cinco preguntas no muy trascendentales.

Continuamos con la inauguración, lo mismo de siempre, rollito de gracias, saludos y tal entre gentes del gobierno local, provincial e invitados ilustres.

Hemos seguido con un almuerzo donde la organización, en el edificio de Filosofía y Letras, al lado de unas 7000 ovejas muy monas seguido de un … ¿café?, bueno, vale, de acuerdo, café.

¡¡Ya son las 16:15, comienza una charla de DNI-e!!! Qué bien, el primer rollito técnico!!!. Mentira, un pufo, un tipo hablando de los peligros de la red, de lo peligroso que es el pasaporte electrónico, vamos, lo de siempre. Pero no ha dicho cómo utilizar el dichoso DNI para interactuar con la administración bajo linux ni nada por el estilo. Un pufo vamos, nada técnico y bastante simple.

Esto lo estoy escribiendo ahora mismo mientras Barahona habla de los últimos 10 años de software libre. Es interesante escuchar a este señor una charla distinta a la de siempre, seguidamente hablará Juan Tomás y otro señor probablemente muy importante pero que no conozco.

La organización del evento está más o menos bien, tienen algunos fallitos, por ejemplo, el presidente de Hispalinux hasta la mitad de la segunda charla no dijo quién era, y todavía no ha dicho cómo se llama sólo ha dicho algo así como … “soy el Presidente de Hispalinux”. Otra cosa que se podría mejorar es colgar algunos paneles con las charlas y actividades que hay en los pasillos y tal, pero en general aceptable, mención especial a los muchísimos voluntarios de la organización (al rededor de 70 personas). Por último la comentar que la asistencia a las charlas está siendo a mi juicio bastante buena, en la sala actualmente puede haber entre 70 y 80 personas. Si puedo subiré alguna fotillo.

Desde esta tarde llevo dándole vueltas a como simplificar el proceso de selección de paquetes. La idea estaba clara dpkg --get-selections. He tenido un ratito y he hecho un pequeño script en python que genera un metapaquete que depende de todos los paquetes instalados en el sistema. Mi idea es poder utilizar esto para disponer de versiones iniciales de varias distribuciones, particularmente de gutsy y hardy, generadas por unidistro. En teoría si arranca desde el cdrom y ejecutas este script obtienes lo que va dentro de la sección metapackages, es una manera muy bestia pero debería funcionar.

NOTA: En la siguiente página está el código

(más…)

Ayer fue un día intenso para mi con unidistro. Primero René nos dio una PACO sobre el asunto. Cuando llegué a casa tenía ganas de probarlo y estuve jugueteando un poco. Básicamente hice lo mismo que había hecho René en la charla. Al final, utilizando un isolinux de un CD de Bardinux, logré generar la iso correspondiente, aunque no la llegué a probar.

Tras estar jugando un rato me surgieron muchas cosas que se podrían hacer para mejorar el sistema pero no me había enfrentado al código. Una de las cosas que se me ocurrió era que los scripts en BASH podrían sobrar; pero claro hacer esto sin tener ni idea del código es complicado, así que se lo comenté al maestro de la comunidad y ahí quedó. Después, en mi ratito de unidistro, me puse a cambiar el módulo que se utiliza para parsear la entrada. Antes usábamos getopt, que no parecía ser suficientemente bueno.

Tras googlear un poco vi un módulo llamado optparser que servía para lo mismo y además forma parte del core de python. Siguiendo la documentación del módulo para python 2.3 no fue difícil hacer un par de ejemplitos sencillos aunque tengo instalado python 2.5.1.

Tras las pruebas pruebas me puse a añadir las opciones reales. Hubo algunas que no incluí porque no funcionan en el framework todavía pero en esencia están todas. René llegó y hablando un poco con él nos dimos cuenta de que simplemente con este cambio y llevando a cabo las distintas opciones en el orden correcto podríamos conseguir el objetivo de hacer innecesarios los scripts en bash (al menos algunas veces).

Con una línea como:

python framework.py -r create -i psmisc -i unidistro -i unidistro-live -i unidistro-base -i unidistro-desktop-base -i kubuntu-kde4 -i kubuntu-kde4-desktop -i kubuntu-kde4-live -i kdebase-dev-kde4 -i kdebase-workspace-dev -i kdebase-runtime -i kdm -i kdm-kde4 -i ksmserver -i unidistro-office -m ../unidistro-data/kubuntu-kde4.xml

Hay que tener en cuenta que los múltiples -i son para instalar cada uno de esos paquetes; pero en realidad lo lógico es sólo haya una. Es decir si tu proyecto se llama bardinux tendrás un metapaquete que dependa de todo lo que haga falta para que se instalen todos los paquetes necesarios.

Disponer de control de versiones en un proyecto de desarrollo de software siempre es interesante. Hace algún tiempo que utilizo sistemas de control de versiones centralizados tipo cvs o svn; ya hasta estos días he estado muy satisfecho con ellos. Personalmente no he tenido que enfrentarme a la administración de estos sistemas; de alguna manera estaban disponibles en los proyectos en los que he participado; pero incluso si hubiera tenido que enfrentarme a administrar alguno de ellos no creo que hubiera tenido demasiados problemas. Tampoco he tenido que hacer un merge bien hecho, que es lo que tengo entendido que es más complicado.

El cambio comenzó cuando en septiembre tuve la oportunidad de asistir a las II Jornadas de Software Libre de la Universidad de La Laguna. Jonathan Riddell estuvo aquí y nos explicó muy de pasada que existía una cosa llamada bazaar (bzr) que era la que utilizaban los proyectos alojados en launchpad. Luego vi este vídeo en el que Linus Torvalds, que de gestionar proyectos grandes algo debe saber a estas alturas, hablar de algo llamado Git que es otro sistema de control de versiones distribuido.

La verdad es que soy bastante cabezón, así que no terminaba de verlo claro. Estos días he estado jugueteando un poco con bzr en el proyecto unidistro, y me ha sorprendido lo sencillo que es hacer algunas cosas que a mi no me resultaban sencillas en concepto.

Cuando trabajas en svn o cvs tiendes a implementar funcionalidades nuevas y luego comitearlas cuando están con un comentario como “La nueva funcionalidad puturru”. En bzr, como cuando comiteas lo haces en tu copia local, puedes ir comiteando cada cosa que vas haciendo sin molestar al resto de desarrolladores, cuando la funcionalidad está lista haces un push y con esto se transmite el historial de cambios, así que tendras un log con pelos y señales de qué fue lo que fue cambiando el desarrollador.

Al ser un sistema distribuido, el esquema de trabajo lo defines tu, no el sistema de control de versiones. Si en svn quieres que alguien participe en el proyecto pero no confias mucho en él o va a trabajar en una funcionalidad nueva diferente al resto le haces un branch, le das permisos sobre dicho branch y rezas para que cuando tengas que hacer un merge del branch no pierdas el coco. Esto es así porque si no le haces un branch el nuevo desarrollador no va a tener control de versiones. En bzr simplemente dejas que él haga un branch de la rama principal y que haga lo que quiera con ella,puesto que tiene control de versiones, pero es que además él puede ir haciendo merge de cualquiera de las otras ramas públicas y cualquier puede hacer merges de su rama también (si está publicada).

Disclaimer: Hablo de bzr porque es el que he probado. Probablemente Git u otros sistemas distribuidos sean tan buenos o mejores que este.

Hoy durante la presentación de unidistro he tenido algunos problemas porque no tenía en ningún repositorio el paquete de unidistro-dev. Estuve intentando subir una y mil veces el dichoso paquete a mi “archivo de paquetes personal” de launchpad pero que no quería el nota aparecer.

Finalmente lo he conseguido hacer. He subido el paquete en lugar de como anónimo como mi usuario de launchpad y en lugar de poner la distro gutsy he puesto hardy. Mañana intentaré subir otra versión del paquete, esta algo más completa, pero al menos ya he entendido cómo demonios subir los paquetitos y que el temita funcione. Espero tener algo presentable para el sábado en hispalinux.

Por ahora el paquete lo puedes descargar desde usando:

deb http://ppa.launchpad.net/agarfu/ubuntu hardy main
deb-src http://ppa.launchpad.net/agarfu/ubuntu hardy main

Página siguiente »