Comentarios aleatorios, semana 13-19/junio

Standard

En adicion de las entradas que pudiera escribir, intentare subir cada semana comentarios que vaya encontrando tanto en los canales (#ubuntu-bugs, #ubuntu-motu, etc) como en las listas (https://lists.ubuntu.com/#Development+Lists).

Aqui la primera entrega, que corresponde a la semana del 13 al 19 de Junio del 2010.


#ubuntu-motu: < geser> build a deb mostly involves: installing the build-dependencies, apply patches if needed, build using the upstream Makefile, install using the upstream Makefile into a stage directory, build the debs from that staging directory

#ubuntu-motu: < geser> crear un paquete deb basicamente implica: instalar las dependencias, aplicar parches segun se requieran, compilar usando el archivo Makefile que viene con el codigo, instalar usando el mismo archivo Makefile dentro de un directorio de pruebas. Crear el paquete deb a partir de ese directorio.


#ubuntu-motu: < dupondje> How can I request a new package into universe? An update of another package is now depending on libopensync-plugin-vformat, but thats not in universe yet…<tumbleweed> dupondje: before debian import freeze, it should come in by itself, afterwards, a sync request works

#ubuntu-motu: < dupondje> Como puedo hacer que un nuevo paquete entre en universe (repositorio)? La actualizacion de un paquete depende de libopensync-plugin-vformat, pero libopensync-plugin-vformat aun no esta en universe…<tumbleweed> dupondje: antes del DIF (debian import freeze), el paquete deberia sincronizarse automaticamente, despues de ello, una peticion para sincronizarlo deberia funcionar


#ubuntu-motu: Abut FTBFS testing: < xteejx> Does it matter that I’m using Lucid?
< Laney> You’ll at least want a maverick chroot, and maybe a VM depending on what you’re up to

#ubuntu-motu: Sobre testeo de FTBFS (Fails To Build From Source –Paquetes que fallan al compilarse desde el codigo fuente)< xteejx> Importa si uso Lucid?
< Laney> Necesitaras al menos un chroot con maverick, y probablemente una maquina virtual dependiendo en lo que estes trabajando


#ubuntu-motu: < ari-tczew> I’m pissed due to outdated packages.ubuntu.com
< Laney> I never use that
< Laney> lp/ubuntu/+source/package is always up to date
debdiffs aren’t wrong, but bazaar is like a fashion, modern system for patches

#ubuntu-motu: < ari-tczew> Estoy molesto porque los paquetes de packages.ubuntu.com estan desactualizados
< Laney> Yo nunca uso eso
< Laney> lp/ubuntu/+source/paquete siempre esta en la ultima version, los debdiffs no estan mal, pero bazaar esta de moda, un sistema moderno para manejar los parches.


#ubuntu-motu: < shadeslayer> are there any packaging jobs that i can look at to contribute to MOTU and eventually become one myself?
< micahg> shadeslayer: merges?
< shadeslayer> geser: where do i upload a package once i work  upon it?
< geser> shadeslayer: file a bug, attach the debdiff, and subscribe the ubuntu-sponsors team

#ubuntu-motu: < shadeslayer> hay algo relacionado con empaquetamiento que pueda hacer para contribuir con la comunidad y eventualmente convertirme en un MOTU?
< micahg> shadeslayer: merges (fusiones)?
< shadeslayer> geser: donde subo los paquetes una vez que haya trabajado en ellos?
< geser> shadeslayer: reporta un bug, adjunta el debdiff, y suscribe al equipo ubuntu-sponsors


#ubuntu-motu: < trombonechamp_> How would one go about getting included in the ubuntu repos?
< funkyHat> trombonechamp_: the ideal way to go about it would be to get included in Debian’s repos, then the package will be automatically synced into Ubuntu in the next (or current) development cycle

#ubuntu-motu: < trombonechamp_> Como podria uno incluir paquetes en los repositorios de ubuntu?
< funkyHat> trombonechamp_: la forma ideal seria que incluyeras tus paquetes en los repositorios de Debian (mentors.debian.net) y luego que los paquetes se sincronizaran automaticamente en la siguiente (o en esta misma) version de ubuntu


#ubuntu-motu: < BlackZ> when I do a merge should I do the debdiff between the old ubuntu modified package and the new one modified, right?
< geser> BlackZ: between “new” Debian and “merged” Ubuntu

#ubuntu-motu: < BlackZ> cuando hago un merge, deberia hacer el debdiff entre el paquete anterior de ubuntu y el nuevo, verdad?
< geser> BlackZ: es entre el nuevo paquete de Debian y el que haz combinado (merged) en Ubuntu


#ubuntu-motu: < dupondje> somebody knows if there is a way to build packages remotely ?
< dupondje> want to build maverick packages on my remote debian system :)
< micahg> dupondje: pbuilder?
< dupondje> but is there some easy way ? like pbuilder interacts remotely ?
< dupondje> or really need to ssh and do pbuilder remote ?
< pochu> dupondje: you can set up a build farm. DktrKranz wrote something for that, can’t remember its name though
< DktrKranz> dupondje, pochu: something like that is called debomatic

#ubuntu-motu: < dupondje> alguien sabe si hay alguna forma de crear paquetes remotamente?
< dupondje> quiero compilar algunos paquetes para maverick en un sistema remoto que corre debian :)
< micahg> dupondje: pbuilder?
< dupondje> no hay una forma mas facil? por ejemplo hacer que pbuilder funcione remotamente?
< dupondje> o realmente necesito logearme via ssh y correr pbuilder?
< pochu> dupondje: puedes crear una granja. DktrKranz escribio algo al respecto, aunque ahora mismo no recuerdo el nombre
< DktrKranz> dupondje, pochu: hay una aplicacion llamada debomatic que puede hacer eso


#ubuntu-motu: < jariq> I am not sure what to do then there is new upstream release available. Should I create new orig.tar.gz file and start with clean changelog ???
< BlackZ> jariq: nope, just add a new changelog entry, and yes, you need a new .orig.tar.gz for the new upstream release

#ubuntu-motu: < jariq> No estoy seguro de lo que tengo que hacer cuando haya una nueva version en upstream (la pagina del proyecto original). Debo crear un nuevo archivo orig.tar.gz y empezar otro changelog ???
< BlackZ> jariq: no, solo agrega otra entrada en el changelog, por otro lado, si tendras que utilizar el nuevo archivo .orig.tar.gz de upstream


#ubuntu-motu: < xteejx> Would source that builds/compiles with “./configure make make install” be easier to package than something that hasn’t got these, or are these scripts easy enough to make that it doesn’t make any difference?
< cpscotti> afaikm, if you use the standard (./conf, make , make install ) everything will get better for you
< cpscotti> (unless your app is in python or the like)
< xteejx> well I’m not a dev so I’d be picking an easy-ish one to package for my 1st time :)
< Laney> I advise you not to start with packaging new software
< xteejx> really? why?
< Laney> both because it’s very difficult and because it tends to lead to unmaintained packages in the archive
< Laney> it’s a better idea to get to grips with how stuff works by fixing existing bugs. And we have enough of those to work on

#ubuntu-motu: < xteejx> Los programas que usan “./configure make make install” son mas faciles de empaquetar que aquellos no lo usan?, o no hay mucha diferencia?
< cpscotti> hasta donde se, si usan la forma estandar (./conf, make , make install ) todo deberia ser mas facil para ti.
< cpscotti> (a menos que tu aplicacion este escrita en python o lenguajes similares)
< xteejx> bueno, no soy programador, asi que creo que escogere uno facil para iniciarme :)
< Laney> No te recomiendo que empieces empaquetando nuevos programas
< xteejx> no?, porque?
< Laney> umm, porque es dificil y tiende a crear paquetes que despues no son mantenidos en el archivo (el lugar donde estan los repositorios)
< Laney> es mejor, si quieres familiarizarte, que empiezas corrigiendo bugs. De esos tenemos muchos en los que podrias trabajar.


#ubuntu-bugs: < charlie-tca> Bugs marked confirmed mean someone else also has it, or there is enough information to determine it is indeed a bug. there may not be a known workaround for it, though.

#ubuntu-bugs: < charlie-tca> Los bugs marcados como ‘confirmados’ quieren decir que alguien mas los tiene o que hay suficiente informacion para determinar que realmente es un bug, eso no significa que exista una forma de arreglarlo todavia.


#ubuntu-bugs: < somethinginteres> hi all, some n00b questions:  I am wondering if there’s a place I can go to explain the basics of launchpad? What each status of a bug means what ‘branch exists’ means etc. Also, when a patch is submitted for a reported bug how does that fix get to me? Will ubuntu find patches and send them out in the upgrade manager?
< micahg> somethinginteres: help.launchpad.net
< micahg> somethinginteres: patches are reviewed and applied when appropriate
< micahg> somethinginteres: patches normally go through -proposed and then to -updates if they test fine

#ubuntu-bugs: < somethinginteres> hola a todos, algunas preguntas de novato: Me pregunto si hay algun lugar donde pueda encontrar como aprender a usar launchpad? Que significa cada etiqueta de estado de los bugs, y lo que significa que exista un ‘branch’ etc.  Tambien me gustaria saber que pasa cuando un parche se adjunta a un reporte como llega ese parche a mi?, ubuntu encuentra esos parches y me los envia a traves del  gestor de actualizaciones?
< micahg> somethinginteres: help.launchpad.net
< micahg> somethinginteres: los parches se revisan y se aplican cuando no contienen errores
< micahg> somethinginteres: luego normalmente se suben a -proposed y de ahi a -updates si funcionan correctamente


#ubuntu-devel: <BlackZ>e.g. 6 months are enough for become a MOTU, if you have demostrated your skills< BlackZ> (merge, packaging work, bug fix …)

#ubuntu-devel: <BlackZ>por ejemplo, 6 meses son suficientes para convertirse en un MOTU, si has demostrado suficientementes habilidades< BlackZ> (combinando, empaquetando, corrigiendo errores …)


#ubuntu-devel: < ogra> you have to either be MOTU or a delegated team developer before applying for core-dev

#ubuntu-devel: < ogra> tienes que convertirte ya sea en un MOTU o en un  delegado de un equipo de desarrollo antes de aplicar para ser miembro del equipo core-dev


#ubuntu-devel: < BlackZ> netshine: if you join the MOTU team you will be an ubuntu member too

#ubuntu-devel: < BlackZ> netshine: si te unes al equipo MOTU entonces tambien seras un miembro de ubuntu (y tendras uno de esos aliases @ubuntu.com :)’


#ubuntu-devel: < nzmm> whats the ‘official’ way to upgrade to a dev version?
< nzmm> upgrade-manager -d?
< zyga> nzmm, yes

#ubuntu-devel: < nzmm> cual es la manera ‘oficial’ de actualizar el sistema a la version en desarrollo?
< nzmm> upgrade-manager -d?
< zyga> nzmm, sip


#ubuntu-devel: < javanix> hey everyone, who should i talk to (and where do i find them) if i want to help out with development?
< blueyed_> javanix: join #ubuntu-motu and look at wiki.ubuntu.com for starters – try also googling for “ubuntu development”. Also, there are bugs tagged “bitesize” on launchpad.net/ubuntu.

#ubuntu-devel: < javanix> hola gente, a quien le deberia preguntar (y donde podria encontrar a las personas adecuadas) si quisiera ayudar con el desarrollo de ubuntu?
< blueyed_> javanix: entra a #ubuntu-motu y hechale un ojo a wiki.ubuntu.com en la parte de principiantes –  prueba buscando en google por “ubuntu development“. y, checa los bugs que tienen la etiqueta “bitesize” en launchpad.net/ubuntu.


#ubuntu-packaging: < nigelb> having a pbuilder is not must for having the code.
< nigelb> you can always push to a ppa instead of using pbuilder

#ubuntu-packaging: < nigelb> usar pbuilder no siempre es necesario
< nigelb> tambien puedes mandar tus cambios a tu ppa en su lugar


#ubuntu-packaging: < svaksha> so wget <lp branch link> should get me the branch
< nigelb> no
< nigelb> svaksha: bzr branch should get you the branch
< geser> svaksha: using wget is like downloading the same file with your browser (e.g. firefox)
< geser> it has nothing to do with “branching” in the context of a version control system (like e.g. bzr)

#ubuntu-packaging: < svaksha> umm, asi que wget <liga del branch en lp (launchpad)> deberia descargar el branch?
< nigelb> no
< nigelb> svaksha: bzr branch deberia hacerlo
< geser> svaksha: usar wget seria como descargarlo desde tu navegador (por ejemplo firefox)
< geser> no tiene nada que ver con el concepto de “branching” en el contexto de un sistema de control de versiones (como bzr –bazaar–)


#ubuntu-packaging: < YoJack> Any good links for creating a debian package ?
< nigelb> https://wiki.ubuntu.com/PackagingGuide/Complete
< nigelb> Also, http://www.debian.org/doc/maint-guide/

#ubuntu-packaging: < YoJack> Alguien sabe de algunas ligas donde expliquen como crear paquetes .deb?
< nigelb> https://wiki.ubuntu.com/PackagingGuide/Complete
< nigelb> Tambien puedes ver, http://www.debian.org/doc/maint-guide/


#ubuntu-packaging: < shadeslayer> backports are : packages uploaded to maverick and ‘ backported ‘ to lucid

#ubuntu-packaging: < shadeslayer> los backports son : paquetes que son subidos a maverick y de ahi exportados a lucid o a una version anterior


#ubuntu-packaging: < shadeslayer> micahg: does motu have all their packaging stuff in bzr ?
< micahg> shadeslayer: well, everything in the archive is in bzr

#ubuntu-packaging: < shadeslayer> micahg: los integrantes del equipo MOTU tienen todos sus paquetes en bzr?
< micahg> shadeslayer: bueno, todo lo que esta en el archivo esta en bzr


#ubuntu-packaging: About how ppa works < shadeslayer> you upload your sources and packaging stuff to servers where the packages get built and published :P

#ubuntu-packaging: Sobre como funcionan los repositorios ppa < shadeslayer> subes tu archivo fuente (.dsc) a los servidores y ellos se encargan de compilarlo y publicarlo :P


#ubuntu-classroom: About how patche management should work: <@dholbach> in an ideal world, it’d work like this:
<@dholbach>  – we get a patch in ubuntu
<@dholbach>  – we send it to the software authors of that piece of software (upstream)
<@dholbach>  – they like it
<@dholbach>  – it gets integrated
<@dholbach>  – the new release makes it into debian
<@dholbach>  – then we get it
<@dholbach> sometimes you’ll find that it’s a patch that has only to do with packaging
07:20 <@dholbach> in that case and if the package is in debian too, you’d just send it to debian
07:21 <@dholbach> if the package is just in ubuntu, we need to integrate it ourselves

#ubuntu-classroom: Sobre como deberia funcionar el manejo de parches: <@dholbach> en un mundo ideal, funcionaria de esta manera:
<@dholbach>  – obtenemos un parche en ubuntu
<@dholbach>  – lo mandamos a los autores del software (upstream)
<@dholbach>  – les gusta
<@dholbach>  – lo integran
<@dholbach>  – la nueva version aparece en debian
<@dholbach>  – entonces lo copiamos de ahi
<@dholbach> algunas veces veran que el parche solo se aplica a un defecto en el paquete
<@dholbach> en ese caso y si el paquete tambien esta en debian, se manda el parche ahi
<@dholbach> si el paquete solo esta en ubuntu, entonces nosotros mismos lo integramos

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s