6ta Cayapa Canaima. Imagen de David Hernández (by-nc-sa). Una actividad creativa tiene muchos matices y particularidades. Podemos estar de acuerdo en que nada está realmente hecho desde cero, puesto que siempre existe un antecedente del cual hemos tomado prestado inspiración. Específicamente en el desarrollo de Software Libre, esta es una actividad recurrente e incluso alentada como buena práctica. Y es que, todo el movimiento del conocimiento libre tiene como premisa la mejora progresiva de la forma en que la sociedad satisface sus necesidades, tomando como referencia los avances que otros han hecho y publicado. El Proyecto Canaima, por su parte, cumple 9 años desde la publicación de la versión 1.0. Desde ese entonces, año tras año, incontables personas han ayudado con su trabajo de diversa índole a la mejora progresiva de los procesos técnicos y no técnicos de la distribución. Realmente son incontables. A pesar de no poseer la mano de obra de otras distribuciones, Canaima es utilizada en un número significativo de instituciones de la administración pública, sirve como sistema operativo para las más de 4 millones de canaimitas distribuídas a nivel nacional y ha entrado varias veces dentro de las 100 distribuciones más populares, según distrowatch. Como trabajador del CNTI, fuí testigo directo de la evolución de la distribución, y de como con cada Cayapa (reuniones técnicas o bug squash parties), la calidad del código, conceptos y estructura de la distribución maduraban. Borrón y cuenta nueva En la última minicayapa celebrada en la Escuela Venezolana de Planificación en la ciudad de Caracas, los actores presentes tomaron la decisión de rehacer la distribución desde cero, bajo la justificación de que lo existente era tan desastroso que no servía. Con un quórum cuestionable y una premura impresa por la institucionalidad, nacieron nuevos paquetes y nuevos procesos. Pero con ellos también volvieron los errores superados, las malas estructuras de diseño corregidas, los errores conceptuales que ya habían quedado atrás, sin mencionar los acuerdos alcanzados que fueron fácilmente rotos sin mayor explicación. No es justificable de ninguna forma este accionar. Incluso, no estaría de acuerdo si se hubiese hecho borrón y cuenta nueva para sustituirlo por algo mejor. La memoria técnica de un proyecto no debe perderse. Rescatando lo perdido Es así como he decidido continuar con la línea de investigación que el Proyecto Canaima (directa o indirectamente) echó a un lado. La nueva distribución tomará el nombre de Tribus GNU/Linux, el mismo nombre de su plataforma (Tribus). Preliminarmente estaré haciendo una imagen ISO con los mismos paquetes originales de Canaima (con los nombres cambiados), basada en Debian Sid y comenzando su versionamiento en 0.1, pero luego me dedicaré enteramente a terminar la plataforma de Tribus para poder establecer los criterios de participación comunitaria, modelos de gobernanza y automatización de procesos. Por ahora, mientras la plataforma de Tribus se completa, las plataformas asistentes serán las siguientes: Versionamiento en Github. Integración contínua en Travis. Compilación de paquetes e isos en OpenShift (Pronto). Listas de Correo en Google. Documentación en Read the Docs. Si alguno desea sumarse a esta iniciativa, es bienvenido en las listas de correo. Esta nueva distribución está dirigida al usuario común y tiene como propósito fundamental mejorar la experiencia en el área de escritorio.
Últimamente estoy muy paranóico. La última de las paranoias que adquirí es tratar de utilizar una sóla aplicación de mensajería instantánea para todos los servicios que utilizo regularmente. Facebook, Google Hangouts, WhatsApp, IRC, Y ahora Telegram, son algunas de las redes sociales con las que me comunico. Me resulta realmente molesto tener que iniciar y revisar una aplicación por cada una, y además tener que ocupar memoria RAM adicional. Es por ello que decidí centralizar las aplicaciones a través de Pidgin. Si bien Pidgin ofrece soporte nativo a una gran cantidad de redes, aún le falta compatibilidad con Whatsapp. Sin embargo, a través de plugins, otras personas han podido adaptar los protocolos de comunicación para hacerlos funcionar con Pidgin. WhatsApp, Yowsup y Pidgin WhatsApp es una aplicación de mensajería desarrollada exclusivamente para teléfonos inteligentes. Permite el envío de mensajes de texto, imágenes, video a través de sus usuarios. La identificación de cada usuario es su número de teléfono móvil. Basta con saber el número de alguien para tenerlo en la lista de contactos. El procedimiento que voy a describir acá requiere que poseas una cuenta en WhatsApp. Oficialmente la única forma de abrir una cuenta en WhatsApp es a través de la aplicación en tu teléfono inteligente; sin embargo, existen alternativas que permiten hacerlo desde tu computadora, utilizando una conexión a internet. Lo primero que debes hacer es seguir la guía para obtener tus credenciales de whatsapp, que son tu número de teléfono con código de país y la cadena de autenticación (password). Dicha guía utiliza Yowsup, una aplicación hecha en python diseñada para comunicarse directamente con los servidores de WhatsApp. Una vez obtenidas las credenciales, debemos compilar e instalar el plugin para pidgin llamado whatsapp-purple. Para ello vamos a instalar las dependencias de compilación. En una distribución derivada de debian podemos hacer así (con permisos de root): sudo apt-get install git make g++ sudo pidgin python-dateutil python-argparse libglib2.0-0 libglib2.0-dev libpurple-dev libfreeimage-dev libprotobuf-dev Luego debemos clonar el repositorio del plugin con el siguiente comando (sin permisos de root): git clone https://github.com/davidgfnet/whatsapp-purple Seguidamente, entramos en la carpeta recién clonada y compilamos el plugin (sin permisos de root): make Y luego (con permisos de root), instalamos el plugin: sudo make install El plugin está instalado, ahora debemos configurarlo. Abrimos pidgin y vamos al menú Cuentas > Gestionar cuentas; pulsamos sobre el botón “Añadir”. Allí rellenaremos los siguientes datos: Protocolo: WhatsApp. Nombre de Usuario: Número de teléfono con código de país. Contraseña: Contraseña obtenida con Yowsup. Listo, ya tenemos nuestro plugin configurado. Ahora podemos agregar contactos introduciendo sus números de teléfono en el cuadro de diálogo Buddies > Añadir un amigo .... Tus grupos existentes se sincronizarán con tu lista de contactos, más no lo harán tus contactos individuales, debes agregarlos manualmente. Puedes enviar fotos y archivos a través del menú Conversación > Enviar archivo ... de la ventana de conversación. Si deseas visualizar los emojis nativos de WhatsApp, debes instalar un tema de íconos con emojis unicode como Twitter for pidgin. Algunas personas reportan problemas para recibir mensajes, por lo que recomiendo realizar el siguiente paso adicional: Se debe cambiar la configuración para que el campo “Resource” diga como aparezca en la imagen. Debes ir a Cuentas > Gestionar Cuentas > (Seleccionar la cuenta de WhatsApp) > Modificar, y en la pestaña “Avanzadas”, poner S 40-2.12.11 en el campo “Resource”. Cierra y vuelve a abrir Pidgin.
Para algunas actividades particulares, a veces es necesario husmear un poco en la base de datos de WhatsApp para obtener los datos de acceso de nuestro usuario en la plataforma. Normalmente esto es un proceso transparente para el usuario común porque la aplicación oficial de tu teléfono inteligente se encarga de manejar la autenticación sin necesidad de que tu introduzcas un usuario o contraseña. Sin embargo, existen otras formas de conectarse a los servidores de WhatsApp sin necesidad de utilizar la aplicación oficial, y para esto necesitamos los datos de acceso de nuestro usuario. Para obtener estos datos, utilizaremos una pequeña aplicación en Python llamada Yowsup. Yowsup El protocolo de WhatsApp es una versión modificada del protocolo XMPP que es de código abierto. Aunque los autores de WhatsApp han hecho su versión de codigo cerrado, el autor de Yowsup ha sido lo suficiente hábil como para hacer ingeniería inversa al protocolo y escribir esta fantástica librería. Yowsup funciona como un cliente de la API pública de whatsapp, permitiendo que registremos nuestro número de teléfono en la base de datos de WhatsApp, y así recibir la cadena de autenticación. La librería es totalmente de código abierto y la tenemos disponible en Github. Yowsup se puede instalar en cualquier distribución GNU/Linux (Ubuntu, Linux Mint, Elementary, Canaima, etc) a través del sistema de versionamiento git. Primero, abriremos una terminal de usuario y clonaremos el repositorio con git de la siguiente forma: git clone https://github.com/tgalal/yowsup Para el siguiente comando, necesitaremos tener nuestro teléfono a mano, ya que recibiremos un mensaje de texto con el código de validación. Nos meteremos dentro de la carpeta y ejecutaremos: ./yowsup-cli registration --phone [PHONE] --cc [CC] --requestcode sms [PHONE] debe sustituirse por el número de teléfono incluyendo el código de país y [CC] es el código de país. Seguidamente recibiremos un mensaje de texto en nuestro teléfono conteniendo el código de verificación para el registro, guardamos ese número. Luego ejecutaremos el siguiente comando: ./yowsup-cli registration --phone [PHONE] --cc [CC] --register [CODE] [CODE] es el código que recibimos por mensaje de texto. Al ejecutar el comando, recibiremos un bloque de información como el que sigue: status: ok kind: free pw: [PASSWORD] price: US$0.99 price_expiration: 1443389834 currency: USD cost: 0.99 expiration: 1472221910 login: [PHONE] type: existing El campo pw contiene la cadena de nuetra contraseña encriptada. Si quieres averiguar que aplicaciones pueden autenticarse usando estas credenciales, lee el artículo que habla sobre usar WhatsApp en Pidgin.
Durante los últimos días he estado dándole vueltas al asunto de la organización para el desarrollo de aplicaciones en Software Libre. He estado reflexionando y hablando con varias personas de la comunidad y sus experiencias en el desarrollo colaborativo de aplicaciones que han tenido éxito, es decir, que han logrado los objetivos que se trazaron. Destaca una conversación con Wil Álvarez (creador de Turpial) y la forma en como él y sus colaboradores han llevado un esquema de desarrollo sano y dinámico durante los últimos años. Manejar un proyecto colaborativo no es una tarea fácil. Si arrugaste la cara cuando leíste esa última frase, piénsalo bien porque es probable que lo estés haciendo mal. Puedo resumir la información que recopilé de la siguiente manera: Los canales de comunicación deben ser prácticos, directos y claramente identificados. Lo ideal es tener una lista de correo para desarrollo y soporte dedicada a la aplicación. Si sientes que una determinada aplicación “no merece” tener una lista aparte, entonces esa aplicación puede que esté gastando una valiosísima porción de tu tiempo y merezca desaparecer. Debe existir una documentación básica antes de hacer un llamado público a colaboración. La documentación debe describir perfectamente: ¿En qué consiste la aplicación? ¿Para qué la vamos a hacer? ¿Qué lenguajes y herramientas utilizaremos inicialmente (versiones, paquetes, etc)? (pueden cambiar con el tiempo) ¿Cuál es el proceso para arrancar la aplicación? ¿Cuál es el procedimiento para armar el ambiente en donde puedo empezar a desarrollar para la aplicación? ¿Cómo se hace para comunicarse con los desarrolladores/colaboradores? ¿Cómo se hace para modificar una parte del código? ¿A dónde lo mando? ¿Quién lo recibe? ¿Cómo sé si aceptarán mi aporte? ¿Dónde lo veo? ¿Cómo es el estilo de programación (code style) de los diferentes lenguajes que se utilizarán? Si se incluye un diagrama de objetos y un diagrama conceptual es mucho mejor. Según la experiencia de muchos, la gente no le gusta participar en las fases de diseño de la aplicación, sino más adelante donde ya existen tareas concretas y granulares que se puedan seleccionar. El código y todos los procedimientos (toma de decisiones, aceptación de contribuciones, lanzamiento de versiones, etc) deben ser públicos. Utilizar sistemas de versionamiento es ideal. Debe existir (al menos) un arquitecto de software por cada aplicación. Generalmente este rol lo asumen las personas que diseñaron la aplicación y consiste en hacer la gestión de la construcción de la aplicación. Estas personas: Abren los tickets para las nuevas funcionalidades de acuerdo al diagrama conceptual. Asignan los tickets a las personas que se han ofrecido a colaborar en determinadas funcionalidades. Cierran los tickets de acuerdo a las funcionalidades completadas. Aceptan peticiones para la fusión de código (pull/merge requests) de los diferentes colaboradores, luego de haber hecho una revisión del estilo de programación y las funcionalidades agregadas o errores corregidos. Atienden los casos de desarrollo o soporte que se presenten en la lista de la aplicación. No pueden descuidar la aplicación mientras se forma la comunidad. Deben formar parte activa en los medios de comunicación. Por ahora, hasta aquí el reporte. Más adelante estaré haciendo otros aportes.
A finales del año pasado, la gente de Twitter decidió hacer publicar los fuentes en formato SVG de sus populares smileys o emojis. Con ayuda de un proyecto base de íconos unicode para pidgin y las fuentes originales de twitter, pude armar un set de íconos para utilizar en pidgin con el aspecto visual de los utilizados en twitter web. Es muy fácil de instalar. Descarga el pack de íconos, descomprímelos y coloca la carpeta twemoji dentro de la carpeta ~.purple/smileys. Reinicia tu pidgin y selecciona el tema nuevo en el menú Herramientas > Preferencias > Temas > Temas de emoticonos, tal como se muestra en la figura de abajo. Por supuesto, el pack es software libre y puede ser usado y compartido bajo la licencia Creative Commons CC-BY-SA 4.0. Su código fuente está disponible en Github y también en Gnome Look.
Luego de 6 meses de trabajo, el equipo de desarrollo de Canaima GNU/Linux se complace en publicar la primera versión alfa de Tribus (0.1~a1). Tribus es nuestra apuesta por conectar a todos los colaboradores que deseen aportar sus contribuciones en algunas de las múltiples áreas de trabajo de la Metadistribución Canaima GNU/Linux. Es también, además, un sistema que nos permitirá automatizar muchas tareas repetitivas o predecibles que forman parte del proceso productivo de las Comunidades de Software Libre. Si quieres conocer más acerca de Tribus, puedes leer un artículo anterior. Durante el desarrollo de Tribus participaron 4 desarrolladores del CNTI pertenecientes a la Oficina de Operaciones Canaima, y 2 miembros de la Comunidad Canaima, con diferentes asignaciones y actividades. Utilizamos diferentes tecnologías libres como Python/Django, AngularJS, PostgreSQL, MongoDB, Redis, OpenLDAP, HTML5/CSS3, entre otros, para poner en marcha la planificación de esta versión (0.1~a1), la cual contiene las siguientes características: Sistema de Autenticación con el directorio de usuarios de la Plataforma Colaborativa de Canaima (OpenLDAP): permite que todos los usuarios previos de la Plataforma puedan loguearse en Tribus con sus credenciales (usuario y contraseña), sin necesidad de volverse a registrar. Además, posee las mismas funcionalidades del Sistema de Registro de Canaima (reestablecer y cambiar contraseña, registro de nuevos usuarios, etc). Sistema de Mensajes Cortos (microblogging): permite publicar mensajes cortos (máximo 200 caracteres) en una cola de mensajes para cada usuario. En cada mensaje los usuarios pueden publicar comentarios cortos (máximo 200 caracteres) que luego pueden eliminar, al igual que con los mensajes cortos. Sistema de Perfiles de Usuario: cada usuario de Tribus tiene un perfil de usuario en donde se exponen algunos de sus datos personales, así como también los mensajes cortos publicados recientemente. El perfil permite “seguir” las actualizaciones de mensajes de otros usuarios, haciendo click en “Seguir a este usuario”. Sistema de Perfiles de Paquetes: muestra un perfil descriptivo (o ficha técnica) de cada uno de los paquetes que se encuentran en los repositorios de Canaima. Sistema de Búsqueda: permite buscar diversos tipos de elementos que se almacenan en Tribus, hasta ahora, usuarios y paquetes. Durante los próximos meses estaremos desarrollando la versión 0.2~a1, en donde seguiremos agregando funcionalidades que permitirán seguir mejorando el proceso productivo de la Comunidad Canaima, y por ende, de la Metadistribución Canaima GNU/Linux. Si deseas colaborar en el desarrollo de Tribus, puedes encontrar mayor información en la documentación. Sin más preámbulo, puedes acceder a Tribus en la siguiente dirección web: http://tribus.canaima.softwarelibre.gob.ve/
Hace algún tiempo, con un poco de insomnio, hice un script para ayudar al compañero Erick en la tarea de la internacionalización de Canaima. Escribo este artículo a manera de reseña y documentación de este script, el cuál posiblemente sea de utilidad para alguna otra distribución que esté comenzando sus tareas de internacionalización. La internacionalización de una distribución es diferente del concepto tradicional que aplica en el desarrollo de aplicaciones, aquí lo importante es: Permitir al usuario escoger el idioma en el cuál se va a instalar su sistema operativo, por lo que predeterminar un idioma en específico está fuera de lugar. Este procedimiento generalmente va en el instalador de la distribución. Generar el procedimiento pertinente para poder habilitar el idioma seleccionado, durante (o posterior) a la instalación del sistema operativo. La idea de este script es generar una base de datos (en forma de diccionario de python) que asocie los códigos de locales (lenguajes), con los paquetes de traducciones de una serie de aplicaciones conocidas y presentes en Canaima. Algunos se preguntarán, ¿Por qué no se utilizan los paquetes de internacionalización de Debian?, la respuesta es que están incompletos. Si bien existen los paquetes de tareas que traducen al español y otros lenguajes comunes, los cuales agrupan los paquetes de traducciones para páginas de manual, diccionarios, entre otros, existen casos en los cuales no existen paquetes de tareas para un lenguaje poco común. ¿Cómo funciona? Este script utiliza la base de datos de locales (lenguajes) soportados, el cuál se encuentra en /usr/share/i18n/SUPPORTED y es colocado allí por el paquete locales. Es utilizado para determinar la lista de los códigos de localización existentes en la forma xy-zw, como por ejemplo: es-es, en-us, en-gb, entre otros. Estos códigos son utilizados luego para ciclar a través de una serie de paquetes de localización comunes, y determinar si existen en los repositorios o no. Por ejemplo, si el paquete myspell-es-es existe, se incluye bajo el ítem 'es-es' del diccionario, y así para todos los paquetes de traducción conocidos (la lista puede ampliarse). Obtendremos algo así: { ... 'es-ve': ['manpages-es', 'myspell-es', 'aspell-es', 'cunaguaro-l10n-es-es', 'libreoffice-l10n-es', 'libreoffice-help-es'], 'et-ee': ['myspell-et', 'aspell-et', 'cunaguaro-l10n-et', 'libreoffice-l10n-et', 'libreoffice-help-et'], 'eu-es': ['hunspell-eu-es', 'aspell-eu-es', 'cunaguaro-l10n-eu', 'libreoffice-l10n-eu', 'libreoffice-help-eu'], 'eu-fr': ['cunaguaro-l10n-eu', 'libreoffice-l10n-eu', 'libreoffice-help-eu'], 'fa-ir': ['myspell-fa', 'aspell-fa', 'cunaguaro-l10n-fa', 'libreoffice-l10n-fa'], ... } Se deben aclarar varias cosas: El script debe ejecutarse como root, de la siguiente forma: bash /ruta/al/archivo.sh El script utiliza los repositorios existentes en el archivo /etc/apt/sources.list, por lo que el diccionario se calculará con la base de datos de paquetes resultante. Esto significa que si se quiere, por ejemplo, hacer una base de datos de paquetes de traducción para Debian Sid, deben introducirse sólo los repositorios de Debian Sid en el archivo /etc/apt/sources.list antes de ejecutar el script. El resultado de este script se guarda en un archivo de nombre locales.dict dentro de la misma carpeta donde se encuentre el script. Este archivo por sí mismo no hace nada, puesto que es simplemente un diccionario de python. La lógica para instalar los paquetes según el código de lenguaje utilizado, debe implementarse en una aplicación aparte. Sin más preámbulo, acá dejo el script con algunos comentarios para explicar. #!/bin/bash -e # Actualizamos la base de datos apt apt-get update SIZE=0 LIST="" # Obtenemos la lista de códigos de locales soportados por el sistema LOCALES="$( cat /usr/share/i18n/SUPPORTED | tr '[:upper:]' '[:lower:]' | sed 's/_/-/;s/[.@ ].*//' | sort -u )" # Construímos estructura de datos inicial en el arcivo 'locales.dict' echo "" > locales.dict echo "{" | tee -a locales.dict # Recorremos la lista de locales for L in ${LOCALES}; do # Determinamos el lenguaje raíz ROOTLC="${L%-*}" # Inicializamos el buffer con el primer corchete de la lista # Esta será la lista de paquetes que se imprimirá en el ítem # del diccionario BUFFER="[" # Recorremos los paquetes comunes for P in manpages hunspell myspell ispell aspell guacharo-l10n cunaguaro-l10n libreoffice-l10n libreoffice-help; do # Si existe un paquete en el repositorio que se llame "NOMBRE_PAQUETE-CÓDIGO_LENGUAJE" ... if apt-get --print-uris download "$P-$L" 1>/dev/null 2>&1; then # Lo metemos en el buffer BUFFER="${BUFFER}'$P-$L', " # Lo metemos en la lista de paquetes LIST="${LIST} $P-$L" # Obtenemos su tamaño SIZE="$( apt-cache show "$P-$L" | grep "Installed-Size: " | awk '{print $2}' )+${SIZE}" # Si no existe un paquete que coincida con el código de lenguaje, pero si existe # su lenguaje raíz ... elif apt-get --print-uris download "$P-$ROOTLC" 1>/dev/null 2>&1; then # Lo metemos en el buffer BUFFER="${BUFFER}'$P-$ROOTLC', " # Lo metemos en la lista de paquetes LIST="${LIST} $P-$ROOTLC" # Obtenemos su tamaño SIZE="$( apt-cache show "$P-$ROOTLC" | grep "Installed-Size: " | awk '{print $2}' )+${SIZE}" fi done # Imprimimos el ítem de diccionario, más el contenido del buffer # el cuál contiene la lista de paquetes de traducción y luego lo # introducimos en el archivo locales.dict echo "'$L': ${BUFFER}]," | tee -a locales.dict done # Cerramos el diccionario echo "}" | tee -a locales.dict # Esta es la lista de paquetes completa echo "La lista de paquetes a incluir en el pool de la ISO:" echo "${LIST}" | sort -u # Este es el tamaño total de todos los paquetes echo "EL tamaño sin comprimir de todos los paquetes:" echo "${SIZE}" | bc
El título de este artículo puede parecer pomposo, pero no tiene ni una pizca de amarillismo o exageración. Una jaula, desde el punto de vista de desarrollo, es un sistema embebido dentro de otro que permite establecer una comunicación entre los procesos del sistema anfitrión y el huésped, es decir, permite hacerlos interoperables. En debian, tener una jaula (o varias jaulas) permite tener otro sistema operativo encerrado en una carpeta, listo para usar, sin la necesidad de utilizar máquinas virtuales. Incluso, es posible tener un sistema huésped de arquitectura diferente al anfitrión. En teoría, cualquier sistema operativo que cumpla con los estándares POSIX y LSB (la mayoría de los GNU/Linux), y que además compartan el mismo tipo de kernel que el sistema anfitrión, puede convertirse en un sistema huésped; por ejemplo, ArchLinux y Debian, Gentoo y Debian, Canaima y Debian, CentOS y Debian, Fedora y Debian, entre otros. La única desventaja es que está pensado para propósitos de desarrollo, es decir, para uso por consola (aunque existen guías para arrancar la interfaz gráfica con Xnest). Los casos de uso para las jaulas son infinitos. Por su capacidad para aislarse del sistema anfitrión, es usado en casos de compilación y empaquetamiento, en donde se hace necesario instalar dependencias que pueden dañar o desconfigurar el sistema anfitrión (que a menudo es nuestro sistema de uso personal y cotidiano), pero al hacerse dentro de la jaula, todo posible daño queda confinado en el sistema huésped. ¿Cómo se hace una jaula? Existen varias herramientas para generar y gestionar jaulas, dependiendo del sistema operativo que utilices y el tiempo que dispongas. Las cosas pueden ser tan fáciles como un comando sencillo, o varios comandos al estilo Linux from Scratch. Para este caso utilizaremos Debian Sid como sistema Anfitrión y Canaima Kerepakupai (4.0) como huésped, y para asistirnos en la creación y operación de la jaula, usaremos debootstrap y coreutils. Los instalamos así, usando una consola de root del sistema anfitrión: aptitude install debootstrap coreutils Chroot es una aplicación que engaña al sistema anfitrión, haciéndolo creer que es el sistema huésped para la sesión de consola que se está ejecutando. Por otro lado, deboostrap es un script que automatiza la creación de la jaula, instalando todos los paquetes esenciales que necesita un sistema operativo básico para funcionar. El único detalle con debootstrap es que sólo contiene scripts para un número limitado de versiones de Debian y de Ubuntu. Nosotros resolveremos este problema haciendo un enlace simbólico desde Debian Wheezy a Canaima Kerepakupai en una consola de root, así: ln -s /usr/share/debootstrap/wheezy /usr/share/debootstrap/kerepakupai Luego ejecutamos debootstrap para crear la jaula dentro de una carpeta que escojamos, diciéndole que no revise las las llaves de las firmas del repositorio (--no-check-gpg) y que la arquitectura de la jaula será i386 (--arch="i386"): mkdir /media/jaulas/kerepakupai-i386 debootstrap --arch="i386" --no-check-gpg kerepakupai /media/jaulas/kerepakupai-i386 http://paquetes.canaima.softwarelibre.gob.ve/ Terminado este paso, la jaula está lista, pero todavía debemos hacer otras operaciones antes de empezarla a utilizar. El sistema huésped utilizará el espacio de kernel del sistema anfitrión para obtener las funcionalidades básicas del sistema operativo, sin embargo, para gestionar los dispositivos del sistema (entre otras cosas), necesita tener disponibles algunas otras cosas dentro de la jaula. Para ello hacemos: mount -o bind /proc /media/jaulas/kerepakupai-i386/proc mount -o bind /sys /media/jaulas/kerepakupai-i386/sys mount -o bind /dev /media/jaulas/kerepakupai-i386/dev mount -o bind /dev/pts /media/jaulas/kerepakupai-i386/dev/pts Estos montajes son del tipo “bind” (enlaces), permitiendo que el comportamiento de /dev, /dev/pts, /proc y /sys del sistema anfitrión se replique en el sistema huésped. Además son montajes temporales: si reinicias la computadora, los montajes se perderán y tendrás que volverlos a hacer. Si quieres montajes permanentes deberás editar el archivo /etc/fstab. Ahora estamos listos para ingresar en la jaula con el comando: chroot /media/jaulas/kerepakupai-i386 Al estar dentro, el sistema anfitrión ya no existe, estamos dentro de la jaula y podemos hacer desastres.
El sistema de paquetes de Debian es uno de los gestores de instalación y desinstalación de software más avanzados en el mundo de las distribuciones GNU/Linux. No podría ser de otra manera, ya que Debian también es una de las distribuciones que más paquetes posee en sus repositorios (mas de 32.000 para la versión 7.0). Si tienes Debian, Canaima o Ubuntu, ¿Alguna vez haz tenido la oportunidad de listar todos los paquetes que tienes instalados? Normalmente daría dolor de cabeza tratar de buscar un paquete en una lista de entre 1000 y 2000 nombres (la cantidad promedio de paquetes instalados en un sistema operativo de escritorio). Es por ello que existen diversos filtros de búsqueda para manejadores de la base de datos de paquetes como aptitude (aunque, estos filtros son implementados de forma nativa por aplicaciones gráficas como Synaptic y Software Center). Normalmente buscamos en la base de datos con aptitude search [paquete], sin embargo, existen formas de ser más específicos con los términos de búsqueda. Por ejemplo, supongamos que queremos buscar todos los paquetes que comiencen con la palabra google. En ese caso, haríamos aptitude search google y tendríamos un resultado así: Como observamos, existen algunos resultados que no necesariamente coinciden con lo que queríamos buscar, puesto que también existen paquetes que contienen la palabra google en el medio de la palabra, por ejemplo. Veamos que sucede su utilizamos el patrón de búsqueda por nombre de paquete ~n y agregamos la expresión regular ^ al principio de google, indicando que queremos listar todos los paquetes que comiencen por google, de la siguiente forma: aptitude search ~n^google. Como vemos, el resultado es más corto y preciso que el anterior. Existen muchos patrones de búsqueda que son útiles en nuestra búsqueda de paquetes; por ejemplo, búsqueda por descripción, por versión, por mantenedor, por repositorio, entre otros. Más abajo tenemos una tabla con todos los patrones disponibles: Forma corta Descripción ~F Selecciona ningún paquete. ~T Selecciona todos los paquetes. [PATRÓN1] [PATRÓN2] Seleccionar cualquier paquete que coincida con el [PATRÓN1] y el [PATRÓN2]. [PATRÓN1] | [PATRÓN2] Selecciona paquetes que coincidan con el [PATRÓN1], el [PATRÓN2] o ambos. ![PATRÓN] Seleccionar cualquier paquete que no coincida con el [PATRÓN]. ~n[PATRÓN] Selecciona paquetes cuyo nombre coincida con [PATRÓN]. ~m[PATRÓN] Selecciona paquetes cuyo mantenedor coincida con [PATRÓN]. ~d[PATRÓN] Selecciona paquetes que contengan [PATRÓN] en su descripción. ~V[PATRÓN] Selecciona paquetes cuya versión coincida con [PATRÓN]. ~E Selecciona paquetes esenciales (aquellos que contienen Essential: yes en sus archivos debian/control). ~O[PATRÓN] Selecciona paquetes desde el origen que coincida con [PATRÓN]. ~P[PATRÓN] Selecciona paquetes que proveean otro paquete que coincida con [PATRÓN]. ~p[PATRÓN] Selecciona paquetes que tengan una prioridad que coincida con [PATRÓN]. ~s[PATRÓN] Selecciona paquetes que pertenezcan a una sección que coincida con [PATRÓN]. ~G[PATRÓN] Selecciona paquetes que contengan un DebTag que coincida con [PATRÓN]. ~t[PATRÓN] Selecciona paquetes que estén en una tarea que coincida con [PATRÓN]. ~M Seleccionar paquetes que estén marcados como instalados automáticamente. ~a[PATRÓN] Seleccionar los paquetes que se encuentren marcados para una acción de aptitude (p. ej.: “install”, “upgrade”) que coincida con [PATRÓN]. ~A[PATRÓN] Seleccionar paquetes desde un rama de un repositorio en específico que se encuentre en el archivo /etc/apt/sources.list (p. ej.: sid) y que coincida con [PATRÓN]. ~b Seleccionar paquetes que tengan al menos una dependencia rota. ~C[PATRÓN] Seleccionar paquetes que entran en conflicto con los paquetes que coincidan con [PATRÓN]. ~c Seleccionar los paquetes que fueron removidos pero no purgados y aún tienen archivos de configuración en el sistema. ~g Selecciona paquetes que no son requeridos por algún paquete instalado manualmente.. ~D[TIPO]:[PATRÓN] Seleccionar paquetes que contengan un [TIPO] de dependencia sobre paquetes que coincidan con [PATRÓN]. ~i Selecciona paquetes que se encuentren instalados. ~N Selecciona paquetes nuevos que hayan sido incorporados al repositorio desde la última vez que se hizo aptitude update. ~o Selecciona paquetes obsoletos, es decir, que después del último aptitude update hayan sido removidos del repositorio (probablemente reemplazados por otros paquetes). ~U Selecciona paquetes instalados que puedan ser actualizados luego de un aptitude update. ~v Selecciona paquetes virtuales. Ejemplos prácticos Todos mis paquetes (en Canaima): aptitude search ~mFaneyth Todos los paquetes de Erick Birbe, Sasha Solano, Carlos Espinoza y Francisco Vásquez que estén instalados (en Canaima): aptitude search ~i~merickcion ~i~mssolano ~i~marmikhael ~i~mfranjvasquezg Todos los paquetes que dependen de Blender: aptitude search ~DDepends:Blender Todos los paquetes que provean al paquete virtual “mail” y que estén instalados aptitude search ~i~DProvides:mail o lo que es lo mismo: aptitude search ~i~Pmail Todos los paquetes que estorban de tu sistema: aptitude search ~c ~g Todos los paquetes que tengan “RC” (Release Candidate) en su número de versión y que estén instalados aptitude search ~i~VRC ¿Cuántos paquetes tengo instalados? aptitude search ~i | wc -l Todos los paquetes de desarrollo para python que estén instalados: aptitude search ~i~n^python.*dev$ Y así, espero que puedas encontrar lo que estás buscando. ¡Hasta una próxima!