Since a long ago I'm looking for a media player for listening my music. In that aspect I'm really exigent. Is not that I need lots of plugins and eye candy, no, I just need a media player that fits my way to listen music.

How do I listen to music? All day long, for starters. I have a collection of .ogg files, which I normally listen in random mode. From time to time I want to listen certain song, so I either queue it or simply stop the current one and start the one I want. Sometimes I enqueue several songs, which might not be related between them (maybe only in my head they are).

I've been using Amarok, I really like its random albums feature; that is, I listen to a whole album, and when it finishes, another album is picked at random and I listen to all its songs. The last feature, a really important one: My collection is my playlist and viceversa. I don't build playlists; if I want to listen to certain songs I just queue them. One feature I like also is a tag editor and the posibility to rearrange the songs based on its tags (with support for albums with songs from various authors, like OST's). Last but no least, reacting to new files in the collection is also well regarded.

I used to use xmms. I still think it's a very good player for me, but it lacks utf support and doesn't react when I add songs to the collection. Then I used Amarok, Juk, QuodLibet, Audacious (I was using it up to today) and probably a couple more. None of them support all the features, so today, completely tired of this situation, I started writing my own. I called it Satyr. Another reason to do it is to play a little more with PyKDE. Talking about Python and KDE, I know the existence of minirok, but it uses GStreamer, and I wanted to play with Phonon.

So, what's different in this media player? If you think about it, if you have a CD (vinyl, cassettes maybe?) collection in your home, what you have is exactly that: a collection of Albums. Most media players manage Songs, grouping them in Albums and by Author too. Notably Amarok used to manage Albums with several artists (what's called a 'Various artists' Album), but since Amarok 2 it doesn't do it anymore, nor the queuing works. So the basic idea is exactly that: you have a Collection of Albums, most of them with songs from the same Author (and sometimes Featuring some other Authors[1]), but sometimes with Songs from different Authors. Of course I will try to implement all the features I mentioned above.

Ok, enough introduction. This post was aimed to show some code, and that's what I'm going to do now. This afternoon I was testing the Phonon Python bindings, trying to make a script to play a simple file. This snippet works:

# qt/kde related
from <span class="createlink">PyKDE4</span>.kdecore import KCmdLineArgs, KAboutData, i18n, ki18n
from <span class="createlink">PyKDE4</span>.kdeui import KApplication
# from <span class="createlink">PyKDE4</span>.phonon import Phonon
from <span class="createlink">PyQt4</span>.phonon import Phonon
from <span class="createlink">PyQt4</span>.QtCore import SIGNAL

media= Phonon.MediaObject ()
ao= Phonon.AudioOutput (Phonon.MusicCategory, app)
print ao.outputDevice ().name ()
Phonon.createPath (media, ao)
media.setCurrentSource (Phonon.MediaSource ("/home/mdione/test.ogg")
media.play ()

app.connect (media, SIGNAL("finished ()"), app.quit)
app.exec_ ()

Of course, this must be preceded by the bureaucratic creation of a KApplication, but it basically plays an ogg file and quits. You just have to define a MediaObject as the source, an AudioOutput as the sink, and then you createPath between them. As you can see, with Phonon you don't even have to worry about where the output will be going: that is defined by the system/user configuration. You only have to declare that your AudioOutput is going to play Music (the second actual line of code).

There are a couple of peculiarities with the Python bindings. First of all, Phonon comes both with Qt and separately. The separate one has a binding in the PyKDE4 package, but it seems that it doesn't work very well, so I used the PyQt binding. For that, I had to install the python-pyqt4-phonon package. Second, the bindings don't support to call setCurrentSource() with a string; you have to wrap it in a MediaSource. The original API supports it. Third, it seems that Phonon.createPlayer() is not supported by the bindings either, so I had to build the AudioOutput by hand. I don't care, it's just a couple lines more.

This code also shows the name of the selected OutputDevice. I my machine it shows HDA Intel (STAC92xx Analog).

In the following days I'll be posting more info about what comes out of this project. I will only reveal that right now the code has classes called Player, PlayList and Collection. It can scan a Collection from a path given in the command line and play all the files found there. Soon more features will come.

python pykde satyr


[1] I'm not planing to do anything about it... yet.

Posted Wed 27 Jan 2010 11:55:55 PM CET Tags:

Heme aquí otra vez, tratando de dar el último paso en darle hosting a humitos, que vendría a ser, dar acceso a subversion por https. Actualmente tenemos acceso anónimo y acceso por ssh, pero el primero no tiene autenticación, por lo que no permite commits, y para acceder al segundo requiere un user en mi server. Éste no deja de ser mi server privado y no me gusta la idea de abrir cuentas a troche y moche.

Prender https fue faćil, aunque lo puse en el puerto 4433, porque en el 443 tengo el ssh. El motivo es medio largo de explicar. Cabía la posibilidad de poner algún programa que me permita tener los dos servicios en el mismo puerto, pero el más maduro que ví decía ser una implementación muy chapucera.

Poner dav y dav-svn a andar es una pavada. Todo está explicado en el libro de subversion. El problema saltó cuando ví los repos de humitos. Este chango tiene bastantes proyectitos chicos puestos en disco de una forma que justo queda incómodo de usar con esto.

Resulta que los paths son de la pinta /home/humitos/proyectos/<proy>/svn. Las directivas que tengo que poner en la configuración de apache son de la pinta:

<Location /~humitos/svn/<proy>>
  DAV svn
  SVNPath /home/humitos/proyectos/<proy>/svn
</Location>

Al día de hoy cuento 15 proyectos. Se me ocurrió que tal vez s podría hacer con un LocationMatch, as in:

<LocationMatch ^/(~|%2f|%2F)humitos/svn/([^/]*)/(.*)$>
DAV         svn
    SVNPath     /home/humitos/projects/$2/svn/$3
</LocationMatch>

El primer match es porque en distintas circunstancias el ~ es enviado en alguna de esas tres formas por los navegadores, y no se desescapan antes de ser procesados por Apache. Lamentablemente no hay nada en la documentación de Apache que diga que se puedan usar el $2 y el $3 de esa forma, cosa que me confirmaron en el canar #apache en freenode. También existe la directiva SVNParentPath, pero serviría sólo si los path fueran de la pinta /home/humitos/proyectos/<proy>/svn.

Así que al fin y al cabo, no me quedó otra más que poner todo en un mismo archivo, darle permiso a humitos para escribir en él, y darle sudo pare reiniciar el Apache.

sysadmin apache subversion

Posted Wed 27 Jan 2010 11:55:55 PM CET Tags:

En marzo del 2007 estaba yo en un limbo laboral. Estaba recién vuelto de un viaje infructuoso por Europa, en el que no había conseguido trabajo y me había gastado todos los ahorros salvo USD200, y terminando un laburo horrible con un WordPress. Había alcanzado a volver a ahorrar unos mangos pero estaba de nuevo en un depto y esa guita iba a desaparecer rápidamente si no conseguía algo estable. Y aún desesperado como pude haber estado, tenía una cosa muy clara: quería entrar a laburar en Except.

Los motivos eran múltiples: muchos amigos míos ya laburaban en ella, sabía que la gente que laburaba allí no estaba muy estresada, que eran flexibles en los horarios y en la vestimenta (cuenta la leyenda que uno de los jefes alguna vez fue a visitar a un cliente en ojotas), se trabajaba en Software Libre, eran responsables con sus empleados, sus clientes y sus proveedores y muchos detalles menores que con suerte iré contando en este post.

Recuerdo que la entrevista fue por IRC, me la hizo John en unos pocos minutos. Recuerdo el 28 de Marzo que fui por primera vez a trabajar, a pesar que mi legajo decía el 1 de Abril; realmente estaba ansioso. Ese día y toda esa semana el Javi Mansilla estuvo contandome de cómo se movía la empresa, mientras Perrito me pasaba la posta de SysAdmin. No recuerdo cuál fue mi primer tarea, pero estoy seguro que la hice con toda el alma puesta en ella.

Muchas cosas pasaron dentro de esa empresa, algunas buenas, otras malas. Recuerdo la época en la que hacía una especie de chiste de que era el janitor de la misma, pues me tocaban un montón de laburos no técnicos como colgar percheros, cambiar cueritos de canillas, perseguir carpinteros y otros detalles.

Recuerdo que mi primer quilombo grande fue cuando quisimos cambiar el hardware del servidor, no funcionó de una, y luego el RAID no quiso andar. Estuve un par de días restaurando los datos a mano. Luego de un segundo intento el hw fallaba misteriosamente.

Recuerdo mi primer laburo para afuera, una empresa a la que se le había caído un servidor RedHat del año del ñaupa y el departamente de IT estaba en Buenos Aires. Recuerdo los viajes a Agua de Oro para ajustar detalles con un servidor en la cooperativa. También trabjar remotamente contra otros servers en sendas cooperativas en Cañada Rosquín y Carlos Pellegrini, Santa Fe.

Ufff, sanitizar el LDAP, poner scripts de backup que funcionaran, instalar varios puestos de trabajo nuevos, pues la empresa crecía rápido, hacer upgrades masivos de release de Ubuntu, sanitizar la configuración de Apache, renegar con Cups y Ubuntu, y tantas, tantas otras tareas mínimas.

Recuerdo la crudeza del invierno en esta oficina nueva que nos obligó a usar mantas de polar y guantes; a comprar leña para el hogar, pues lo único que había para calentarnos era un calefactorcito diminuto en uno de los pasillos y una estufita de cuarzo; convertirme en Jesús del Fuego por esto mismo. Recuerdo la dureza del verano, todos laburando en lompas cortos y sentados en la punta de la silla; la muerte de dos ventiladores.

Recuerdo los comidas comunitarias, en particular la lasagna de Perrito, los ñoquis para su cumple, unos cuantos asados hechos por mí y por él. Recuerdo el día que llegaron los escritorios nuevos, ergonómicos y con alzada para monitor a medida, para Laura y para mí. Recuerdo los PyWeeks de Corp y Ventus Virginis, y hasta el último, en el que al final no producimos nada. PyCamp, una fantástica iniciativa de Except que llevó 24 geeks a Los Cocos y que el año que viene se va a repetir. Las cervecitas los viernes a la tarde, algún que otro vino en los almuerzos, los postres de La Postrería por cualquier excusa. Los concursos literarios, los refuerzos positivos de Waldo y luego Perrito, el juego de rol truncado, los Teg y otros juegos de mesa y por red. Recuerdo las tarjetas de presentación de cada uno, en las que en vez de hablar de puestos como "Administrador de Sistemas" o "Desarrllador", nos inventamos nuestras propias carreras; yo en mi carrera a ser Shogun estaba en la etapa de [ 浪人 - ronin ]. Recuerdo los hackergotchi que nos hizo Laura para la entonces nueva versión del sitio, y que muchos adoptamos para todo tipo de representación de nosotros mismos.

Recuerdo toda la gente que pasó por la oficina: Ra que se fue, toda una sorpresa para los que quedamos; la llegada y luego partida de Marcos Espontón, su reemplazo, que me volvía loco con Quique Iglesias y Luis Miguel y que compartía con Perrito su gusto casi morboso por Sergio Denis; el Pablo Moisset, que hacía experimentos con cohetes y unos postres de la hostia; Martín Gaitán, el pasante que le apretó las tuercas a Beppo y lo liberó.

Recuerdo Xarope, un proyecto con el que pensábamos abrir el mercado de hosting de Zope/Plone, una de las tecnologías que más dominábamos, con el cual aprendí mucho de Xen y muchas cosas de redes. Recuerdo dar una charla del proyecto en la 7JRSL, y que tuvo muy buena aceptación. Recuerdo que entramos en un programa de financiamiento del gobierno con el cual pensábamos ponerle mas pila al proyecto. Lamentablemente el programa requería que Except hiciera una inversión que no pudo hacer. Recuerdo cuando casi me voy a Sudáfrica a hacer una capacitación con unos ya casi casi clientes, pero que luego compraron indios por la tercera parte del presupuesto que nosotros les pasamos.

Luego los golpes duros. Ra ya se había ido hace rato ya, y entonces le tocó a Laura, mi entonces compañera de oficina. Poco tiempo mas tarde otra noticia bomba: John, el que todos considerábamos el padre de todos nosotros dentro de la empresa, luego de varios intentos de no llegar a un extremo tal, dejaba de trabajar en apenas un mes. Pero el resto de los jefes nos dieron un mensaje claro: "Except sigue", y eso es lo que ocurrió. Vinieron clientes de Holanda a conocer a Anthony y a mi, pues hacía ya varios meses que venía haciendo laburos de SysAdmin para ellos en forma regular. Inclusive cuando se fue ya teníamos planteado un proyecto de migración de servidores. Except seguía.

Entonces Anthony también decidió irse. Daniel y Javi, los dos socios que quedaban, tiraron la toalla: "A partir del 31 de Diciembre Except va a cerrar". Yo no voy a explicar los motivos de esto, no me toca a mí decirlo. Sólo voy a aclarar que no es consecuencia directa de la partida de los Lenton.

Revuelo. Desazón. Incertidumbre. Tristeza.

Este último mes y piquito nos hemos dedicado a seguir laburando como se podía y en lo que se podía. Al mismo tiempo estuvimos catalogando, poniendo precio y vendiendo todo el activo de la empresa: máquinas, escritorios, hasta el rallador de queso. A mi también me tocó desarmar la red, destruir los discos de las máquinas a medida que las vendíamos, apagar el servidor... Duro, muy duro.

Para terminar, voy a decir que hay futuro. Capaz no es la última vez que escuchan hablar de un proyecto llamado Except, un proyecto donde es un placer trabajar, donde la gente involucrada tiene una visión de cómo se tiene que hacer las cosas: tratar bien al cliente, tratar bien al empleado, tratar bien al proveedor, hacer Software Libre, tener un ámbito de trabajo donde el empleado es una persona y no un recurso, donde las cosas se hacen bien. Capaz yo esté en ese proyecto otra vez, capaz no, pero de lo que estoy seguro es que siempre querré estar en él como hace casi dos años.

Dani, Javi, Waldo, Perrito, Paula, Ale, Nati, Mati, Fran, Germán, Rafa, Antony, John, Laura, Pablo, Marcos, Martín, Ra, ha sido un placer trabajar con todos ustedes, aún con mi mal humor y los roces, pero también con mis TMI y la increíble buena onda que le ponen, todas las cosas que pasamos juntos... Todos estos recuerdos que menciono muy capaz los olvide, como seguro ya me he olvidado de muchas cosas, pero nunca los voy a olvidar a ustedes ni a este proyecto. Fue excelente mientras duró y espero que se repita.


PD: Carlitox también trabajó en Except, pero se fue muy poco antes de que yo entrara.

Posted Wed 27 Jan 2010 11:55:55 PM CET

Hoy me tocó hacer una negrada marca cañón. Resulta que tenemos un Xarope andando. En la arquitectura de Xarope tenemos un Apache que nos hace de frontend a todos los sitios Zope que corren en los DomU's.

El tema es que estaba poniendo a andar en uno de los DomU's un repo Mercurial, el cual corre detrás de un lighty. Ponerlo a andar no fue muy duro, salvo que no sabía mucho ni de uno ni del otro. Cuestión que llegué al punto en que podía hacer un hg clone para bajarme una copia del repo, mas no hacer un push. Acá es donde se ponía peluda la cosa.

El problema es el siguiente: para que las passwds no anden volando en cueros tenía que poder acceder al repo por https. Ahora, repiensen el esquema: tengo un Apache al que le llegan los pedidos https, el que a través de un Rewrite forwardea el pedido al Lighttpd corriendo en otra máquina (virtual, pero no viene al caso). Por razones casi obvias forwardear de un 443 a un 443 no anda. ¡Pero resulta que si el forward es al 80 si!

Es decir, el Apache recibe https, y cuando forwardea el pedido, lo hace en http plano. Esto responde a mi pregunta "¿Comocatzo vamos a hacer cuando los usuarios de Zope pidan acceso por https?". La única contra que le veo a este setup es que el sitio final (sea un Zope o un repo Mercurial) no sabe si el acceso viene con SSL o no.

sysadmin lighttpd apache ssl mercurial xarope

Posted Wed 27 Jan 2010 11:55:55 PM CET Tags:

anoche puse a andar un trac para kreissy. una de las cosas que dejé colgando fue que el trac quedó abierto como... bueno, apelen a su imaginación para terminar esa frase. esa misma noche humitos dejó su impronta, cosa que no me molesta, pero marca que esto no puede quedar así. so, a poner auth.

trac delega todo el sistema de autenticación en apache, así que es lo mismo que poner a andar tal cosa. apache tiene muy buena doc9n[1] al respecto. el desafío es hacerlo andar desde un .htpasswd.

pero, no se puede poner un bloque en un .htpasswd, lo cual imposibilita la empresa. y esto, ahora recuerdo, es lo que lo hizo imposible antes. así que no queda otra que recurrir a la configuración global de apache y dejarnos de joder.

al final el archivo /etc/apache2/sites-available/trac-kreissy quedó:

<Location /~mdione/projects/kreissy>
    <span class="createlink">SetHandler</span> mod_python
    <span class="createlink">PythonHandler</span> trac.web.modpython_frontend
<span class="createlink">PythonOption</span> <span class="createlink">TracEnv</span> /home/mdione/src/projects/kreissy/trac
    <span class="createlink">PythonOption</span> <span class="createlink">TracUriRoot</span> /~mdione/projects/kreissy
</Location>

# auth
<Location /~mdione/projects/kreissy/login>
<span class="createlink">AuthType</span> Basic
    <span class="createlink">AuthName</span> "kReiSSy-trac"
<span class="createlink">AuthUserFile</span> /home/mdione/src/projects/kreissy/trac/htpasswd
    Require valid-user
</Location>

luego agregamos el sitio como enabled y reiniciamos apache:

$ sudo a2ensite trac-kreissy
Site trac-kreissy installed; run /etc/init.d/apache2 reload to enable.
$ sudo /etc/init.d/apache2 reload

c'est tout! luego configuro el trac con trac-admin y listo.

sysadmin trac apache

[1] documentación.

Posted Wed 27 Jan 2010 11:55:55 PM CET Tags:

Siguiendo el post anterior, y en particular con bazaar, un par de links más.

Empecemos por el hecho de que bazaar acaba de lanzar su versión 1.0. Notable que entonces yo encuentre esto:

$ dpkg -l bazaar
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name    Version    Description
+++-=======-==========-========================================================
ii  bazaar  1.4.2-5.3  arch-based distributed revision control system

La explicación según la comunidad:

14:56 < <span class="createlink">StucKman</span>> is debian's version numbering wrong?
14:57 < <span class="createlink">MattCampbell</span>> The package name is bzr
14:58 < sabdfl> <span class="createlink">StucKman</span>: bzr was bazaar-ng
14:59 < sabdfl> there was a project called tla
14:59 < sabdfl> some folks at canonical had a branch of that, which they called bazaar
14:59 < sabdfl> that's what you are looking at v1.4.2 of
15:00 < sabdfl> bzr was a skunkworks, from scratch clean set of ideas
15:00 < sabdfl> and when most of the canonical guys embraced that, they brought the name along

Del sitio de bazaar, recomiendo el minitutorial, un pdf con una quick reference, obviamente la extensa documentación, y muy particularmente los workflows.

Por último, acá hay un link de cómo usar bazaar para administrar /etc, el cual al momento de escribir este post parece estar caído.

bazaar

Posted Wed 27 Jan 2010 11:55:55 PM CET Tags:

Yo sabía que tener un serven en Debian Sid es una lotería, pero como no me anduvo volver a poner a andar mi instancia Xen con Debian Etch, bueno, acá estamos.

Cuestión que hoy hice una actualización de los paquetes, cosas que hago una vez por semana, y resulta que ahora mis tracs no andan. Revisando los logs de Apache veo backtraces que terminan en:

<span class="createlink">ValueError</span>: database parameter must be string or APSW Connection object

Buscando encontré que es un bug en Debian. Ahora, resulta que estoy usando apt-listbugs, que te muestra los bugs reportados de los paquetes que van a ser instalados/actualizados antes de que lo sean, de forma que puedas decidir si lo querés hacer o no. Recuerdo haber visto el bug en la lista e ignorarlo, cosa que fue mi perdición.

Según la lista trac-users, una forma de soplucionarlo es volver a la versión anterior de python-pysqlite2. ¿Y cuál era la versión anterior? Bueno, eso lo puede responder el log de la actualización, /var/log/apt/term.log:

Preparing to replace python-pysqlite2 2.3.5-1 (using .../python-pysqlite2\_2.4.0-1\_i386.deb) ...

Fantástico. Por suerte justo esa versión fué migrada a Lenny hace poco; sino, habría que haber buscado un mirror que no actualizara muy seguido. Además, parece que el bug ya está reparado por la nueva versión del paquete. Así que simplemente me bajé la 2.4.0-2 y la instalé con dpkg -i. ¡Listo!

¿Listo? I wish. El trac que estaba revisando quedó sin css y otras cosas. De los logs de Apache:

GET /~mdione/projects/kreissy/chrome/common/css/trac.css HTTP/1.1" 500

Internal Server Error. Now what? ¡Seguimos en la misma!:

<span class="createlink">ValueError</span>: database parameter must be string or APSW Connection object, referer: http://grulicueva.homelinux.net/~mdione/projects/kreissy/

Ok, tons vamos patrás. Instalo 2.3.5-1 y... ¡tampoco! Same shit... ¿No me olvido de algo? ¡Sí, de reiniciar Apache! Reinicio, y allí está mi querido trac, vivito y coleando.


PD: Ustedes tal vez se preguntarán "¿Este pibe piensa globear todo lo que le pase en Sid?". La respuesta es: espero que no. Only time will tell. Supongo que será hasta que descubra qué está bueno y qué no.

sysadmin debian

Posted Wed 27 Jan 2010 11:55:55 PM CET Tags:

El otro día dí una charlita un poquito larga de ssh/scp y screen en el IATE, el lugar donde laburo. En la misma hablo de ssh/scp básico, mas cómo poner claves públicas/privadas y cómo usar el ssh-agent para administrarlas (algo de lo que ya hablé en este glob), mas otros temas como el X11 forwarding y el agent-forwarding. Además hablé de screen, una herramineta que se complementa muy bien con ssh. Dejo las filminas acá.

security utils

Posted Wed 27 Jan 2010 11:55:55 PM CET Tags:

Antes que nada, feliz año para todos. Que este año no nos muramos de calor y de frío ni de hambre.

Desde hace unos meses que me anda dando vueltas por la cabeza una idea, y es la de armar máquinas baratas y chicas. Con chicas me refiero tanto a micros de potencia moderada como a de tamaño físico reducido. En la medidda de lo posible que tampoco requieran de muchas partes móviles, es decir, que sobrevivan sin un ventilador dedicado para el micro, a lo sumo un ventilador para toda la computadora.

¿Con qué objetivo? Tengo dos en mente: servidores hogareños y/o para pymes (esto último basado en la idea del PyMO Server y para estaciones de trabajo que no requieran grandes cantidades de procesamiento, como para una oficina o una casa donde no se juegue mucho.

El primer paso para lograr fue buscar placas madres chicas y con micros de ~1GHz. Hay bastante oferta de esto, tanto en formato Mini-ITX como Micro-ATX, con micros yendo de los 800MHz a los 1.5GHz, algunos de ellos fanless. Pero pareciera que esos bichos no llegaron a la Argentina, ni siquiera a ésa que está toda concentrada en los 3.833 km² que se denomina comoo el AGBA. Me pasé toda una tarde bajando y subiendo por la Galería Jardín en busca tanto de estas plaquitas como de fuentes y gabinetes chicos. Lo único que encontré es un local en el que mostraban unas Albatron KI690AM2, pero que no vendían al por menor, sino que trataban de engancharte como distribuidor. Viéndola en restrospectiva, me doy cuenta que menos mal, pues necesita memorias en formato SO-DIMM, que suelen ser más caras. Gabinetes encontré unos aún muy grandes para mi gusto.

Con la cola entre las patas, volvía a mi querida ciudad y casi que me olvidé del tema. Pero entonces una tarde me llamó perrito diciéndome que había visto una plaquita Intel a cuadras de la oficina y que estaba a meros USD100. Fui casi corriendo a verla. La plaquita viene con un micro Celeron de 1.3GHz que tiene un disipador no muy grande y un ventiladorcito que tiene toda la pinta de ser sacable. Las únicas desventajas que le veo son que tiene un solo slot de memoria, una sola boca PATA y nunguna SATA, y el chipset es SiS y no Intel. El modelo GLY2/GLY2A ya viene con dos bocasa SATA. Menciono esto como desventaja porque ya casi no se consiguen discos PATA en el mercado local. Lo que se pueden conseguir son conversores SATA/PATA o cajas para discos USB. También tiene un slot PCI para poner una segunda NIC y hacer de server de internet y con un dongle USB se le puede poner wireless.

Tardé 4 días en animarme y me la compré nomás, junto con 512MiB de RAM y una fuente de 400W. Saqué mi disco de 120GiB con un Debian Sid y se lo puse. A falta de gabinete tuve que armarla "en el aire", y también a modo de prueba, la armé en la tapa de una caja de zapatos. Esto demuestra que con un poco de habilidad se la puede meter en un gabinete realmente chico.

El bicho en un momento hasta booteó un Kubuntu 6.06 Live sin dramas, y en general siento que para el rol de servidorcito chico anda muy bien. Como competencia de sistemas de escritorio es más difícil, pues aproximadamente por la misma plata se puede uno comparar una máquina con mobo Biostar (puaj!) y un AMD Sempron 1100 de nosecuántos GHz. Si bien la mobo no va a ser de la misma calidad, la gente que compra máquinas para su casa le dá lo mismo lo uno o lo otro; el que decide es el bolsillo. Por otro lado no olvidemos que chipset SiS o no, no deja de ser una mobo marca Intel, y la máquina más chica Intel que pude conseguir sale más del doble (ARS700; mobo Intel D946 + micro Celeron 420 de 1.6GHz).

El costo total del proyecto hasta ahora es de ARS400 (300 la mobo, 50 y 50 de RAM y fuente). Revolviendo mucho MercadoLibre y DeRemate encontré la serie CM9x de gabinetes de pequeño porte (34x34x14 cm) de Biswal, y como muy baratos los encuentro en USD50. Terminando el experimento cabrían uno o dos discos nuevos, que salen unos ARS200 cada uno. El layout actual lo pueden ver en esta foto, junto con el servidor de correo de Vía Libre, un Linksys con OpenWRT y el modem Cisco 575 LRE que entrega I-Plan.

cobra

Posted Wed 27 Jan 2010 11:55:55 PM CET Tags:

Estoy organizado un code jam en Córdoba y Lisandro está organizando una en Bahía Blanca. La idea es que nos juntemos a laburar un poco en KDE, aprendiendo y haciendo o features o cerrando bugs o lo que sea. En función de eso estaría piola que cada uno ya lleve un kde trunk compiladito, al menos la parte que les interese. Este post apunta a explicar cómo hacerlo. Casi toda la info la saqué en su momento de techbase y/o preguntando en IRC, listas de correo y hasta en DebConf.

Veamos cómo se organiza el código de KDE. Éste reside en un repositorio subversion que tiene dos formas de acceso: uno autenticado por ssh para los desarrolladores que tienen cuenta y uno anónimo que es de sólo lectura. Los que ya tienen cuenta ya deberían saber usarlo y hasta cómo compilar, así que para ellos este post no sirve. Cuando mencioné a trunk en el párrafo anterior me refería a la rama principal de este repo.

A su vez el código está diseminado en distintos módulos: kdesupport, kdelibs, kdepimlibs, kdebase, etc. Estos módulos y otras porciones de código que andan dando vueltas están en un árbol:

anonsvn.kde.org/home/kde/
+ branches
| + ...
+ tags
| + ...
+ trunk
  + extragear
  | + ...
  + kdereview
  | + ...
  + playground
  | + ...
  + kdesupport
  | + ...
  + qt-copy
  + KDE
    + kdebase
    + kdegraphics
    + kdelibs
    + kdemultimedia
    + kdenetwork
    + kdepim
    + kdepimlibs
    + ...

Pueden ver este mismo árbol por web. La rama KDE es la que tiene el código de los distintos módulos de KDE. kdesupport contiene un montón de software que no es de KDE, pero que es necesario para correrlo. Allí van a encontrar las versiones adecuadas de los mismos, y por lo general es muy aconsejable compilarlo. qt-copy es una copia del código de Qt a su última versión, con el agregado de varios parches. kdereview son proyectos que están siendo considerados para la inclusión en KDE. playground está llenos de proyectos a medias o casi completos, pero que no tienen pinta de estar listos para revisión. Los nuevos proyectos normalmente nacen y/o crecen allí. Sin embargo, mucho de lo que hay ahí funciona. Por último, extragear contiene aplicaciones KDE que no se ajustan al ciclo de desarrollo de KDE (actualemnte, un release menor cada 6 meses). En este directorio podemos encontrar aplicaciones grosas como el amarok, el k3b o el digikam.

Una instalación mínima de KDE consta de los módulos qt-copy, kdesupport, kdelibs, kdepimlibs y kdebase. Compilarlos uno por uno es un garrón, por lo que vamos a usar kdesvn-build, un script que lo automatiza todo. Pero antes, las dependencias.

Por un lado necesitamos las herramientas de configuración y de compiloación. Éstas son cmake y g++ (en realidad es cualquier compilador de C++, pero para hacerla fácil me voy a limitar a g++. También me voy a limitar a distros basadas en Debian, como *buntu, sólo porque es lo que más conozco.). El cmake de Debian Sid es el 2.6.0 y desde hace un rato KDE necesita el 2.6.2 [ Update: 2.6.2 acaba de entrar en Sid ], así que capaz haya que bajar y compilar ése también. Si lo hacen, les aconsejo que corran el configure con la opción --prefix=/usr/local o mejor, apuntando a algún lado de su propio home. En mi caso, instalé todo en ~/local/soft/kde4.

Luego están las dependencias de cada módulo per se. La siguiente es una tabla que he ido creando con el tiempo y que trata de ser tan completa como pude, pero seguro se me ha escapado más de un paquete. Los nombres corresponden a los de los paquetes en Debian Sid, y que deben ser muy similares a los de los *buntu. En cada módulo encontramos dos grupos de dependencias: las estrictamente necesarias, sin las cuales el módulo no compila, seguido de una línea en blanco, seguida por otra lista con las dependencias opcionales. Estas dependencias hacen que el módulo ofrezca más funcionalidad. Yo puse las que me interesan; después veremos cómo ver qué otras son posibles.

cmake:
~~~~~~
libncurses5-dev

qt-copy:
~~~~~~~~
libssl-dev
libpng12-dev
zlib1g-dev
libsqlite3-dev
libxinerama-dev
libdbus-1-dev
libjpeg62-dev

libsm-dev

kdesupport:
~~~~~~~~~~~
cmake
mysql
libclucene-dev
doxygen
dotty
librdf0-dev
libbz2-dev
libxml2-dev
libexiv2-dev

libgstreamer0.10-dev
libgstreamer-plugins-base0.10-dev
libgl1-mesa-dev
libgamin-dev
sun-java6-jdk

kdelibs:
~~~~~~~~
libsm-dev
libpcre3-dev
libgif-dev
libxrender-dev
libglu1-mesa-dev

libopenexr-dev
libenchant-dev
libgamin-dev

kdepimlibs
~~~~~~~~~~
libical-dev
libgpg-error-dev
libgpgme11-dev
libboost-dev
libsasl2-dev

kdebase
~~~~~~~
libfontconfig1-dev
libxt-dev
libsensors4-dev
libxklavier12-dev
libusb-1.0-0-dev
libxcomposite-dev
libxdamage-dev
libxtst-dev
libusb++-dev
libasound2-dev
libxss-dev
libxft-dev
libxkbfile-dev

kdemultimedia
~~~~~~~~~~~~~

libvorbis-dev
libcdparanoia0-dev
libxine-dev

kdegraphics
~~~~~~~~~~~
liblcms1-dev

libgphoto2-2-dev
libxxf86vm-dev
libimlib2-dev

kdepim
~~~~~~

libopensync0-dev
libpisock-dev

extragear
~~~~~~~~~
libjasper-dev

kdenetwork
~~~~~~~~~~
libavahi-compat-libdnssd-dev

Muchas, eh? Y éstos son sólo algunos de los módulos.

Ah! Antes de que nos mandemos a compilar, tenemos que preparar tres cosas: un directorio donde van a ir las fuentes, otro donde vamos a compilar y otro donde lo vamos a instalar. Yo personalmente prefiero mantener todo a nivel de usuario, por lo que las fuentes las pongo en ~/src/system/kde4, compilo en build dentro de ese directorio y lo instalo en ~/local/soft/kde4. El primero en realidad puede ser cualquier directorio, realmente no es relevante, salvo por el espacio que ocupa. Las fuentes de cada módulo (en MiB):

316     extragear[*]
549     kdebase
42      kdegraphics
185     kdelibs
18      kdemultimedia
106     kdenetwork
156     kdepim
41      kdepimlibs
10      kdereview
160     kdesupport
81      playground[*]
570     qt-copy

Los marcados con [*] no están completos, sino que elegí algunas cosas que me interesaban. Los directorios donde compilamos, también en MiB:

2146    build/extragear
1152    build/kdebase
253     build/kdegraphics
971     build/kdelibs
99      build/kdemultimedia
570     build/kdenetwork
1045    build/kdepim
194     build/kdepimlibs
33      build/kdereview
623     build/kdesupport
264     build/playground
1441    build/qt-copy

El último directorio sí me parece relevante; si no les gusta instalarlo en su home, les aconsejo que lo hagan en /opt o al menos en /usr/local, de forma de no destruir lo que haya instalado sus sistemas.

Ok, suficiente introducción, vamos a los bifes. Bajamos kdesvn-build en el directorio de compilación, lo descomprimimos y lo configuramos. La configuración pasa por darle algunos detalles de qué, cómo y dónde compilar e instalar. Pueden tomar del kdesvn-buildrc-sample que viene incluido o tomar del que estoy usando yo. Revísenlo bien; la mayoría del trabajo es configurar la sección global, que es la que está al principio del archivo; está bastante comentada. Vean en particular source-dir, build-dir, kdedir (donde va a ser instalado), qtdir (donde vamos a instalar qt-copy; yo lo puse en el mismo directorio que todo kde4), svn-server (ojo que mi copia apunta al servicio autenticado, pero tiene el anónimo comentado), cmake-options, y lo que mas o menos les pinte. Ponemos este archivo en ~/.kdesvn-buildrc y ya casi estamos.

Otra cosa que hay que hacer es poner todo un conjunto de variables de entorno a tono. Yo robé mucho de un script en techbase. A diferencia de todos los tutoriales en techbase, en vez de crear todo un usuario para hacer toda la bola, yo simplemente puse todas esas variables en un script que podía cargar a piaccere. Allí tambié puse que el directorio donde KDE4 va a guardar la configuración es .kde4-dev, así no me pisa la configuración de KDE3. también péguenle una revisada así pega con lo que tienen puesto en otros lados.

Bueno, ya estamos listos. Levantamos las variables de entorno y lanzamos el script de compilación:

$ source environ.sh
$ ./kdesvn-build-1.7.1/kdesvn-build --reconfigure --verbose --color

¡Eso es todo! El script saca los módulos unos a uno de svn; a medida que los tiene bajado los va compilando e instalando en paralelo. La primera vez tarda muchisimo, sobre todo si configuraron muchos módulos. Recomiendo compilar primero lo mínimo indispensable, dejarlo compilado de noche, y luego ir compilando de a pedacitos.

El script va dejando en log/latest logs de la compilación de cada módulo. Allí podemos encontrar la salida del proceso de configuración, donde veremos qué dependencias encontró y cuáles faltan. Si hay errores deja un error.log con la falla.

Para ejecutar la bestia, la cosa no se complica mucho mas. Yo no sé bien cómo hacer para que me lo tome el DM de turno (KDM, GDM, el que sea), por lo que lo lanzo a mano desde una terminal de texto:

$ source ~/src/system/kde4/environ.sh
$ xinit /home/mdione/local/soft/kde4/bin/startkde

También podemos lanzarlo en un Xephir, que es como un X dentro de X. Eso sí, no le pidan OpenGL (necdesario para los efectos de escritorio). Abrimos un konsole o la terminal que prefieran y:

$ Xephyr :1 -screen 1280x800 -ac -extension GLX
$ export DISPLAY=:1
$ ~/local/soft/kde4/bin/startkde

Una forma truchísima mal es entrar en una sesión failsafe (*buntu le llama 'Terminal a prueba de fallos' últimamente). Esto nos da un X pelado con una xterm y ni siquiera un Window Manager. En la terminal entramos levantamos el entorno y lanzamos KDE4:

$ source ~/src/system/kde4/environ.sh
$ ~/local/soft/kde4/bin/startkde

Voilá. Sólo asegúrensé no cerrar nunca esa xterm, sino se les cierra todo sin preguntar nada.

Un detalle es que el sistema queda solamente en inglés. Ya me voy a sentar a ver cómo meter los módulos de traducción al español.

Ok, ya estoy cansadísimo y esto es larguísimo. Cualquier duda la seguimos en el thread en kde-ar y lo vamos puliendo.

kde

Posted Wed 27 Jan 2010 11:55:55 PM CET Tags: