Pestañas laterales en Empathy

Vamos directamente a la parte interesante de esta entrada.

Si usas Ubuntu Saucy 13.10 y quieres tener pestañas laterales en Empathy, sólo tienes que ejecutar los comandos siguientes:


$ sudo add-apt-repository ppa:tanty/ppa

Si además de Ubuntu Saucy 13.10 también utilizas el PPA del GNOME3 Team, también tienes que ejecutar:


$ sudo add-apt-repository ppa:tanty/gnome3

Sin más, actualiza tus repositorios, actualiza Empathy y escoge la configuración adecuada:


$ sudo apt-get update && sudo apt-get install empathy
...
$ gsettings set org.gnome.Empathy.conversation tab-position 'left'

Lo siguiente es abrir una ventana de chat desde una nueva instancia de ejecución de Empathy. Esta es una captura de algo similar a lo que deberías de ver:

Side tabs in Empathy by ::Tanty::
Side tabs in Empathy, a screenshot by ::Tanty:: on Flickr.

Motivación

Desde hace mucho tiempo soy usuario de Jabber y Empathy. Los uso a diario en mis comunicaciones y en Igalia tenemos también salas internas que usamos para coordinarnos. Debido a la cantidad de salas en las que estoy habitualmente, la ventana de chat de Empathy no es capaz de mostrar todas las pestañas en la barra superior de las conversaciones.

Esto me obliga, o bien a abrir diferentes ventanas en las que repartir las pestañas, o bien a navegar entre las pestañas de la ventana en busca de alguna actualización interesante. Una tarea bastante molesta 🙂 .

Hace tiempo fue reportado el bug #586145 que pide tener la posibilidad de posicionar las pestañas no sólo en una barra superior sino, especialmente, también en los laterales.

Por esto, decidí retomar la propuesta de parche existente y hacer unos cuantos pequeños cambios sobre el trabajo previo de Neil Roberts completando la posibilidad de tener estas pestañas laterales.

Con esta característica nueva es posible cambiar la posición de las pestañas sólo con cambiar la configuración pertinente ya que ambas están conectadas. Para posicionar las pestañas ‘arriba’, a la ‘izquierda’, ‘abajo’ o a la ‘derecha’ respectivamente, sólo tenemos que ejecutar:


$ gsettings set org.gnome.Empathy.conversation tab-position 'top'
$ gsettings set org.gnome.Empathy.conversation tab-position 'left'
$ gsettings set org.gnome.Empathy.conversation tab-position 'bottom'
$ gsettings set org.gnome.Empathy.conversation tab-position 'right'

Tras los cambios, he actualizado el parche propuesto y ya sólo estoy esperando pasar la revisión e integrarlos en el código.

Esta característica es una pequeñísima mejora del gran trabajo realizado por varios desarrolladores de GNOME a lo largo de los años. Sin embargo, significa una importante diferencia en mi uso cotidiano y es por esto que he decidido compartirla lo más pronto posible por si hubiera más gente interesada ya que llevará un tiempo hasta que alcance a las principales distribuciones. Para ello, he migrado el parche a la versión de Empathy que estoy utilizando en mi Ubuntu Saucy 13.10.

Si quieres probarla, simplemente sigue las instrucciones que he escrito al principio de esta entrada.

Notas finales

Además de Empathy, también puedes encontrar en mis PPAs:

  • Una versión personalizada del paquete icecc oficial que no funciona. En ella he aplicado los parches que corrigen el bug LP#1182491.
  • Una versión personalizada de webkitgtk en la que he aplicado los parches que arreglan el bug WK#115650. Estos cambios aceleran sustancialmente la velocidad a la que se abren pestañas nuevas en Web.

Que disfrutes de Emapthy!

Actualización: Recientemente he añadido las versiones parcheadas de empathy también para Ubuntu Trusty 14.04.

Actualización 2: Recientemente he añadido las versiones parcheadas de empathy también para Ubuntu Utopic 14.10.

Cómo publicar rápidamente en tu PPA de Ubuntu

Esta entrada es, principalmente, unas cuantas notas personales con instrucciones para publicar rápidamente un paquete (habitualmente parcheado) en mis propios PPAs.

Parcheando un paquete existente

Lo primero es descargar las fuentes del paquete del repositorio que está proporcionando la versión que queremos parchear y cuyo binario tenemos instalado en el sistema.

Por ejemplo, para parchear webkitgtk, si el paquete que está instalado procede directamente de Ubuntu, sólo tendremos que comprobar que tenemos el repositorio de fuentes oficial de Ubuntu. Sin embargo, si el paquete procede de otro PPA, tendremos que comprobar que también tenemos el repositorio con las fuentes de ese mismo PPA. De no ser así, tendremos que descargar los ficheros necesarios de forma manual. Asumamos que el paquete que tenemos instalado procede del PPA del GNOME3 Team:

$ cd ~/ppa/ && mkdir -p webkitgtk/gnome3 && cd webkitgtk/gnome3
$ apt-get source webkitgtk
Reading package lists... Done
Building dependency tree
Reading state information... Done
NOTICE: 'webkitgtk' packaging is maintained in the 'Git' version control system at:
git://git.debian.org/git/pkg-webkit/webkit.git
Need to get 9,440 kB of source archives.
Get:1 http://ppa.launchpad.net/gnome3-team/gnome3/ubuntu/ saucy/main webkitgtk 2.3.2-1ubuntu6~saucy1 (tar) [9,353 kB]
Get:2 http://ppa.launchpad.net/gnome3-team/gnome3/ubuntu/ saucy/main webkitgtk 2.3.2-1ubuntu6~saucy1 (diff) [82.2 kB]
Get:3 http://ppa.launchpad.net/gnome3-team/gnome3/ubuntu/ saucy/main webkitgtk 2.3.2-1ubuntu6~saucy1 (dsc) [4,577 B]
Fetched 9,440 kB in 3s (2,769 kB/s)
gpgv: Signature made Sun 22 Dec 2013 01:34:25 AM EET using RSA key ID 153ACABA
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on ./webkitgtk_2.3.2-1ubuntu6~saucy1.dsc
dpkg-source: info: extracting webkitgtk in webkitgtk-2.3.2
dpkg-source: info: unpacking webkitgtk_2.3.2.orig.tar.xz
dpkg-source: info: unpacking webkitgtk_2.3.2-1ubuntu6~saucy1.debian.tar.gz
dpkg-source: info: applying 02_notebook_scroll.patch
dpkg-source: info: applying aarch64.patch
dpkg-source: info: applying fix-ppc.diff
dpkg-source: info: applying fix-aarch64.patch
dpkg-source: info: applying remove-use-lockfree-threadsaferefcounted.patch
dpkg-source: info: applying no-jit-build-failure.patch
dpkg-source: info: applying 0001-GTK-Fails-to-build-with-freetype-2.5.1.patch
dpkg-source: info: applying disable-jit-harder.patch
dpkg-source: info: applying fix-llint-c-loop.patch
dpkg-source: info: applying fix-armv7.patch
dpkg-source: info: applying bugzilla_clear_surface.patch
dpkg-source: info: applying ppc64el.patch
$ cd webkitgtk-2.3.2

Por si acaso, algo que me gusta hacer es añadir el código descargado a un sistema de control de versiones local con git:

$ git init
$ git add *
$ git commit -m "Initial commit"
...

Ahora es el momento de realizar los cambios al código fuente. Esta es mi principal razón por la que git puede resultarnos útil si es que los cambios no son triviales y necesitamos realizar algo de trabajo para tener una versión funcional. Una vez que hemos finalizado los cambios debemos añadirlos al paquete debian como un parche adicional al código fuente original. Esto lo haremos con dpkg-source:

$ dpkg-source --commit
dpkg-source: info: local changes detected, the modified files are:
 webkitgtk-2.3.2/Source/WebKit2/GNUmakefile.am
 webkitgtk-2.3.2/Source/WebKit2/GNUmakefile.list.am
 webkitgtk-2.3.2/Source/WebKit2/Shared/Plugins/Netscape/NetscapePluginModule.h
 webkitgtk-2.3.2/Source/WebKit2/Shared/Plugins/Netscape/x11/NetscapePluginModuleX11.cpp
 webkitgtk-2.3.2/Source/WebKit2/UIProcess/Plugins/gtk/PluginInfoCache.cpp
 webkitgtk-2.3.2/Source/WebKit2/UIProcess/Plugins/gtk/PluginInfoCache.h
 webkitgtk-2.3.2/Source/WebKit2/UIProcess/Plugins/unix/PluginInfoStoreUnix.cpp
Enter the desired patch name: 0001-GTK-WK2-Blocks-when-fetching-plugins-information.patch
...

Escribimos el nombre del parche y la descripción de los cambios realizados:

$ cat debian/patches/0001-GTK-WK2-Blocks-when-fetching-plugins-information.patch
Description: [GTK][WK2] Blocks when fetching plugins information
 https://bugs.webkit.org/show_bug.cgi?id=115650
 .
 Patch by Carlos Garcia Campos.
 Reviewed by Gustavo Noronha Silva.
 .
 Use a persistent cache to store the plugins metadata to avoid
 having to load all the plugins everytime a plugin is used for the
 first time.
 .
 * GNUmakefile.am:
 * GNUmakefile.list.am:
 * Shared/Plugins/Netscape/NetscapePluginModule.h:
 * Shared/Plugins/Netscape/x11/NetscapePluginModuleX11.cpp:
 (WebKit::NetscapePluginModule::parseMIMEDescription): Make this
 method public.
 (WebKit::NetscapePluginModule::buildMIMEDescription): Added this
 helper to build the MIME description string.
 * UIProcess/Plugins/gtk/PluginInfoCache.cpp: Added.
 (WebKit::PluginInfoCache::shared):
 (WebKit::PluginInfoCache::PluginInfoCache):
 (WebKit::PluginInfoCache::~PluginInfoCache):
 (WebKit::PluginInfoCache::saveToFileIdleCallback):
 (WebKit::PluginInfoCache::saveToFile):
 (WebKit::PluginInfoCache::getPluginInfo):
 (WebKit::PluginInfoCache::updatePluginInfo):
 * UIProcess/Plugins/gtk/PluginInfoCache.h: Added.
 * UIProcess/Plugins/unix/PluginInfoStoreUnix.cpp:
 (WebKit::PluginInfoStore::getPluginInfo): Check first if we have
 metadata of the plugin in the cache and update the cache if we
 loaded the plugin to get its metadata.
...

Finalmente, modificaremos la información de publicación añadiendo o incrementando el digito «non-maintainer». Por ejemplo, para este caso la versión del código descargado es 2.3.2-1ubuntu6~saucy1 por lo que modificaremos la versión a 2.3.2-1ubuntu6~saucy1.1. Debemos también acordarnos de proporcionar el nombre adecuado de distribución o bien modificarlo al adecuado cuando estemos introduciendo el resumen de los cambios realizados. En este caso la distribución sería saucy. Comprueba también que estás utilizando la dirección de correo electrónico adecuada en el resumen de los cambios. En el caso de mis PPAs, uso mi cuenta personal:

$ DEBEMAIL="mi@cuenta-de.correo" dch -n -D saucy
$ cat debian/changelog
webkitgtk (2.3.2-1ubuntu6~saucy1.1) saucy; urgency=low

  * Fixes #115650:
    - debian/patches/0001-GTK-WK2-Blocks-when-fetching-plugins-information.patch

 -- Andres Gomez   Wed, 19 Mar 2014 14:26:19 +0200
...

Con esto habremos terminado de modificar el código fuente del paquete.

Alternativa mediante la importación de un parche

Quizá esta es la forma más limpia y rápida de parchear el código fuente del paquete descargado. En vez de modificar el código y ejecutar dpkg-source –commit, símplemente podemos importar un parch ya existente que se pueda aplicar sin problemas sobre el código fuente.

Para ello ejecutaremos:

$ quilt import //mi_parche.patch

Este método es también válido para versiones de paquetes Debian en los que no funciona el comando dpkg-source –commit. Además, es la forma más rápida de reutilizar un parche para un paquete de una versión previa de Ubuntu en una nueva versión, por ejemplo.

A partir de este punto retomaremos los mismos pasos que se describieron anteriormente para añadir la información de publicación.

Construyendo el paquete con el código fuente

Sólo tenemos que tener en cuenta que, si tenemos más de una clave GPG, el firmado del paquete fallará, tal y como muestra la siguiente línea:

$ debuild -S -rfakeroot
...
Finished running lintian.
Now signing changes and any dsc files...
 signfile webkitgtk_2.3.2-1ubuntu6~saucy1.1.dsc Andres Gomez 
gpg: skipped "Andres Gomez ": secret key not available
gpg: /tmp/debsign.vhpVY32w/webkitgtk_2.3.2-1ubuntu6~saucy1.1.dsc: clearsign failed: secret key not available
debsign: gpg error occurred!  Aborting....
debuild: fatal error at line 1280:
running debsign failed

Debido a esto, tenemos que especificar el id de la clave a usar mediante el parámetro -k.

Además, si el código fuente del paquete no procede de uno de los repositorios oficiales de Ubuntu, tendremos que proporcionar el código fuente original para que también sea transferido al PPA. Esto lo haremos pasando el parámetro -sa. En nuestro ejemplo, como el código fuente proced del PPA del GNOME3 Team, el comando sería algo como:

$ debuild -S -sa -rfakeroot -k3FEA1034

Mientras que para otros paquetes que hayamos modificado a partir de fuentes que procedan directamente de uno de los repositorios oficiales de Ubuntu, usaremos:

$ debuild -S -rfakeroot -k3FEA1034

Construcción local opcional

Construir el paquete localmente no es un paso realmente necesario pero nos dirá si los cambios realizados están «rompiendo» la compilación.

La mejor manera de hacer esto de una manera confiable es mediante pbuilder.

Cuando usemos pbuilder nos tendremos que asegurar de que estamos usando los paquetes adecuados, no sólo los que proceden de los repositorios oficiales de Ubuntu, si no también que estamos usando los que proporcionan los PPAs de los cuales depende nuestro PPA y también los proporcionados por nuestro propio PPA.

Yo ya me he creado los ficheros comprimidos con los «chroot» necesarios con las distribuciones adecuadas para mis PPAs. Sin embargo, con el ánimo de mostrar un ejemplo, usaríamos un comando parecido al que sigue para crear este fichero comprimido si mi PPA objetivo fuese gnome3, que depende de mi otro PPA ppa y también del PPA gnome3 del GNOME3 Team:

$ sudo pbuilder --create --distribution saucy --mirror "http://fi.archive.ubuntu.com/ubuntu/" --othermirror "deb http://fi.archive.ubuntu.com/ubuntu/ saucy restricted universe multiverse|deb http://fi.archive.ubuntu.com/ubuntu/ saucy-updates main restricted universe multiverse|deb http://fi.archive.ubuntu.com/ubuntu/ saucy-proposed main restricted universe multiverse|deb http://fi.archive.ubuntu.com/ubuntu/ saucy-security main restricted universe multiverse|deb http://archive.canonical.com/ubuntu saucy partner|deb http://ppa.launchpad.net/gnome3-team/gnome3/ubuntu trusty main|deb http://ppa.launchpad.net/tanty/ppa/ubuntu saucy main|deb http://ppa.launchpad.net/tanty/gnome3/ubuntu saucy main" --basetgz //saucy-gnome3.tgz --buildplace //build --aptcache  //aptcache/

Utilizo <ruta_base_de_pbuilder> porque, por defecto, todo el proceso de la creación del fichero comprimido se realiza en /var y no siempre tengo el espacio necesario allí.

Una vez que el fichero comprimido ha sido creado y siguiendo nuestro ejemplo, construiríamos el paquete para el PPA objetivo gnome3 tal y como sigue:

$ sudo pbuilder --build --mirror "http://fi.archive.ubuntu.com/ubuntu/" --othermirror "deb http://fi.archive.ubuntu.com/ubuntu/ saucy main restricted universe multiverse|deb http://fi.archive.ubuntu.com/ubuntu/ saucy-updates main restricted universe multiverse|deb http://fi.archive.ubuntu.com/ubuntu/ saucy-proposed main restricted universe multiverse|deb http://fi.archive.ubuntu.com/ubuntu/ saucy-security main restricted universe multiverse|deb http://archive.canonical.com/ubuntu saucy partner|deb http://ppa.launchpad.net/gnome3-team/gnome3/ubuntu trusty main|deb http://ppa.launchpad.net/tanty/ppa/ubuntu saucy main|deb http://ppa.launchpad.net/tanty/gnome3/ubuntu saucy main" --basetgz //saucy-gnome3.tgz --buildplace //build --aptcache  //aptcache/ ../webkitgtk_2.3.2-1ubuntu6~saucy1.1.dsc

Ya sólo resta esperar y comprobar los resultados.

Publicando en el PPA

El último paso es transferir el paquete con los cambios a nuestro PPA.

En mi caso, tengo un PPA para pruebas por cada PPA estable. Estos PPAs no están pensados para su utilización por el usuario de Ubuntu general sino, simplemente, para poder jugar con los cambios que realizo hasta que siento que son lo suficientemente estables como para ser publicados en mis PPAs estables. Por esto, los 4 PPAs que manejo son:

  • ppa: Donde publico los paquetes procedentes de repositorios oficiales de Ubuntu con cambios que me son útiles.
  • ppa-next: No dirigido al público general. Aquí tengo los paquetes inestables hasta que son suficientemente estables como para ser publicados en el PPA ppa.
  • gnome3: Donde publico los paquetes procedentes del PPA del GNOME3 Team con cambios que me son útiles.
  • gnome3-next: No dirigido al público general. Aquí tengo los paquetes inestables hasta que son suficientemente estables como para ser publicados en el PPA gnome3.

Durante el primer ciclo de desarrollo publico los cambios en mis PPAs inestables antes de publicarlos en los estables. Siguiendo nuestro ejemplo, el PPA en el que publicaría por primera vez sería gnome3-next:

$ dput ppa:tanty/gnome3-next ../webkitgtk_2.3.2-1ubuntu6~saucy1.1_source.changes

Cuando ya estoy lo suficientemente convencido de mis cambios, lo siguiente sería publicar en el PPA estable:

$ dput -f ppa:tanty/gnome3 ../webkitgtk_2.3.2-1ubuntu6~saucy1.1_source.changes

El argumento -f lo utilizo para evitar el error que se produce cuando ya existe un fichero de «log» procedente de una publicación anterior de un fichero «.changes» mediante dput.

Tras esto, sólo tenemos que esperar a que el paquete sea contruído en los bots del PPA, actualizar nuestros repositorios y actualizar el sistema:

$ sudo apt-get update && sudo apt-get upgrade

Disfruta tu nuevo paquete!

Cómo convertir un video

Versión ultra rápida: descarga Miro Video Converter y sigue los pasos de este video tutorial.

Motivación

Cómo todo informático que se precie, aunque mi plataforma de trabajo personal y profesional es un escritorio GNOME en una distribución de GNU/Linux, de manera recurrente mis amigos y familiares me hacen el mismo tipo de preguntas: «¿cómo hago x en Windows?».

No importa que repita sin parar que no tengo ni idea de Windows desde la última vez que lo usé de forma habitual, allá por Windows 2000, la respuesta es siempre la misma: «Ya, pero seguro que sabes… ¿Qué clase de informático eres, si no?».

El caso es que mi conocimiento de Windows se limita a lo que cualquiera puede obtener haciendo búsquedas en Internet. Es decir, yo no sé de Windows. Sé cómo funciona un sistema operativo en general y, sobre todo, sé inglés y sé cómo buscar información. De cualquier manera, mientras GNOME no acabe llegando masivamente al usuario final de ordenadores, supongo que tendré que seguir enfrentándome a seguir dando soporte de Windows, aunque cada vez menos …

Pero vamos a la parte sustancial de esta entrada. Una de esas preguntas recurrentes es: «¿cómo convierto este video?». En realidad, esta pregunta esconde información que está implícita y que es: ¿cómo convierto este video, gratis, en Windows?.

Aún así, voy a contestar a esta pregunta también para el caso de GNU/Linux.

Windows y Mac

  • Un conversor GPL muy sencillo y es Miro Video Converter. Aquí dejo un video tutorial.
  • También GPL y algo más complejo y con más opciones es Avidemux.
  • GPL, parecido a Avidemux por tener más opciones, y usando el potente conversor proporcionado por MEncoder, es TEncoder.
  • Finalmente, en esta pequeña lista, añado otro programa llamado Ligtworks que, sin ser libre como los dos anteriores, sí que (por ahora) es de uso gratuíto. Es un programa orientado al uso profesional, así que su complejidad es mucho mayor y sólo lo recomendaría para quien de verdad quiera hacer edición de videos.

Por supuesto, hay multitud de otros programas que podrían usarse para convertir videos, algunos tan conocidos como Virtualdub o SUPER, pero no quiero añadir más para no marear con opciones. Quién de verdad esté interesado sabrá cómo encontrar más alternativas.

GNOME en GNU/Linux

Las posibilidades en GNU/Linux son realmente numerosas. Encontramos entre ellas de nuevo tanto Avidemux como Lightworks o múltiples opciones para usar con MEncoder, pero también alguna más que pueden ser útiles.

  • Arista es un programa muy similar en su concepción a Miro Video Converter. Aquí tenéis un video tutorial.
  • Otra opción sería Transmageddon, aunque los mismos autores recomiendan usar Arista si no eres un usuario con algo más de conocimientos.
  • Los creadores de Miro Video Converter también proporcionan el reproductor Miro para GNU/Linux que permite convertir videos de una manera muy similar al primer programa. Este reproductor también está disponible para Windows y Mac.
  • Como opción más compleja en esta lista añado Kdenlive, que estaría también orientado a usuarios que no sólo quieren convertir un video si no realizar modificaciones.

Como digo, las opciones en GNU/Linux son bastante más numerosas, incluyendo programas muchos más completos y complejos como Cinelerra, PiTiVi, OpenShot, LiVES, Flowblade o Shotcut.

Índice de radios de Internet

A continuación listo un índice de radios de Internet en streaming que emiten de una manera compatible con sistemas abiertos como GNU/Linux. Normalmente esto implica que no será necesario utilizar el plugin de flash o algún tipo de codec propietario raro.

Actualizaré esta entrada de vez en cuando.

Radios

Índices

España

Grupo Prisa (Cadena SER, 40 Principales, M80, Máxima FM, Radiole, Cadena DIAL, etc)

Otros índices

¿Tendra alumnos la FIC para el curso 2012/2013?

Cualquiera podría pensar que no o, al menos, que no es lo que está buscando la mismisima plantilla educativa que trabaja en la facultad.

Y es que es difícil no pensar en esta posibilidad a la vista de esta oferta de contratación, Ref. 2012/CP/062, dónde el requisito formativo, nuevamente, no llega más allá de estar en posesión del título de bachillerato, aparte de la posible experiencia profesional.

¡Total, ¿para qué vas a querer estudiar una carrera en la FIC cuando la propia facultad no exige la titulación que imparte para realizar contrataciones?!

Dejo aquí el PDF de la oferta, por si acaso desapareciera en un tiempo.

Esta es una convocatoria que en realidad ya es vieja. El contrato era de 3 meses y la fecha estimada de inicio era mediados de junio de 2012, así que a estas alturas es posible hasta que el contrato ya se haya extinguido.

Uno no dispone de mucho tiempo para sentarse y escribir con todo el cuidado necesario este tipo de entradas. Aún así, no quería dejar de comentar esta oferta de contratación. Como ya decía anteriormente en No estudies Ing. Informática, no le interesa ni a tu facultad, aquel caso era sólo «un ejemplo más de una práctica bien generalizada» y a eso mismo suena también esta oferta de contratación.

Esta vez, además de la titulación de bachillerato se requiere «Traballo previo en investigación para tarefas de I+D, al menos 6 meses en puesto similar. Experiencia de 2 años entorno .NET C#, Hibernate, Spring, Javascript, Servicios Web WCF, SOAP.». Vamos, que si el CV no es técnicamente tan explícito como en la anterior, tampoco es que se queden muy cortos en cuanto a detallar lo que necesitan. Sobre todo por el hecho de pedir haber trabajado 6 meses en un puesto similar. Como es I+D, ya sabemos cuantas posibilidades hay de que haya alguien investigando algo similar en otro sitio: prácticamente ninguna.

«¡Oye, que si no has trabajado con nosotros ya 6 meses antes, te puedes volver por donde has venido!».

En todo caso, si se necesita un perfil tan especializado, lo mínimo sería pedir la titulación de Ing. Informática, ¿no?. Y con más razón cuando es un puesto para un laboratorio de la Universidad que imparte dichas titulaciones … Vamos, que estamos asistiendo de nuevo a un caso de enchufe. Esa práctica que ya incluso se está haciendo tristemente famosa como «typical Spanish» y lacra de nuestro propio desarrollo con artículos hasta en The Guardian.

Lo que no entiendo de estas convocatorias es por qué no ponen ya el nombre y apellido en los requisitos. Así nos enteraríamos mucho antes de quién es el agraciado.

El puesto es para participar en el proyecto «Axudas para a consolidación e estruturación de unidades de investigación competitivas do sistema universitario de Galicia».

El nombre es de un abstracto que da la risa pero, resumiendo, es un puesto de trabajo financiado con fondos públicos, por si no quedaba todavía totalmente claro al ser una convocatoria de la UDC (Universidade da Coruña).

La persona admitida para estas ayudas, que es el investigador principal del proyecto y quien firma la convocatoria de contratación es Alejandro Pazos Sierra. Como vemos en su linkedin (aquí una captura), es profesor en la UDC y participa en el equipo de investigación SABIA (Sistemas Adaptativos y Bioinspirados en Inteligencia Artificial), que está integrado en el grupo de excelencia RNASA (Redes de Neuronas Artificiales y Sistemas Adaptativos), a quien pertenece el laboratorio para donde se ofertaba este contrato.

Como decía, en realidad no sé a quién estaba dirigida esta oferta de contratación. Ya dije en su momento que yo no estoy buscando perjudicar particularmente a los implicados en este tipo de convocatorias. Más al contrario, para mi está claro que son cosas como estas las que están perjudicando al común de los ingenieros al no hacer las cosas de una forma justa.

Es simplemente triste ver como las cosas en España y la Universidad no cambian y los ecos de estos comportamientos ya llegan hasta a medios internacionales.

¿Seguirá la FIC desprestigiando a su propia titulación con convocatorias como esta? Lo veremos en el futuro …