Archivo de la etiqueta: module

Reactivar módulo wireless en Acer Aspire para Ubuntu y derivados

Si usas las últimas versiones de Ubuntu 13.10 o siguientes, en concreto aquellas distribuciones que usen algún núcleo entre la versión 3.8 y 3.11 habrás notado que si dispones de un portátil Acer Aspire te hayas quedado sin soporte wireless e incluso algunas otras funciones inhabilitadas como ventilador de la CPU u otros. En concreto la lista de elementos hardware que pueden dejar de funcionar son:

  • La tarjeta de red (interfaz wireless)
  • El adaptador de bluetooth integrado
  • Tarjeta de red 3G (sólo los modelos que disponga de una integrada)
  • Indicadores LED frontales (CPU, email, multimedia, etc)
  • Botones de iluminación LCD

wireless Ubuntu

En el caso de la conectividad wireless lo primero que se suele pensar es que el interruptor esta mal pulsado o no llega a activar la wifi (normalmente suele estar en el canto de la parte inferior izquierda). En mi caso y creo que en otros no será ese el problema. Por si acaso, puedes comprobarlo con el siguiente comando:

$ rfkill list all

Si no esta bloqueado por hardware o software, debería aparecer un resultado como:

1: phy1: Wireless LAN
 Soft blocked: no
 Hard blocked: no

Tras investigar un poco en los registros del sistema, parece que no existe una buena compatibilidad para mi modelo de Acer Aspire a través del módulo del kernel que se utiliza para controlar el hardware. Se trata del módulo acer_wmi que es un reemplazo incompleto y no muy estable del módulo acer_acpi que se utilizaba en versiones más antiguas del kernel. pero a partir de la versión 2.6.25 fueron fusionados. Este módulo suele autocargarse en el kernel basándose en la concordancia por detección DMI (Destktop Management Information)

Solución temporal al problema

Para resolver el problema, lo primero es conocer tu modelo exacto de portátil. Si no te apetece mirar etiquetas, cajas, facturas o albaranes de compra, puedes sacar el modelo exacto con el siguiente comando:

sudo dmidecode -t 2 | grep Product

En mi caso se trata del siguiente modelo:

Product Name: Aspire 5943G

Tras comprobar la compatibilidad, si prefieres no usar dicho módulo, basta con ejecutar:

sudo modprobe -r acer-wmi; echo 'blacklist acer-wmi' | sudo tee -a /etc/modprobe.d/blacklist.conf

Reinicia y posteriormente no debería aparecer ningún módulo en la salida del comando:

lsmod | grep acer

Distutils2 el posible futuro del empaquetado de aplicaciones en Python

Distutils (Python Distribution Utilities) es un módulo estándar de la biblioteca de python con el propósito de distribuir aplicaciones Python de forma sencilla. Es el módulo estándar para empaquetado de aplicaciones en Python.

Si has utilizado distutils en pequeños proyectos puede que haya sido suficiente para tus necesidades. Sin embargo, a medida que es necesario personalizar con más detalles la instalación o realizar funciones avanzadas, distutils resulta ser un módulo carente de algunas funcionalidades y con muchos pequeños detalles por mejorar. Es simple, pero limitado y no extensible de forma trivial.

En mi opinión, hay dos principales problemas en la forma en la que se distribuye aplicaciones y módulos python:

  • 1) Existen muchas formas de realizar la instalación de una distribución de paquetes Python y crea un estado de interoperabilidad difícil.
  • 2) No existe una API para conseguir información de las distribuciones de paquetes instaladas.

Alternativas

Están disponibles otras alternativas como Setuptools. Este proyecto nació para rellenar pequeñas funcionalidades olvidadas en distutils y explorar nuevas direcciones. Para algunas subcomunidades Setuptools es un estándar de facto. Pero actualmente su desarrollo no esta siendo mantenido (por inactividad en 2 años) y su uso esta en decadencia desde que no tiene soporte para python 3.x.

Posteriormente surgió Distribute. Es un fork como reemplazo de Setuptools iniciado por los mismos desarrolladores que sentían que el proyecto no avanzaba lo suficiente y pensaban que no era posible una evolución.

De este último grupo ha surgido una nueva biblioteca, llamada Distutils2. Iniciada desde la base de distutils y tomando las buenas ideas de Setuptools (discutidas fuertemente en PEPs como PEP 376, PEP 386), además de inspirarse en un instalador básico similar a pip.

Integración Distutils2

Distutils2 tenia como principal objetivo la integración como módulo nativo en la rama de Python 3.3 bajo el módulo packaging. Debido a problemas en su desarrollo esta semi-paralizado hasta Python 3.4 a la espera de acuerdos entre desarrolladores y fijación de objetivos aunque este cuenta con una buena cobertura de test y estabilidad.

Novedades

Compatibilidad con otros sistemas

Distutils2 Estado actual del empaquetado de aplicaciones Python
Estado actual del empaquetado de aplicaciones Python

Los módulos de Distutils2 están capacitados para funcionar con PyPI y los metadatos asociados en proyectos instalados. El objetivo a largo plazo es la coexistencia de proyectos escritos para Pip o Distribute puesto que usan los mismos estándares. Por ejemplo, esta iniciándose una remodelización de pip, llamada pip2 que debería comtemplar la coexistencia con distutils2.

Nuevos comandos de instalación

Distutils2 habilita nuevos comandos de instalación como:

  • test : un comando para ejecutar las pruebas del proyecto (idea inspirada en Setuptools).
  • upload_docs: un comando para subir la documentación a packages.python.org
  • check: previamente añadido, pero ha sido mejorado para que se realicen comprobaciones antes de liberar o subir un paquete. Comprueba los metadatos, cumplimiento de reglas reST en la descripción.
  • uninstall: es una función muy básica añadida en el módulo distutils2.util que permite desinstalar de forma sencilla la aplicación. Esta ha sido una petición muy demandada para python 3.3. Además se incluye una API para eliminar todos los archivos que no cambiaron o directorios vacíos. Por ejemplo, para listar una lista de todos los archivos posibles para desinstalar:
from distutils2.util import uninstall
uninstall('setuptools')

Grafico de dependencias

El módulo constructor de grafos de dependencias de paquetes analiza las dependencias entre varias distribuciones de paquetes y permite a través de una API de código crear un grafo representando las relaciones entre ellos. Se sirve de graphviz para realizar los gráficos desde lenguage DOT. Por ejemplo, este sería el aspecto más básico y sin personalizar de un paquete de dependencias con el nombre “bacon”.

Gráfico de dependencias generado
Gráfico de dependencias generado

Archivo de configuración

Distutils2 toma como primera opción el archivo distutils2.cfg además del setup.cfg para permitir la compatibilidad con antiguos archivos de configuración. Es posible por tanto configurar la instalación sin necesidad de setup.py y sólo usar setup.cfg. Por defecto, los archivos como README o README.txt además del setup.py no serán más incluidos en la opción de distribución de fuentes.

Generación del archivo de configuración

Editar los archivos de configuración desde cero puede resultar muy tedioso, por ello se ha ideado un script interactivo (mkcfg) que permite generar el archivo setup.cfg preguntando los datos esenciales.

Para ejecutarlo:

$ python -m distutils2.mkcfg

Hooks

Distutils2 permite ser extensible a través de comandos que se ejecutan antes y después de una opción (hooks). Los hooks son simples funciones python (u objetos invocables) que están especificados en el archivo de configuración usando los nombres completos.

Los hooks se ejecutan después de que las opciones sean leídas y antes y después del comando a ejecutar.  Un ejemplo de hook necesitaría inicialmente que el hook estuviera presente en la ruta de ejecución, es decir, en el directorio del setup.py. Se crea un archivo en python para el hook, por ejemplo myhoook.py para el comando de instalación:

def my_install_support_hook(install_cmd):
    print "Genial, acabas de instalar mi proyecto! Ahora visita mi web blablable.com para soporte."

Posteriormente se edita el archivo setup.cfg bajo la sección de comandos apropiadas para la instalación:

[install]
pre-hook.myproject = myhooks.my_install_support_hook

Nuevas keywords

En la función setup donde recibe todas las palabras claves como autor, email, version, etc se han añadido nuevas que faciliten un mayor control.

Sistema de logging mejorado

La primera versión de disutils incluye un modulo de depuración para mensajes de error e información que no utilizaba el módulo logging estándar de Python, es decir siguiendo el estilo del PEP 282. La nueva versión de distutils2 usa de forma nativa el módulo logging.

Instalación

Si te ha parecido interesante el módulo de Distutils2, probablemente estés muy interesado en probarlo e instalarlo.

Para instalarlo puedes seguir la guía de instalación o el tutorial que se ofrece desde la documentación

Para python 2.7 puedes probar a instalarlo desde pip:

$ sudo pip install distutils2

Para Python 3, necesitas instalar (en Ubuntu) pip con compatibilidad para python3 con el paquete python3-pip:

$ sudo apt-get install python3-pip

Y después instalarlo vía:

$ sudo pip install http://hg.python.org/distutils2/archive/python3.tar.bz2

Si estas interesado en ver el código, puedes clonar el repositorio Mercurial con:

$ hg clone http://hg.python.org/distutils2

Como contribuir

Los autores de Distutils2 animan a contribuir y realizar sprints para finalizar características pendientes y corregir fallos.

Fuentes

Solucionar: RuntimeWarning: Python C API version mismatch for module en CentOS 5.5 con cPanel

Si utilizas CenOS y por ejemplo has decidido hacer una actualización de tu versión de Python ya que puede que estuvieras usando la versión 2.4 o 2.6 y quieres actualizar a 2.6 o 2.7 respectivamente, puede ser que te encuentres el error siguiente al ejecutar yum:

# yum
/usr/lib/python2.6/site-packages/rpm/__init__.py:7: RuntimeWarning: Python C API version mismatch for module _rpm: This Python has API version 1013, module _rpm has version 1012.
  from _rpm import *
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:
   No module named sqlitecachec
Please install a package which provides this module, or
verify that the module is installed correctly.
It's possible that the above module doesn't match the
current version of Python, which is:
2.6.5 (r265:79063, Jun  4 2010, 21:43:07)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-48)]
If you cannot solve this problem yourself, please go to
the yum faq at:
  http://wiki.linux.duke.edu/YumFaq

Este error se debe, a que yum, esta buscando sus bibliotecas para ejecutarse y no las encuentra. Posiblemente por que tu versión de yum esta instalada en otra versión de python anterior y la nueva no tiene dicha versión.

Existen varias formas de solucionar esto, pero en CentOS no esta documentada y a fecha de hoy en google no puedes encontrar ninguna solución. Es más acudiendo al IRC de centos pidiendo ayuda, su respuesta liberal en ingles fue “Date una bofetada o directamente disparate en la cabeza por lo que has hecho“.

Esta respuesta me indigno mucho, sobre todo porque me pareció pésimo el soporte, que sin darme solución, encima me respondía de esa forma, aparte el problema realmente reside en que ellos no son capaces de solucionártelo y puesto que no actualizan la versión de python en años “para que sea estable“, los usuarios y sysadmin deben ingeniárselas solucionando los problemas.

Luego después de experimentar mis soluciones fueron las siguientes:

Reinstalar yum a traves de rpm: esto probablemente funcionaría, pero no, ya que se instalaría incorrectamente con la nueva versión de python y no conseguí hacer nada, quizás hice mal algún paso.

– Reinstalar el paquete yum-metadata-parser que contiene las dependencias de yum. Igualmente al reinstalarlo no tuvo efecto ya que estaría cogiendo una mezcla de paths.

– Modificar la variable de entorno PYTHONPATH. De igual forma no funciono ni poniendo versiones más antiguas.

La solución final, que aunque fue cutre, conseguí hacerlo funcionar, fue la siguiente:

Buscar el binario de yum:

# which yum

En mi caso la salida fue:

# which yum
/usr/bin/yum

Luego tras comprobar que el tipo del archivo era un script en python:

# file /usr/bin/yum
/usr/bin/yum: python script text executable

Me fije en el archivo para editarlo:

# cat /usr/bin/yum
#!/usr/bin/python
import sys
try:
 import yum
except ImportError:
 print >> sys.stderr, """\
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:

 %s

Please install a package which provides this module, or
verify that the module is installed correctly.

It's possible that the above module doesn't match the
current version of Python, which is:
%s

If you cannot solve this problem yourself, please go to 
the yum faq at:
 http://wiki.linux.duke.edu/YumFaq
 
""" % (sys.exc_value, sys.version)
 sys.exit(1)

sys.path.insert(0, '/usr/share/yum-cli')
try:
 import yummain
 yummain.user_main(sys.argv[1:], exit_code=True)
except KeyboardInterrupt, e:
 print >> sys.stderr, "\n\nExiting on user cancel."
 sys.exit(1)

Si os fijáis, nuestro error se da en este preciso archivo, ya que falla una excepción con el ImportError. Y en la primera línea tenemos un:

#!/usr/bin/python

Basta con cambiar esa línea para decirle al script que ejecute una versión antigua de python (la que funcionaba) de nuestro sistema. Es decir, cambiar (en mi caso a python 2.4):

#!/usr/bin/python2.4

Y listo, yum funcionará sin problemas. Obviamente, con un mejor análisis de la situación, se podría hacer que yum cogiera realmente la última versión de python y sus bibliotecas (probablemente por el path), pero eso requiere de mayor trabajo y tiempo y para mí esta solución fue valida. Sin embargo, si alguien esta dispuesto a comentar una mejor solución, estaré agradecido.