«Estaban en el lugar equivocado en el momento equivocado. Naturalmente, se convirtieron en héroes.» .-Leia

No es muy habitual dedicar un post a un bug, pero en este caso es lo suficientemente curioso como para que me anime a ello. Quién sabe si no es una venganza del Imperio por jugar en gvSIG con la imagen ráster de la Estrella de la Muerte… aunque también es un buen ejemplo de lo escondidos que pueden estar algunos bugs.

El caso es que uno de los desarrolladores de gvSIG estaba intentando instalar la RC2 de gvSIG 2.3 en su casa…sin éxito. Algo raro pasaba, pues en la oficina no había tenido ningún problema, con el mismo sistema operativo y mismas características. Ubuntu 16.04 de 64 bits para más señas.

Primero probó con el instalador .run pero cuando se iniciaba la instalación, se cerraba sin motivo aparente. Tras esto probó con el instalador .jar con el mismo resultado.

Por alguna razón el instalador decidía que allí no se podía instalar gvSIG. Siguió dando vueltas al asunto intentando averiguar los motivos…y nada.

La siguiente prueba sería con la versión portable. gvSIG fallaba al intentar arrancar, sin llegar a mostrar el splash y sin generar el fichero “gvSIG.log” que es el que permite averiguar qué podía estar pasando.

Entonces ve en el fichero “gvSIG-installer.log” que se estaba intentando ejecutar un archivo denominado “cygcheck.exe” y que no lo encontraba.

¿cygchec.exe?¿Un ejecutable de Windows en la instalación de Linux? Estaba claro que ahí estaba el problema…¿pero qué estaba pasando? La conclusión no tenía lógica: gvSIG pensaba que se estaba ejecutando en un sistema Windows.

Y, claro, esto sólo le pasaba a él y sólo en el equipo de su casa.

Y ahora viene la explicación: nuestro desarrollador, en el equipo de casa, había puesto el nombre del sistema como Xwing, un tipo de nave de la saga Star Wars utilizado por la Alianza Rebelde. Y lo que nadie podía imaginar estaba pasando…si tú sistema Linux se llama Xwing no puedes instalar ni ejecutar gvSIG.

Cuando gvSIG le pide al sistema sus características para averiguar la arquitectura y sistema operativo ejecuta el comando:

# uname -a

Linux XWing 3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

…como resultado ve que contiene las letras “win” y decide que es un sistema operativo Windows…y claro, a partir de ahí, es normal que nada funcionara como tocaba.

Aunque haremos las pruebas necesarias, la corrección a priori es sencilla, haciendo que gvSIG utilice “uname -p -o” en lugar de “uname -a”, lo que informa sólo de la arquitectura del procesador y del sistema operativo (y no del nombre que haya decidido ponerle el usuario a su sistema). Con esto parece que la Alianza Rebelde podrá seguir utilizando gvSIG en su lucha contra el Imperio.

¿Merece o no ser nombrado el bug del año?

¡Y que la fuerza os acompañe!

🙂