MarioDebian, mi devlog

Bitácora de un desarrollador newbie.

Drivers de TDT (DVB) AverTV TwinStar 07ca:0825 en formato DKMS

Como veo que los artículos en los que he publicado los parches para el driver de este dispositivo TDT están teniendo seguimiento en este blog y harto de compilar a mano un montón de cosas en cada actualización del kernel ayer dediqué un ratillo a preparar un paquete más automático usando DKMS.

DKMS es un sistema que compila módulos del kernel en varios eventos (actualización del kernel, nuevo kernel, actualización de drivers, etc...) sin intervención del usuario.

Muchos paquetes de Debian y Ubuntu lo usan (drivers de NVIDIA/ATI, VirtualBox, etc...) ¿Porqué no tenerlo para el driver AF9035?

He dado de alta un PPA en Launchpad,  que contiene el paquete fuente y el .deb generado listo para instalar en cualquier distribución.

El paquete sólo depende de dkms por lo que debería funcionar en i386/amd64 y desde versiones cuyo kernel sea 2.6.26 o superior (en el 3.0.0 de Debian Unstable funciona sin problemas)

El paquete compila 6 módulos: af9033, dvb-core, dvb-usb-af9035, dvb-usb, mxl5007t, tua9001 que se instalan en /lib/modules/`uname -r`/updates/dkms por lo que tienen preferencia sobre los módulos instalados. Puede que rompa otros drivers de TDT pero normalmente no se suelen tener varios modelos funcionando a la vez.

El paquete se ha generado partiendo del código fuente de dvb-usb-af9035, cabeceras y fuentes de la rama v4l e incluye el firmware /lib/firmware/dvb-usb-af9035-01.fw necesario. 





Drivers de TDT (DVB) AverTV TwinStar 07ca:0825 para kernel 2.6.37

Esta es la continuación de otro artículo de hace más o menos un año, en estos días en Debian unstable ha entrado una nueva versión del kernel (2.6.37) y las anteriores fuentes ya no compilan.

Las nuevas instrucciones quedan así (el nuevo parche disponible aquí):

1.- Descargar nueva rama v4l:

hg clone http://mercurial.intuxication.org/hg/s2-liplianin/
cd s2-liplianin
zcat s2-liplianin-af9035-af9033.diff.gz | patch -p1

2.- Añadir al v4l/.config estas líneas:

###############################
CONFIG_DVB_AF9033=m
CONFIG_DVB_USB_AF9035=m
CONFIG_MEDIA_TUNER_TUA9001=m
##############################
 
3.- Compilar
make
 
4.- Instalar en un temporal
make install DESTDIR=`pwd`/tmp
5.- Copiar al directorio de módulos del kernel
sudo cp -ra tmp/lib/modules/$(uname -r)/kernel/drivers/media/ \
            /lib/modules/$(uname -r)/updates/v4l
sudo depmod -a

6.- Reiniciar y disfrutar (del hardware porque de la tele últimamente no mucho)

 

UPDATE. Para el kernel 2.6.38 nuevo parche: aquí 





Gestión de dispositivos extraíbles en MultiSeat
Hacía tiempo que programar me aburre (según que cosas claro) pero el fin de semana pasado me lo he vuelto a pasar como un niño escribiendo código.
 
Problema:
 
En la Consejería de Educación de la Comunidad de Madrid han empezado a usar un nuevo invento llamado Multiseat (Microsoft lo llama Multipoint) que consiste en unos pequeños aparatos que de una forma lógica vienen a ser un HUB USB que contiene una tarjeta de vídeo, una tarjeta de sonido, y 4 puertos USB, si conectamos varios (pongamos seis) en un equipo automáticamente multiplicamos los puestos disponibles en ese equipo (por USB conectamos un teclado y un ratón a cada Multiseat) (puedes ver algún detalle más en la web de Thinetic Systems)
 
El cómo hicimos andar todo este montaje es otra historia que algún día contaré, pero lo que hoy nos centra es un pequeño problema, y es la gestión de los dispositivos de almacenamiento que se conectan a los puertos USB del Multiseat, para que todos lo entendamos, cuando conectamos una memoria USB se conecta físicamente al servidor (con un HUB USB por el medio) y teníamos que inventar una manera de que sólo pudiera verlo/usarlo el usuario sentado directamente en ese puesto. Ya os adelanto que en Microsoft aún no lo han conseguido (que yo sepa).
 
Solución:
 
En los sistemas basados en Linux durante los últimos años se han venido usando distintas soluciones para el automontaje de discos extraibles (usbmount, HAL, DeviceKit), ahora estamos en la era de UDisk. Es un software que se conecta al gestor de dispositivos del kernel (udev) mediante unas reglas (/lib/udev/rules.d/80-udisks.rules) y crea un bus de sistema (en dbus) donde expone todo lo que encuentra, así las aplicaciones que quieran gestionar un dispositivo sólo tienen que escuchar esos eventos.
 
UDisks permite inhibir el montaje (sigue reconociendo lo que enchufamos pero advierte en dbus que está inhibido y no realiza ninguna acción) por lo que no se montan los dispositivos automáticamente, a este inhibidor se le puede pasar un comando que cuando termine deje de inhibir... un ejemplo de uso práctico es el asistente de instalación gráfico que usa Ubuntu (ubiquity) y que inhibe el montaje de dispositivos (por razones obvias) durante la modificación de particiones y la instalación.
 
Nuestra primera aplicación a desarrollar es un demonio que se conecte al bus del sistema, escuche los dispositivos que se conectan y desconectan, leemos sus propiedades y a partir de ellas adivinamos (por el DEVPATH) en que puesto Multiseat se ha conectado para entonces montarlo con privilegios exclusivos para ese usuario y crearle un icono en el escritorio para que pueda desmontarlo. Este demonio decidí programarlo en python y lo bauticé como multiseat-udisks.py se ejecuta cuando (al arranque) encuentra los puestos MultiSeat (subcarpetas en /dev/usbseat)
 
Ya tenemos solucionado que los dispositivos de almacenamiento se automonten en su sitio y con sus permisos, ahora viene cuando el usuario quiere extraerlo, GNOME crea un icono en el escritorio con nuestro pendrive, realmente no es un archivo y con el inhibidor por el medio no lo va a crear por lo que modifiqué multiseat-udisks.py para que crease un lanzador *.desktop especial con la línea mágica «X-multiseat-desktop=x» siendo x el puesto donde esta montado (subcarpeta de /dev/usbseat ).
 
Para desmontar tenemos dos problemas, primero el usuario no es root y como el dispositivo no está en fstab no le va a dejar desmontarlo, y segundo ese icono del escritorio nos permite abrir el contenido del dispositivo de memoria pero no extraerlo de manera segura (sync && umount) lo primero que se me ocurrió es hacer una extensión para Nautilus (gestor de archivos de GNOME) para que cuando se haga click derecho sobre un archivo *.desktop busque la línea mágica y, si existe, añada una entrada a ese menú derecho del tipo «Desmontar dispositivo extraíble multiseat», cuando se pulse sobre esa opción se llama al proceso de desmontar. Esta extensión (también escrita en Python) la bauticé como nautilus-umount-multiseat.py 
 
Para el problema de los privilegios tuve que programar la tercera ficha de este puzle, una pequeña aplicación en C (instalada con bit SUID) y que eleva privilegios a root para llamar al comando de desmontaje umount.multiseat.c. Muchas aplicaciones de montar y desmontar (instaladas en /sbin) van con el BIT SUID por lo que me parece una manera bastante estandar de hacerlo y más teniendo en cuenta que los usuarios que usan MultiSeat pueden estar en un LDAP.
 
Cuando la extensión de Nautilus detecta que el icono es de un dispositivo conectado a un Multiseat, llama a esta aplicación que eleva los privilegios a root (mediante setuid(0) ) y llama a multiseat-udisks.py con 2 argumentos, el primero es el dispositivo montado (ejemplo: /dev/sdc1 ) y el segundo que se genera dentro del programa C es el UID (identificador numérico del usuario que quiere desmontarlo). El script multiseat-udisks hace una serie de comprobaciones para que los parámetros sean correctos y que el usuario pueda desmontar ese dispositivo (que el punto de montaje le pertenezca) lo desmonta y limpia tanto la carpeta donde se ha montado como el icono del escritorio.
 
El sistema lo hemos probado en varias instalaciones y funciona a la perfección, más tarde convertí el código en paquete *.deb y a instalar en los centros...
 
El motivo por el que me he vuelto a divertir programando es que nadie había hecho algo del estilo y la documentación que podía buscar por internet solo se centraba en el uso de cada herramienta o API por separado por lo que el desarrollo ha sido desde cero hasta algo terminado y funcionando.
 
Siento el tostón técnico pero a algunos nos gusta contar nuestras frikadas Tongue out




HOWTO cacheado de repositorios Debian/Ubuntu para colegios/instituciones

La idea de este HOWTO es poder cachear paquetes deb en un servidor local cuando en un centro tienen varios equipos con Debian/Ubuntu instalado (supongo que valdrá para otros casos menos concretos)

1.- Tenemos que tener un servidor haciendo de puerta de enlace, pongamos que tiene como IP en la LAN interna: 192.168.1.1

2.- En ese equipo tenemos que instalar un apache, el paquete approx y un servidor DNS, me quedo con dnsmasq. Se pueden tener más cosas, yo por ejemplo tengo montado un squid transparente.

3.- Configuramos approx para que cachee paquetes, en /etc/approx/approx.conf añadimos estas 2 líneas al final:

ubuntu http://uk.archive.ubuntu.com/ubuntu
debian http://ftp.uk.debian.org/debian

Lógicamente pon los repositorios que vayan mejor según tu zona geográfica y no uses los principales. Es importante que apuntemos a uno local, porque si apuntamos al principal haremos un bucle infinito. Approx por defecto sirve los repos en el puerto 9999, ahora necesitamos redirigir el 80 al 9999 de nuestra máquina. Se puede hacer con iptables (sabiendo las IPs de destino) o se puede hacer con mod_proxy de apache2.

4.- Creamos un site para apache /etc/apache2/sites-available/cache.mirror:

ProxyRequests Off
ProxyPass /debian/ http://localhost:9999/debian/ 
ProxyPassReverse /debian/ http://192.168.1.1:9999/debian/

ProxyPass /ubuntu/ http://localhost:9999/ubuntu/ ProxyPassReverse /ubuntu/ http://192.168.1.1:9999/ubuntu/

5.- Lo activamos:

# a2enmod proxy
# a2enmod proxy_http
# a2ensite cache.mirror
/etc/init.d/apache2 restart

6.-Ahora viene la magia... como los equipos de la red interna tienen 192.168.1.1 como DNS y gateway (y si no, lo forzamos con iptables) editamos /etc/hosts y añadimos:

# cache paquetes deb
192.168.1.1 archive.ubuntu.com
192.168.1.1 ftp.debian.org

En los equipos del centro tenemos que configurar los repositorios con estos repositorios, si usamos uno nacional no cacheará... Por ejemplo este sería el contenido de un sources.list de Ubuntu Hardy:

deb http://archive.ubuntu.com/ubuntu hardy main universe multiverse restricted
deb http://archive.ubuntu.com/ubuntu hardy-updates main universe multiverse restricted
deb http://archive.ubuntu.com/ubuntu hardy-security main universe multiverse restricted

7.-Reiniciamos dnsmasq (que lee el /etc/hosts antes de hacer peticiones DNS hacia fuera)

8.- Para comprobar que está funcionando en nuestro servidor miramos /var/cache/approx/ y veremos como empiezan a aparecer archivos. El paquete tiene 2 utilidades que se ejecutan diaria y semanalmente, una para actualizar los Packages.gz y otra para hacer limpieza por lo que no deberíamos preocuparnos de tener que mantener el sistema.Supongo que si crece exagerádamente y borramos el contenido de la cache seguirá funcionando y volverá a descargar...

Esta solución desde el punto de vista de consumo de ancho de banda es mejor que debmirror ya que sólo cacheamos los paquetes según se instalan, con debmirror se descarga el repositorio completo.





Compilando rsync en Android

Hace muy pocos días que he aterrizado en el mundo de android pero creo que voy avanzando poco a poco. Voy a publicar una minireceta de como compilar utilidades linux (sencillas) nativamente en Android. Antes de empezar sería bueno recordar que los binarios de Android se compilan para arquitectura ARM por lo que o usamos un emulador (tipo qemu) o un toolchain. Yo he usado el toolchain para compilar nativamente, con el emulador deberíamos compilar en estático y el binario ocupará bastante más. Vamos por pasos:

1.- Descargar el git de android, viene muy bien explicado aquí. Yo lo he descargado en mi $HOME/toolchain.

mkdir ~/toolchain
cd toolchain
wget http://android.git.kernel.org/repo
chmod +x repo
./repo init -u git://android.git.kernel.org/platform/manifest.git
./repo sync

2.- Hora de tomarse algo, descarga la friolera de 2.1 GiB, seguimos, hay que compilar la parte base (librerías)

make BUILD_TINY_ANDROID=true

3.- Tarda otro buen ratillo, ahora compilamos la parte oprofile (lo he compilado aquí porque así tenía a mano los includes de popt.h que son los únicos que he necesitado), cargamos el entorno de ayuda y compilamos el directorio actual y subdirectorios con "mm":

cd external/oprofile
. ../../build/envsetup.sh
mm 

4.- Ahora descargamos las fuentes de rsync (pueden valer las de Debian)

dget -u http://ftp.uk.debian.org/debian/pool/main/r/rsync/rsync_3.0.6-1.dsc
cd rsync-3.0.6

5.- La parte que más me ha costado ha sido entender los Makefile de Android que se llaman Android.mk. Este es mi Android.mk para rsync:

LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_SRC_FILES:= \
flist.c\
rsync.c\
generator.c\
receiver.c\
cleanup.c\
sender.c\
exclude.c\
util.c\
main.c\
checksum.c\
match.c\
syscall.c\
log.c\
backup.c\
options.c\
io.c\
compat.c\
hlink.c\
token.c\
uidlist.c\
socket.c\
hashtable.c\
fileio.c\
batch.c\
clientname.c\
chmod.c\
acls.c\
xattrs.c\
progress.c\
pipe.c\
params.c\
loadparm.c\
clientserver.c\
access.c\
connection.c\
authenticate.c\
lib/wildmatch.c\
lib/compat.c\
lib/snprintf.c\
lib/mdfour.c\
lib/md5.c\
lib/permstring.c\
lib/pool_alloc.c\
lib/sysacls.c\
lib/sysxattrs.c\
zlib/deflate.c\
zlib/inffast.c\
zlib/inflate.c\
zlib/inftrees.c\
zlib/trees.c\
zlib/zutil.c\
zlib/adler32.c\
zlib/compress.c\
zlib/crc32.c
LOCAL_SRC_FILES += netbsd_getpass.c
LOCAL_STATIC_LIBRARIES := \
libpopt
LOCAL_C_INCLUDES := \
$(LOCAL_PATH)/.. \
$(LOCAL_PATH)/../libdb \
$(LOCAL_PATH)/../libutil \
$(LOCAL_PATH)/../libop \
$(LOCAL_PATH)/../libabi
LOCAL_MODULE := rsync
include $(BUILD_EXECUTABLE)

El archivo netbsd_getpass.c lo he tomado de ~/toolchain/external/dropbear/netbsd_getpass.c ya que Android no debe tener la rutina getpass(), sólo se usa si la rutina getpassf() de rsync nativa falla.

6.- A compilar toca, sólo hay que ejecutar "mm" dentro del directorio rsync-3.0.6 y si todo va bien veremos al final:

target Executable: rsync (out/target/product/generic/obj/EXECUTABLES/rsync_intermediates/LINKED/rsync)
target Non-prelinked: rsync (out/target/product/generic/symbols/system/bin/rsync)
target Strip: rsync (out/target/product/generic/obj/EXECUTABLES/rsync_intermediates/rsync)
Install: out/target/product/generic/system/bin/rsync
make: se sale del directorio `/home/mario/toolchain'

7.- Para copiarlo al móvil (conectar el cable USB y activar el modo depuración USB en las preferencias)Necesitamos el SDK de Android.

cd ~/sdk/tools
sudo ./adb kill-server
sudo ./adb remount
sudo ./adb push ~/toolchain/out/target/product/generic/system/bin/rsync /system/bin
sudo ./adb shell chmod 755 /system/bin

Ya podemos abrir el terminal desde android (o desde adb shell) y ejecutar rsync para ver si se copio bien.

Se me ocurren miles de cosas sencillas (GScript + rsync) para tener las fotos publicadas en un blog, hacer copias de seguridad remotas (incrementales) o incluso usarlo para descargar contenido pudiendo perder la conexión temporalmente.

Rizando el rizo, estaría guapo hacer un pequeño frontend con las opciones más usadas y llamarlo desde una aplicación APK.

Como próximo objectivo compilar alguna otra cosa que hecho en falta (¿git? etc...)





Nautilus scripts :: Configuración de Pantalla

No será por tener mucho tiempo libre pero me parecía útil programarlo y más compartirlo:

 

#!/usr/bin/env python
# -*- coding: UTF-8 -*-
#

import nautilus
import subprocess
import os

# put or comment Display configurators here.
# FORMAT
#   [ (string)command  ,        (boolean)need gksu  ]
HELPERS=[
    ["/usr/bin/displayconfig-gtk",              True],
    ["/usr/bin/nvidia-settings",                False],
    ["/usr/bin/gnome-display-properties",       False],
    ["/usr/bin/grandr",                         False],
]

class OpenDisplaySettings(nautilus.MenuProvider):
    def __init__(self):
        pass

    def open_window(self, *args):
        cmd=[]
        for helper in HELPERS:
            if os.path.exists(helper[0]):
                if helper[1]: cmd.append("/usr/bin/gksu")
                cmd.append(helper[0])
                subprocess.Popen(cmd,
                                shell=False,
                                bufsize=0,
                                stdout=subprocess.PIPE,
                                stderr=subprocess.STDOUT,
                                close_fds=True)
                return


    def get_background_items(self, window, _file):
        ICON="/usr/share/icons/gnome/16x16/devices/display.png"
       
        item = nautilus.MenuItem('NautilusPython::open-display-prop',
                                 'Configuración de pantalla',
                                 'Abrir configuración gráfica de pantalla')
        if not os.path.exists(ICON):
            ICON="gtk-dialog-warning"
        item.set_property('icon', ICON)
        item.connect('activate', self.open_window)
        return item,

Guardarlo como "open-display-prop.py" en el directorio ~/.nautilus/python-extensions/ (sino existe se crea)

¿Qué obtenemos?

 


Se pueden añadir más «helpers» o comentar alguno que no nos guste... los «helpers» se buscarán en órden, el segundo parámetro del helper es ver si necesita privilegios de root.

Para que funcione tenemos que tener instalado gksu y python-nautilus.





USBIP ya funciona

Hace un tiempo hablé un poco de refilón sobre USBIP, [USB/IP] un sistema que permite «mover» el punto de conexión de un dispositivo de una máquina a otra (por red) para por ejemplo conectarnos a un scaner, webcam o impresora remota...

Parece que se ha avanzado mucho en el proyecto y de hecho la parte que se ejecuta en el kernel está en el staging (algo como la cuarentena de nuevos drivers que entran al kernel antes de considerarse estables...) tanto es así que incluso las tools están en la cola NEW de Debian. Los paquetes que hice en su día no generaban libusbip así que habrá que tener cuidado cuando entren para no provocar conflictos.

Hoy me he descargado la última versión de las tools (0.1.7) y las fuentes del módulo de un kernel 2.6.28, lo he compilado en un 2.6.26-1-486 y parece que funciona Laughing

Ahora estoy haciendo pruebas con un terminal ligero sobre TCOS (recuerdo que ya teníamos soporte USBIP, aunque desactivado) y he conseguido pasar al servidor tanto una memoria USB (que se ha montado automáticamente Tongue out) como una captura de televisión analógica.

Para que esto sea útil en TCOS me surgen algunos problemas...

  • Tengo que hacer un nuevo interfaz de usuario para ver que dispositivos USB hay en su terminal y conectarlos al servidor...
  • lo que me lleva a modificar tcos-devices-ng o crear un programa nuevo...
  • y lo más complicado, dar permisos exclusivos sólo a ese usuario cuando el dispositivo se conecte al servidor. (jugar con bits SUID y ver que dispositivos /dev se crean al cargar el driver del dispositivo en el servidor)
  • Este nuevo driver puede provocar comportamientos no demasiado buenos en el servidor ¿que pasa si desenchufamos el terminal sin hacer «dettach»?

Para empezar he creado un pequeño parche para que la salida de «bin_driver --list» se pueda leer más facilmente por un script y poderlo mandar por XMLRCP al servidor. No se si mandarselo al upstream para ver si al menos lo tiene en cuenta. Diferencias:

La que viene por defecto

sudo bind_driver --list

List USB devices
- busid 3-3 (04b4:6830)
3-3:1.0 -> usb-storage
- busid 1-2 (147e:2016)
1-2:1.0 -> none
- busid 7-1 (05e3:0608)
7-1:1.0 -> hub
- busid 7-1.2 (04fc:0c15)
7-1.2:1.0 -> usb-storage
- busid 7-1.4 (05e3:0608)
7-1.4:1.0 -> hub
- busid 4-2 (0573:4d28)
4-2:1.0 -> usbvision
- busid 7-1.4.4 (046d:c062)
7-1.4.4:1.0 -> usbhid

La que añade el parche

sudo bind_driver --list2
#busid=3-3#usbid=04b4:6830#3-3:1.0=usb-storage#
#busid=1-2#usbid=147e:2016#1-2:1.0=none#
#busid=7-1#usbid=05e3:0608#7-1:1.0=hub#
#busid=7-1.2#usbid=04fc:0c15#7-1.2:1.0=usb-storage#
#busid=7-1.4#usbid=05e3:0608#7-1.4:1.0=hub#
#busid=4-2#usbid=0573:4d28#4-2:1.0=usbvision#
#busid=7-1.4.4#usbid=046d:c062#7-1.4.4:1.0=usbhid#

De momento no hay mucho más que decir, faltan muchas pruebas para que esto sea funcional.

UPDATE (20090126):

Parche aceptado en el proyecto y posiblemente sea co-mantenedor del paquete en Debian





Mí no entender

Esto es muy curioso:

$ time sha512sum debian-testing-amd64-netinst.iso
0d4527ef57a43f070fd09eb0e5fe7e893be7f404d3aedb06a8b\
ac1666422e6e194b2cba13167033464146718adce77b5b75c\
9d276a2c344a62fbe25b883977af  debian-testing-amd64-netinst.iso

real    0m8.273s
user    0m7.648s
sys    0m0.532s

 

$ time sha512.py debian-testing-amd64-netinst.iso
0d4527ef57a43f070fd09eb0e5fe7e893be7f404d3aedb06a8b\
ac1666422e6e194b2cba13167033464146718adce77b5b75c\
9d276a2c344a62fbe25b883977af debian-testing-amd64-netinst.iso

real    0m1.731s
user    0m1.428s
sys    0m0.292s

 

Este es sha512.py:

#!/usr/bin/env python
import sys
import hashlib
f=open(sys.argv[1], 'rb')
data=f.read()
f.close()
print "%s %s" %(hashlib.sha512(data).hexdigest(), sys.argv[1])

 

No es fruto del cacheado ni el azar,tengo un script que mide varias ejecuciones (en modo alterno) y en python es casi 5 veces más rápido.




Hace un año: Nuevo TcosMonitor2.0

Comprimiendo el protocolo XDMCP

Esta tarde ha sido I+D+i+P+E, el protocolo NX no está muy bien documentado y existen ciertas partes que no son del todo compatibles con Debian por lo que la cosa consistía en rizar el rizo...

OBJETIVO: Reproducir un vídeo de Youtube en remoto con y sin compresión NX

Usando sólo herramientas disponibles en Debian (nxproxy, libnxcl) esta es la diferencia:

Sin compresión... (la barra blanca es un iftop con el máximo configurado en 100MiB, el típico ancho de banda de un switch 10/100, lo más común en redes educativas)

Esta es la buena noticia, con nxproxy (enlace tipo modem) casi 10 veces menos.

Falta mucho trabajo para integrar todo esto en TCOS y bastante código pero sin duda es un buen comienzo, saber que es posible: SE PUEDE COMPRIMIR XDMCP.

El vídeo de la chinita era el primero que salía en youtube, no canta del todo mal.




Hace un año: Empieza el curro en MaX

CDFS works again

Desde TCOS he ido tomando partes de otros proyectos para dar una solución todo en uno sin tener que compilar ni configurar demasiadas cosas.

Una de ellas es el soporte de CDAUDIO desde el terminal ligero.

Cuando metemos un disco con datos mediante LTSPFS vemos las carpetas y los archivos en la sesión del servidor, pero como bien sabeis un disco de audio (o incluso VIDEOCD) no funciona así, no se puede montar a la manera tradicional y hay que usar una aplicación para reproducirlo.

CDFS es un pseudo sistema de archivos para el kernel de linux que añade una capa para que cuando montemos un CDAUDIO veamos los archivos wav de cada pista, se puedan copiar, reproducir, etc...

A partir de un cambio entre el kernel 2.6.24 y 2.6.25 se perdieron ciertas compatibilidades con las funciones iget() por lo que cdfs dejo de compilar y por supuesto de funcionar.

Uno que es un novato chapucero pero con muy buena iniciativa se estuvo documentando e intentando hacer un parche. Este parche ha dado la vuelta a varios buzillas de diferentes distribuciones (cdfs compilaba, no había probado a usarlo) pero dentro del punto de montaje aparecían fifos o directorios con el contenido del CDAUDIO de tamaño cero.

Hace unos días aparece mi bug en Debian como RC y el equipo debian-release se propone eliminarlo de la próxima versión "Lenny", así que yo pregunto al que cambió el kernel (trabajador de Red Hat y mi héroe particular el día de hoy) y me ha dado una clase magistral por correo.... resumiendo CDFS vuelve a funcionar (working cdfs patch for 2.6.26).

Cada vez estoy más convencido de lo bien que funciona el Software Libre.

UPDATE:

No me ha dado tiempo a acabar este post cuando me llega el correo del bugzilla de Debian cerrando el bug. Toma ya !!!





1 2 3 4 5 6 7 8 9 10  Siguiente»