 |
| El nacimiento de Jesús |
Declarado de interés provincial y municipal.
jueves, 9 de diciembre de 2010
El nacimiento de Jesús
Declarado de interés provincial y municipal.
miércoles, 1 de diciembre de 2010
OpenVox G400P in Debian
Éste post está también disponible en español.
This post is also available in spanish.
I bought an OpenVox G400P GSM telephony card to set up a VoIP server running Debian. I clearly didn't do my research homework before starting, and it turned out that it was not easy to set up this card with Dahdi, wich I had to keep in order to be able to use another card I already had on that server.
2.- Create an upstream branch to follow Dahdi's development.
$ git checkout -b upstream
3.- Tag Dahdi's release in the upstream branch.
$ git tag -a dahdi-x.y.z
4.- Go back to the master branch and develop the driver.
$ git checkout master
[... desarrollo...]
5.- Once finished a release, tag it.
$ git tag -a chan-extra-x.y.z
6.- Make a patch out of it (althought it would be better to just publish the git repo).
$ git diff upstream master > chan-extra-x.y.z.patch
Note: there are far more better ways to generate a proper patch using git... but I had no time to get into that yet :-/ Comments welcomed :-)
7.- Whenever we need to develop with a newer Dahdi's release, we just need to update the upstream branch and merge it back to master.
$ git checkout upstream
$ git rm '*'
$ git clean -xdff
$ tar zxfv ../../dahdi-x.y.z+1.tar.gz --strip=1
$ git add -A
$ git commit -m "Import upstream x.y.z+1 release."
$ git checkout master
$ git merge upstream
Then the user will just need to patch the original source code and compile. Of course, the same workflow can be used for making patches for Asterisk.
Comments on this workflow will be much appreciated :-)
This post is also available in spanish.
I bought an OpenVox G400P GSM telephony card to set up a VoIP server running Debian. I clearly didn't do my research homework before starting, and it turned out that it was not easy to set up this card with Dahdi, wich I had to keep in order to be able to use another card I already had on that server.
Problems I found:
- There was not official Dahdi support for this board until about ~6 months ago.
- When it finally appeared, it turned out that there were not just some patches to the original source code, but some scripts that supossed that my system was RPM based. Oh, and it also downloads, modifies, compiles and installs Dahdi and Asterisk, leaving no room for customization.
- When I asked the support about this issue, they told me that if I gave them SSH access they would install it for me (!?). I took the time to explain them that asking their clients for SSH access to their servers was not a good idea. Sadly, it seems that they didn't took my advice.
Dissasembling the script:
So my next move was to get and install either Elastix or Trixbox in a virtual machine, supossedly supported by the script they provide, get the modified source code, check it and compile it in my Debian box. I got to download three different versions of those distros, and it seems I couldn't get the correct version the script needed. So the next step was obvious: print the script, analyze it and modify it to get the source code.
Of course, I used git to keep the changes :-)
Final source code:
Asterisk: http://dumbledore.com.ar/gitweb/?p=asterisk.git;a=summary (might be incomplete, I still have to check it).
In the Dahdi repo, the openvox-g400p branch has the chan-extra modifications, the oslec branch contains the support for OSLEC echo canceler. Finally master is a merge of both. I still didn't check if the G400P supports oslec, but I have it there because I use it with the other card I have in the server.
Recommendations for OpenVox:
While I find an excellent idea to have an "automagic" script for your clients, a user os another distributions or/and an advanced user will find a patch most suitable. The good thing about this is that git makes it's creation quite simple.
I suggest the following workflow:
1.- Uncompress Dahdi's source code, rename the new directory and create a git repo out of it.
$ tar -xf dahdi-x.y.z.tar.gz
$ mv dahdi-x.y.z dahdi
$ cd dahdi
$ git init
$ git add -A
$ git commit -m "Original Dahdi source code version x.y.z."
While I find an excellent idea to have an "automagic" script for your clients, a user os another distributions or/and an advanced user will find a patch most suitable. The good thing about this is that git makes it's creation quite simple.
I suggest the following workflow:
1.- Uncompress Dahdi's source code, rename the new directory and create a git repo out of it.
$ tar -xf dahdi-x.y.z.tar.gz
$ mv dahdi-x.y.z dahdi
$ cd dahdi
$ git init
$ git add -A
$ git commit -m "Original Dahdi source code version x.y.z."
2.- Create an upstream branch to follow Dahdi's development.
$ git checkout -b upstream
3.- Tag Dahdi's release in the upstream branch.
$ git tag -a dahdi-x.y.z
4.- Go back to the master branch and develop the driver.
$ git checkout master
[... desarrollo...]
5.- Once finished a release, tag it.
$ git tag -a chan-extra-x.y.z
6.- Make a patch out of it (althought it would be better to just publish the git repo).
$ git diff upstream master > chan-extra-x.y.z.patch
Note: there are far more better ways to generate a proper patch using git... but I had no time to get into that yet :-/ Comments welcomed :-)
7.- Whenever we need to develop with a newer Dahdi's release, we just need to update the upstream branch and merge it back to master.
$ git checkout upstream
$ git rm '*'
$ git clean -xdff
$ tar zxfv ../../dahdi-x.y.z+1.tar.gz --strip=1
$ git add -A
$ git commit -m "Import upstream x.y.z+1 release."
$ git checkout master
$ git merge upstream
Then the user will just need to patch the original source code and compile. Of course, the same workflow can be used for making patches for Asterisk.
Comments on this workflow will be much appreciated :-)
OpenVox G400P en Debian
This post is also available in english.
Éste post también se encuentra redactado en inglés.
Instalando un servidor de telefonía IP no tuve mejor idea que adquirir una placa OpenVox G400P para conectarme a la red GSM sin buscar lo suficiente en la web antes. Mi error.
2.- Crear una rama upstream para seguir el desarrollo de Dahdi.
$ git checkout -b upstream
3.- Taggear la release específica de Dahdi en la rama upstream.
$ git tag -a dahdi-x.y.z
4.- Volver a la rama master y realizar el desarrollo del driver en la misma.
$ git checkout master
[... desarrollo...]
5.- Una vez terminada una release, taggearla.
$ git tag -a chan-extra-x.y.z
6.- Crear un parche a partir de ambas ramas (aunque sería mejor publicar el repositorio git directamente):
$ git diff upstream master > chan-extra-x.y.z.patch
Nota: hay mejores formas para obtener un parche que ésta manera... pero no es algo que haya explorado lo suficiente. Se aceptan comentarios ;)
7.- Cuando se deba desarrollar para una nueva versión de Dahdi, basta con actualizar la rama correspondiente y hacer un merge:
$ git checkout upstream
$ git rm '*'
$ git clean -xdff
$ tar zxfv ../../dahdi-x.y.z+1.tar.gz --strip=1
$ git add -A
$ git commit -m "Import upstream x.y.z+1 release."
$ git checkout master
$ git merge upstream
Luego el usuario podrá aplicar el parche usando patch y compilar. Basta con seguir el mismo workflow para crear parches para Asterisk.
Por supuesto, se aceptan comentarios sobre éste workflow :-)
Éste post también se encuentra redactado en inglés.
Instalando un servidor de telefonía IP no tuve mejor idea que adquirir una placa OpenVox G400P para conectarme a la red GSM sin buscar lo suficiente en la web antes. Mi error.
Los problemas:
- Al momento de adquirir la placa (hace apenas ~6 meses) no existía soporte oficial para Dahdi.
- Cuando el mismo apareció, resulta ser que no constaba de unos simples parches, sino un script que supone que uno usa un sistema basado en RPMs, baja y modifica las fuentes de Dahdi y Asterisk, los compila e instala, sin dejar lugar a modificaciones por parte del usuario.
- Al preguntar al soporte, me dijeron que me lo instalaban ellos mismos... si les daba acceso SSH (de no creer). Me tomé el trabajo de explicarles que pedir acceso SSH a sus clientes era una mala idea, pero me parece que no entendieron.
Desarmando el script:
Mi idea entonces fué instalar una máquina virtual con la versión de Elastix o Trixbox que ellos pedían para hacer correr el script, obtener el código fuente parcheado, revisarlo y compilarlo en mi Debian. Llegué a bajar tres versiones distintas de ésas distros... y parece ser que ninguna de ellas era la que el script esperaba. Para ese momento decidí hacer lo que debía haber hecho desde un principio: imprimir el script, desarmarlo y armar ése código fuente yo mismo.
Por supuesto, usé git para el proceso :)
El código fuente resultante:
Asterisk: http://dumbledore.com.ar/gitweb/?p=asterisk.git;a=summary (puede estar incompleto, todavía lo tengo que chequear).
En el caso de Dahdi, la rama openvox-g400p contiene las modificaciones de chan-extra, la rama oslec contiene el soporte para el cancelador de eco OSLEC. Finalmente la rama master es un merge de ambas. Todavía no probé que la placa funcione con oslec, pero está ahí porque la uso en la otra placa que tengo en el servidor.
Recomendaciones para la gente de OpenVox:
Si bien me parece excelente que quieran proveer a sus clientes de un script "automágico", un usuario de otras distribuciones y/o un usuario avanzado va a encontrar mejor que le proporcionen un patch para el código fuente. Lo bueno es que gracias a git ésto no es complicado.
Les sugiero el siguiente workflow:
1.- Descomprimir el código fuente original de Dahdi, renombrar el directorio y crear un repositorio git del mismo.
$ tar -xf dahdi-x.y.z.tar.gz
$ mv dahdi-x.y.z dahdi
$ cd dahdi
$ git init
$ git add -A
$ git commit -m "Original Dahdi source code version x.y.z."
Si bien me parece excelente que quieran proveer a sus clientes de un script "automágico", un usuario de otras distribuciones y/o un usuario avanzado va a encontrar mejor que le proporcionen un patch para el código fuente. Lo bueno es que gracias a git ésto no es complicado.
Les sugiero el siguiente workflow:
1.- Descomprimir el código fuente original de Dahdi, renombrar el directorio y crear un repositorio git del mismo.
$ tar -xf dahdi-x.y.z.tar.gz
$ mv dahdi-x.y.z dahdi
$ cd dahdi
$ git init
$ git add -A
$ git commit -m "Original Dahdi source code version x.y.z."
2.- Crear una rama upstream para seguir el desarrollo de Dahdi.
$ git checkout -b upstream
3.- Taggear la release específica de Dahdi en la rama upstream.
$ git tag -a dahdi-x.y.z
4.- Volver a la rama master y realizar el desarrollo del driver en la misma.
$ git checkout master
[... desarrollo...]
5.- Una vez terminada una release, taggearla.
$ git tag -a chan-extra-x.y.z
6.- Crear un parche a partir de ambas ramas (aunque sería mejor publicar el repositorio git directamente):
$ git diff upstream master > chan-extra-x.y.z.patch
Nota: hay mejores formas para obtener un parche que ésta manera... pero no es algo que haya explorado lo suficiente. Se aceptan comentarios ;)
7.- Cuando se deba desarrollar para una nueva versión de Dahdi, basta con actualizar la rama correspondiente y hacer un merge:
$ git checkout upstream
$ git rm '*'
$ git clean -xdff
$ tar zxfv ../../dahdi-x.y.z+1.tar.gz --strip=1
$ git add -A
$ git commit -m "Import upstream x.y.z+1 release."
$ git checkout master
$ git merge upstream
Luego el usuario podrá aplicar el parche usando patch y compilar. Basta con seguir el mismo workflow para crear parches para Asterisk.
Por supuesto, se aceptan comentarios sobre éste workflow :-)
sábado, 23 de octubre de 2010
El planeta Debian en español también está en identi.ca
Cuando ví el anuncio de Zack de que el feed de Planet Debian se estaba exportando a la cuenta @planetdebian de identi.ca, le pregunté si también iba a haber una cuenta similar para el Planeta Debian en español. Me dijo que no, pero que me sintiese libre de hacerlo yo mismo. Y eso hice :-)
Señoras y señores, con ustedes, @planetdebianes.
miércoles, 20 de octubre de 2010
Configurando la placa de sonido M-Audio Delta 1010LT por defecto
Me compré una placa M-Audio Delta 1010LT a la que quiero usar como placa por defecto. Pero las cosas ya no son como antes que bastaba desactivar la placa on board:
La primera es la placa onboard, que quiero dejar activada por el momento. La segunda, el mic de la webcam. La tercera, el HDMI de la placa de video. Y la cuarta, la M1010LT.
Y acá viene el problema: la M1010LT no es la placa por defecto, por ende algunas aplicaciones no la van a usar (¿les suena flash player?). Ya me había pasado algo similar antes (la E320SE quedaba por defecto), así que recurrí al archivo asound.conf. Mi primer intento fué:
El resultado: silencio absoluto :-( . Luego usé el script sugerido en la página de asound.conf y llegué a:
Otra vez, silencio absoluto :-/. Me cansé de buscar en la web y no encontrar soluciones. No uso pulseaudio y no sé si vale la pena usar jack. Bueno, de todas maneras las aplicaciones que usan phonon andaban bien, y para los videos podía usar los auriculares. Pero cuando uno tiene que ver un stream en vivo que dura muchas horas (¿les suena el rescate de los 33 mineros?), se hace una molestia. ¿que tal un hack rápido? Cable de audio conectado a la salida de la placa on board y en su otra punta a una de las entradas de la M1010LT. Feo, pero anda.
La "suerte" a veces ayuda.
$ cat /proc/asound/cards
0 [SB ]: HDA-Intel - HDA ATI SB
HDA ATI SB at 0xfe024000 irq 16
1 [E320SE ]: USB-Audio - Eye 320SE
PixArt Imaging Inc. Eye 320SE at usb-0000:00:13.1-2, full speed
2 [Generic ]: HDA-Intel - HD-Audio Generic
HD-Audio Generic at 0xfdffc000 irq 19
3 [M1010LT ]: ICE1712 - M Audio Delta 1010LT
M Audio Delta 1010LT at 0xbf00, irq 21
La primera es la placa onboard, que quiero dejar activada por el momento. La segunda, el mic de la webcam. La tercera, el HDMI de la placa de video. Y la cuarta, la M1010LT.
Y acá viene el problema: la M1010LT no es la placa por defecto, por ende algunas aplicaciones no la van a usar (¿les suena flash player?). Ya me había pasado algo similar antes (la E320SE quedaba por defecto), así que recurrí al archivo asound.conf. Mi primer intento fué:
pcm.!default {
type hw
card M1010LT
}
ctl.!default {
type hw
card M1010LT
}
El resultado: silencio absoluto :-( . Luego usé el script sugerido en la página de asound.conf y llegué a:
pcm.SB { type hw; card SB; }
ctl.SB { type hw; card SB; }
pcm.E320SE { type hw; card E320SE; }
ctl.E320SE { type hw; card E320SE; }
pcm.M1010LT { type hw; card M1010LT; }
ctl.M1010LT { type hw; card M1010LT; }
pcm.Generic { type hw; card Generic; }
ctl.Generic { type hw; card Generic; }
pcm.!default pcm.M1010LT
ctl.!default ctl.M1010LT
Otra vez, silencio absoluto :-/. Me cansé de buscar en la web y no encontrar soluciones. No uso pulseaudio y no sé si vale la pena usar jack. Bueno, de todas maneras las aplicaciones que usan phonon andaban bien, y para los videos podía usar los auriculares. Pero cuando uno tiene que ver un stream en vivo que dura muchas horas (¿les suena el rescate de los 33 mineros?), se hace una molestia. ¿que tal un hack rápido? Cable de audio conectado a la salida de la placa on board y en su otra punta a una de las entradas de la M1010LT. Feo, pero anda.
La "suerte" a veces ayuda.
Ayer, siguiendo un link en la web, dí con unos videos en You Tube. Me puse los auriculares, apreté play y... el sonido salía por los parlantes :S. Un cat /proc/asound/cards me decía que la M1010LT estaba como placa 0. Bien, entonces era posible usarla por defecto, mas allá de que no lo haya logrado con asound.conf. Buscando en la web un poco mas de información sobre toda la que ya busqué, dí con una página donde explican como setear los módulos de las placas restantes como placa 1 (o lo que siga por defecto). No es la solución, pero al menos es mas prolija que el cable externo :-)
Por supuesto, lo mejor sería solucionarlo desde asound.conf, pero no lo he logrado aún :-/ . Por cierto, uso Debian.
Actualización 20101025 00:21 ARST: parece ser que la cosa no termina ahí. Como puse en un comentario mas abajo, tuve que modificar /etc/modprobe.d/alsa-base.conf. Y encima empecé a dar con un bug: la placa no siempre se detecta al arrancar el sistema. Así que finalmente hice ésto en el citado archivo:
# Options for the M1010LT.
alias snd-card-0 snd-ice1712
options snd-ice1712 model=delta1010lt index=0
Y si la placa no es detectada, basta ejecutar alsa force-reload como root.
martes, 14 de septiembre de 2010
Ensalada con riñón de vaca
Mi mamá dice que, en lo que a comidas se refiere, de lo que hay le pongo. Y tiene razón. Hoy salimos de compras con mi novia y mientras ella compraba carnes, dí con un paquetito de riñón de vaca. "Excelente para hacerlos salteados en una ensalada" pensé. Y eso salió :-)
Con ustedes, una mitad de nuestro invitado especial:
La otra mitad ya estaba en la sartén:
Por supuesto, una ensalada no se puede hacer solo con riñón. Por eso incorporamos algunos ingredientes mas:
La lista completa:
El resultado final:
Espero que no me caiga tan pesado como a éste morocho ;-)
Con ustedes, una mitad de nuestro invitado especial:
La mitad de un riñón de vaca. cc-by-sa 3.0.
La otra mitad ya estaba en la sartén:
Riñones en la sartén. cc-by-sa 3.0.
Por supuesto, una ensalada no se puede hacer solo con riñón. Por eso incorporamos algunos ingredientes mas:
Algunos ingredientes mas para la ensalada. cc-by-sa 3.0.
La lista completa:
- Zanahoria.
- Lechuga.
- Atún al natural.
- Arvejas (de las congeladas y no en conserva, las conocí gracias a mi novia).
- Aceitunas negras.
- Granos de choclo amarillo.
- Ajo granulado.
- Perejil disecado.
- Pimienta.
- Aceite de oliva.
El resultado final:
Ensalada de rinón de vaca completa. cc-by-sa 3.0.
Espero que no me caiga tan pesado como a éste morocho ;-)
jueves, 9 de septiembre de 2010
Paquetes semi oficiales de KDE SC 4.5.1
George Kiagiadakis envió un correo a la lista debian-kde anunciando paquetes semi-oficiales de KDE SC 4.5.1, los que se encuentran disponibles en http://qt-kde.debian.net/.
Algunos detalles mas del correo:
"Desafortunadamente no todos los paquetes están listos, por lo que puede que noten algunos faltantes. Los paquetes fuentes faltantes hasta el momento son kdeaccessibility, kdeadmin, kdegames, kdemultimedia, kdebindings, kdetoys, kdewebdev y kde-l10n como también meta-kde (el paquete kde-standard y misceláneos). A pesar de ésto pueden actualizar todo lo demás a partir de su instalación de KDE SC 4.4.5 usando las instrucciones del sitio (en inglés).
Una vez que todos los paquetes estén preparados y funcionando, planeamos liberarlos a Debian experimental. Hasta que eso ocurra, todas las actualizaciones o paquetes nuevos irán a ése repositorio.
Pedimos disculpas for el largo retrazo desde que 4.5.0 fué liberado, pero espero que entiendan las razones detrás de ésto (preparando a Squeeze para que esté listo, trabajo, vida real, vacaciones de verano, pocas personas activas en el equipo, etc...).
A toda la gente que se ofreció para ayudar: apreciamos su oferta y pedimos disculpas por la falta de documentación acorde. Empaquetar KDE SC no es una tarea fácil y normalmente le recomendamos a los recién llegados que intenten empaquetar algo mas chico primero, como algo de kde-apps.org. Intentaremos hacer las cosas mejores en el futuro, documentando mejor nuestro flujo de trabajo y políticas. Si aún quieren ayudar, como pueden ver, todavía hay trabajo por hacer. Además de empaquetar, hay otras cosas que pueden hacer, como actualizar archivos de copyright (lo que encuentro fácil, pero consume mucho tiempo).
Los mejores deseos,
George
PS: Por favor lean bien las instrucciones y por favor reporten los bugs de empaquetamiento aquí (n. del e.: en la lista debian-kde) y en irc, pero no en el sistema de seguimiento de bugs de Debian. Gracias por adelantado".
Particularmente nunca me pude dar el gusto de compilar KDE SC por mi mismo. Lo intenté un par de veces, pero mi peor enemigo es el tiempo. Y mantener paquetes para Debian tiene que ser un gusto y no una carga. Por eso encuentro la sugerencia de George de empaquetar cosas de kde-apps.org muy adecuada, en especial para los que tenemos poco tiempo ;-) ya que suelen ser programas de menor complejidad de empaquetado.
Por otro lado, si bien estoy lejos de tener muchos conceptos claros, en breve me voy a juntar con unos amigos a enseñarles a empaquetar software. Con un poco de suerte vamos a mantener una serie de paquetes, muy posiblemente relacionados con la electrónica. Espero poder generar sinergia suficiente para que ésto se expanda :-)
Ah, cabe aclarar que gran parte del trabajo para creaer los paquetes de KDE SC 4.5.1 fué realizado por George (o al menos eso tengo entendido) ¡Gracias George!
Suscribirse a:
Entradas (Atom)
