Viewvc (previously viewcvs)

Right now viewcvs is the old version which is available under Debian. I recomend to install the latest viewvc from official website until package gets updated.
For more about it’s history, look up in http://www.viewvc.org/who.html
Instalation is really simple, it’s only complexity resides in the apache 2 configuration. Which is not really well documented and can cause some headache.

Installation

Download here latest stable version from viewvc

I will install everything under /opt because it’s my favourite place (and because it’s standar (LSB rules I think) to put extrange things there).

user@machine:~$ cd /opt
user@machine:~$ wget http://viewvc.tigris.org/files/documents/3330/34803/viewvc-1.0.3.tar.gz
user@machine:~$ tar -xvzf viewvc-1.0.3.tar.gz
user@machine:~$ cd viewvc-1.0.3
user@machine:~$ ./viewvc-install

[will be prompted some easy questions] Answer first /opt and then leave it as it is.

Take a look at INSTALL and README. It’s always good to read this stuff, and doesn’t hurt.

user@machine:~$ emacs /opt/viewvc/viewvc.conf
[main changes I made]
user@machine:~$ diff viewvc.conf ../viewvc-1.0.3/viewvc.conf.dist
72c72
< #cvs_roots = cvs: /home/cvsroot
---
> cvs_roots = cvs: /home/cvsroot
80c80
< svn_roots = svn: /var/lib/svn/repository
---
> #svn_roots = svn: /home/svnrepos
105c105
< default_root = svn
---
> default_root = cvs
138c138
< mime_types_file = /etc/mime.types
---
> #mime_types_file = /usr/local/apache/conf/mime.types
142c142
< address = < a href="mailto:svn-admin@XXX.XXX">Administrador del repositorio Subversion< / a>

> address = < a href="mailto:cvs-admin@insert.your.domain.here">No admin address has been configured< / a>
248c248
< languages = es-es, en-us
---
> languages = en-us
391c391
< docroot = /viewvc-doc
--- (LOOK APACHE 2 CONFIG TO EXPLAIN THIS CHANGE)
> #docroot = /docroot
435c435
< use_enscript = 1
---
> use_enscript = 0
445c445
< use_highlight = 1
---
> use_highlight = 0
459c459
< use_php = 1
---
> use_php = 0
473c473
< allow_tar = 1
---
> allow_tar = 0

For coloured syntax I installed next packages. But I am not really sure they are needed.

user@machine:~$ apt-get install highlight enscript

Apache 2 configuration

Here I put my apache 2 configuration for viewvc. I’ve two versions, both of them work. Again I recomend take a take a look at INSTALL and README for answers. One is the version for cgi and the other for mod_python. I’m using mod_python because it’s known to be faster.

CGI

< IfModule !mod_python.c>
< IfModule cgi.c>
# para la instalacion local
ScriptAlias /viewvc /opt/viewvc/bin/cgi/viewvc.cgi
# para el paquete debian
# ScriptAlias /viewsvn /usr/lib/cgi-bin/viewcvs.cgi
< /IfModule>
< /IfModule>

mod_python

< IfModule mod_python.c>
Alias /viewvc-doc “/opt/viewvc/templates/docroot”
ScriptAlias /viewvc /opt/viewvc/bin/mod_python/viewvc.py
< Location /viewvc>
AddHandler python-program .py
# This appends “our path” to python path
PythonPath “['/opt/viewvc/bin/mod_python'] + sys.path”
PythonHandler handler
PythonDebug On
< /Location>
< /IfModule>

Look the result at http://www.eldemonionegro.com/viewvc/

Resources and comments
Etiquetas: , , , , , , , , , , ,

Screen: Guía rápida para empezar

Screen es una herramienta genial para trabajar con varias sesiones a la vez desde una misma terminal.

Yo principalmente lo uso para control remoto de máquinas.
Otro de los usos más comunes es para compartir una consola con otros usuarios, de forma que todos trabajen o vean a la vez la misma línea de comandos.
No obstante, seguro que hay más usos.

De lo más interesante que nos aporta screen es que se pueden recuperar consolas/sesiones. Es como tener una terminal siempre abierta en un equipo remoto. Aunque se corte la conexión y estés haciendo alguna tarea crítica no vas a perder lo que estés haciendo, puedes volver a conectarte y allí estará todo tal y como estaba antes de la desconexión .
Un buen ejemplo de uso es si estas administrando remotamente una máquina. Se te ocurre hacer un apt-get install y se corta la conexión. Pues luego ándate con ojo, que lo mismo algo se ha quedado a medias y tienes dependencias rotas o que se yo.
No hablemos si haces cualquier otra cosa un poco más crítica, como un formateo de disco o una copia o desplazamiento de ficheros….

Ejemplo de uso

Bien, para empezar de forma rápida a usarlo un ejemplo.
Conectamos con la máquina remota, ejecutamos:

user@host $: screen -U

-U es para tener soporte para unicode uft-8
Para salir de screen y dejarlo corriendo tecleamos la secuencia < Control > + a d. Os saldrá lo siguiente:

user@host $: screen -U
[detached]

Pues para recuperar screen hacemos:

user@host $: screen -r -d

-r -d Reattach a session and if necessary detach it first.. Recuperamos la sesión seguro.

Listo.
El último comando que recomiendo es el maestro de maestros, para no memorizar nada, tenemos la fantástica ayuda instantánea de la secuencia < Control > + a ? que nos mostrará todos los atajos.

Accesos rápidos

Key Action Notes
Ctrl+a c new window
Ctrl+a n next window I bind F12 to this
Ctrl+a p previous window I bind F11 to this
Ctrl+a ” select window from list I have window list in the status line
Ctrl+a Ctrl+a previous window viewed
Ctrl+a S split terminal horizontally into regions Ctrl+a c to create new window there
Ctrl+a :resize rezize region
Ctrl+a :remove remove region Ctrl+a X is the same
Ctrl+a tab Move to next region
Ctrl+a d detach screen from terminal Start screen with -r option to reattach
Ctrl+a A set window title
Ctrl+a x lock session Enter user password to unlock
Ctrl+a [ enter scrollback/copy mode Enter to start and end copy region. Ctrl+a ] to leave this mode
Ctrl+a ] paste buffer Supports pasting between windows
Ctrl+a > write paste buffer to file useful for copying between screens
Ctrl+a < read paste buffer from file useful for pasting between screens
Ctrl+a ? show key bindings/command names Note unbound commands only in man page
Ctrl+a : goto screen command prompt up shows last command entered

Referencias y enlaces:

Etiquetas: , , , , , ,

Probando FlowPlayer

Ahora que está tan de moda (y es que mola) lo de poner vídeos que se reproducen rápidamente he decidido incluir el mío propio.
No tanta mierda de youtube.com ni leches. Si google se quiere gastar más de 1000 millones de €…, será porque les cuesta poco ganarlos.
¿Para qué depender de otros cuando lo puedes hacer tú mismo? Bastante censura me aplico, como para que de repente me dejen sin vídeo porque no entra en su política de contenidos.

Encima FlowPlayer, que es como se llama el bicho, mola más.
Sólo falta que gnash termine de funcionar para poder mandar al carajo a macromedia y su flash plugin. Y es que en mis pruebas, gnash mostraba una especie de garabatos que más bien parecían Picassos en movimiento que vídeos.

Por supuesto flowplayer no es mío, pero como si lo fuera, porque tiene licencia Apache 2.0 (otra licencia de código libre, casi compatible con GPL). Página web del proyecto FlowPlayer

Estaremos en fase de pruebas, dependiendo del ancho de banda que me consuma.

¿Cómo usarlo?

Los ejemplos son de su página. Parece todo bastante fácil.

Lo primero, transformar el vídeo al formato de vídeo flash, el FLV.
Para transformar una película en formato FLV (desde un original: .mp4 .mov .mpg .3gp .mpeg .wmv .avi), seguir los siguientes pasos:

El comando flvtool2 añade la duración del vídeo en los metadatos del archivo FLV. FlowPlayer lee la información de duración del archivo FLV y la muestra. Así pues, los metadatos del archivo FLV se pueden insertar mediante flvtool2.

ffmpeg -i movie.[avi] -s 320×240 -ar 44100 -r 12 movie.flv
cat movie.flv | flvtool2 -U stdin movie.flv

EJEMPLO
Yo concretamente me voy a estrenar con el vídeo de la ocupación multitudinaria y molona de Ikea en Barcelona.

Para instalar flvtool2 he utilizado el directorio /opt, que para eso está.

$ ruby setup.rb config –prefix=/opt –siterubyver=/opt/lib/site_ruby/1.8
$ ruby setup.rb setup
$ ruby setup.rb install

(Para instalar, según los permisos que tengas en opt, puedes necesitar ser superusuario)

Para ejecutar flvtool2, al no usar directorios estándar que suelen estar en los $PATH, … se me ha ocurrido crear un miniscript conteniendo:

#!/bin/bash
ruby -I /opt/lib/site_ruby/1.8 /opt/bin/flvtool2.ruby $@

El script de bash lo he llamado flvtool2 y el archivo flvtool2 lo he renombrado a flvtool2.ruby

Tras eso he creado el archivo…

ffmpeg -i ocupacion_multitudinaria_viviendadigna_ikea_barcelona.mov -s 320×240 -ar 44100 -r 12 ocupacion_multitudinaria_viviendadigna_ikea_barcelona.flv

cat ocupacion_multitudinaria_viviendadigna_ikea_barcelona.flv | flvtool2 -U stdin ocupacion_multitudinaria_viviendadigna_ikea_barcelona.flv

Vaya, me sale el error:

/opt/lib/site_ruby/1.8/flv/amf_string_buffer.rb:163: [BUG] Segmentation fault
ruby 1.8.5 (2006-08-25) [i486-linux]
/opt/bin/flvtool2: line 2: 14262 Abortado ruby -I /opt/lib/site_ruby/1.8 /opt/bin/flvtool2.ruby $@

Pues mi buscador me dice que mire en Using Lighttpd, Mplayer/Mencoder and Flvtool2 to Implement Flash Video Streaming
y allí me indican sustituya en /opt/lib/site_ruby/1.8/flv/amf_string_buffer.rb la línea 163 :

de
    write [(time.to_i * 1000.0)].pack('G')
a
    write [(time.to_f * 1000.0)].pack('G')

Repito lo mismo

cat ocupacion_multitudinaria_viviendadigna_ikea_barcelona.flv | flvtool2 -U stdin ocupacion_multitudinaria_viviendadigna_ikea_barcelona.flv

Ahora ya no da ningún error.

Como colofón quiero incluir el modo que tiene que muestra también una lista de imágenes en miniatura de diferentes instantes del vídeo. Pero no va. A ver si me contesta el autor cómo va el tema este.
El comando usado para empotrar en el flv las miniaturas se supone que es el siguiente.

flvtool2 -AUt tags.xml ocupacion_multitudinaria_viviendadigna_ikea_barcelona.flv

El contenido del fichero tags.xml

En último lugar edito el ejemplo de código html que se debe poner en la web para adaptarlo a mi caso particular:

<object type=”application/x-shockwave-flash” data=”/wordpress/wp-content/plugins/flowplayer/FlowPlayerLP.swf” width=”420″ height=”340″ id=”FlowPlayer”>
<param name=”allowScriptAccess” value=”sameDomain” />
<param name=”movie” value=”/wordpress/wp-content/plugins/flowplayer/FlowPlayerLP.swf” />
<param name=”quality” value=”high” />
<param name=”scale” value=”noScale” />
<param name=”wmode” value=”transparent” />
<param name=”flashvars” value=”baseURL=/wordpress/wp-content/archivos/&videoFile=ocupacion_multitudinaria_viviendadigna_ikea_barcelona.flv&thumbsOnFLV=true&loop=false” />
</object>

El resultado final:

TATATACHÁN

Referencias:

Página web del proyecto flvtool2
Página web del proyecto FlowPlayer

Etiquetas: , , , , , , , , ,

Firewall en Debian/Linux. Guardog vs Firestarter

Hace tiempo leía yo en algún lugar

On Tue, 30 Mar 2004, XXX YY wrote:
> Listeros, unas preguntas. Estoy recibiendo estos mensajes en consola :
>
> Mar 30 11:20:22 mail kernel: martian source 192.168.x.x from 192.168.x.x, on dev eth1
> Mar 30 11:20:22 mail kernel: ll header: ff:ff:ff:ff:ff:ff:00:0b:db:18:fe:3d:08:00
>
> ¿Qué son?

En todo caso, lo que está diciendo es que por la interfaz eth1 se recibió un paquete cuya dirección de origen es _imposible_ a la luz de la actual configuración de interfaces/tabla de rutas; en otras palabras, por esa interfaz nunca podría venir un paquete con la dirección que vino, por tanto es un paquete “marciano” que, de paso, es obvio con sólo mirar el encabezado “extraño” [3].

Quizás alguien está haciendo spoofing, o bien alguna máquina tiene una muy mala configuración IP.

> ¿Son un problema?

Si, paquetes inesperados que llegan por un camino por el cual no pueden llegar indica algún problema de audacia (cracker), indolencia (administrador que no configuró correctamente los segmentos IP) o incoherencia (interfaces/tablas de rutas no cónsonas con la necesidad).

Usando paquetes como éstos se pueden atacar vulnerabilidades remotas en stacks TCP/IP (¿cuáles?, ahora no se me ocurre ninguna particular, pero las hay). Usando las IP que ocultaste, la MAC que aparece presentada en el encabezado, un sniffer, arping y otras herramientas similares puedes determinar cuál es la máquina que está generando esos paquetes y golpear al dueño con algún objeto contundente.

Por eso es un paquete marciano.

> ¿Cómo puedo correjir el problema?

Revisa las tres posibilidades anteriores: spoofing, mala configuración IP en los clientes, mala configuración IP en el servidor.

[1] Las máquinas en una red IP _nunca_ deben llamarse como “lo que hacen” sino con un nombre único, preferiblemente siguiendo un tema. Lo que haces no es más que un “rol”, y como los roles cambian pero los nombres no, se utiliza un alias (CNAME en DNS) para asociar roles a nombres. Eso permite comenzar con una sola máquina que tenga todos los roles, y luego agregar máquinas y cambiar roles… pero el resto de la configuración puede quedar exactamente igual, en particular para los clientes y sus aplicaciones que suelen ser los más afectados cuando hay cambios de máquinas servidoras.
[2] El syslog acompaña cada mensaje con el nombre de la máquina origen, porque puede configurarse para que reciba todos los mensajes de todas las máquinas, cosa que es más práctica porque así hay un sólo sitio donde estudiar logs.
[3] La primera parte del encabezado (ff:ff:ff:ff:ff:ff) corresponde a la dirección MAC origen, que corresponde al broadcast local. Digo que es muy obvio porque _nunca_ se usa ese tipo de direcciones en un intercambio Ethernet:
a. Cuando el origen conoce al destino, ambos serán MACs específicas.
b. Cuando el origen no conoce al destino, el origen será una MAC específica y el destino será ff:ff:ff:ff:ff:ff (esto es un caso de ARP).
c. Cuando el origen no conoce su dirección IP y quiere averiguarla, el origen será 00:00:00:00:00:00 y el destino será ff:ff:ff:ff:ff:ff (esto es RARP, BOOTP y/o DHCP).
d. No hay otro caso.
El kernel sabe tanto IP e Ethernet como el Comer, así que puede sacar la misma conclusión que yo y decir que hay algo anormal en el paquete, en consecuencia la notificación.

*** Fin correo electrónico de la persona XXX YY

De Cortafuegos y Firewalls

Aunque GNU/Linux goza de buena salud en seguridad y velocidad de respuesta para cerrar fallos nunca está demás configurar un Cortafuegos (firewall).
Los eruditos dicen que *BSD son más seguros. Más rápidos es corregir fallos. Presumen de ello. Yo no digo que si, ¿ni que no?, porque aun no he probado a usar un sistema *BSD.

Yo conozco dos grandes soluciones para el diseño de los mismos. Guardog y Firestarter. Porque aquí tu puedes diseñar tu cortafuegos, quieres saber lo que hace.

Uno me permite diseños complejos de enrutado, etc. Es Guardog que se usa junto con Guidedog para permitir NAT o redireccionamiento de puertos, creo, yo lo uso únicamente para NAT.
La pareja Guardog-Guidedog es mágica. Te permite diseñar redes pensando en zonas. Tal y como se diseñan las redes. El día que se configure mediante dibujos (tal y como lo explican en la Universidad) será la bomba.

Pantallazos de Guardog y Guidedog:

Otro me permite blindar una sola máquina. Firestarter. También tiene interfaz de monitorización.

Pantallazos de Firestarter:

Existe otro programa que permite control remoto e interactividad en tiempo real. No recuerdo el nombre pero si que estaba en Debian. Si alguien se interesa lo puedo buscar o lo puede buscar (ya sabiendo que existe).
Permite interactividad con las reglas según llegan los paquetes a las colas de recepción y envio. Pero no es tan bonito y “usable” como los de “esto que pase, esto que no” destinados a window$. Además que lo de tu si vale, se termina haciendo pesado y muchas veces ni prestas atención con tal de que desaparezca el mensajito.

A los especialistas y los puristas estos artilugios les incomodan. A mi me mola, porque lo de las reglas de los cortafuegos me parece un coñazo sobervio. Quisiera saber mucho más del tema, pero quiesiera ser especialista en tantas cosas que no me cunde el tiempo.
Estas herramientas son muy cómodas por tanto.

Referencias y enlaces
Etiquetas: , , ,

Otra vez GNU/Linux y su coste estimado de desarrollo.

Ya hablé hace tiempo del coste estimado de desarrollo de GNU/Linux pero me pareció que los datos que aportaba no eran de suficiente actualidad.

He tardado mucho en publicar esta entrada, la tenía guardada desde hace muchos meses.

Leía poco después en las listas de debian.org un estudio realizado por profesores de la Universidad Politécnica de Madrid y la Universidad Rey Juan Carlos de riguroso interés.
Son 4 páginas de las que resalto algunos detalles interesantes

Los cálculos se han estimado sólo para la rama main (no se ha considerado ni contrib ni nonfree).

La verdad es que los ojos te hacen chirivitas. :shock_tb:

A día 6 de Junio de 2005:

La distribución Debian es producida por el proyecto Debian, un grupo de cerca de 1499 voluntarios.

…hay más de 8,600 paquetes fuente. El release completo comprende cerca de 15,300 paquetes de binarios…

La siguiente tabla de resumen por lenguajes de programación del número de líneas de código de Debian Sarge.

Lenguaje Lineas de código fuente Porcentaje (%)
C   130,847,000 57
C++ 38,602,000 16.8
Shell 20,763,000 9
LISP 6,919,000 3
Perl 6,415,000 2.8
Python 4,129,000 1.8
Java 3,679,000 1.6
FORTRAN 2,724,000 1.2
PHP 2,144,000 0.93
Pascal 1,423,000 0.62
Ada 1,401,000 0.61
Totales 229,496,000 100


Below 0.5% there are some other languages such as Objective C (0.37%), ML (0.31%), Yacc (0.29%), Ruby (0.26%), C# (0.23%) or Lex (0.10%). A number of other languages score less than 0.1%.


COCOMO model are as follows:
Total physical SLOC count: 229.495.824
Estimated effort: 714.440,52 person-months (59.536,71 person-years). Formula: 2,4 * (KSLOC^1,05)
Estimated schedule: 105,84 months (8,82 years). Formula:2.5 * (Effort^0,38)
Estimated cost to develop: 8,043,000,000 USD
To reach these figures, each project was estimated as though it had been developed independently, which is true for nearly all cases.
For calculating the cost estimation, we have used the mean salary for a full-time systems programmer in 2000 according to Computer World – 56,286 USD per year – and an overhead factor of 2.4.

Gráfico. Tamaño de paquetes frente a líneas de código representadas en escala logarítmica para Debian 3.1 Sarge.

Sistema Operativo Lineas de código fuente
Microsoft Windows 3.1 (Abril 1992) 3,000,000
Sun Solaris (Octubre 1998) 7,500,000
Microsoft Windows 95 (Agosto 1995) 15,000,000
Red Hat Linux 6.2 (Marzo 2000) 17,000,000
Microsoft Windows 2000 (Febrero 2000) 29,000,000
Red Hat Linux 7.1 (Abril 2001) 30,000,000
Microsoft Windows XP (2002) 40,000,000
Red Hat Linux 8.0 (Septiembre 2002) 50,000,000
Fedora Core 4 (versión previa; Mayo 2005) 76,000,000
Debian 3.0 (Julio 2002) 105,000,000
Debian 3.1 (Junio 2005) 229,500,000




El número de paquetes continua creciendo y doblándose casi cada dos años

También encontré desde aquel momento a esta parte otra página dedicada a estimaciones de Debian, supongo que del mismo grupo de investigadores.

http://libresoft.dat.escet.urjc.es/debian-counting/
General Statistics for Debian Sarge Code Counting
SLOCCount Web for Debian Sarge: Packages
SLOCCount Web for Debian Sarge: General Graphs

El artículo en formato PDF “Measuring Libre Software Using Debian 3.1 Sarge as a case study”

Algunas de las referencias del artículo:

Y eso que es de hace más de un año. ¿Cómo andará la cosa ahora?

Etiquetas: , , , , ,

Crear imágenes de disquetes

Hoy vamos a crear una imagen de un disquete.

Hoy nos ponemos un poquito retro.
Ahora que las disqueteras no las usa ni su inventor, pues nosotros las sacamos a relucir.

Tan sólo tenemos que tener… todas las herramientas necesarias.

Primero hay que crear una imagen vacía. La llamaremos “disquete.img”

usuario@maquina:~$ dd if=/dev/zero of=disquete.img bs=512 count=2880

Ahora hay que preparar la imagen para ser montada como dispositivo loopback.

root@maquina:~$ losetup /dev/loop0 disquete.img

Se crea el sistema de ficheros, por ejemplo como MSDOS.

root@maquina:~$ mkdosfs /dev/loop0

Finalmente se monta en /mnt/midisquetera

root@maquina:~$ mkdir /mnt/midisquetera
root@maquina:~$ mount -t msdos /dev/loop0 /mnt/midisquetera

Etiquetas: , , , , , , , , ,

Cámaras Web. Logitech Quickcam for Notebooks Pro

No ha sido fácil pero tras unos días he conseguido hacer funcionar la cámara en Debian.
Hay que utilizar drivers aún en desarrollo pero la cosa funciona.

Existen por Internet otros drivers denominados pwc que no funcionan con este modelo. Parece ser que funcionan con cámaras anteriores a los últimos modelos de Logitech (ver tabla).

El mayor problema es que para sistemas operativos GNU/Linux no hay mucho mundo en relación a las cámaras web. Esta es la impresión que yo tengo en cuanto al soporte de cámaras web.
Los fabricantes deberían contratar o pagar a todos los desarrolladores de drivers que hay y apuntarse ya al mundo del software libre. Y si no desarrollan sus drivers como software libre, que al menos se den cuenta de una vez de que es un mercado desaprovechado.

El meollo

La documentación digamos que hay que extraerla de la lista de correo del proyecto Linux uvc driver. Le queda mucho como proyecto, pero el driver es estable.
Aunque quizás como proyecto no llegue a tener un sentido completo, porque por lo que he leído lo que quieren es introducir el driver en el kernel Linux. La opción más sensata, así viene de serie con el kernel el soporte.
Se han centrado en V4L2 y no en V4L en su primera versión que ya ha quedado abandonada por. Al menos de momento V4L está descartado.


Linux UVC driver and tools es el proyecto que da soporte, de momento, a:

Identificador de dispositivo Modelo de cámara Fabricante
046d:08c1 Logitech Quickcam Fusion Logitech
046d:08c2 Logitech Quickcam Orbit Logitech
046d:08c3 Logitech Quickcam Pro for Notebooks Logitech
046d:08c5 Logitech Quickcam Pro 5000 Logitech
046d:08c6 Logitech Quickcam OEM Dell Notebook Logitech
046d:08c7 Logitech Quickcam OEM Cisco VT Camera II Logitech


Para hacer funcionar el driver para la cámara Logitech Quickcam for Notebooks Pro la receta consta de descargar, compilar e instalar :

usuario@maquina:~/src/svn/linux-uvc$ svn checkout http://svn.berlios.de/svnroot/repos/linux-uvc/trunk
root@maquina:~/src/svn/linux-uvc$ su
root@maquina:~/src/svn/linux-uvc$ cd trunk/
root@maquina:~/src/svn/linux-uvc$ make
Building USB Video Class driver…
make[1]: se ingresa al directorio `/usr/src/linux-headers-2.6.17-1-686′
Building modules, stage 2.
MODPOST
CC /PATH/src/svn/linux-uvc/trunk/uvcvideo.mod.o
LD [M] /PATH/src/svn/linux-uvc/trunk/uvcvideo.ko
make[1]: se sale del directorio `/usr/src/linux-headers-2.6.17-1-686′
root@maquina:~/src/svn/linux-uvc$ make install
Installing USB Video Class driver…
make[1]: se ingresa al directorio `/usr/src/linux-headers-2.6.17-1-686′
INSTALL /PATH/src/svn/linux-uvc/trunk/uvcvideo.ko
DEPMOD 2.6.17-1-686
make[1]: se sale del directorio `/usr/src/linux-headers-2.6.17-1-686′
depmod -ae

Obviamente para compilar serán necesarios los paquetes de cabeceras del núcleo Linux y puede que alguno más que se me pase por ser obvio.

Hay que añadir al(los) usuario(s) al grupo video por los permisos que se asignan al dispositivo que se crea (en mi caso /dev/video0)

root@maquina:/home/user/src/svn/linux-uvc/trunk$ ls -la /dev/video0
crw-rw—- 1 root video 81, 0 2006-08-03 14:03 /dev/video0
root@maquina:~/src/svn/linux-uvc$ adduser USUARIO video

Una vez enchufemos la cámara salen mensajes de este tipo (yo la he enchufado y desenchufado para que se vean un poco todos los mensajes).

usuario@maquina:~$ dmesg | tail -n 14
uvcvideo: Found UVC 1.00 device <unnamed> (046d:08c3)
usbcore: registered new driver uvcvideo
USB Video Class driver (v0.1.0)
usb 4-4: USB disconnect, address 5
usb 4-4: new high speed USB device using ehci_hcd and address 6
usb 4-4: configuration #1 chosen from 1 choice
uvcvideo: Found UVC 1.00 device <unnamed> (046d:08c3)
6:3:1: cannot set freq 0 to ep 0x86
6:3:2: cannot set freq 0 to ep 0x86
6:3:3: cannot get freq at ep 0x86
usb 4-4: USB disconnect, address 6
usb 4-4: new high speed USB device using ehci_hcd and address 7
usb 4-4: configuration #1 chosen from 1 choice
uvcvideo: Found UVC 1.00 device <unnamed> (046d:08c3)

El mensaje cannot set freq 0 to ep 0x86 es debido al micrófono incorporado en la cámara, que aún no funciona.

La aplicación luvciew es útil para ver si funciona nuestra cámara.

usuario@maquina:~/src/webcam/$ wget http://mxhaard.free.fr/spca50x/Investigation/uvc/luvcview-20060706.tar.gz
usuario@maquina:~/src/webcam/$ tar -xvf luvcview-20060706.tar.gz
usuario@maquina:~/src/webcam/$ cd luvcview-20060706
usuario@maquina:~/src/webcam/luvcview-20060706$ make
ERRORES debido a la falta de las librerias Simple DirectMedia Layer
usuario@maquina:~/src/webcam/luvcview-20060706$ apt-get install libsdl1.2-dev

Para que funcione la cámara con ekiga es necesario instalar el plugin para V4L2 de las Portable Windows Library.

usuario@maquina:~$ apt-get install libpt-plugins-v4l2


Aplicaciones

Que soportan V4L2

Todas estas las he probado y funcionan:

Aplicaciones en el limbo, es decir, por el momento sin comprobar
  • camorama
  • camE
  • (esto es un comando encontrado en la lista de correo) ffmpeg -vd /dev/video0 -s 640×480 -r 5 -b 5000 -y -vcodec mpeg4 -f avi – | mplayer –
Aplicaciones que NO soportan V4L2, por el momento que yo sepa


Cuestiones

¿Alguien conoce algún otro programa?
¿Me dejo algo?

Otros proyectos y referencias

Versión actual del driver pwc.. Parece dar soporte completo (a alta resolución) con un driver libre. De hecho, en esta versión está basado el paquete pwc-source de Debian .
Versión no mantenida desde hace tiempo de los drivers pwc. Para funcionamiento “completo” requieren del driver binario (y polémico) pwcx.
Linux support for Philips USB webcams (and Linux only). No lo he probado. Creo que tiene que ver con el enlace anterior porque no hay noticias nuevas desde el 2004.

Etiquetas: , , , , , , , , , , , , , , , ,

Warning: "/tmp/vmware-config0/vmnet-only/vmnet.o" failed to load: Not a kernel module, lacks modinfo section

Si usas la última versión del kernel, la 2.6.17 puede que los módulos para vmware no compilen.
Tienen un pequeño problema de carencia de información básica (autor, licencia….) que se suele incluir en los módulos para el kernel linux:

*** Warning: "/tmp/vmware-config0/vmnet-only/vmnet.o" failed to load: Not a kernel module, lacks modinfo section
make[2]: *** [__modpost] Error 1
make[1]: *** [modules] Error 2
make[1]: se sale del directorio `/usr/src/linux-headers-2.6.17-1-686'
make: *** [vmnet.ko] Error 2
make: se sale del directorio `/tmp/vmware-config0/vmnet-only'
Unable to build the vmnet module.

Para resolverlo hay dos opciones.

Opción 1

root@einstein:/usr/lib/vmware/modules/source$ tar -xvf vmnet.tar

Añadimos MODULE_AUTHOR(“VMWare”); al archivo driver.c antes de la línea #ifdef VMW_HAVE_SK_ALLOC_WITH_PROTO

root@einstein:/usr/lib/vmware/modules/source$ emacs vmnet-only/driver.c
root@einstein:/usr/lib/vmware/modules/source$ ll
total 1387
-rw-r--r-- 1 root root 1003520 2006-07-04 17:59 vmmon.tar
drwxr-xr-x 2 root root    1528 2006-07-29 16:41 vmnet-only
-rw-r--r-- 1 root root  358400 2006-07-04 17:59 vmnet.tar
-r--r--r-- 1 root root   51200 2006-07-04 17:55 vmppuser.tar
root@einstein:/usr/lib/vmware/modules/source$ mv vmnet.tar vmnet.tar.old
root@einstein:/usr/lib/vmware/modules/source$ tar cvf vmnet.tar vmnet-only/
root@einstein:/usr/lib/vmware/modules/source$ ll
total 1787
-rw-r--r-- 1 root root 1003520 2006-07-04 17:59 vmmon.tar
drwxr-xr-x 2 root root    1528 2006-07-29 16:41 vmnet-only
-rw-r--r-- 1 root root  409600 2006-07-29 16:42 vmnet.tar
-rw-r--r-- 1 root root  358400 2006-07-04 17:59 vmnet.tar.old
-r--r--r-- 1 root root   51200 2006-07-04 17:55 vmppuser.tar
root@einstein:/usr/lib/vmware/modules/source$ rm -rf vmnet-only/

Tras esto volvemos a compilar/configurar el vmware con el comando destinado a tal efecto y listo.

root@einstein:/usr/lib/vmware/modules/source$ vmware-config.pl
...
Building the vmnet module.

Building for VMware Workstation 5.5.x.
Using 2.6.x kernel build system.
make: se ingresa al directorio `/tmp/vmware-config2/vmnet-only'
make -C /lib/modules/2.6.17-1-686/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. modules
make[1]: se ingresa al directorio `/usr/src/linux-headers-2.6.17-1-686'
  CC [M]  /tmp/vmware-config2/vmnet-only/driver.o
  CC [M]  /tmp/vmware-config2/vmnet-only/hub.o
  CC [M]  /tmp/vmware-config2/vmnet-only/userif.o
  CC [M]  /tmp/vmware-config2/vmnet-only/netif.o
  CC [M]  /tmp/vmware-config2/vmnet-only/bridge.o
  CC [M]  /tmp/vmware-config2/vmnet-only/procfs.o
  CC [M]  /tmp/vmware-config2/vmnet-only/smac_compat.o
  CC [M]  /tmp/vmware-config2/vmnet-only/smac_linux.x386.o
  LD [M]  /tmp/vmware-config2/vmnet-only/vmnet.o
  Building modules, stage 2.
  MODPOST
  CC      /tmp/vmware-config2/vmnet-only/vmnet.mod.o
  LD [M]  /tmp/vmware-config2/vmnet-only/vmnet.ko
make[1]: se sale del directorio `/usr/src/linux-headers-2.6.17-1-686'
cp -f vmnet.ko ./../vmnet.o
make: se sale del directorio `/tmp/vmware-config2/vmnet-only'
The module loads perfectly in the running kernel.
...

Opción 2
La otra opción es aplicar la última actualización de los parches de la serie any any. No se quién los realiza. Pero resuelven cualquier problema para poder compilar los módulos de vmware con las últimas versiones del kernel linux al poco de liberarse.

Siempre se puede encontrar la última versión aquí:
Directorio donde encontrar la úlitma versión de vmware-any-any. A fecha de hoy el archivo se llama vmware-any-any-update113.tar.gz

También dejo un enlace para la mula:
vmware-any-any-update102.tar.gz (Enlace tipo ed2k)
vmware-any-any-update104.tar.gz (Enlace tipo ed2k)
vmware-any-any-update113.tar.gz (Enlace tipo ed2k)

Se aplica en tres sencillos pasos:

tar xzf vmware-any-any-update113.tar.gz
cd vmware-any-any-update113
./runme.pl
Referencias:

Can’t compile vmnet.ko on (Debian) Linux kernel 2.6.17

Etiquetas: , , , , , , , , ,