El Demonio Negro

Estos son los errores que obtenía al intentar ejecutar la versión 2.1 para GNU/linux.

Traceback (most recent call last):
  File "/usr/share/ipodder/iPodderGui.py", line 44, in ?
    import GUI.iPodderWindows
  File "/usr/share/ipodder/gui/iPodderWindows.py", line 21, in ?
    import listctrl  as  listmix
  File "/usr/share/ipodder/gui/listctrl.py", line 296, in ?
    EVT_DOPOPUPMENU = wx.PyEventBinder(wxEVT_DOPOPUPMENU, 0)
AttributeError: 'module' object has no attribute 'PyEventBinder'

Que se han solventado tras editar el archivo /usr/share/ipodder/iPodderGui.py e incluir las dos primeras líneas en negrita.

import wxversion
wxversion.select(’2.6-gtk2-unicode’)
import wx

Página dónde encontrar todo sobre ipodder

Pues durante mi divagación por algunos de los top 20 del blog de Ian Murdock, fundador del proyecto debian., dentro de la entrada sobre Ubuntu vs. Debian, reprise encontré algo bastante interesante.

Es un Artículo en inglés del año 2001/2002 con una estimación del coste de desarrollo de GNU/linux.

Aunque es algo antigua, y estará basada en datos aún más antiguos (si leo algo hoy, publicado ayer, la fase de documentación habrá sido anterior a ayer, ¿no?), me parece que viene bien para saber datos, como cuál es por ejemplo el número de desarrolladores que se puede estimar tiene GNU/linux, o comparativas del número de líneas de código de Sistemas Operativos como Windows, Solaris…
La estimación del coste del “proyecto” de una distribución Red Hat 7.1 es de 1 BILLÓN de dólares americanos, del año 2000, cuando el euro estaba por debajo del dólar. Para ello se basa en el método COCOMO para cálculo de costes (no se nada de él), y los calculos los realiza a partir de 8000 desarrolladores al año y sus 30 millones de líneas de cógido.

Saturday, August 16th, 2003

Ten years ago, I posted a message announcing a new LINUX project:

From: Ian A Murdock (imurdock@shell.portal.com)
Date: August 16, 1993 6:09:59 PST
Newsgroups: comp.os.linux.development
Subject: New release under development; suggestions requested
Fellow Linuxers,

This is just to announce the imminent completion of a brand-new LINUX release, which I’m calling the Debian LINUX Release. This is a release that I have put together basically from scratch; in other words, I didn’t simply make some changes to SLS and call it a new release. I was inspired to put together this release after running SLS and generally being dissatisfied with much of it, and after much altering of SLS I decided that it would be easier to start from scratch. The base system is now virtually complete (though I’m still looking around to make sure that I grabbed the most recent sources for everything), and I’d like to get some feedback before I add the “fancy” stuff.

Esto es lo que encontré en esas divagaciones por la web, tras ver la cantidad de distribuciones de GNU/linux que existen hoy en día, dí con la distribución en la que trabaja el fundador de debian hoy en día.
blog de Ian Murdock, fundador del proyecto debian.

Si utilizas la versión, actualmente inestable, de apt-get, puede que errores de este tipo se hallan convertido en habituales:

W: GPG error: Release: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY XXXXXXXXXXX

Se deben a la verificación de firmas de los repositorios.

A mí concretamente me aparecían estos:

W: GPG error: ftp://ftp.nerim.net stable Release: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY 07DC563D1F41B907
W: GPG error: ftp://ftp.nerim.net unstable Release: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY 07DC563D1F41B907
W: GPG error: ftp://ftp.nerim.net testing Release: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY 07DC563D1F41B907
W: GPG error: http://non-us.debian.org/debian-non-US Release: The following signatures couldn’t be verified because the public key is not available:
NO_PUBKEY B629A24C38C6029A
W: GPG error: http://debian.cihar.com/ unstable Release: The following signatures couldn’t be verified because the public key is not available:
NO_PUBKEY E64A2AA53714DD6A

Después de buscar por google, encontré una solución:

Escribir esto como root:

root@maquina:~$ gpg –keyserver wwwkeys.eu.pgp.net –recv-keys DD41397117E73B4E
gpg: directory `/root/.gnupg’ created
gpg: can’t open `/gnupg/options.skel’: No existe el fichero o el directorio
gpg: keyring `/root/.gnupg/secring.gpg’ created
gpg: keyring `/root/.gnupg/pubring.gpg’ created
gpg: requesting key 17E73B4E from hkp server wwwkeys.eu.pgp.net
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key 17E73B4E: public key “Gianluigi Tiesi < sherpya @ netfarm.it >” imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1
root@maquina:~$ gpg –armor –export 17E73B4E | apt-key add -

donde DD41397117E73B4E es la combinación de letras y números de la firma que dice no encontrar.

De esta forma se añaden las firmas que dan los errores.
El servidor de llaves puede cambiarse, pero a mí me funciona bastante bien, suele encontrar muchas de las claves públicas que necesito.

Actualización:
Para importar clases desde ficheros, se usan los siguientes comandos:

root@maquina:~$ wget http://download.tuxfamily.org/shames/A42A6CF5.gpg
–16:08:51– http://download.tuxfamily.org/shames/A42A6CF5.gpg
=> `A42A6CF5.gpg’
Resolviendo download.tuxfamily.org… 88.191.250.18
Connecting to download.tuxfamily.org|88.191.250.18|:80… conectado.
Petición HTTP enviada, esperando respuesta… 200 OK
Longitud: 1,690 (1.7K) [application/octet-stream]
100%[======================================================================>] 1,690 –.–K/s
16:08:52 (21.49 KB/s) - `A42A6CF5.gpg’ saved [1690/1690]
root@maquina:~$ apt-key add A42A6CF5.gpg
OK

Aquí dejo la configuración de mi archivo pppoe.conf para el programa de la empresa Roaring Penguin RP-PPPoE.

Hasta ahora me ha funcionado perfectamente, tanto para la anterior conexión con Arrakis como ahora con Iberdrola.

Día oscuro el de ayer con GNOME.
Más de 14 horas para intentar averiguar que le sucedía al gestor de sesiones del portatil.
El principal problema es que tras introducir el login y la password se quedaba la sesión colgada tranquila y placidamente. Únicamente lograba aparecer la “splash screen”, pero ningún icono de los que indican el progreso de inicio de sesión llegaba a aparecer.
Tras un par de vueltas empiezan los diagnósticos.
Los ficheros que parecían solventar algunos problemas son los de configuración de GNOME, los que estuve tocando fueron:

$HOME/.gconfd/saved_session

Causaba problemas de cuelgues.

$HOME/.gnome2/.gnome-proxy-XXX

Causaba problemas de cuelgues con el GNOME-smproxy.

$HOME/.gnome2/session

Este fichero, o si no existe por defecto se usa /usr/share/gnome/default.session, es el que tiene los pasos y los programas que se lanzan al comenzar la session de GNOME.

$HOME/.xsession-errors

Fichero donde se vuelcan todos los errores que ocurren durante una sesión gráfica, este forma parte de las X-Window (el gestor de ventanas).

Alternativos inicios de sesión entre KDE(que funcionaba perfectamente) y GNOME para comprobar si se arreglaba algo con los modificaciones de los ficheros y reinstalación de paquetes sin ningún éxito. Lo mejor de todo era que para otro usuario que tengo para pruebas esto no pasaba, jeje, hasta que sí le paso. Concretamente cuando fuí a configurar el sonido de la sesión en el GNOME-sound-properties, se quedó el gestor de ventanas colgado. Con mi usuario también había conseguido arrancar alguna vez, pero el administrador de propiedades de sesió de GNOME (GNOME-session-properties)no arrancaba, y acto seguido se colgaban las ventanas.
Así poco a poco, sumiendo en la más profunda desesperación que produce la informática cuando falla algo y no sabes por qué, cuando ni siquiera crees haber hecho algo para que algo falle, llegué a la que ahora mismo parece la solución. Desde una sesión de KDE cacharreando con synaptic(administrador de paquetes .deb gráfico de uso diario) vi que existía la posibilidad de que el problema fuera de las x.org, que recomiendan el paquete discover1 (el cual no se debido a qué recientemente había yo cambiado) y no el discover. Procedí a su intercambio, además de aprovechar e instalar una serie de paquetes que no tenía de las x.org como eran el xdm o el x-window-manager, que instaban algo con proxy manager y parecía la solución a mis problemas.
Histórico de cambios de synaptic:

Quitó los paquetes siguientes:
discover
discover-data
libdiscover2

Instaló los paquetes siguientes:
discover1 (1.7.12)
discover1-data (1.2005.07.31)
lbxproxy (6.8.2.dfsg.1-5)
libdiscover1 (1.7.12)
proxymngr (6.8.2.dfsg.1-5)
twm (6.8.2.dfsg.1-5)
x-window-system (6.8.2.dfsg.1-5)
xdm (6.8.2.dfsg.1-5)
xfs (6.8.2.dfsg.1-5)
xfwp (6.8.2.dfsg.1-5)
xlibosmesa4 (6.8.2.dfsg.1-5)
xprint (1:0.1.0.alpha1-11)
xprint-common (1:0.1.0.alpha1-11)
xvfb (6.8.2.dfsg.1-5)

Tras reiniciar el sistema parece que todo ha vuelto a la normalidad.

19 de Agosto.
:help_tb:Problemas de nuevo esta mañana, esta vez parecen solucionarse tras borrar el paquete gconf antiguo junto con su librería libgcong11 y alguna otra dependecia.

21 de Agosto
Ayer por la noche se acabó lo que se daba, :furious_tb: he cambiado a KDE que funciona sin problemas, a la espera de que quizás una nueva actualización de GNOME resuelva el desastre.
Esto es un cachondeo, por la tarde, tarde, he reinstalado el gconf2 y de momento funciona.

11 de Septiembre
Hace semanas ya que todo funciona bien, en alguna actualización se ha solucionado todo. :clap_tb:

Si se quiere tener un Debian actualizándose a traves de apt por Internet.Si hay más máquinas en la misma red, para evitar tener que bajar los paquetes de nuevo para las otras máquinas, se crea un mirror instantaneo:

$ cd  /var/cache/apt/archives
$ dpkg-scanpackages  .  .  > Packages
$ gzip Packages

Despues de esto, ir al directorio www (/var/www) y hacer un link simbolico. ejemplo

$ ln -s /var/cache/apt/archives debian

con eso ya estaría listo..
y para los clientes , agregas una línea en el archivo /etc/apt/sources.list

deb http://[nombre máquina]/debian ./

ejemplo:

deb http://192.168.1.2/debian ./

He tenido problemas mientras intentaba ejecutar un script escrito en perl en el servidor con apache2. El script estaba fuera del directorio común para los archivos CGI.
El problema era que el navegador me mostraba el contenido del script, me decia que quería hacer con “archivo.pl”.
Después de buscar en los buscadores he encontrado la solución a mi problema:

Si tu navegador te muestra el CGI probablemente lo que necesitas es revisar en tu httpd.conf.
Con descomentar la línea del manejador es suficiente.
Así es como ha quedado :

# If you want to use server side includes, or CGI outside
# ScriptAliased directories, uncomment the following lines.
#
# To use CGI scripts:
#
AddHandler CGI-script .cgi .pl