Archivos Mensuales: octubre 2008 - Paginas 2

Sobre Las Linux Autonómicas

Hola, llevo tiempo pensando sobre las distribuciones linuxeras autonómicas españolas. En la actualidad casi todas las comunidades autonómicas tienen una distro linuxera: LliureX, Guadalinex, Molinux, etc… Desgraciadamente la mayoría de los españoles desconocen su existencia, es natural, casi nadie conoce Linux. Lo que ya no es tan natural es que el profesorado y alumnado de colegios e institutos públicos no conozcan ni utilicen dichas distribuciones, máxime cuando el principal objetivo de estas distribuciones es ser utilizadas en la enseñanza pública.

comunitatur5

lliurex

Las distros autonómicas casi ni se instalan en los colegios e institutos públicos, y en muchos de los que se instalan no se utilizan porque al profesorado ni se le enseña ni se le conciencia sobre las bondades que tiene el uso de estas distribuciones en la sociedad.

Hoy en día utilizar Linux no es tan complicado como utilizar Windows, y la casi totalidad de las aplicaciones principales para la enseñanza tienen su paralelo linuxero. Por ejemplo, todos podemos utilizar Openoffice para escribir textos, crear presentaciones, etc. También podemos utilizar las TIC en Linux, ya que la mayoría dependen sólo de una conexión a internet, un navegador y como mucho soporte Java y Flash. A los alumnos se les puede enseñar ha realizar tareas de matemáticas utilizando herramientas como Geogebra o WxMaxima, con eso tienen más que suficiente para manejarse en las matemáticas escolares.

Si se diese el caso de que en los colegios o institutos se diese algún lenguaje de programación hay que tener en cuenta que Linux va muy bien soportado en estos menesteres: Java, Python, C, C++, Perl, Html, CSS, etc. Todos ellos se pueden enseñar en las aulas a nivel de iniciación.

Pero claro, si al profesorado no se le ha enseñado el uso de estas aplicaciones y el uso de su correspondiente distribución linuxera autonómica difícilmente podrán enseñar sus conocimientos a sus pupilos.

Al profesorado habría que concienciarle de que si enseña en Linux la sociedad obtiene grandes beneficios, hay que decirle que con Linux las autoridades no gastan miles y miles de euros en el pago de licencias privativas, dinero que al fin y al cabo pagamos todos los españoles. Hay que informar al docente de que los padres de los alumnos se ven beneficiados también, ya que pueden obtener un SO y un conjunto completo de software gratuito y legal que cumplimenta con creces la enseñanza en el alumnado. Hay que informar de que detrás de la creación de estas distros autonómicas hay un personal al que se le paga con el dinero de los contribuyentes para que todos tengamos acceso a estos SO, pero que el coste es infinitamente menor que el tener que pagar las licencias privativas.

Creo que todo radica en enseñar, concienciar, informar y hablar sobre las bondades del uso de las distribuciones autonómicas al docente y al alumnado.

Otra cosa que pienso es sobre si realmente es útil tener distribuciones autonómicas sabiendo que las distribuciones linuxeras oficiales que podemos instalar en los colegios e institutos con un coste menor que las autonómicas, son más actualizadas y completas que las autonómicas. Lo digo porque para qué queremos tener un, por ejemplo, LliureX basada en Ubuntu Gutsy en la actualidad cuando podemos disfrutar de un Ubuntu Hardy o Intrepid en nuestros institutos y colegios de forma legal y con menor coste económico para las autoridades porque no habría que pagar a los que crean las distribuciones autonómicas.

Pienso que los políticos deberían enfocar más el asunto en crear cursos de formación gratuitos sobre la utilización de Linux tanto en el profesorado como en el mercado laboral, que en gastar el dinero en crear su propia distribución linuxera, las cuales últimamente tienen un carácter mas que nada reivindicativo sobre no se qué nacionalismos ficticios.

Realmente deberíamos plantearnos si la existencia de las distribuciones linuxeras autonómicas sirven para algo o no, ya que dado su bajísimo nivel de utilización no parece compensar el gasto económico que reportan al estado: personal, cds, servidores web, transporte, publicidad, marketing, etc; y todo ello para no ser casi utilizado en las aulas. Para eso casi que prefiero que no existan, de hecho, casi no existen pero nos cuestan dinero.

Saludos :-h

El Blues Africano deee….

Hola peñaaa :) , aquí toy pa daros el coñazo con el blues, esta vez con blues africano, casi ná ;) . El blues africano de Ali Farka Touré, un tipo de Mali que se dedica ha hacer blues con ritmos africanos. Aunque como muy bien él dice, no hay negros americanos, porque los negros americanos son africanos que migraron a América. Os dejo con un vídeo de muestra para ver si os mola.


“Ai-du” ali farka toure
Cargado por jahconnect1975

Creando Paquetes RPM: Sin Fuentes Y Sin Autotools

Hola, vamos a continuar el tutorial sobre cómo crear paquetes RPM que empecé el otro día, si me lees te advierto que antes leas la primera parte de este tutorial si no lo hiciste antes.
Bien, en esta segunda parte trataré de explicar cómo crear un paquete rpm de un programa del cual no poseemos sus fuentes.
Recordar antes que en el mundo rpm lo de fuentes es referirnos a que el programa a empaquetar no posee el paquete en formato src-rpm, en cuyo interior se encuentra el fichero de extensión spec; lo cual nos obliga a crearlo por nuestra cuenta.
La explicación se basará mediante un ejemplo concreto, me basaré sobre el programa VerTV de nuestro coleguilla Alberto.
El primer paso será obtener el programa a empaquetar en formato comprimido, es fuertemente recomendable que esté comprimido en formato .tar.bz2, así que si no lo está lo podemos cambiar fácilmente con una simple descompresión y volviendo a comprimir en dicho formato, lo podéis realizar con un patr de clicks sin tener que aplicar ningún comando por terminal, al estilo ventanas ;) Si queréis os podéis bajar el programa de AQUI, para hacer una práctica interactiva.
Detengámonos un suspiro en este punto para aclarar una cosa, si abrís el comprimido de VerTV notaréis que si intentamos instalarlo directamente no podemos hacerlo mediante la típica compilación del programa ya que no figuran los ficheros correspondientes. Hasta el momento yo conozco tres formas de hacer esta compilación:

1. Mediante Autotools-> Con configure y make
2. Mediante la forma cmake
3. Mediante Scons-> Es una herramienta similar a autotools

Otra forma sería que el programa fuese de codigo python y llevase un fichero instalador, pero esto ya escapa de este ámbito explicativo. Hasta aquí este pequeño inciso para aclarar a qué me refiero cuando en el título he escrito lo de “Sin Autotools”.
Bien, nuestro programa VerTV no lleva autotools y, por tanto, deberemos tenerlo muy en cuenta para crear el fichero spec que os explico en breve.
Bueno si has leido mi primera parte del tutorial recordarás quie en nuestro directorio ppal. creamos un directorio raíz llamado rpm con una serie de subdirectorios, de esos directorios hay uno que se llama SOURCES, dentro de dicho directorio debéis meter el fichero .tar.bz2 de vuestro programa, ¡sin descomprimirlo!. En nuestro ejemplo concreto se llama vertv-1.0.1.tar.bz2; ya tenemos otro paso superado ;)
El siguiente peldaño será crear el fichero .spec, este paso es el más dificultoso e importante de todo el proceso. Os pongo primero como guía el de nuestro ejemplo y os voy explicando lo más importante. Al fichero le he llamado vertv.spec, debéis guardarlo en la ruta rpm/SPECS, y se puede escribir con gedit, kate o el que más os mole. Aquí tenéis el mio:

Name: vertv
Version: 1.0.1
Release: 1
URL: http://diariodeunlinux3ro.es/
Summary: Front-end para Sopcast
License: GPL
Group: Internet/Remote Access
Source0: vertv-1.0.1.tar.bz2
BuildRoot: %{_tmppath}/%{name}-%{version}-buildroot
Requires: zenity >= 2.20, totem >= 2.18, mplayer >= 0.99, vlc >= 0.8.0, libstdc++5-devel, libstdc++5, glibc, gcc, libgcc1
Provides: %{name}, ld-linux.so.2(GLIBC_PRIVATE),libc.so.6(GLIBC_PRIVATE)

%description
VerTV es un front-end realizado por Alberto Jimenez (http://diariodeunlinux3ro.es) mediante zenity gracias al cual podremos visualizar vídeos de Sopcast. El objetivo de este proyecto es construir una interfaz potente y bonita, aunque zenity no sea muy apropiado para ello. Sin embargo, zenity hace que sea muy intuitivo el manejo del programa.

Más información en: http://diariodeunlinux3ro.es

%prep
%setup -q -a 0

%install
rm -rf $RPM_BUILD_ROOT
install -D -m 755 vertv.sh $RPM_BUILD_ROOT/usr/bin/vertv.sh
install -D -m 755 sp-sc-auth $RPM_BUILD_ROOT/usr/bin/sp-auth/sp-sc-auth
install -D -m 644 vertv.desktop $RPM_BUILD_ROOT/usr/share/applications/vertv.desktop
install -D -m 644 vertv.png $RPM_BUILD_ROOT/usr/share/pixmaps/vertv.png
install -D -m 755 postinst $RPM_BUILD_ROOT/usr/bin/sp-auth/postinst

%clean
rm -rf $RPM_BUILD_ROOT

%post
sh /usr/bin/sp-auth/postinst
rm -f /usr/bin/sp-auth/postinst

%files
%defattr(0755,root,root)
/usr/bin/vertv.sh
/usr/bin/sp-auth/sp-sc-auth
/usr/share/applications/vertv.desktop
/usr/share/pixmaps/vertv.png
/usr/bin/sp-auth/postinst

%changelog
* Mon Sep 22 2008 Cristobal Lopez <http://tobal.cymaho.com>
- Modificando el fichero spec
- Construir el rpm sin ser superusuario
* Wed Sep 17 2008 Alejandro Sanchez <http://sinwindows.es>
- Primer fichero spec
- Conseguido que pregunte por la dependencia de Zenity
- Contiene lo mismo que el .deb creado por Alberto

Bien, no os asustéis que no es muy difícil. Vamos con la explicación de un primer bloque:

Name: vertv
Version: 1.0.1
Release: 1
URL: http://diariodeunlinux3ro.es/
Summary: Front-end para Sopcast
License: GPL
Group: Internet/Remote Access

En Name y Version ponemos el nombre del programa y la versión a empaquetar, en Realease ponemos el número de la versión del rpm que vamos a crear, normalmente será 1, pero si hacemos cambios en el rpm y no afectan a la versión del programa a empaquetar, el número será mayor que 1.
En URL ponemos la web de donde nos hayamos bajado el programa, en Summary ponemos en una línea de qué va el programa, ¡sin acentos!. En License ponemos la licencia del programa, en Group ponemos la sección a la que corresponde nuestro programa cuando aparezca en Rpmdrake, en el caso de Mandriva.
Pasemos a un segundo bloque:

Source0: vertv-1.0.1.tar.bz2
BuildRoot: %{_tmppath}/%{name}-%{version}-buildroot
Requires: zenity >= 2.20, totem >= 2.18, mplayer >= 0.99, vlc >= 0.8.0, libstdc++5-devel, libstdc++5, glibc, gcc, libgcc1
Provides: %{name}, ld-linux.so.2(GLIBC_PRIVATE),libc.so.6(GLIBC_PRIVATE)

%description
VerTV es un front-end realizado por Alberto Jimenez (http://diariodeunlinux3ro.es) mediante zenity gracias al cual podremos visualizar vídeos de Sopcast. El objetivo de este proyecto es construir una interfaz potente y bonita, aunque zenity no sea muy apropiado para ello. Sin embargo, zenity hace que sea muy intuitivo el manejo del programa.

Más información en: http://diariodeunlinux3ro.es

En Source0 ponemos el nombre del comprimido que hemos puesto en el directorio SPECS. Si tuviésemos más ficheros en SOURCES que estuviesen relacionados con el programa añadiríamos Source1, Source2,…. hasta tenerlos todos. Aquí en los manuales que he leido recomiendan que pongáis la web, pero yo no os lo recomiendo si la web es muy larga y con símbolos raros, porque os dará error de sintaxis.
En BuidRoot os aconsejo que lo pongáis como está, su función es especificar que en /rpm/tmp se realizarán las operaciones necesarias de construcción del paquete rpm sin permisos de superusuario para no dañar nuestro sistema.
En Requires escribiremos las dependencias necesarias para que nuestro programa funcione, junto con la versión mínima de cada dependencia. Podemos añadir secciones como Suggests o Conflicts
La sección Provides se utiliza para especificar qué cosas extras provee nuestro programa, esto normalmente no deberéis ponerlo, lo que pasa es que este programa daba problemas con ciertas macros de C y se tuvo que hacer una triquiñuela, que solucionó Sin Windows.
En %description añadiremos una descripción más larga del programa y sin acentos.
Si habéis debianizado alguna vez un programa podréis discernir que hasta aquí se puede corresponder en un 99 % al fichero control de Debian. Pasemo a otro bloque:

%prep
%setup -q -a 0

Esto es un script en el cual lo que se hará es descomprimir el .tar.bz2 de nuestro programa en /rpm/BUILD y dejarlo todo preparado para la consrucción. Esto lo conseguimos con setup, con la opción -q nos lo descomprimirá de forma silenciosa, el 0 indica que lo haga con el Source0 que especificamos anteriormente, si tenemos más sources los especificamos aquí.

%install
rm -rf $RPM_BUILD_ROOT
install -D -m 755 vertv.sh $RPM_BUILD_ROOT/usr/bin/vertv.sh
install -D -m 755 sp-sc-auth $RPM_BUILD_ROOT/usr/bin/sp-auth/sp-sc-auth
install -D -m 644 vertv.desktop $RPM_BUILD_ROOT/usr/share/applications/vertv.desktop
install -D -m 644 vertv.png $RPM_BUILD_ROOT/usr/share/pixmaps/vertv.png
install -D -m 755 postinst $RPM_BUILD_ROOT/usr/bin/sp-auth/postinst

En la sección install especificamos dónde se instalarán nuestros ficheros del programa a empaquetar, lo haremos con el comando install, por ejemplo:

%install
install -D -m 755 vertv.sh $RPM_BUILD_ROOT/usr/bin/vertv.sh

Lo que hará es indicar que el fichero vertv.sh se copiará/instalará en /usr/bin con permisos 755, de ejecución, creando los directorios que falten gracias a -D. Normalmente los permisos serán 644, y sólo pondremos permisos 755 a los que sean ejecutables. Es obligado introducir la macro $RPM_BUILD_ROOT para que sepa que será root. Podéis consultar sobre install mediante la terminal escribiendo man install.
Si no queréis hacerlo con install lo podéis hacer con mkdir y cp, pero os aconsejo hacerlo con install porque es como se hace normalmente en los ficheros make de autotools, ya que nos facilita lo de especificar los permisos.
Recalco que esto debemos hacerlo sólo en aquellos programas que no lleven autotools, en los demás veréis que es mucho más sencillo en una próxima entrega ;)
La línea rm -rf $RPM_BUILD_ROOT es aconsejable ponerla para limpiar anteriores empaquetamientos, para ser más limpios.

%clean
rm -rf $RPM_BUILD_ROOT

Este código creo que esta claro lo que hace ;)

%post
sh /usr/bin/sp-auth/postinst
rm -f /usr/bin/sp-auth/postinst

Bien, esta sección de post no es frecuente añadirla, consiste en que cuando instalemos el rpm si hay que hacer alguna tarea posterior indicarle cuál hacer, en este caso se requiere que se ejecute el fichero postinst y luego se borre, no voy a explicar mucho más de ello, es un tema avanzado y que podéis obviar.

%files
%defattr(0755,root,root)
/usr/bin/vertv.sh
/usr/bin/sp-auth/sp-sc-auth
/usr/share/applications/vertv.desktop
/usr/share/pixmaps/vertv.png
/usr/bin/sp-auth/postinst

Esta sección sirve para definir los atributos de nuestros ficheros del programa y hacer un listado de los ficheros que compondrán el paquete, se deben listar todos con su ruta, es bastante coñazo, nos podemos ayudar con el comando rpm -bi mipaquete.spec para un listado.

%changelog
* Mon Sep 22 2008 Cristobal Lopez <http://tobal.cymaho.com>
- Modificando el fichero spec
- Construir el rpm sin ser superusuario
* Wed Sep 17 2008 Alejandro Sanchez <http://sinwindows.es>
- Primer fichero spec
- Conseguido que pregunte por la dependencia de Zenity
- Contiene lo mismo que el .deb creado por Alberto

Esta sección no tiene nada de especial, tan sólo es una especie de diario sobre los distintos cambios realizados en el programa o paquete rpm, tan sólo debemos respetar la estructura para no tener fallos de escritura.
Con esto tenemos explicado el fichero .spec, como véis es un poco fastidioso, sobretodo cuando no lo tenemos hecho por alguien, es decir, no tenemos las fuentes, pero os aseguro que esto es la menor de las veces. Quisiera hacer notar que hay muchas formas de hacer el spec, yo he puesto un standard, no he puesto cómo añadir parches u otras cosas. Os recomiendo que os bajéis las fuentes de otros programas para aprender más del asunto.
Bueno llegamos al final del proceso, sólo nos queda crear el paquete con rpmbuild así:

cd rpm
cd SPECS
rpmbuild -ba --target noarch vertv.spec

La opción -ba especifica que construya el paquete y el paquete fuente src-rpm del programa, le hemos añadido en éste caso la opción –target noarch para aclarar que nuestro programa sirve para cualquier procesador. Si queremos firmar el paquete debemos añadir la opción –sign.
Si todo ha ido bien podéis encontrar vuestros paquetes en /rpm/RPMS y /rpm/SRPMS listos para probarlos y compartirlos.
Y hasta aquí esta segunda parte del tutorial #:-S
Fuente -> Construir RPM en la Wikipedia

Saludos :-h

Page 2 of 212