[04:28] <chilicuil> comenzare con la interpretacion de la ultima sesion del dia de hoy, 'Configuracion del entorno, para el desarrollo de Ubuntu'/'Getting set up for Ubuntu development' por Daniel Holbach
[04:29] <chilicuil> durante esa charla se configura el entorno, las herramientas y todo lo que sea necesario para que puedan aprovechar el resto de las sesiones, y para que puedan involucrarse con el desarrollo de Ubuntu
[04:29] <chilicuil> si logramos terminar a tiempo, podemos incluso avanzar un poco mas, y analizar algun paquete
[04:30] <chilicuil> esta sesion sera practica, les sugiero que tengan abierta por lo menos una terminal
[04:31] <chilicuil> hay ciertas cosas que necesitan hacer para tener un sistema listo para el desarrollo de Ubuntu
[04:32] <chilicuil> algunas de ellas son; configurar sus equipos para modificar paquetes, y para subir sus cambios a Launchpad, la plataforma de desarrollo de Ubuntu
[04:32] <chilicuil> esto es lo que haremos:
[04:34] <chilicuil> - Instalar programas para empaquetar programas. Esto incluye: utilidades especificas de Ubuntu, software de cifrado (para que podamos verificar quien ha hecho los cambios), y software para transmitir de forma segura datos entre la plataforma y su computadora
[04:34] <chilicuil> - Crear y configurar una cuenta en launchpad
[04:35] <chilicuil> - Configurar software para poder recompilar paquetes en su equipo, para interactuar con otros desarrolladores, y para enviar parches a Launchpad
[04:37] <chilicuil> es recomendable hacer el trabajo de empaquetamiento usando la version en desarrollo de Ubuntu, de esta forma, pueden hacer pruebas en el mismo entorno donde seran integrados
[04:37] <chilicuil> asi que tendran que correr Ubuntu Quantal (12.10) de alguna forma
[04:38] <chilicuil> no teman, podran hacerlo a traves de un entorno chroot, de una maquina virtual, o por algun metodo parecido
[04:39] <chilicuil> aunque si les es posible, lo mejor seria que pudieran hacer las pruebas en un entorno que utilicen todos los dias
[04:39] <chilicuil> https://wiki.ubuntu.com/UsingDevelopmentReleases explica algunos metodos para correr la ultima version de forma segura
[04:42] <chilicuil> si alguno de ustedes utiliza 12.04, no importa, pueden seguir las instrucciones, y luego repetirlas en su entorno de desarrollo
[04:43] <chilicuil> existen un numero de utilidades que les hara la vida mas facil como desarrolladores de Ubuntu, analizaremos algunas mas tarde, por lo pronto, para instalarlas, copien y peguen este comando en su terminal
[04:44] <chilicuil> $ sudo apt-get install packaging-dev
[04:44] <chilicuil> esto tomara unos minutos, asi que dejenlo funcionando
[04:44] <chilicuil> al finalizar tendran instalado el siguiente software
[04:50] <chilicuil> - gnupg, el gnup privacy guard contiene herramientas que necesitan para crear llaves criptograficas, con estas llaves se firman los archivos que se suben a Launchpad
[04:52] <chilicuil> - pbuilder, esta es una herramienta para recompilar los paquetes, en un entorno limpio y completamente aislado
[04:53] <chilicuil> - ubuntu-dev-tools (y devscripts, que figura como dependencia directa), es una coleccion de scripts que permiten automatizar algunas de las tareas de empaquetamiento
[04:55] <chilicuil> - bzr-builddeb (y bzr, como dependencia), sirve para obtener un sistema de control de versiones basado en Bazaar, esta es una forma relativamente nueva de trabajar con los paquetes en Ubuntu, a mediano plazo permitira que varios programadores de Ubuntu puedan colaborar mas rapido y facilmente
[04:58] <chilicuil> - apt-file, es una herramienta para encontrar el paquete al que pertence determinado archivo
[04:58] <chilicuil> - y obviamente muchas otras cosas buenas que no cubriremos en esta guia introductoria :)
[04:58] <chilicuil> alguna pregunta hasta aqui?
[05:00] <chilicuil> NickE pregunta sobre la maquina virtual que usa TestDrive
[05:00] <chilicuil> dholbach responde que la ultima vez que vio, usaba kvm
[05:00] <chilicuil> nja pregunta si es necesario correr "apt-file update" despues de instalar ese metapaquete
[05:02] <chilicuil> dholbach responde que no cree que sea necesario. nota del interprete: si que es necesario, por lo menos una vez justo despues de la instalacion
[05:04] <chilicuil> conner_bw pregunta si bzr esta grabado en piedra, o si algun dia se podra usar git en su lugar
[05:04] <chilicuil> dholbach responde que no lo sabe, y que tal vez seria mejor preguntar en #launchpad
[05:06] <chilicuil> agrega que aunque personalmente le gusta trabajar con bzr, porque es facil de aprender, comprende que otras personas prefieran trabajar con otros sistemas de control de versiones, como git, o hg
[05:07] <chilicuil> la buena noticia es que Launchpad puede importar ramas de git, y de otros sistemas, asi que despues de importarlos pueden trabajar con bzr nativamente
[05:08] <chilicuil> en fin, vayamos a la accion!
[05:09] <chilicuil> el primer paso es hacer que las herramientas de empaquetamiento conozcan sobre ti, asi que por favor, abran su archivo ~/.bashrc con editor de texto, y agreguen algo como esto al final
[05:09] <chilicuil> export DEBFULLNAME="Bob Dobbs"
[05:09] <chilicuil> export DEBEMAIL="subgenius@example.com"
[05:10] <chilicuil> reemplacen el nombre y correo con los suyos :)
[05:10] <chilicuil> ahora, guarden el archivo, y cierren y vuelvan a abrir su terminal, o utilicen el comando:
[05:11] <chilicuil> $ source ~/.bashrc
[05:11] <chilicuil> (si no utilizan bash como shell, editen el archivo correspondiente a la shell que usen)
[05:13] <chilicuil> una vez que lo hayan hecho, las herramientas de empaquetamiento utilizaran su nombre y direccion cuando tengan que introducir un nombre de autor
[05:13] <chilicuil> nja pregunta si Lernid utiliza bash como la shell por defecto
[05:14] <chilicuil> dholbach responde que si, que Lernid utiliza la shell que suelas utilizar, siendo esta por defecto bash
[05:14] <chilicuil> una vez que hayan completado este paso, crearemos la llave GPG
[05:15] <chilicuil> si ya tienen una llave de este estilo, con esa basta, no tienen que crear otra
[05:18] <chilicuil> GPG se utiliza por GNU Privacity Guard, y es una implementacion libre del estandarn OpenPGP que permite firmar y cifrar archivos, esto puede ser util de diferentes formas
[05:19] <chilicuil> en nuestro caso, es importante que firmen los archivos que modifiquen para que podamos identificar aquellos lugares donde trabajaron. Cuando suban un archivo a launchpad, solo les permitira hacerlo, si puede determinar de forma exacta quien lo esta haciendo
[05:20] <chilicuil> para crear una llave GPG, utilicen:
[05:20] <chilicuil> $ gpg --gen-key
[05:22] <chilicuil> GPG les preguntara sobre el tipo de llave que desean generar, escojan la opcion por defecto (RSA y DSA). Despues les preguntara sobre el tamaño de la clave, el tamaño por defecto (2048) esta bien, sin embargo 4096 es mas seguro
[05:22] <chilicuil> una vez hayan contestado, les preguntara si desean que expire la llave en determinado momento, contesten con '0', lo que significa que su llave nunca expirara
[05:24] <chilicuil> las ultimas preguntas son sobre su nombre y correo electronico. Escojan los datos que estaran usando para el desarrollo de Ubuntu, pueden agregar mas correos electronicos despues
[05:25] <chilicuil> no es necesario poner un comentario. Dejenlo vacio, despues de esto, tendra que configurar una clave, escojan una que sea segura (acepta espacios en blanco)
[05:26] <chilicuil> con esta informacion GPG creara su llave, esto puede tomar un poco de tiempo, ya que necesita recoger bytes aleatorios, para que los pueda tomar mas rapido, hagan que su computadora realice alguna operacion que haga uso intensivo del cpu
[05:27] <chilicuil> tambien podemos dejar que la genere mientras configuramos el resto del entorno, abran otra terminal
[05:27] <chilicuil> ahora crearemos la llave SSH
[05:31] <chilicuil> SSH obtiene su nombre de Secure Shell/Shell segura, y es un protocolo que permite intercambiar datos de una forma segura sobre una red. Es comun usar ssh para accesar a consola remotas, y para transferir archivos de forma segura. En nuestro caso, utilizaremos la segunda caracteristica, para enviar cambios a Launchpad
[05:31] <chilicuil> para crear una llave SSH, ejecuten:
[05:31] <chilicuil> $ ssh-keygen -t rsa
[05:33] <chilicuil> el nombre por defecto, comunmente esta bien, asi que dejenlo de esa forma (si ya tienen una clave anterior, entonces pueden seleccionar otro nombre). Se recomienda que tambien establezcan una contraseña para esta clave
[05:33] <chilicuil> para esta llave*
[05:33] <chilicuil> nja pregunta si la contraseña se puede cambiar despues
[05:33] <chilicuil> dholbach responde que si
[05:33] <chilicuil> el siguiente paso, es configurar pbuilder
[05:34] <chilicuil> pbuilder les permitira compilar paquetes en su maquina, esto tiene 2 ventajas:
[05:35] <chilicuil> - la compilacion se hace en un entorno limpio y minimalista, esto asegura que se pueda compilar en un sistema que no haya sido alterado
[05:35] <chilicuil> - no hay necesidad de instalar todas las dependencias localmente, se instalan en su lugar temporalmente en el entorno pbuilder
[05:36] <chilicuil> mm, una tercera ventaja, es que pueden tener varios entorno en una misma maquina, por ejemplo, varias versiones de Ubuntu o Debian al mismo tiempo
[05:36] <chilicuil> usar pbuilder es muy facil, utilicen:
[05:36] <chilicuil> $ pbuilder-dist version_de_ubuntu create
[05:37] <chilicuil> para crear un nuevo entorno
[05:37] <chilicuil> en el caso de Ubuntu quantal, pueden crear un nuevo entorno con:
[05:38] <chilicuil> $ pbuilder-dist quantal create
[05:39] <chilicuil> esto tomara algunos minutos, ya que descargara todos los paquetes necesarios para crear una instalacion "minimalista", los paquetes que se descarguen se guardaran en una cache
[05:40] <chilicuil> hay alguna pregunta hasta el momento?
[05:40] <chilicuil> jsjgruber-l82-p pregunta para que se necesita un archivo ~/.pbuilderrc
[05:41] <chilicuil> dholbach responde que en ese archivo, se pueden configurar muchas cosas, por ejemplo, el uso de mirrors adicionales, la instalacion de paquetes por defecto, etc
[05:41] <chilicuil> la pagina man de pbuilder: $ man pbuilder
[05:42] <chilicuil> describe las cosas que pueden agregar, aunque en la mayoria de los casos, no se requiere
[05:47] <chilicuil> exodus hace el siguiente comentario: imagina que estoy creando un paquete que tiene dependencia a otros paquetes, y esos paquetes a su vez aun no estan disponibles, por ejemplo, el paquete A, depende del paqeute B y del C. Una vez que compilo B & C, pbuilder conoce de la existencia de estos paquetes, y entonces puedo compilar A. Hay alguna configuracion especial para esta clase de problemas?
[05:51] <chilicuil> dholbach responde que es una excelente pregunta, y continua diciendo que efectivamente algunas veces querras seguir determinada secuencia en la construccion de los paquetes, por ejemplo cuando quieres actualizar algunas librerias de libalgo1 a libalgo2
[05:52] <chilicuil> para estos casos, se tiene que configurar pbuilder para que re utilice los paquetes que ha compilado
[05:56] <chilicuil> lengau pregunta porque pbuilder requiere permisos de super usuario (root)
[05:57] <chilicuil> dholbach responde que porque chroot internamente lo requiere para crear un sistema minimalista separado del sistema de donde fue invocado
[05:57] <chilicuil> TheLordOfTime pregunta como hacer que pbuilder utilice los paquetes que ya han sido compilados, retomando el caso hipotetico de exodus
[05:58] <chilicuil> dholbach responde que lo mejor seria ver https://wiki.ubuntu.com/PbuilderHowto y que en caso de que este desactualizado, se pregunte en #ubuntu-motu
[06:00] <chilicuil> ahora, asumire que GPG ha terminado de crear la llave :)
[06:00] <chilicuil> si es asi, habran obtenido un mensaje similar a este:
[06:00] <chilicuil> pub   4096R/43CDE61D 2010-12-06
[06:01] <chilicuil>     Key fingerprint = 5C28 0144 FB08 91C0 2CF3  37AC 6F0B F90F 43CD E61D
[06:01] <chilicuil> uid                  Daniel Holbach <dh@mailempfang.de>
[06:01] <chilicuil> sub   4096R/51FBE68C 2010-12-06
[06:01] <chilicuil> para este caso, el ID de la llave es: 43CDE61D
[06:05] <chilicuil> una vez que tengan estos datos, tendran que subir la parte publica a un servidor de llaves, de esta forma el mundo podra identificar los mensajes y archivos que les pertenezcan, en una consola:
[06:05] <chilicuil> $ gpg --send-keys <ID>
[06:07] <chilicuil> este comando subira la parte publica a un servidor de llaves, aun tendran que esperar a que se sincronice con el resto de servidores en el mundo (lo cual puede tardar algunos dias), para que todos puedan verificar sus archivos
[06:08] <chilicuil> nja pregunta el proposito de estas llaves
[06:09] <chilicuil> dholbach responde con un ejemplo, si intentas subir algun paquete a launchpad (a un repositorio personal), el sistema verificara si ese paquetes fue realmente hecho por ti
[06:10] <chilicuil> la llave GPG, es un seguro que se rompe, cuando una tercera persona intenta modificar los archivos
[06:11] <chilicuil> la llave SSH la utiliza Bazaar, y sirve para enviar esos datos a traves de una coneccion segura
[06:12] <chilicuil> con las configuraciones que hemos hecho hasta el momento, el siguiente paso es configurar el equipo para que funcione con launchpad
[06:12] <chilicuil> launchpad es la pieza central de infraestructura que usa Ubuntu
[06:14] <chilicuil> no solo almacena todos los paquetes y el codigo fuente de cada uno, tambien guarda traducciones, reportes de bugs, y la informacion de las personas que trabajan en Ubuntu, asi como los equipos a los que pertenecen
[06:15] <chilicuil> Launchpad tambien se utiliza para enviar parches, revisarlos e integrarlos en la distribucion
[06:19] <chilicuil> la integracion, se hace generalmente a traves del patrocinio de los parches de otras personas, esto quiere decir: 'subir un paquete en nombre de alguien mas'. esta es la unica forma de colaborar con Ubuntu, si quieres enviar un parche y no tienes permisos para modificar el archivo
[06:20] <chilicuil> tendran que crear una cuenta en launchpad y dar una cantidad minima de informacion. esto les permitira descargar y subir codigo fuente, enviar reportes de bugs, entre algunas otras cosas
[06:21] <chilicuil> ademas de Ubuntu, launchpad ofrece sus servicios, a cualquier proyecto de software libre, https://help.launchpad.net/ contiene mas informacion
[06:22] <chilicuil> si aun no tienen una cuenta, pueden obtenerla en: https://launchpad.net/+login , si tienen una pero no recuerdan su id, puede saberlo, si entran a https://launchpad.net/~ y despues se fijan en el nick que este despues del ~
[06:23] <chilicuil> TheLordOfTime menciona que ha escuchado del codigo de conducta (CoC) y se pregunta si debe firmarlo para desarrollar ubuntu
[06:25] <chilicuil> dholbach responde que si, y agrega que si desea formar parte de algun equipo, convertirse en un miembro oficial (y con eso, obtener derecho a votar, obtener un alias @ubuntu.com y en general ser reconocido por su trabajo) tendra que firmarlo
[06:26] <chilicuil> no hay ninguna clausula oculta, no tendran que pagar por algo que no quieren
[06:26] <chilicuil> el codigo de conducta basicamente dice que seran amables, unos con otros
[06:27] <chilicuil> eso, generalmente es algo con lo que estarias feliz de cumplir :)
[06:27] <chilicuil> man_let pregunta si hay cosas en las que puedan ayudar personas no tan inteligentes
[06:28] <chilicuil> dholbach responde que existen diferentes formas de involucrarse, y que estas actividades incluyen la mayoria de intereses, habilidades o preferencias personales
[06:30] <chilicuil> el proceso de registro en Launchpad, les preguntara por un nombre que pueda usar cuando tenga que mostrar un nombre. Se sugiere que usen su nombre real, de esta manera, las personas pueden empezar a conocerse de mejor manera, unas a las otras
[06:31] <chilicuil> tambien, cuando se registre una nueva cuenta, se enviara un link con los pasos necesarios para verificar la cuenta, si no lo reciben, verifiquen que no este en su carpeta de spam
[06:38] <chilicuil> la pagina de ayuda https://help.launchpad.net/YourAccount/NewAccount les dara mas informacion sobre el proceso, y las opciones de configuracion que pueden modificar
[06:39] <chilicuil> una vez que tengan su cuenta, tendran que decirle cual es su llave GPG, para esto necesitaran el fingerprint, en una consola ejecuten:
[06:39] <chilicuil> $ gpg --fingerprint <email@address.com>
[06:39] <chilicuil> lo que les imprimira algo como esto:
[06:39] <chilicuil> pub   4096R/43CDE61D 2010-12-06
[06:39] <chilicuil>     Key fingerprint = 5C28 0144 FB08 91C0 2CF3  37AC 6F0B F90F 43CD E61D
[06:39] <chilicuil> uid                  Daniel Holbach <dh@mailempfang.de>
[06:39] <chilicuil> sub   4096R/51FBE68C 2010-12-06
[06:40] <chilicuil> vayan a https://launchpad.net/~/+editpgpkeys y copien lo que esta despues de "Key fingerprint" en la caja de texto, para este ejemplo es:
[06:41] <chilicuil> 5C28 0144 FB08 91C0 2CF3  37AC 6F0B F90F 43CD E61D
[06:41] <chilicuil> una vez hecho esto, hagan click sobre 'Import Key'
[06:44] <chilicuil> Launchpad utilizara el fingerprint para buscar su llave en los servidores de Ubuntu, si la encuentra les enviara un correo cifrado, una vez leido el mensaje podran hacer click en el enlace que se indique, y con eso habran confirmado su llave
[06:44] <chilicuil> si su cliente de correo soporta OpenGPG, les preguntara la constraseña que configuraron cuando crearon la llave
[06:45] <chilicuil> de regreso al sitio de launchpad, hagan click sobre el boton 'Confirm', y con eso habran linkeado su llave con su cuenta
[06:45] <chilicuil> si tienen dudas sobre como finalizar el proceso, hechen un vistazo a https://help.launchpad.net/YourAccount/ImportingYourPGPKey
[06:46] <chilicuil> cuando terminen, pueden hacer lo mismo para su llave ssh
[06:46] <chilicuil> abran https://launchpad.net/~/+editsshkeys y tambien el archivo ~/.ssh/id_rsa.pub en gedit
[06:47] <chilicuil> verifiquen que estan abriendo ~/.ssh/id_rsa.pub (la parte publica), y no ~/.ssh/id_rsa (la parte personal)
[06:47] <chilicuil> :)
[06:48] <chilicuil> copien los contenidos de ese archivo, y peguenlos en la caja de texto, luego hagan click en 'Import Public Key'
[06:48] <chilicuil> si tienen dudas en algun paso de este procedimiento, revisen https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair
[06:49] <chilicuil> thotp pregunta si las llaves gpg cambian cuando se reinstala el sistema operativo
[06:49] <chilicuil> dholbach responde que sera mejor que haga una copia de seguridad del directorio ~/.gnupg
[06:52] <chilicuil> la ultima cosa que me gustaria comentar, antes de que comencemos con la sesion de preguntas y respuestas, es bazaar, bazaar es un programa que se utiliza para almacenar los cambios en el codigo de una manera logica, para intercambiar cambios, y para fusionarlos, incluso cuando el desarrollo se esta haciendo al mismo tiempo. Se usa con el nuevo metodo de desarrollar Ubuntu de manera distribuida en la modificacion de paquetes
[06:53] <chilicuil> lo primero que se tiene que hacer es configurar a bazaar con su nombre y correo, ejemplo:
[06:53] <chilicuil> $ bzr whoami "Bob Dobbs <subgenius@example.com>"
[06:53] <chilicuil> $ bzr launchpad-login subgenius
[06:55] <chilicuil> el primer comando, tomara su nombre y correo, estos datos se utilizaran para firmar sus mensajes de modificaciones (commits). El segundo comando sirve para configurar su ID en launchpad, de esta forma, el codigo que suban desde su maquina sera asociado a su cuenta
[06:56] <chilicuil> de nuevo, si no pueden recordar su ID pueden ir a https://launchpad.net/~ y ver hacia donde los redirecciona, el nombre que este despues del ~ es su ID
[06:56] <chilicuil> y eso es basicamente todo lo que tienen que hacer
[06:58] <chilicuil> una cosa que tal vez deseen hacer, es abrir desde Ubuntu "propiedades del software" y asegurarse que la pestaña que dice 'Sources' esta activada, una vez lo hayan hecho, podran descargar el codigo fuente de cualquier aplicacion de Ubuntu
[06:59] <chilicuil> eklok pregunta de donde se puede sacar la motivacion para trabajar con esto todos los dias. Menciona que el siempre se lo propone, pero al final del dia falla
[07:00] <chilicuil> dholbach responde que son las personas y la sensacion de saber que si un error es solucionado, no solo se arregla para el, sino para millones de usuarios
[07:01] <chilicuil> tambien dice, que aprende terminan aprendiendo algo nuevo, lo que le parece fantastico
[07:01] <chilicuil> agrega, que algunas veces puede ser dificil solucionar algun problema, pero que siempre se puede preguntar por ayuda
[07:02] <chilicuil> man_let pregunta lo que pasaria si 2 personas tuvieran la misma llave publica
[07:03] <chilicuil> dholbach responde que ya ha escuchado de colisiones entre llaves gpgp, pero que son muy raras, asi que no podria darle una respuesta mas especifica, le gustaria que alguien mas le enviara un link que explicara a detalle el tema
[07:04] <chilicuil> envia http://www.gnupg.org/gph/en/manual.html#AEN282  y espera que eso pueda ayudar a obtener una respuesta
[07:04] <chilicuil> alguna otra pregunta?
[07:05] <chilicuil> continuando con la sesion, si han seguido todas las instrucciones hasta el momento
[07:05] <chilicuil> deberian poder seguir el siguiente ejemplo
[07:05] <chilicuil> en una consola ejecuten:
[07:05] <chilicuil> $ bzr branch ubuntu:hello
[07:06] <chilicuil> lo que descargara una rama del programa 'hello' en Ubuntu, junto con todas sus revisiones (historial, versiones anteriores)
[07:06] <chilicuil> despues de haber hecho eso, ejecuten:
[07:06] <chilicuil> cd hello
[07:06] <chilicuil> bzr bd -- -S
[07:08] <chilicuil> lo que compilara un paquete de codigo fuente a partir del repositorio - de esta forma se reconstruira el paquete en su forma original, y en las modificaciones que se agregan, para hacer que se compile como un paquete de Debian/Ubuntu
[07:08] <chilicuil> si escriben:
[07:08] <chilicuil> $ ls
[07:08] <chilicuil> veran algunos archivos como:
[07:08] <chilicuil> hello_2.8-2.debian.tar.gz  hello_2.8-2_source.changes
[07:09] <chilicuil> hello_2.8-2.dsc            hello_2.8.orig.tar.gz
[07:09] <chilicuil> si los ven, ejecuten a continuacion:
[07:09] <chilicuil> $ pbuilder-dist quantal build ../hello_2.8-2.dsc
[07:09] <chilicuil> lo que compilara el paquete 'hello', dentro de la instancia de pbuilder que habiamos creado con anterioridad
[07:10] <chilicuil> lo primero que hara, sera descargar las dependencias, y posteriormente compilarlo
[07:10] <chilicuil> el paquete resultante, estara disponible en ~/pbuilder/quantal_result/
[07:11] <chilicuil> nja pregunta porque obtiene el siguiente mensaje de error: http://paste.ubuntu.com/1172150/
[07:11] <chilicuil> dholbach responde que el error que obtuvo es una advertencia, y que se puede ignorar por el momento
[07:12] <chilicuil> gpg: skipped "Santiago Vila <sanvila@debian.org>": secret key not available
[07:12] <chilicuil> gpg: /tmp/debsign.16cckC0A/hello_2.8-2.dsc: clearsign failed: secret key not available
[07:12] <chilicuil> se refiere, a que la ultima persona que trabajo en el paquete fue Santiago Vila, y que no tenemos su llave GPG, como debia de esperarse
[07:13] <chilicuil> pudimos haber agregado "-us -uc" a "bzr bd -- -S" para que no mostrara ningun error
[07:13] <chilicuil> pero como decia, se puede ignorar por el momento
[07:16] <chilicuil> con estos pequeños pasos, 3-4 comandos, fuimos desde una rama del codigo fuente (con todas las revisiones de Ubuntu incluidas), a un paquete de codigo fuente (unicamente de la ultima revision) - esto es lo que se sube a launchpad para su compilacion), y finalmente fuimos a un paquete binario (.deb)
[07:17] <chilicuil> esto solo es una probada, espero que encuentren muchas otras cosas interesantes durante las siguientes sesiones, que los ayuden a unirse al grupo de desarrolladores de Ubuntu
[07:18] <chilicuil> haganme un ultimo favor, y agreguen a marcadores http://developer.ubuntu.com/packaging/html/
[07:19] <chilicuil> e intenten seguir a @ubuntudev en identi.ca/twitter/facebook/gplus
[07:19] <chilicuil> marcosb pregunta si -us -uc no es en realidad un comando para pbuilder, o si lo es para bzr
[07:21] <chilicuil> dholbach responde que efectivamente, los parametros son para $ bzr db (y que todo lo que va detras de -- se envia a debuild/dpkg-buildpackage internamente)
[07:22] <chilicuil> espero que se animen a probar el desarrollo de Ubuntu, que aprendan mucho, que ayuden a crear del mundo un mejor lugar, y que hagan un puñado de amigos en el proceso :)
[07:23] <chilicuil> dholbach pregunta si hay mas preguntas, tal vez pueda resolver otro par antes de que Oliver "ogra" Grawert comience su charla sobre ARM
[07:24] <chilicuil> nja pregunta sobre que es lo sigue despues de correr: "bzr bd -- -S -us -uc"
[07:24] <chilicuil> dholbach responde que $ pbuilder-dist quantal build ../hello_2.8-2.dsc
[07:25] <chilicuil> y agrega que tambien deberia poder encontrar las instruccines precisas en http://developer.ubuntu.com/packaging/html/
[07:25] <chilicuil> y en los logs que se generen y que se publiquen en: https://wiki.ubuntu.com/UbuntuDeveloperWeek
[07:27] <chilicuil> marcosb comenta: otra sesion para aprender a hacer parches para el paquete hello? :)
[07:28] <chilicuil> dholbach responde que si, y agrega que hubiera sido muy complicado querer abarcar mas en 2 horas :)
[07:28] <chilicuil> alucardni pregunta como puede hacer que $ bzr bd invoque a pbuilder para crear un paquete binario
[07:30] <chilicuil> dholbach responde que no se puede, que tiene que correr ambos comandos
[07:30] <chilicuil> pero que seria genial tener un plugin para bzr, que simplifique el proceso a un solo paso
[07:31] <chilicuil> gracias a todos por estar aqui, espero que pueda saber de ustedes pronto, ogra, todo tuyo :)
[07:32] <chilicuil> y con esta termina la interpretacion de la sesión, pueden consultar los logs del resto de las interpretaciones en https://wiki.ubuntu.com/SemanaDesarrollador , saludos cordiales
[14:02] <chilicuil> hola KervinRodriguez, bienvenido, dentro de algunos minutos comenzara el segundo dia de la semana del desarrollador, las platicas generales se daran en #ubuntu-classroom (es una buena idea a unirse a ese canal), en este canal, se estara haciendo una interpretacion simultania, tambien si tienes algun problema para plantear tu pregunta en ingles en #ubuntu-classroom-chat puedo ayudarte, las sesiones de ayer estan disponibles en https
[14:04] <KervinRodriguez> Gracias
[14:42] <meropachanguero> hola
[14:52] <jossed> buenos dias
[14:54] <gus-tavo> bienos dias jossed
[14:54] <FTG> hola
[14:55] <chilicuil> buenos dias a todos, hola gustavo_ =)
[14:55] <joshua1983> buenos dias chilicuil
[14:55] <gus-tavo> soy el mismo, logeado dos veces :)
[14:56] <chilicuil> genial, al menos parecera que somos mas ;)
[14:58] <jossed> jajjaja
[14:58] <jossed> si
[15:01] <chilicuil> wop, acaba de comenzar =)
[15:01] <gus-tavo> Comienza la sesión :9
[15:01] <gus-tavo> Michael Terry, es quien mantiene los paquetes de Quickly
[15:02] <gus-tavo> Usualmente da charlas durante la Semana del Desarrollador, como esta, quiere saber si les gustaria hablar de algo mas tecnico o no
[15:03] <gus-tavo> Comienza con una rapida intro a Quikly y los planes para 12.10 y 13.04
[15:04] <gus-tavo> Quicly es un forma de comenzar a desarrollar muy rápida
[15:04] <gus-tavo> Y no tener que preocuparse mucho acerca del empaquetado o como enviar la app a Ubuntu
[15:05] <gus-tavo> Hay algunas opiniones sobre la elección (como Python, GTK+) que Ubuntu hace, para ofrecer una mejor experiencia
[15:06] <gus-tavo> Hay muchas "plantillas" que Quickly ofrece para otras cosas (como HTML5 o Flash)
[15:06] <gus-tavo> Por que usar Quicly o integrarse al desarrollo ?
[15:07] <gus-tavo> La razón es que si queres comenzar a desarrollar sin importar mucho acerca del empaquetamiento
[15:07] <mwallacesd> =)
[15:07] <gus-tavo> Siempre  hay muchas cosas para hacer, y hay planeado mucho trabajo
[15:08] <gus-tavo> en 12.04 hay tres plantillas, la nomal Python+GTK, una interfaz de linea de comandos y otra de juegos flash
[15:09] <gus-tavo> Tambien estan HTML5, Qt, Qt Quick, y una Unity Lens mantenida por la comunidad
[15:09] <chilicuil> bienvenido mwallacesd , en este canal se hace la interpretacion en tiempo real de #ubuntu-classroom, si tienes alguna pregunta para la sesion, y no estas seguro de como hacerlo, tambien podemos ayudarte, si no tienes problemas con Ingles, igual podemos darnos apoyo uno al otro, todos aqui estamos de una forma u otra interesados en el desarrollo de Ubuntu
[15:10] <gus-tavo> eklok pregunta: se puede trabajar con Quickly via teminal e interfaz gráfica?
[15:10] <gus-tavo> Ahora, está diseñado para ser usado solamente via terminal
[15:10] <gus-tavo> Michael Hall trabaja en un interfaz gráfika
[15:10] <gus-tavo>  https://launchpad.net/quickly-gtk
[15:11] <gus-tavo> skizobass pregunta: puede usar Eclipse, PyDev para escribir una App Python con quickly y luego publicarla en el Software Center?
[15:11] <gus-tavo> Si y no
[15:12] <gus-tavo> No tenemos una integración con Eclipse o PyDev
[15:12] <gus-tavo> Pero puedes escribir una app y pegarte dentro de un proyecto Quickly con un pequeña suma de trabajo
[15:13] <gus-tavo> Lo que da Quicly es un proyecto esqueleto
[15:14] <jossed> que nos ofrece Quicly en desarrollo
[15:14] <jossed> que nos ofrece Quickly en desarrollo
[15:14] <gus-tavo> Y si tiras algo del codigo,  y te adhieres al tuyo, tenes las mayorias de las ventajas que ofrece Quicky
[15:14] <joshua1983> pregunta: esa estructura creada por Quickly es el estándar para desarrollar aplicaciones en ubuntu?
[15:15] <gus-tavo> ben72 pregunta: in 12.04 quickly es el paquete a obtener?
[15:15] <gus-tavo> sSi
[15:15] <jossed> se conecta contoda las base de datos o hay q utilizar librerias_
[15:15] <gus-tavo> FlowRiser pregunta: Como es el actual flujo de trabajo de Quickly?
[15:16] <gus-tavo> Digamos que comienzas un proyecto
[15:16] <gus-tavo> Abres la Terminal
[15:16] <gus-tavo> corres "quickly create ubuntu-application  test-project"
[15:17] <jossed> pero es orientada a la web o son para aplicaciones de escritorio
[15:17] <gus-tavo> La app Ubuntu es elegida en ese paso y elijes una plantilla
[15:17] <gus-tavo> En nuestro caso, queremos la default-ubuntu-recommendation, que es Python+GTK
[15:17] <chilicuil> jossed: acabo de hacer tu pregunta sobre base de datos en #ubuntu-classroom-chat
[15:18] <jossed> ok
[15:18] <gus-tavo> Ahora, crea el esqueleto y y lo lanza
[15:19] <gus-tavo> Cierra este proyecto, "cd test-project" y estás sobre el nuevo proyecto
[15:19] <gus-tavo> Ahora puedes editar el codigo con "quickly edit" o empaquetarlo con "quickly package". Vamos a esos comandos mas tarde
[15:20] <gus-tavo> skizobass pregunta: Puedo escribir y organizar el codigo (clases, paquetes, et,) como en Eclipse?
[15:20] <chilicuil> jossed: acabo de hacer tu segunda pregunta sobre aplicaciones web vs aplicaciones de escritorio =)
[15:21] <gus-tavo> No estoy seguro como hace Eclipse, espera.
[15:21] <jossed> ok >(
[15:21] <jossed> si me responde me madas las respuesta a mi correo que tengo q salir ok es jsdrnt@gmail.com gracias
[15:22] <gus-tavo> El esqueleto por defecto te da un directorio/modulo-Python para tu codigo
[15:22] <chilicuil> jossed: las respuestas estaran accesibles como parte del log, te lo mandare todo junto, que te diviertas
[15:23] <gus-tavo> y tambien un modulo Python que tiene su propio codigo boilerplate
[15:24] <gus-tavo> Colocas todo tu codigo en tu modulo y Quickly lo envuelve
[15:24] <jossed> ok
[15:25] <gus-tavo> Si quieres importar codigo existente en Quickly, tienes que reemplazar un modulo con tu codigo
[15:25] <gus-tavo> Pero asi como van clases, Python y Quickly recomiendan una-clase-por-archivo
[15:26] <gus-tavo> puedes hacer como quieras. no es estricto, como Java
[15:26] <gus-tavo> nja pregunta: estaras cubriendo algo de Python en esta sesion?
[15:26] <gus-tavo> No lo tengo planeado, hay mejores recursos para eso
[15:27] <SergioMeneses> gus-tavo, puse un tuto bastante bueno de python en el canal de chat
[15:27] <gus-tavo> No hay mas preguntasm comencemos a usar Quickly
[15:27]  * SergioMeneses is still working
[15:28] <gus-tavo> Antes que lo olvide, Quickly tiene un tutorial embebido
[15:28] <SergioMeneses> gus-tavo, el fin de semana sera q miro lo de la semana xD
[15:28] <gus-tavo> Si no me quieren escuchar repetido
[15:29] <gus-tavo> corre "quickly tutorial" en tu directorio
[15:29] <SergioMeneses> :O
[15:29] <SergioMeneses> exelente aporte
[15:30] <gus-tavo> FlowRiser pregunta: Veo que la mayoria de los lenguajes que usa no requiere compilar el codigo, hay alguna chance de usar Cpp y una plantilla GTK?
[15:30] <gus-tavo> Es una posibilidad
[15:30] <gus-tavo> pero no lo hemos hecho aun
[15:31] <chilicuil> oh si, creo que muchos de nosotros tendremos de sobra con eso: $ quickly tutorial
[15:31] <gus-tavo> El sistema de plantillas le permite a alguien eschibir algo como una plantilla fácilmente
[15:31] <gus-tavo> Tenemos un progreso con la plantill Vala, que esta compilada
[15:32] <gus-tavo> Pero en general, usuarios nuevos prefieren lenguajes no compilados, como HTML o Python
[15:33] <mwallacesd> SergioMeneses, nos puede pasar el tuto aqui?
[15:33] <gus-tavo> peaceisid pregunta; para usar quickly, debo saber programar en python?
[15:33] <gus-tavo> Si, al menos para la plantilla recomendada por defecto
[15:33] <gus-tavo> pero, nuevamente, no va a ser necesario en el futuro
[15:33] <gus-tavo> estamos hora
[15:34] <SergioMeneses> gus-tavo, mwallacesd http://mundogeek.net/tutorial-python/
[15:34] <mwallacesd> Gracias SergioMeneses
[15:34] <gus-tavo> coalitians pregunta: Quickly esta en python?
[15:34] <gus-tavo> Si, el proyecto esqueleto y Quickly en si
[15:35] <gus-tavo> BebopSteve pregunta: con "quickly edit", que hay de especial?  o puedes usar tu editor preferido?
[15:36] <gus-tavo> Puedes usar el editor de tu elección, puedes asignar EDITOR o QUICKLY_EDITOR variables de entorno para cambiarlo
[15:37] <gus-tavo> NickE pregunta: Quickly tiene soporte para Python 3?
[15:37] <gus-tavo> No aún
[15:37] <gus-tavo> Queremos soportarlo, pero eso no pasara hasta 13.04
[15:38] <gus-tavo> chilicuil pregunta: quickly soporta el acceso a bases de datos? o necesito usar librerias?
[15:39] <gus-tavo> Para eso, no se necesita nada especial, Quickly las soporta
[15:39] <gus-tavo> Solo impota el modulo apropiado Python
[15:40] <gus-tavo> No limita tu eleccion en como escribes tus app. Es solo un envoltorio, para proveer integracion dentro de Ubuntu
[15:40] <gus-tavo> Otro comando util para cambiar tus app, es "quickly design"
[15:41] <gus-tavo> que traera el editor Glade, una interfaz gráfica
[15:42] <gus-tavo> Como usar Glade es enteramente otra charla, trata de ser un constructor interfaces con apunta y clika
[15:43] <gus-tavo> Te ayuda a entender GTK un poco cuando lo usas
[15:44] <gus-tavo> Pero la idea básica es que puede crear nuevas widgets un el panel a la izquierda, colocrlos en el medio y ajustar las propiedades del widget en la zona inferior derecha
[15:45] <gus-tavo> chilicuil pregunta: Quickly esta planeado para producir app de escritorio o app web?
[15:45] <gus-tavo> Ahora, app de escritorio
[15:45] <gus-tavo> Tenemos una plantilla HTML5 en el conjunto de la comunidad
[15:46] <gus-tavo> Pero aun esta diseñado para el escritorio (corre Python por debajo)
[15:47] <gus-tavo> green7 pregunt: Necesitamos conocer GTK para usar Quickly?
[15:47] <gus-tavo> Si, para la plantilla estándar
[15:47] <gus-tavo> como para Glade
[15:47] <gus-tavo> nja pregunta: Donde recomendarias aprender Python?
[15:48] <gus-tavo> Dive into Python es muy bueno
[15:48] <gus-tavo> http://www.diveintopython.net/
[15:48] <gus-tavo> Digamos que te sientes a gusto con Glade, y has hecho algunos cambios (y podemos volver a ellos)
[15:49] <gus-tavo> Si quieres ver como se ve tu proyecto, corre "quickly run"
[15:49] <gus-tavo> lo que cargara todos los archivos editados y te mostrara el estado actual del proyecto
[15:50] <gus-tavo> un lindo truco Quickly hace es que cuando agregas un eidget, respondes frecuentemente a eventos de usuario que hay en el
[15:50] <gus-tavo> como clicks
[15:51] <gus-tavo> Quickly lo hace facil
[15:51] <gus-tavo> Si agregas un widget llamado boton1
[15:52] <gus-tavo> puedes escribir un método en la clase ventana llamada on_boton1_clicked (self, widget, data=None)
[15:52] <gus-tavo> y es todo lo que necesitas alli
[15:53] <hephisto> buen dia alguno conoce algun tutorial de AS3
[15:53] <gus-tavo> Quicky lo notificara y ancla el widget a tu método
[15:54] <gus-tavo> Necesitas usar el formato on_WIDGETNAME_SIGNALNAME
[15:54] <gus-tavo> y la señal cambiara de acuardo al tipo de señal
[15:54] <gus-tavo> Vean la documentacion GTK para detalles en una señal dada
[15:55] <gus-tavo> green7 pregunta: hay una diferencia entre packaging y quickly run?
[15:55] <gus-tavo> si
[15:55] <chilicuil> hephisto: hola, este canal es sobre las sesiones de la semana del desarrollador, https://wiki.ubuntu.com/SemanaDesarrollador, ahora mismo estamos hablando de quickly, una herramienta para crear aplicaciones en python en Ubuntu, para soporte general, usa #ubuntu-es =)
[15:56] <hephisto> si estaba mirando eso gracias  esta interesante  y me interesa
[15:57] <gus-tavo> cuando haces quickly run hace solo quick spot-check
[15:57] <gus-tavo> corre todos los archivos desde done estan en el directorio de tu proyecto
[15:58] <gus-tavo> pero quickly package crea archivo paquete Debian
[15:58] <gus-tavo> que puedes instalar en tu sistema si eres root
[15:59] <gus-tavo> Digamos que cuando corremos 'quickly package' en nuesto test-project
[15:59] <gus-tavo> nos dara un archivo como ../test-project_0.1_all.deb
[16:00] <gus-tavo> si corremos 'sudo dpkg -i ../test-project_0.1_all.deb' lo instalamos
[16:00] <gus-tavo> Y lo verás en el Dash
[16:01] <gus-tavo> antes de empaquetar seriamente tu app, lo mejor es llenar alguna informacion en el archivo 'setup.py'
[16:01] <gus-tavo> como pagina web y autor
[16:02] <gus-tavo> al correr 'quickly license' para especificar la licencia de tu programa
[16:03] <gus-tavo> porque toda esa informacion es importante antes de comenzar la distribucion
[16:03] <gus-tavo> dejenme hablar algo acerca  del empaquetamiento
[16:04] <gus-tavo> digamos que pensamos que esta app por defecto es genial
[16:04] <gus-tavo> y la queremos distribuir a amigos
[16:04] <gus-tavo> primero, debemos correrla localmente con 'quickly package'
[16:04] <gus-tavo> asegurarnos que instala bien
[16:05] <gus-tavo> pero si queremos distribuirla a una comunidad amplia, deberias asignarle un PPA
[16:05] <chilicuil> gus-tavo: acaba de comenzar la segunda sesion, podrias pausar la interpretacion?, si quieres puedo terminar lo que hizo falta
[16:06] <gus-tavo> ok chilicuil,
[16:06] <gus-tavo> gracias
[16:06] <chilicuil> gracias gus-tavo =), van un poco rapido estos chicos
[16:07] <chilicuil> vale, para la segunda sesion, tendremos a coolbhavi que nos hablara del equipo consultor de desarrolladores de Ubuntu, o el 'developer advisory team' en ingles
[16:08] <chilicuil> == Por que estamos aqui? ==
[16:09] <chilicuil> el equipo de consultores, es un conjunto de personas que intentan hacer el desarrollo de ubuntu un poco mas social, con la esperanza de hacer que cada vez mas personas se involucren
[16:09] <SergioMeneses> chilicuil, gus-tavo no se desordena mucho el log?
[16:09] <chilicuil> esto significa, que nos enfocamos en las personas que recien comienzan, y les ayudamos a introducirse en el mundo de desarrollo de Ubuntu
[16:09] <chilicuil> SergioMeneses: lo pondre todo junto, en un pastebin ;)
[16:10] <SergioMeneses> chilicuil, aaaa ok jeje good one!
[16:10] <chilicuil> == El proceso en general ==
[16:10] <chilicuil> tenemos 4 formas lograr esto
[16:11] <chilicuil> primero, contactamos a las personas interesadas por correo (hacemos esto dependiendo de la cantidad de contribuciones que hayan hecho, si vemos que son constantes, nos comunicamos con ellos)
[16:11] <chilicuil> NOTA: hay probabilidades de que ya hayas recibido este correo si sueles enviar parches
[16:12] <chilicuil> despues de esto, organizamos una entrevista con los candidatos, y les preguntas sobre su experiencia con el proceso
[16:12] <chilicuil> en esa misma entrevista, les preguntamos cuales son sus objetivos dentro de la comunidad
[16:13] <chilicuil> cuando hemos terminado con el segundo punto, les hacemos sugerncias (no confundir con el proceso de mentores, uno a uno), y seguimos pendientes de sus contribuciones
[16:14] <chilicuil> por ultimo, si sentimos que un candidato ya esta listo, le ayudamos a enviar su aplicacion para entrevistarse con el DBM (el council que aprueba nuevos desarrolladores oficiales)
[16:15] <chilicuil> nja: pregunta sobre los privilegios que se ganan cuando se es parte del DMB
[16:15] <chilicuil> coolbhavi responde que no podria contestar esa pregunta porque el no es miembro de ese council
[16:16] <chilicuil> NickE pregunta si el objetivo entonces el objetivo del equipo es convertir  desarrolladores casuales, en oficiales?
[16:16] <chilicuil> coolbhavi responde que si, de eso se trata
[16:17] <chilicuil> BebopSteve pregunta si entre sus planes esta crear un sitio web con informacion que pueda ayudar a los nuevos desarrolladores
[16:17] <chilicuil> coolbhavi responde que si, y que lo respondera de mejor forma conforme avance la sesion
[16:18] <chilicuil> siguiendo con la charla, seguramente algunos de ustedes se estan preguntando, ok, estoy interesado, donde comienzo?
[16:19] <chilicuil> a lo que yo responderia, si te interesa convertirte en un desarrollador de Ubuntu, nuestro equipo esta aqui para lograrlo
[16:20] <chilicuil> == eso quiere decir que me asignaran un mentor? ==
[16:21] <chilicuil> desafortunadamente la respuesta a esa pregunta es "no". Solo damos sugerencias (como ligas de los equipos, o de introduccion al desarrollo), sin embargo si en algun momento tienen algun problema, pueden preguntar en #ubuntu-motu, el canal de los desarrolladores MOTU o preguntar en la lista de correo ubuntu-motu@lists.ubuntu.com
[16:22] <chilicuil> FlowRiser pregunta que es lo que pasa, si no es tan buen programador?
[16:22] <chilicuil> coolbhavi responde que no tiene que preocuparse mucho por eso, ya que no todas las personas comienzan siendo excelentes programadores
[16:23] <chilicuil> == Entonces, como pueden ayudarme para que me sea mas facil involucrarme en el desarrollo de Ubuntu ? ==
[16:24] <chilicuil> empezar es relativamente facil, pueden empezar hechandole un vistazo a http://developer.ubuntu.com/packaging/html/ , y si desean tener algo en que trabajar, pueden consultar la iniciativa de correcion de bugs disponible en https://wiki.ubuntu.com/UbuntuDevelopment/BugFixingInitiative
[16:25] <chilicuil> NickE pregunta sobre el significado de la palabra MOTU
[16:25] <chilicuil> coolbhavi responde que son las iniciales del equipo Master Of The Universe (Dueños del universo, en referencia del repositorio -universe)
[16:26] <chilicuil> y del -multiverse
[16:26] <chilicuil> skizobass pregunta si hace falta estar certificado en alguna tecnologia para ser parte de Ubuntu
[16:26] <chilicuil> coolbhavi responde que no, solo se necesita querer ser parte =)
[16:27] <chilicuil> == Que clase de personas estamos buscando? ==
[16:28] <chilicuil> buscamos desarrolladores (que apenas se hayan integrado, o que ya tengan tiempo de haberlo hecho) y que no han aplicado para obtener derechos para modificar el archivo (los repositorios), tambien nos interesa saber de aquellas personas que despues de haber colaborado han dejado de hacerlo, nos interesa saber cuales han sido las causas, y si podemos ayudar
[16:29] <chilicuil> == He contribuido por X meses, puedo aplicar para convertirme en desarrollador de Ubuntu?, me pueden ayudar? ==
[16:30] <chilicuil> definitivamente :) (aunque como regla, y segun el DMB, el tiempo minimo debe ser mayor a 6 meses de contribuciones continuas). Tambien es buena idea que se pongan en contacto con el desarrollador que ha estado subiendo los cambios por ustedes (sponsor) y que le piden que agregue comentarios en su wiki de aplicacion
[16:31] <chilicuil> BebopSteve pregunta, cual es la diferencia entre poder subir, y contribuir?, no se se supone que si contribuyes, es por que puedes subir cosas?
[16:32] <chilicuil> coolbhavi responde que hasta que tengas permisos para modificar el archivo por ti mismo, los cambios que desees enviar tienen que pasar por otro desarrollador previamente aprobado
[16:33] <chilicuil> FlowRiser comenta que le gustaria que le aclaran el tema de sponsor (patrocinado), no se supone que hacemos esto gratis?
[16:35] <chilicuil> coolbhavi responde que el proceso en el que otro desarrollador sube cambios por uno que aun no puede hacerlo se llama patrocinio 'sponsoring', y al que lo hace patrocinador 'sponsor'
[16:36] <chilicuil> skizobass pregunta si es necesario ser programador de python, o cuales son otras formas contribuir?
[16:37] <chilicuil> coolbhavi responde que no es necesario, pero que especialmente en Ubuntu no es una mala idea
[16:38] <chilicuil> FlowRiser pregunta si existe una lista con diferentes actividades organizado por nivel de dificultad (aplicaciones, kernel, modulos, etc)
[16:39] <chilicuil> coolbhavi responde que si, y que si desea verlas, puede leer las paginas de los diferentes equipos (desktop, kernel, etc), o revisar la wiki del equipo MOTU
[16:41] <chilicuil> NickE comenta, entonces si envias suficientes contribuciones  ganas la confianza de tu patrocinador hasta que tu mismo te conviertes en uno?
[16:41] <chilicuil> coolbhavi responde que asi es exactamente como funciona, despues de obtener permisos para modificar el archivo, te abras convertido en desarrollador de Ubuntu :)
[16:42] <chilicuil> TheLordOfTime pregunta si todos los desarrolladores oficiales automaticamente se convierten en patrocinadores (sponsors)
[16:43] <chilicuil> coolbhavi responde que si, como desarrallores oficiales puede subir sus cambios, o los de otras personas
[16:43] <chilicuil> == Bueno esto suena interesante, como puedo ayudar a mejorar la iniciativa? ==
[16:44] <chilicuil> si te ha gustado la idea, y deseas ayudarnos, nos gustaria escuchar tus comentarios
[16:44] <chilicuil> por favor, busquen el reporte de comentarios del ultimo ciclo: http://fridge.ubuntu.com/2012/04/17/developer-advisory-team-report-12-04-feedback-from-new-contributors/
[16:45] <chilicuil> == Perfecto!, quienes son los actuales miembros del equipo, y como puedo ponerme en contacto con ellos? ==
[16:45] <chilicuil> todos los miembros pueden verse en toda su gloria aqui: https://launchpad.net/~ubuntu-developer-advisory-team/+mugshots
[16:46] <chilicuil> para cualquier comentario/queja/sugerencia sientanse libres de ponerse en contacto con cualquiera de ellos :)
[16:47] <chilicuil> creo que es todo, como aun queda algo de tiempo pueden hacerme mas preguntas =)
[16:48] <chilicuil> NickE pregunta si el trabajo dentro del equipo se divide por areas de especializacion, o si todos pueden ayudar con cualquier cosa?
[16:49] <chilicuil> coolbhavi responde que aunque algunos de los miembros tienen amplios conocimientos, en su conjunto, pueden ayudar a las personas con cualquier cosa que este relacionado con el desarrollo de Ubuntu
[16:50] <chilicuil> skizobass pregunta donde puede enviar sus programas si estan hechos en python
[16:51] <chilicuil> coolbhavi: responde que el 'Application review board' es el encargado de revisar ese tipo de cosas y le sugiere que lo envie con ellos
[16:52] <chilicuil> marcosb pregunta si la junta de revision de aplicaciones 'the app review board' se encarga de aprobar todos los programas, o solo para los programas comerciales
[16:53] <chilicuil> coolbhavi responde que el ARB es para las aplicaciones libres, otro equipo se encarga de evaluar los programas comerciales
[16:54] <chilicuil> aqui, hago una pausa, alguien desea interpretar la siguiente sesion, sobre corregir bugs en ubuntu que dara Stefano (tumbleweed])?
[16:55] <chilicuil> stadtfeld pregunta si solo se le brinda ayuda a las personas que han enviado parches, o si es a todos por igual
[16:55] <chilicuil> coolbhavi responde que a todos
[16:56] <chilicuil> alucardni pregunta si puede aplicar para obtener derechos en los repositorios si ha estado enviando parches a Debian
[16:56] <chilicuil> coolbhavi responde que si, pero que depende del impacto que tus modificaciones hayan tenido en ubuntu
[16:57] <chilicuil> y se puede aplicar para obtener una membresia PPU (per package/por paquete)
[16:59] <chilicuil> pueden encontrarlo en facebook a traves de la cuenta facebook.com/bshankar o en google+
[16:59] <chilicuil> con eso termina la sesion de coolbhavi
[17:01] <chilicuil> ok, si no hay inconvenientes entonces comenzare la interpretacion de la tercera sesion, durante ella, Stefano Rivera nos hara un breve resumen de como trabajar con algunos bugs de Ubuntu, la platica se ha estructurada para ser facil de seguir
[17:02] <chilicuil> comenzare ahora
[17:02] <chilicuil> veo que tenemos muchas personas en la sala, pueden regalarma en 'hi' en #ubuntu-classroom-chat?
[17:03] <chilicuil> oh si, si se tienen algunos problemas durante la sesion, no olviden entrar a #ubuntu-motu una vez haya finalizado
[17:03] <chilicuil> bien, mi nombre es  Stefano Rivera y soy desarrollador de Debian y Ubuntu
[17:03] <chilicuil> vivo en sudafrica
[17:04] <chilicuil> y justo ahora, estoy en el apartamento de un amigo, con mi laptop en la esquina y una conexion 3G, asi que espero no desaparezca repentinamente
[17:05] <chilicuil> estoy aqui, para decirles como trabajar con upstream
[17:05] <chilicuil> que quiere decir esta palabra?
[17:06] <chilicuil> bueno, Ubuntu esta hecho de ~20 000 paquetes de codigo fuente (los que en su conjunto crean mas ~40 000 paquetes binarios - .debs)
[17:06] <chilicuil> como desarrolladores de Ubuntu, escribimos una parte muy pequeña de todos ellos
[17:06] <chilicuil> todo lo demas, viene de otros proyectos
[17:06] <chilicuil> y estos proyectos son los que llamamos upstream
[17:07] <chilicuil> cada proyecto libera una nueva version de su programa, cuando pasa eso, lo empaquetamos, y despues de algunos cambios hacemos que se integre con Ubuntu, eso es lo que entregamos a nuestros usuarios
[17:08] <chilicuil> tambien nos encargamos de filtar muchos de los reportes que originalmente deberian ir para esos proyectos
[17:08] <chilicuil> y solo reenviamos los validos
[17:08] <chilicuil> suena divertido, no? =)
[17:08] <chilicuil> jeje, bueno, he mentido un poco en eso
[17:08] <chilicuil> espero que todos sepan para este momento, que Ubuntu se deriva de Debian
[17:09] <chilicuil> pues bien, la mayoria de los problemas que encontramos en Ubuntu, tambien afectan a debian
[17:09] <chilicuil> asi que debian es un proyecto upstream especialmente importante para Ubuntu
[17:09] <chilicuil> enviamos muchos cambios para alla
[17:09] <chilicuil> https://wiki.ubuntu.com/Debian/ForUbuntuDevelopers
[17:10] <chilicuil> un poco mas adelante dare mas detalles sobre como hacer eso
[17:10] <chilicuil> por ahora, hablare de los proyectos upstream en general
[17:10] <chilicuil> generalmente es buena idea tratar de arreglar los bugs, tan cercanos del proyecto original como sea posible
[17:11] <chilicuil> esto se hace, para no duplicar el trabajo, y compartir las mejoras a la mayor cantidad de personas posibles
[17:12] <chilicuil> marcosb pregunto si se le puede explicar lo que significa la nomenclatura de los paquetes, por ejemplo en hello_1.1-1ubuntu1.deb o en hello_1.1-1upstream1.deb
[17:12] <chilicuil> tumbleweed responde que si
[17:12] <chilicuil> todos los paquetes .deb tienen nombres del tipo nombrepaquete_version_arquitectura.deb
[17:13] <chilicuil> la version es especialmente importante para saber cual es el paquete anterior, y cual el siguiente
[17:13] <chilicuil> los paquetes que se hacen en Debian, y en sus derivados tienen otra version que luce como esto 1.0.0
[17:14] <chilicuil> no hay ningun '-1' al final
[17:14] <chilicuil> si un desarrollador de debian empaqueta la version 1.0.0 de un programa, el paquete tendra la version 1.0.0-1
[17:14] <chilicuil> -1 significa que es el primer paquete de su clase en Debian
[17:15] <chilicuil> si alguien hace un cambio en ese paquete en Ubuntu, la version sera 1.0.0-1ubuntu1
[17:15] <chilicuil> si en Ubuntu se empaqueta la version 1.0.1 del programa antes que en debian, se llama 1.0.1-0ubuntu1
[17:15] <chilicuil> etc
[17:16] <chilicuil> por supuesto, hay algunas personas que no siguen estas reglas, sin embargo en la mayoria de los casos aplica
[17:16] <chilicuil> en fin, estabamos hablando de porque es buena idea colaborar con los proyectos upstream
[17:17] <chilicuil> y esta es la razon, si enviamos un parche a los desarrolladores originales, y ellos liberan una nueva version con nuestra mejora, se benefician todos
[17:17] <chilicuil> los usuarios de otras distribuciones (no solo de ubuntu), los de otras plataformas com wygwin o macports, o las personas que lo descargan desde el sitio oficial
[17:18] <chilicuil> ademas de eso, los programadores del proyecto original, pueden darte buenas sugerencias para mejorar tus programas/parches
[17:18] <chilicuil> nadie su codigo, como ellos
[17:19] <chilicuil> espero que ya tengamos claro porque es buena idea, trabajar con los proyectos upstream
[17:19] <chilicuil> como pueden encontrar un bug para comenzar a trabajar?
[17:19] <chilicuil> bueno, hemos puesto una buena cantidad en https://wiki.ubuntu.com/UbuntuDevelopment/BugFixingInitiative
[17:20] <chilicuil> los primeros son unicamente para Ubuntu, estos no requeriran ningun esfuerzo extra
[17:20] <chilicuil> asi que es una buena idea comenzar por ellos
[17:21] <chilicuil> despues de esos, estan otros ejemplos que no solo afectan Ubuntu, y los parches que se hagan para ellos tendran que reenviarse a los proyectos originales
[17:21] <chilicuil> (que es de lo que realmente hablaremos hoy)
[17:22] <chilicuil> otra buena estrategia para comenzar a involucrarte es tomar algun paquete que te interese, y que no este bien mantenido
[17:22] <chilicuil> algun proyecto con algunos bugs abiertos de los cuales nadie se haya hecho cargo
[17:23] <chilicuil> puede ser que incluso algunos de ellos, solo se corrigan en nuestra distro, algunos desarrolladores de Ubuntu pueden ser flojos :)
[17:23] <chilicuil> existen *muchos* programas como estos en los repositorios
[17:24] <chilicuil> en Debian, cada paquete tienen un mantenedor explicito asociado que debe velar por el programa
[17:24] <chilicuil> pero en Ubuntu, muchos de esos paquetes no son vigilados por nadie
[17:25] <chilicuil> hay una lista de algunos de ellos en http://qa.ubuntuwire.org/neglected/
[17:25] <chilicuil> AmberJ_ pregunta, en un comentario anterior alguien dijo que si se modifica un paquete en Ubuntu, la version seria 1.0.0-1ubuntu1, que pasa si nadie lo modifica?
[17:26] <chilicuil> tumbleweed responde que entonces se mantiene la misma version que en Debian
[17:26] <chilicuil> como he dicho anteriormente, la mayoria de los paquetes en los repositorios son versiones sin modificar de Debian
[17:27] <chilicuil> en Ubuntu existe sin embargo, una forma ligeramente diferente de compilar algunos programas
[17:27] <chilicuil> pero a la mayoria de los programas, no se les hacen modificaciones
[17:27] <chilicuil> siguiendo con la sesion, como soluciono el bug?
[17:28] <chilicuil> bueno, esa una pregunta un tanto dificil de contestar, y depende en gran parte de la clase de bug con el que estemos tratando
[17:28] <chilicuil> todo lo que puedo decir, es como meter sus manos en el codigo fuente, y que hacer una vez que este arreglado
[17:29] <chilicuil> dholbach cubrio la primera parte de ese proceso ayer
[17:29] <chilicuil> de todas formas, dejenmen recordarselo
[17:29] <chilicuil> se debe instalar el paquete packaging-dev
[17:29] <chilicuil> eso les dara muchas herramientas necesarias
[17:30] <chilicuil> deben descargar el codigo fuente de la aplicacion con el problema, esto lo pueden hacer con: $ pull-lp-source PAQUETE
[17:30] <chilicuil> marcosb pregunta si aprendera a hacer parches en esta sesion
[17:30] <chilicuil> tumbleweed responde que si, y agrega que eso suena como algo interesante
[17:31] <chilicuil> siguiendo con la charla.., hay 2 formas de en Ubuntu de descargar el codigo fuente, la forma tradicional, usando las herramientas de Debian, y con bzr
[17:32] <chilicuil> durante esta sesion les hablare principalmente de la forma clasica, porque aun sigue siendo mas popular, y encuentro que es mas rapido de esa forma
[17:32] <chilicuil> asi que, si han descargado y extraido el codigo fuente con pull-lp-source
[17:32] <chilicuil> podrian agregar su solucion facilmente
[17:33] <chilicuil> una vez llegados a este punto, podrian tener que hacer varias cosas, gracias a las diferentes formas en las que se empaquetan los programas
[17:33] <chilicuil> podrian correr "what-patch" para que clase de parches usa el paquete
[17:34] <chilicuil> pongamos como ejemplo, que se esta usando quilt, este es el formato mas comun actualmente, espero que dentro de poco sea el unico que quede
[17:34] <chilicuil> si es asi, podran correr: $ quilt new NOMBREDEMIPARCHE
[17:34] <chilicuil> despues: $ quilt edit ARCHIVO
[17:35] <chilicuil> y para finalizar $ quilt refresh, lo que creara el parche
[17:35] <chilicuil> pueden encontrar el resultado en debian/patches
[17:35] <chilicuil> la mayoria de las veces, cuando trabajen con paquetes en debian, esta es la forma en la que se generaran
[17:36] <chilicuil> este parche es el que puedes enviar a upstream
[17:36] <chilicuil> como puedes encontrarlos?
[17:36] <chilicuil> bueno, empecemos por Debian
[17:36] <chilicuil> pueden ver informacion detallada sobre cada programa en http://packages.qa.debian.org/
[17:37] <chilicuil> http://packages.qa.debian.org/$PAQUETE
[17:37] <chilicuil> asi que por ejemplo, para el paquete 'hello', pueden ir a http://packages.qa.debian.org/hello
[17:37] <chilicuil> ojo, que estoy hablando de paquetes de codigo, y no de paquetes binarios
[17:38] <chilicuil> como desarrolladores, la mayor parte del tiempo estaremos trabajando con paquetes de codigo
[17:38] <chilicuil> los binarios (.deb) solo se crean cuando el programa este listo
[17:39] <chilicuil> en packages.qa.debian.org (tambien conocida como el PTS) encontraran una ista de bugs
[17:39] <chilicuil> en la esquina superior derecha pueden ver los bugs de cada paquete, en la izquierda quien esl mantenedor
[17:39] <chilicuil> y en el centro el historial de versiones
[17:40] <chilicuil> bien, revisando en el historial, encontramos que solo tiene 1
[17:41] <chilicuil> que pasa si encontramos el bug que estabamos buscando, bueno, pues vamos a el y hecharemos un vistazo para ver cual es el progreso que se ha hecho
[17:41] <chilicuil> tal vez hasta haya un parche, o tal vez se haya enviado el parche al proyecto original
[17:42] <chilicuil> podemos ver que el bug aqui (bugs.debian.org/621716) ha sido reenviado al proyecto original
[17:42] <chilicuil> desafortunadamente no tenemos un link porque ha sido enviado a un correo
[17:43] <chilicuil> algunos proyectos no tienen un sistema de control de bugs (bugtracker) y por lo tanto lo unico que modemos decir es: "se lo enviamos al correo"
[17:43] <chilicuil> marcosb pregunta si existe otro mecanismo para crear parches ademas de quilt
[17:43] <chilicuil> tumbleweed responde que lamentablmente si, existen otros dos, dpatch y cdbs-simple-patch (aunque ambos se usan cada vez menos)
[17:44] <chilicuil> y algunos paquetes no tienen ningun sistema para manejar los parches
[17:44] <chilicuil> eso significa que todos los cambios que se han hecho, tanto en Ubuntu como en Debian estan mezclados en un solo y enorme diff
[17:45] <chilicuil> esta forma es la mas facil para modificar paquetes, pero es dificil entender los cambios que se estan haciendo
[17:46] <chilicuil> calmi pregunto si existe un sistema para evitar bugs duplicados
[17:46] <chilicuil> tumbleweed responde que si, que antes de enviar un nuevo reporte busques si ya existe y agrega que launchpad es realmente bueno haciendo esto
[17:47] <chilicuil> una vez que introduces un titulo, hace una busqueda de bugs similares
[17:47] <chilicuil> en debian, la herramienta estandard, $ reportbug, tambien muestra una lista de bugs parecidos antes de poder enviar el tuyo
[17:48] <chilicuil> marcosb pregunta si se le puede indicar como crear paquetes con dpatch y dbs-simple-patch?
[17:48] <chilicuil> tumbleweed dice que desafortunadamente no los cubrira por el momento, y que los paquetes que los utilizan son tan raros que no deberia preocuparse por ellos
[17:49] <chilicuil> hablemos unicamente de los paquetes que no tienen ningun sistema de parches
[17:49] <chilicuil> la forma mas simple de obtener un parche de estos es hacer tus cambios, agregar una nueva entrada en el archivo /debian/changelog (con dch) y compilar el paquete
[17:50] <chilicuil> despues se puede usar "debdiff" para crear el parche, por ejemplo $ debdiff foobar_0.1-1.dsc foobar_0.1-1ubuntu1.dsc
[17:51] <chilicuil> en fin, regresemos a lo estaba diciendo antes
[17:51] <chilicuil> si ya buscamos en el tracker de debian, y no encontramos el bug en el que estamos trabajando
[17:51] <chilicuil> nos podemos preguntar, el bug en el que trabajamos se genero en Debian?
[17:51] <chilicuil> si es asi, sera mejor que hagamos el reporte nosotros mismos
[17:52] <chilicuil> algunas veces, si el problema esta en upstream, podemos trabajar en una solucion temporal para Debian/Ubuntu mientras los cambios se aplican en el proyecto original
[17:52] <chilicuil> o si es un problema muy serio, podemos crear un parche para la version estable de las versiones en Ubuntu/Debian
[17:53] <chilicuil> si no encontramos razones para reenviarlos a Debian, podemos solo reenviarlos a upstream (en caso de que aplique)
[17:53] <chilicuil> podemos encontrar sus paginas de varias formas, la mayoria de los proyectos tienen una pagina oficial, podemos buscar esa pagina en el archivo /debian/control
[17:54] <chilicuil> tambien la podemos encontrar en el PTS, para el paquete hello, http://packages.qa.debian.org/hello es http://www.gnu.org/software/hello/
[17:54] <chilicuil> a su vez, esa pagina nos dice que el bugtracker se encuentra en savannah http://savannah.gnu.org/projects/hello/
[17:55] <chilicuil> asi que eventualmente llegaremos al bugtracker de upstream
[17:55] <chilicuil> ahora podemos crear un reporte en su sistema (claro, primero debemos fijarnos si no ha sido reportado o solucionado con anterioridad)
[17:56] <chilicuil> y anexarles el parche que hemos creado, \o/, si es asi lo habremos logrado =)
[17:56] <chilicuil> muchos proyectos no estan interesados en las versiones de sus programas que estan en las distribuciones de linux, pues las pueden considerar demasiado antiguas
[17:57] <chilicuil> asi que lo mejor que pueden hacer es ver, si la version mas nueva de ese programa, aun tiene ese problema
[17:57] <chilicuil> como investigar eso, dependera de cada proyecto
[17:57] <chilicuil> lo que yo suelo hacer, es intentar reproducir el error en mi computadora
[17:58] <chilicuil> de esta manera puedeo saber, si se ha arreglado o no
[17:58] <chilicuil> y me puedo poner en el mismo lugar que la persona que lo reporto en primer lugar
[17:58] <chilicuil> tambien ayuda a redactar un buen reporte a upstream
[17:59] <chilicuil> jsjgruber-x-p_ pregunto que es lo que pasa si los desarrolladores de upstream no te contestan
[17:59] <chilicuil> tumbleweed responde que se puede solucionar en Debian/Ubuntu
[17:59] <chilicuil> ahora hablare un poco del sistema de reportes de bugs, el BTS que esta en bugs.debian.org
[18:00] <chilicuil> cuando lo usen, hay links en cada paquete que los llevara a diferentes secciones, bugs.debian.org/PAQUETE, bugs.debian.org/NUMEROBUG
[18:00] <chilicuil> notaran que no hay forma de agregar comentario, o llenar otros bugs
[18:00] <chilicuil> esto es porque todo el sistema esta controlado via email
[18:01] <chilicuil> tal vez crean que eso es arcaico, pero hasta el momento ha funcionado bien
[18:01] <chilicuil> ben72 pregunto que pasa cuando el parche es muy pequeño, vale la pena agregarlo como comentario?
[18:01] <chilicuil> tumbleweed responde que si, y que de hecho asi es como muchas veces se envian los parches
[18:02] <chilicuil> algunas veces el problema es tan facil de solucionar que podria bastar con describir el proceso
[18:02] <chilicuil> por el contrario, si es muy grande, tal vez prefieran dividirlo en varios parches
[18:03] <chilicuil> marcosb pregunta si despues de agregar la entrada en changelog y el parche con quilt, se debe generar el paquete con debuild -us -uc y ejecutar despues debdiff?
[18:03] <chilicuil> tumbleweed: responde que primero debe ejecutarse $ debuild -uc -us -S
[18:04] <chilicuil> y luego $ debdiff
[18:04] <chilicuil> agrega que la -S provoca que unicamente se construya el paquete del codigo fuente, y no el binario
[18:04] <chilicuil> por lo que es mucho *mas* rapido
[18:04] <chilicuil> y con eso termina la sesion
[18:08] <chilicuil> con eso termino mi participacion el dia de hoy, si alguien mas desea ser voluntario para interpretar algunas de las sesiones de mañana, es bienvenido =) https://wiki.ubuntu.com/SemanaDesarrollador que pasen un excelente dia, los logs estan disponibles desde esa misma pagina o desde http://irclogs.ubuntu.com/2012/08/29/%23ubuntu-classroom-es.html#t15:01
[19:00] <Alexander> hola
[19:00] <Guest11820> hola
[19:00] <Guest11820> hola
[19:00] <Guest11820> como estas?
[19:00] <Guest11820> como estan?
[19:06] <Guest11820> hola
[19:18] <chilicuil> hola Guest11820 , bienvenido, las interpretaciones terminaron hace rato, puedes ver los logs de ayer en https:///wiki.ubuntu.com/SemanaDesarrollador o en la pagina en Ingles https://wiki.ubuntu.com/UbuntuDeveloperWeek
[19:19] <chilicuil> dentro de unas hrs se subiran los logs de las charlas de hoy a la wiki, si quieres verlas ahora mismo puedes buscarlas aqui http://irclogs.ubuntu.com/2012/08/29/%23ubuntu-classroom-es.html#t15:01
[19:20] <chilicuil> mañana sera el ultimo del evento, comienza a las 15:00 UTC