Instalación de XBMC sobre OpenSuse: optimización y personalización

En el post anterior, dejamos nuestro XBMC en u punto en el que ya era utilizable. Ahora ha llegado el momento de hacer unas cuantas pruebas y de realizar un ajuste fino para optimizar el arranque. Además le daremos un pequeño toque de personalización para que nos de más impresión de estar ante un equipo HTPC.

Sobre tiempos de arranque

Las comparaciones son odiosas, y esta no va a ser una excepción. Tiempo atrás había estado haciendo unas cuantas pruebas con el equipo original y OpenElec. Como dije, OpenElec está muy optimizado y eso se nota también a la hora de iniciar nuestra máquina.

La prueba inicial, antes de embarcarme en todo esto, fue comparar tiempos de arranque con diferentes medios. Realmente tenía OpenElec instalado en una tarjeta microSD y después la cloné a una memoria USB bastante más rápida. Luego, por tener una primera referencia, comparé esos tiempos con los de arranque de la OpenSuse, que tenía instalada en el disco SATA de 3,5" de la misma máquina.

 Quiero aclarar que el tiempo que quise medir se corresponde con lo que el usuario percibiría como arranque, o sea, desde que se inicia el ordenador hasta que el sistema acepta la interacción con el usuario por ratón, teclado o lo que sea. Así que en el caso de OpenElec era desde que le daba al botón de alimentación hasta que presenta el menú inicial, mientras que para openSuse también comenzaba a contar con el botón de alimentación, me saltaba la espera de Grub pulsando intro y paraba cuando KDE mostraba el escritorio.

Aclarado esto, antes de ponernos con la faena y para tener más información y poder deducir más cosas, podemos averiguar la velocidad de nuestros discos. Para ello, ejecutaremos como root lo siguiente:

hdparm -t /dev/xxxx

donde xxxx podrá ser hda, sda...

En mi caso me dio por comparar unos cuantos medios que tenía a mi alcance pero, para no marear, sólo pondré los que he mencionado antes. Las velocidades de lectura fueron las siguientes:

1. Tarjeta MicroSD: 12MB/s
2. USB Kigston DataTraveler G2: 20MB/s
3. Disco duro SATA 3,5": 120MB/s

Y después me puse a arrancar el mismo PC desde cada uno de los soportes y a tomar tiempos crono en mano:

1. Arranque de OpenElec desde MicroSD: 40 segundos
2. Arranque de OpenElec desde la memoria USB: 30 segundos
3. Arranque de OpenSuse desde el disco: 42 segundos

Viendo esto, y teniendo en cuenta que iba a comprar un disco SATA de 2.5" donde iba a instalar una openSuse que no cargaría KDE, esperaba tener unos tiempos menores de 40 segundos.

 Tras llegarme todo el material, montarlo e instalar el sistema operativo, el tiempo de inicio era de unos 35 segundos. Para mejorarlo busqué algún artículo en el que se hablaba de cómo optimizar este tiempo modificando los servicios arrancados durante el inicio de la máquina. Así pues, lo siguiente que se puede hacer para comprobar nuestros avances, será instalar el paquete systemd-analyze.

El primer resultado que obtuve al ejecutar dicho comando fue el siguiente:

En Yast, en Servicios del Sistema, se puede desactivar aquello que no necesitemos. Yo quité sólo Postfix y CUPS

Como se puede ver en la primera linea ejecutada en la imagen mostrada a continuación, sólo mejoró unas décimas de segundo. Tendremos más pistas de lo que está sucediendo gracias a la segunda orden que aparece:

systemd-analyze blame

En este caso levantar la red resulta ser un proceso muy pesado.

Para evitar lo que acabamos de ver podremos conectarnos a la red mediante NetworkManager en vez de hacerlo con ifup en el arranque. Para ello lo cambiaremos otra vez en Yast, en el apartado de Ajustes de Red tal como se ve aquí:

 Ahora nos avisará de que necesitamos tener una aplicación que nos gestione la conexión. Aceptaremos.

 Revisamos los tiempos y vemos que se obtiene una mejora sustancial (ver en la imagen siguiente). Es cierto que sigue siendo necesario conectarse a la red, pero esa operación se realizará una vez cargado XBMC y no nos percataremos de ello.

Para conseguir lo que se acaba de comentar, es necesario instalar un Addon de XBMC para NetworkManager. Lo encontraremos en el listado de addons de programas de XBMC

Tras la instalación lo encontraremos en el menú programas y solo tendremos que configurar nuestra red.

Ahora vuelvo a referirme al tiempo crono en mano. Tras todos estos cambios el nuevo tiempo de arranque era de 29 segundos frente a los 35 iniciales. Había mejorado unos 6 segundos, no está mal, aunque supongo que será mejorable, así que cualquier idea será bienvenida :) Me gustaría ver esto mismo en un disco SSD pero, como ya dije, sacrifiqué tiempo por espacio.

Ocultar Grub

Al tratarse de un equipo dedicado a arrancar sólamente nuestro XBMC ¿por qué mostrar el menú de Grub? ¿Por qué perder unso valiosos segundos esperando a que el usuario haga una elección en el menú de arranque? No nos hace falta: vamos a ocultarlo.

Para hacer esto acudiremos como siempre a Yast. En Configuración del cargador de Arranque haremos clic sobre el botón Opciones del cargador de arranque

 Ahora simplemente marcaremos la opción Ocultar el menú en el arranque

 Gracias a esto nuestro sistema iniciará sin pausas nuestro XBMC, con lo que nos habremos ahorrado 8 segundos más. Ojo, este tiempo no lo estaba contabilizando en las referencias que estaba dando antes, así que en el ejemplo siguen siendo los 29 segundos que comentaba antes.

Un arranque más XBMC

No tengo nada en contra de la mascota de openSuse pero no me apetece ver el camaleón verde en los 30-40 segundos en los que carga el sistema, en todo caso se debería mostrar una imagen algo más integrada en el espíritu de nuestro media center. Afortunadamente alguien ya ha pensado en esto y tenemos un paquete que sustituirá al fondo por defecto: plymouth-branding-xbmc

Para bajarlo acudiremos a la web de búsqueda de paquetes, ya que no lo tendremos en ningún repositorio de nuestra máquina y no podremos instalarlo directamente.

Buscaremos el término xbmc

Escogeremos el paquete que nos interesa y se nos desplegarán las opciones. Si no hay versión estable le diremos que nos muestre las que no lo son y finalmente seleccionaremos 1 click install

 Después de esto nos eliminará el paquete  por defecto y nos añadirá el nuevo.

 No hay nada más que hacer, en el próximo reinicio nos encontraremos con una pantalla similar a esta:

Mi guerra con la temperatura

Ya dije en el otro post que adquirí dos nuevos ventiladores. Lo que no conté es que fue una compra posterior, después de ver como funcionaba el equipo recién montado. Con el ventilador original de la placa Zotac, llegaba facilmente a los 65 grados e, incluso, a los 70 en determinadas condiciones. Cuando la tuve montada en la caja anterior no era así, seguramente porque había más espacio interior. Tras el montaje de los dos nuevos ventiladores más silenciosos, y con mejor circulación de aire, la situación mejoro bastante (de 5 a 10 grados).

En todo caso, esto fue un problema mío que tal vez no interese. Lo que sí que puede interesar es lo siguiente. Todos estos valores los veía en un monitor de sistema de KDE ya que mi XBMC no me los mostraba en las pantallas de información en las que debe aparecer.

Si os ocurre esto podéis consultar este enlace y después poneros manos a la obra con el archivo de configuración. Básicamente, necesitáis hacer un script que devuelva el valor de la temperatura que debe ser mostrar tanto para la CPU como para la GPU.

Podéis ejecutar las pruebas que hagáis en un terminal de comandos hasta que os funcione adecuadamente:

después se debe crear el archivo XML que contenga la instrucción, que deberá estar en la ruta:

~./xbmc/userdata/advancedsettings.xml

Este es mi fichero, pero no tiene por qué ser válido para otros, como se puede ver, depende mucho del hardware que se tenga:

  

echo "$(nvidia-settings -c :0 -tq GPUCoreTemp | tail -n 1) C"
echo "$(sensors -u | tail -n64 | grep temp2_input | awk '{print $2 }' |awk '{printf("%d\n",$1 + 0.5);}') C"

Una vez hecho esto ya deberías ver la temperatura de la CPU (sólo mostrará un valor aunque tengáis varios cores)

 Y la temperatura del chip gráfico

Después de todo esto parece que nuestro equipo ya se está ganando un sitio en el salón de nuestra casa. En el próximo capítulo contaré como solucionar alguna de las carencias que sufriremos al no estar bajo la ayuda de KDE, por ejemplo, el manejo de dispositivos Bluetooth.

Instalación de XBMC sobre OpenSuse

Como se puede ver por el título del post, he estado pegándome con la instalación de XBMC en un equipo con OpenSuse. No hay ningún misterio en ello, sólo elegir los paquetes a instalar y dejar que Yast haga todo el trabajo. Sin embargo quiero contar la experiencia porque hay unas particularidades que tal vez sean interesantes para otros, de hecho creo que lo haré en más de un artículo porque me parece que en uno sólo quedaría demasiado largo.

Antes de nada quiero decir que tal vez no debas seguir leyendo. Sí, te invito a que pares aquí. Si te gustan las soluciones fáciles te recomiendo que te compres un pincho HDMI Android, una Ouya o incluso que cojas un PC viejo o una Raspberry Pi y le pongas OpenElec. Realmente OpenELec es una de mis opciones favoritas por su simplicidad y su optimización. Si sólo quieres un equipo media center conectado a tu tele recomiendo decididamente esta opción.

El problema es que yo quiero pedirle algo más a este equipo, quiero instalarle OwnCloud para tener mi nube personal disponible allí donde esté, quiero administrarlo remotamente, encenderlo y apagarlo a distancia, descargar torrents, etc. Además, aprovechando que el equipo estará en el salón de la casa, le pondré un emulador de Amiga que, por supuesto, se manejará desde XBMC, Todo esto me hizo descartar la opción de usar cualquier dispositivo basado en Android e hizo que OpenElec no fuese lo más recomendable para mi.

Sobre el hardware

Por otro lado, habían una serie de factores que condicionaban cómo haría las cosas. En primer lugar quería reciclar un equipo que ya tenía, utilizando, cómo mínimo, la placa madre con su RAM. En cuando al disco duro hubiese sido muy recomendable usar un SSD pero el hecho de usar el equipo como servidor OwnCloud me hizo decantarme por una unidad convencional de 2,5" para tener más almacenamiento a un precio asequible.

Sin duda el mayor quebradero de cabeza fue la caja. Aclaro que en principio no me interesaba la típica caja HTPC grande, con aspecto de equipo de DVD. Quería algo pequeño que tuviese un aspecto similar a una consola Wii, algo que no cantase mucho cerca del televisor. Así que mi primera opción fue comprar una Morex T3320 pero fui victima de mi elección en cuanto al reciclaje. Hoy puedo decir que cuando compré la placa Zotac IONITX-D-E  no estuve muy acertado. El error fue que esa era una de las primera placas que incluían un Atom N330 que, si no recuerdo mal, fue el primer Atom con doble núcleo y 64 bits. El caso es que no ofrecía mucho más rendimiento que sus hermanos pequeños y, en cambio, obligaba a hacer uso de un ventilador sobre el disipador de la placa. Pues bien, esto eliminaba la mayoría de las cajas que me gustaban pues con unos 6 o 6,5 cm de altura y espacios tan reducidos no podía incluir el ventilador. Teniendo todo esto en cuenta, al final, me hice con una Intertech Mini ITX E-i5 con mayor altura y cuyo aspecto y acabado (todo aluminio) no estaba mal.

Otra de las compras fueron unos nuevos ventiladores. Ya que no podía librarme de la ventilación, el que venía de serie con la placa me parecía demasiado ruidoso. Tras las típicas búsquedas en foros, decidí comprar dos  Blacknoise uno de 60 mm para la placa y otro de 40 para la caja.

Resumiendo, los componentes son los siguientes:

• Kingston ValueRAM 2GB DDR2 800 PC2-6400 (Reciclado)
• Zotac IONITX-D-E ION mini-ITX Atom N330 WiFi (Reciclado)
• Intertech Mini ITX E-i5 (69,60€)
• Blacnoise BlackSilentFan XR1  (5,99€)
• Blacnoise BlackSilentFan  XM1 (4,99€)
• Toshiba MQ01ABD050 2.5" 500GB 5400RPM SATA  (43,99€)

Instalando OpenSuse y XBMC

Evidentemente, empezaremos por instalar OpenSuse. No voy a entrar mucho en detalles con esto ya que sólo hay que dejarse llevar por el asistente de instalación y todo es muy sencillo.

Seguiremos los pasos habituales de elección de idioma, zona horaria, etc. Llegado el momento aceptaremos que instale el escritorio KDE, ya que nos dará flexibilidad para instalar y configurar todos los paquetes que deseemos de un modo más agradable.

Después de esto, aceptaremos o modificaremos a nuestro antojo las particiones sugeridas, crearemos nuestro usuario y aceptaremos el resumen de la instalación, con lo que comenzará todo el proceso. Pues bien, ahora tenemos unos 30 o 40 minutos para hacer algo realmente maravilloso ¡¡¡como jugar en otro PC con un emulador de Amiga al Project X!!!

Bueno... en realidad lo que hice fue vaciar el lavavajillas y colocar vasos, platos y cubiertos en sus lugares correspondientes :(

En fin, después de este lapso tan enriquecedor, el sistema se reiniciará y vermos por primera vez nuestro escritorio.

Ahora tendremos que configurar la red, así que introduciremos las opciones que necesitemos respecto a DCHP, etc. Si usamos configuración inalámbrica es posible que quiera instalar el paquete iw, simplemente hay que decir que sí.

Una vez comprobado que tenemos conectividad y podemos salir al mundo exterior, es un buen momento para actualizar los paquetes instalados. Como se ha usado una imagen de DVD, una gran cantidad de rpms contarán con nuevas versiones con correcciones de fallos etc. Para forzar su renovación en el apartado Maquina del lanzador KDE elegiremos Añadir / quitar programas. Una vez cargada la aplicación, iremos al menú Paquete y en el submenú Todos los paquetes escogeremos Actualizar si hay una versión disponible.

En mi caso me avisó de que se instalarían casi 400 paquetes ¡con lo cuál era una gran oportunidad para jugar al Project X!

Pero... en realidad me puse a fregar todo aquello que no había cabido en el lavavajillas :(

Ahora añadiremos dos repositorios de paquetes rpm que nos serán muy útiles: el de los drivers de la tarjeta gráfica (Nvidia en mi caso) y el repositorio Packman donde encontraremos el software XBMC además de los codecs de vídeo que necesitaremos. Para hacer esto iremos al lanzador de KDE y en el apartado Máquina escogeremos Yast. Tras autenticarnos como root seleccionaremos la aplicación Repositorios de software y veremos lo siguiente:

Haremos clic sobre el botón añadir, después en la opción Repositiorios de la comunidad y por último añadiremos los correspondientes a Packman y Nvidia:

Tras hacer esto estaremos en disposición de empezar a instalar lo que nos sea necesario. Iremos de nuevo al instalador de software y buscaremos los paquetes xbmc y w32codec-all (este último son todos los codecs propietarios que no vienen por defecto en OpenSuse)

Haremos clic sobre Aceptar y probablemente nos  avise de un conflicto respecto a xbmc lo que haremos será de proveedor de la librería afectada:

Con ello empezará el proceso, que también incluirá más rpms por cuestiones de dependencias.

Primeros pasos con XBMC

Ya estamos en disposición de probar XBMC, podremos hacerlo desde el lanzador KDE en Aplicaciones, Multimedia, TV, XBMC. Si todo va bien se puede aprovechar este primer arranque para establecer el idioma y uso horario. Para ello ir a Ajustes y después a Apariencia.

Cómo hacer que nuestro ordenador arranque directamente el XBMC

Para hacer que nuestro equipo arranque con el gestor de ventanas de XBMC y por tanto que no se cargue KDE, cerraríamos sesión y en la pantalla de login de OpenSuse, haríamos clic en la rueda dentada y escogeríamos el tipo de sesión XBMC. Desde ese momento nuestro ordenador arrancará siempre directamente el XBMC. Mi consejo es dejar esto para más tarde ya que ahora nos será util disponer del escritorio KDE para poner a prueba las cosas antes. Me explico: cuando más adelante queramos disponer de un emulador en XBMC lo más lógico será tenerlo probado todo antes sobre KDE, una vez configurado todo correctamente, será la hora de pegarnos con la configuración del addon correspondiente en XBMC.

Para volver a cambiar el tipo de sesión cuando se está en XBMC sólo hay que pulsar la tecla s del teclado, opción Salir y estaremos otra vez en la pantalla de login con lo que podremos elegir el tipo sesión KDE.

Ventana o pantalla completa

De nuevo mi consejo, mientras se esté preparando todo, es trabajar en modo ventana y, como he dicho antes, sobre el escritorio KDE. Este valor se puede cambiar en Ajustes, Sistema, Hardware de vídeo.

Si te conectas a la TV por HDMI y no tienes sonido

Si vas a usar un cable HDMI entre la tele y tu HTPC, lo normal es que lo probases ahora. Una de las cosas que puede ocurrirte, como a mí, es que no tengas sonido. Si te ocurre esto, comprueba que la salida de audio es la correcta en OpenSuse

Aún así probablemente la cosa siga sin funcionar así que en un terminal ejecuta Alsamix y comprueba si tienes enmudecidos los canales denomindados s-pif, en ese caso actívalos todos.

Ahora ya deberías tener sonido en tu escritorio, pero deberías asegurarte de que en XBMC también, así que debes configurar su salida de audio en Ajustes, Sistema, Salida de Audio.

Si esperas poder manejar XBMC con el mando de tu TV y no te va

XBMC está preparado para recibir comandos CEC a través del cable HDMI, lo que permite controlarlo con el mando de la TV a la que se conecta. Yo lo comprobé tiempo atrás con mi teléfono Android, un Sony Xperia P con salida micro HDMI en el que tengo instalada la beta de XBMC (de momento no está en Google Play). Por esta razón asumí que mi PC también las recibiría ¡Error! Mi placa Zotac ignora completamente las señales CEC. Si estáis en el mismo caso podéis solucionarlo con el adpatador usb Pulse Eight (no lo he probado).

En resumen para disponer de CEC tanto la TV, como el PC deben soportarlo. En caso contrario no debemos desesperarnos, podremos usar una app de control remoto en nuestro móvil:

• XBMC official remote
• Yatse XBMC

 

Hasta aquí, de momento

Creo que es un buen punto para dejarlo por ahora. Si todo ha ido bien, tendréis una instalación básica de XBMC con la que podréis empezar a disfrutar de un equipo multimedia en vuestra TV. Más adelante escribiré sobre como optimizar el arranque y como añadir mis addons favoritos (rom collection browser, transmission...). ¡Ah! También pienso contar como incluir Owncloud.

Creando binarios para linux con Open Suse Build Service. II Paquetes rpm

Después de ver de un modo general como funciona OBS intentaremos mostrar ahora el caso práctico de creación de RPMs para varias distribuciones.
Imaginemos que nuestra aplicación consta de un archivo binario y de un .desktop, es un caso sencillo ya que no contamos con archivos de traducción. Lo que tenemos que montar es un archivo de descripción .spec y un .tar.gz de nuestro código fuente.

Entorno de trabajo:

Si trabajamos con Subversion, o cualquier otro sistema de control de versiones, haremos un "commit" de todo nuestro proyecto antes de comenzar con la paquetización. Después de esto exportaremos una copia limpia de archivos ocultos a un directorio de trabajo diferente. Sobre esta nueva carpeta ya podremos crear nuestro tar.gz.
Tal como vimos en el capítulo anterior en nuestra cuenta en OBS habremos creado un proyecto, las distribuciones para las que se construirá  y el paquete correspondiente a la versión sobre la que estamos trabajando. Una vez hecho todo esto, para añadir nuestro código fuente navegamos hasta el paquete creado y seleccionamos la pestaña Sources, donde clicaremos sobre el botón Add files.

Se nos despliegará un formulario en el que podemos cargar, en este caso, nuestro código. Lo más cómodo es haber nombrado el tar.gz de la mejor manera posible, especificando la versión, y ahorrarnos el rellenar el campo nombre, de manera que OBS lo haga automáticamente. Más adelante podremos subir el .spec del mismo modo.

El archivo spec

Ahora toca montar el archivo spec con la información adecuada. Tenéis, a continuación,  todo el archivo apropiado para el proyecto de ejemplo. Después desgranaremos lo más importante a destacar:

%if 0%{?fedora_version}
%define breq qt4-devel
%define reqs qt qt-x11
%define qmake /usr/bin/qmake-qt4
%endif
%if 0%{?mandriva_version}
%define breq libqt4-devel qt4-linguist
%define reqs libqtcore4 libqtgui4
%define qmake /usr/lib/qt4/bin/qmake
%endif
%if 0%{?suse_version}
%define breq libqt4-devel
%define reqs libqt4 libqt4-x11
%define qmake /usr/bin/qmake
%endif
 
Name: RegExpTester
Summary: RegExpTester is an application that lets you test regular expresions
Version: 1.0
Release: 1
License: GPL v3
Group: Productivity/Utility/TextTools
BuildRoot: %{_tmppath}/build-root-%{name}
Source0: /usr/src/packages/SOURCES/RegExpTester-1.0.tar.gz
Packager: Guillermo Amat
Url: https://www.deuteros.es
Vendor: Guillermo Amat
 
BuildRequires: gcc-c++, make, %{breq}
Requires: %{reqs} libc.so.6 libgcc_s.so.1 libgcc_s.so.1(GCC_3.0) libm.so.6 libpthread.so.0 libstdc++.so.6 libstdc++.so.6(CXXABI_1.3) libstdc++.so.6(GLIBCXX_3.4)
%description
RegExpTester is an application that lets you test regular expresions
 
RegExpTester is an application that lets you test regular expresions
 
%prep
rm -rf %{buildroot}
mkdir %{buildroot}
 
%setup -q
 
%build
mkdir -p %{buildroot}%{_bindir}
mkdir -p %{buildroot}%{_datadir}/%{name}
mkdir -p %{buildroot}%{_datadir}/applications
%{qmake} %{name}.pro
CFLAGS="$RPM_OPT_FLAGS" CXXFLAGS="$RPM_OPT_FLAGS" \
make
 
%install
cp %{name} %{buildroot}%{_bindir}
cp %{name}.png %{buildroot}%{_datadir}/%{name}/
 
cat > $RPM_BUILD_ROOT%{_datadir}/applications/%{name}.desktop << EOF
[Desktop Entry]
Encoding=UTF-8
Name=%{name}
GenericName=%{name}
GenericName[de]=%{name}
Comment=Synchronize files between computers
Exec=%{_bindir}/regexptester
Icon=%{_datadir}/%{name}/%{name}.png
Terminal=false
Type=Application
StartupNotify=false
Categories=Qt;KDE;Utility;TextEditor;
EOF
 
%clean
rm -rf %{buildroot}
 
%files
%defattr(-,root,root)
%dir %{_datadir}/RegExpTester
%{_datadir}/applications/RegExpTester.desktop
%{_bindir}/RegExpTester
%{_datadir}/%{name}/%{name}.png
 
%changelog

Menudo rollo ¿no? Pues vamos a destriparlo paso a paso para que se entienda mejor:
El primer bloque se corresponde con una serie de declaraciones condicionales que dependerán de la maquina virtual en la que OBS ejecute la construcción del rpm.

%if 0%{?fedora_version}
%define breq qt4-devel
%define reqs qt qt-x11
%define qmake /usr/bin/qmake-qt4
%endif
%if 0%{?mandriva_version}
%define breq libqt4-devel qt4-linguist
%define reqs libqtcore4 libqtgui4
%define qmake /usr/lib/qt4/bin/qmake
%endif
%if 0%{?suse_version}
%define breq libqt4-devel
%define reqs libqt4 libqt4-x11
%define qmake /usr/bin/qmake
%endif 

Por ejemplo, en los requisitos de construcción (breq) para Mandriva y Opensuse se necesitará el paquete libqt4-devel, mientras que el equivalente en Fedora recibe el nombre qt4-devel. OBS instalara el paquete adecuado en cada máquina virtual gracias a eso. En todo caso para cada una de las distribuciones definimos tres variables que usaremos mas tarde:

• breq: requisitos para la construcción
• reqs: dependencias para la ejecución de nuestro programa en el PC del usuario que se lo instale
• qmake: ruta al ejecutable qmake

El siguiente bloque que nos encontramos es el de la información general de nuestra aplicación.  Aquí y en todo el fichero spec hay que tener cuidado con los saltos de línea y en concreto aquí  con no equivocarse con el valor del campo source0. Además, parte de esta información será mostrada al usuario en el gestor de paquetes de su distribución:

Name: RegExpTester
Summary: RegExpTester is an application that lets you test regular expresions
Version: 1.0
Release: 1
License: GPL v3
Group: Productivity/Utility/TextTools
BuildRoot: %{_tmppath}/build-root-%{name}
Source0: /usr/src/packages/SOURCES/RegExpTester-1.0.tar.gz
Packager: Guillermo Amat
Url: https://www.deuteros.es
Vendor: Guillermo Amat
BuildRequires: gcc-c++, make, %{breq}
Requires: %{reqs} libc.so.6 libgcc_s.so.1 libgcc_s.so.1(GCC_3.0) libm.so.6 libpthread.so.0 libstdc++.so.6 libstdc++.so.6(CXXABI_1.3) libstdc++.so.6(GLIBCXX_3.4)
%description
RegExpTester is an application that lets you test regular expresions
 
RegExpTester is an application that lets you test regular expresions  

En el bloque anterior también se aprecia la aparición de las variables que hemos definido con anterioridad. Su valor se concatena al de los nombres de los paquetes que aparecen definidos. Más claro: BuildRequires contiene gcc-c++ y make porque se llaman así en todas las distribuciones (menos mal) y el contenido de la variable breq que cambia en función de la máquina virtual.
En description tenemos una descripción corta y otra que puede ser más extensa. La linea en blanco que separa a ambas es necesaria.
Vamos con el siguiente trozo. Esto ya tiene que ver con la construcción del paquete y en el aparecen nuevas variables. La diferencia es que estas no son nuestras, sino predefinidas por el sistema:

•  buildroot: el directorio donde se construirá el paquete en la MV
• _bindir: el directorio de los ejecutables
• _datadir: directorio de datos
• name: es el nombre que aparece en el campo Name (linea 17 del .spec)

Así pues lo que se hace en este bloque es preparar todos los directorios necesarios. Después se ejecuta qmake sobre el archivo .pro cosa que creará el Makefile en la MV. La siguiente linea contiene opciones de compilación específicas para la creación de rpms que, a su vez, son usadas por el comando make.
Después de ejecutar make se procede con la sección install que, en este caso, copia un par de archivos en sus lugares correspondientes.

%prep
rm -rf %{buildroot}
mkdir %{buildroot}

%setup -q

%build
mkdir -p %{buildroot}%{_bindir}
mkdir -p %{buildroot}%{_datadir}/%{name}
mkdir -p %{buildroot}%{_datadir}/applications
%{qmake} %{name}.pro
CFLAGS="$RPM_OPT_FLAGS" CXXFLAGS="$RPM_OPT_FLAGS" \
make

%install
cp %{name} %{buildroot}%{_bindir}
cp %{name}.png %{buildroot}%{_datadir}/%{name}/

 En el siguiente bloque se crea el archivo .desktop que hará que nuestro programa aparezca en el menú de inicio de KDE. No es necesario crearlo así, podríamos haberlo escrito en un editor, empaquetado en el tar.gz y por último tratarlo en el .spec de la misma forma que al png. En todo caso, se debe saber que durante la construcción se comprobará este archivo y que es muy importante que el contenido de Categories siga las definiciones del estándar de freedesktop.org 

cat > $RPM_BUILD_ROOT%{_datadir}/applications/%{name}.desktop << EOF
[Desktop Entry]
Encoding=UTF-8
Name=%{name}
GenericName=%{name}
GenericName[de]=%{name}
Comment=Synchronize files between computers
Exec=%{_bindir}/regexptester
Icon=%{_datadir}/%{name}/%{name}.png
Terminal=false
Type=Application
StartupNotify=false
Categories=Qt;KDE;Utility;TextEditor;
EOF 

Y para acabar se define el paso de limpieza y se enumeran los archivos generados para la creación del paquete. Cualquier inconsistencia entre esta lista y lo que se encuentre realmente generará un error, por ejemplo: si nuestro tar.gz contiene un segundo png que no hayamos nombrado aquí.

%clean
rm -rf %{buildroot}

%files
%defattr(-,root,root)
%dir %{_datadir}/RegExpTester
%{_datadir}/applications/RegExpTester.desktop
%{_bindir}/RegExpTester
%{_datadir}/%{name}/%{name}.png

%changelog

El archivo tar.gz

Como se ha dicho antes, lo mejor es generar el tar.gz desde una copia limpia de nuestro código fuente. Si trabajamos con Subversion haremos un "svn export" y después comprimiremos el resultado.
A parte de eso, habrá que llevar cuidado con incluir todo lo necesario y especificar correctamente las rutas de todo lo que aparezca en el .spec

El resultado

Si todo va bien en nuestro panel de resumen del paquete tendremos indicado que el proceso ha finalizado con éxito y podremos navegar hasta el repositorio de descarga de cada una de las distribuciones.

 Si por ejemplo pulsamos sobre openSuse_11_3 llegaremos a la página donde tenemos todos sus binarios disponibles:

Si algo falla, desde la pantalla de resumen veremos que se nos indica un error (failed en vez de success) y haciendo clic sobre la palabra failed accederemos al log de la máquina virtual donde veremos el error.

Una imagen vale más que mil palabras

Y un par de enalces y de archivos de ejemplo también, así que allá va:

• El proyecto RegExpTester en OBS [ir] 
• El archivo .spc [descargar]
• El archivo tar.gz [descargar]

Creando binarios para linux con Open Suse Build Service

Hay que reconocerlo: crear archivos ditribuibles para Linux es un auténtico infierno.  Además, como no, seremos víctimas de una nueva lucha de estándares rpm vs deb. Esto hace que sea bastante tentador distribuir simplemente el código fuente y desear suerte a los usuarios con la compilación, aunque de esta manera no llegaremos a los menos aventajados. También es cierto que distribuyendo el fuente no tardarán en aparecer voluntarios que crearán paquetes para determinadas distribuciones pero de esa manera perderemos el control de nuestro software. De modo  que, si queremos enfrentarnos a este problema, parece que sólo hay unas pocas soluciones: o bien encontrar un software que nos cree un instalable independiente de la distribución o tratar de llegar a la máxima cantidad de usuarios creando rpms y debs para las mayores distribuciones. Este artículo se centrará en el segundo enfoque. Open Suse Build Service (OBS) es, como su nombre indica, un servicio de construcción de paquetes binarios para las mayores distribuciones de Linux, incluyendo Ubuntu, Open Suse, Fedora, CentOs, Mandriva y alguna que otra más. Además de la creación de paquetes, pone a nuestra disposición los correspondientes repositorios de descarga para que puedan ser distribuidos a todo el mundo bien directamente, enlazando desde nuestra propia web si disponemos de ella, desde sitios capaces de integrar el servicio como kde-apps.org o desde el propio lugar habilitado por Open Suse para ello.
En este artículo trataré de describir mi experiencia para generar los binarios de un proyecto propio pero será difícil que no se me escape algún detalle así que, en todo caso, recomiendo que se de un vistazo a proyectos existentes en OBS para tener una referencia de la estructura de los archivos y a las configuraciones que se pueden encontrar en los .spec y .dsc necesarios para la construcción.
Como resumen antes de comenzar, sólo me queda decir que aunque su manejo no es todo lo sencillo que desearíamos, en cuanto se tiene un poco de práctica, obtenemos la ventaja de producir archivos instalables para la gran mayoría de distribuciones tanto en arquitectura 32 como 64 bits, algo que de otro modo no podríamos conseguir por nosotros mismos.

En qué consiste

Básicamente lo que se pone a nuestra disposición es una máquina virtual que se crea en el momento en base a nuestras necesidades. Dicho de otro modo, obtenemos un entorno de compilación y paquetización generado dinámicamente según los paquetes que habremos indicado previamente en los ficheros de descripción (uno para .deb y otro para .rpm)
Cada vez que modifiquemos alguno de los archivos de nuestro proyecto el servicio realiza una petición de construcción por el cual se crea de cero la máquina y, posteriormente a la instalación de todos los paquetes, se compila nuestro proyecto y se crea el binario. Como es natural este proceso no es especialmente rápido y más teniendo en cuenta que compartimos el servicio con otros usuarios pero con suerte, si no hay mucha cola, en poco más de unos 5 minutos podemos tener el resultado de todo el proceso.

Preparando el proyecto

Después de  crear nuestra cuenta llegará el momento de crear nuestro primer proyecto. Una de las cosas que hay que considerar es comprobar que no existe el mismo proyecto en la cuenta de otro usuario, si por ejemplo se está recompilando un fuente que no es nuestro porque lo queremos para nuestra distribución preferida.
En todo caso tendremos un proyecto creado por defecto, pero llevará el nombre de nuestro usuario, así que es recomendable crear uno nuevo.

Una vez creado el proyecto podremos asignarle paquetes y a estos a su vez podremos añadirles archivos. De una forma más práctica:

1. Nuestro proyecto puede ser el nombre de nuestro programa
2. Asignaremos las distribuciones (repositorios) para los que queremos paquetizar
3. Podemos crear un paquete para cada versión
4. A cada versión (paquete) le añadiremos todos los archivos descriptivos y de código fuente para que se creen sus binarios.

Iremos viendo a continuación como cumplir con los pasos que continúan a la creación del proyecto, pero antes de eso, como adelanto, en la imagen siguiente se puede ver la página inicial de un proyecto ya maduro

Creando los repositorios

El objetivo final de todo esto debería ser tener varios repositorios de paquetes para distribuir a nuestros usuarios. El concepto de repositorio estará ligado siempre a una distribución por lo que si elegimos distribuir para OpenSuse y Ubuntu, contaremos con dos repositorios.

En todo caso estará en nuestras manos que esta distribución de los binarios construidos sea libre o no. ¿Y por que no debería serlo? Para mí la respuesta es fácil, en mi cuenta nadie puede acceder a ellos ya que de momento OBS no registra estadísticas de descargas y ese es un dato que interesa controlar ya que mide el grado de aceptación que tiene nuestro trabajo. Una posible solución es descargarse los binarios (nuestro usuario siempre tendrá permiso por ser el creador) y subirlos a SourceForge dónde sí podremos controlar el número de descargas.
Al margen de cómo lo planteemos, la publicación es bastante flexible y podremos elegir que archivos son públicos o no por distribución y arquitectura. Esto lo veremos más adelante cuando se explique todo lo relativo a paquetes.

Creando paquetes en nuestro proyecto

Como se ha dicho con anterioridad podremos asimilar el concepto de paquetes a una versión de nuestro software. Además las tareas de construcción se lanzan contra los paquetes, dicho de otro modo, las maquinas virtuales creadas por OBS se ejecutan con la información de los archivos que habremos subido para un determinado paquete. Es por ello que todo lo que hemos visto con anterioridad sobre los permisos de construcción y publicación se hace para un determinado paquete.

La creación de un nuevo paquete es muy simple, sólo se nos pide un nombre y una descripción que podemos dejar en blanco.

Una vez creado, de nuevo contaremos con una pantalla de resumen general desde la que tendremos a nuestro alcance las diversas opciones existentes para el paquete seleccionado. Es muy similar a la del proyecto pero tiene la opción files para añadir los archivos y aquí la opción repositories sirve para controlar la construcción y publicación para distintas distros y arquitecturas, mientras que en la opción del proyecto sirve para añadir o quitar distribuciones.

 Los archivos

A nuestro paquete subiremos archivos para que OBS construya los binarios pero antes de nada debemos saber que cada vez que subamos un archivo a un determinado paquete, se disparará un petición de construcción para los sistemas/arquitecturas permitidos.
Veremos por ahora de forma muy superficial los archivos que necesitaremos para la versión 0.0.1 de una aplicación llamada app de la que queremos .deb para Ubuntu y rpms para diversas distribuciones basadas en este otro sistema:
Para construir los rpms:

• app.spec Es el descriptor del paquete que vamos a construir
• app-0.0.1.tar.gz El código fuente a compilar para obtener el rpm

Para los debs:

•  app_0.0.1-1.dsc Archivo de descripción
• app_0.0.1-1.tar.gz Fuentes a compilar

Podremos editar los archivos de descripción desde la misma web pero veremos más adelante todo esto de forma más detallada cuando hablemos de cada uno de los casos de construcción en profundidad.

Controlando la construcción y distribución

Como se dijo antes, desde esta opción controlaremos todo lo relativo a la construcción y publicación de los repositorios que hemos elegido para nuestro proyecto. En la imagen que se puede ver abajo tenemos prohibida la publicación del repositorio para todas las distros y arquitecturas. Sólo nosotros, como creadores del paquete tendremos acceso a la descarga de los archivos generados.

 

También tendremos un modo similar de seleccionar para que distros y arquitecturas se debe lanzar la construcción. Por ejemplo si estamos peleándonos con la construcción de .deb para Ubuntu podemos tener paradas todas las construcciones basadas en rpm. De este modo no consumiremos recursos del servicio y no entorpeceremos a otros usuarios.

Conclusiones

Hemos visto como crear nuestro proyecto y la información básica para empezar a obtener archivos. Realmente con esto y observando en OBS algunos de los proyectos existentes, los más impacientes podrán empezar a trabajar ya. En todo caso, próximamente podréis encontrar por aquí los casos de construcción de .deb y .rpm con algunos problemas comunes y la forma a enfrentarse a ellos,

Montando una placa Zotac ION ITX-D-E en una caja Foxconn RS233

La semana pasada contaba que me había hecho un autoregalo en forma de modesto equipo informático y había prometido aburrir al personal con el montaje, pues bien lo prometido es deuda. Aquí tenéis los detalles...

La caja

Se trata de una caja Foxconn RS232 cuyo formato es mini-ITC. No es de las más pequeñas dentro de esta familia pero esto nos permitirá montar discos de 3.5, lectores de DVD de tamaño normal y además cuenta con una bahía externa de 3.5, donde montar por ejemplo un lector multitarjeta.

La caja incluye una fuente de 150w, el cableado necesario para el frontal y los soportes para montarla en vertical

A favor:

• Permite montar dispositivos de 3,5 y lectores de tamaño normal
• Relación calidad precio
  

En contra

• Sí quieres un tamaño muy reducido esta no es tu caja
  

La placa madre

Qué puedo decir de esta placa más que lo tiene todo: múltiples salidas de vídeo, infinidad de puertos usb, audio 5.1, ethernet y wifi y procesador Intel Atom 330. Sólo requiere que se le añada RAM, un disco duro y la correspondiente caja.

Hay que comentar que la conectividad wifi se proporciona mediante una tarjeta PCI que ya viene incrustada ocupando el único de estos puertos existente, así que conviene pensarse antes de adquirirla si se va a hacer uso de la conexión inalámbrica o no.

A favor

• Tiene todo lo necesario y en formato mini-ITX

En contra

• Sólo tiene un puerto PCIe y está ocupado por una tarjeta wifi así que no hay opciones de expansión.
  

El lector de tarjetas y bluetooth

En realidad sólo buscaba un lector de tarjetas de memoria pero sin querer di con uno que además era bluetooth ¿que más se puede pedir por menos de 10€?

A favor

• Incluye bluetooth
• Precio
  

En contra

• ¿Nada?
  

Montándolo todo

Antes de continuar tengo que decir, y muchos podrían dar fe de ello, que si un torpe como yo ha podido montar el equipo cualquiera puede hacerlo. ¡Comencemos!

Este es el aspecto de la caja después de quitar la tapa superior. Para dejarla así sólo hay que aflojar un único tornillo.

El siguiente paso será quitar el frontal, que no está atornillado si no que va a presión y asegurado por unas pestañas y a continuación desmontar la parte superior del armazón metálico. Para esto tendremos que acceder a dos tornillos visibles tras quitar el frontal.

Una vez nos quedamos sin obstáculos podemos montar en el chasis la placa y el disco duro:

En el panel superior que hemos desmontado de la caja atornillamos el lector de tarjetas y, si la tuviéramos, la unidad óptica.

Volvemos a colocar el panel superior y tras esto ya podremos poner el frontal y la tapa superior. Por cierto, ya que nos dan unas cuantas no está de más sujetar los cables con alguna brida.

El resultado final

Pues eso es todo, montarlo no es nada del otro mundo incluso para los más novatos. El equipo va bastante bien, arranca en unos 30 segs una OpenSuse 11.2 y todo se mueve con fluidez. Eso sí, hay que ser consciente de las limitaciones y no exigirle un gran rendimiento de proceso o con gráficos 3D.