Comentarios aleatorios, semana 21-26/junio

Standard

Segunda entrega que corresponde a la semana del 21 al 26 de junio del 2010.


#ubuntu-bugs: About kernel syncs < ogasawara> xteejx: right, we rebase with each 2.6.35-rc# candidate as they come out

#ubuntu-bugs: Sobre la sincronizacion del kernel < ogasawara> xteejx: correcto, sincronizamos el paquete base con cada version de 2.6.35-rc# que va saliendo


#ubuntu-bugs: < cwillu> what’s the email address to email to a launchpad bug report?
< cwillu> <bug#>@bugs.launchpad.net?
< cwillu> ah, yep;  just showed up

#ubuntu-bugs: < cwillu> cual es el correo de los bugs que estan en launchpad?
< cwillu> <#bug>@bugs.launchpad.net?
< cwillu> oh, sip; lo acabo de encontrar


#ubuntu-devel: < zyga> dholbach, where does ubuntu developer week take place? #ubuntu-meeting?
< dholbach> zyga: #ubuntu-classroom

#ubuntu-devel: < zyga> dholbach, donde se va a dar el “ubuntu developer week” (la semana del desarrollador de ubuntu), en #ubuntu-meeting?
< dholbach> zyga: #ubuntu-classroom


#ubuntu-devel: < encodec> hey all
< encodec> i want to understand how packages work
< encodec> by that i mean…
< encodec> who compiles them
< encodec> how are they added to package system
< cjwatson> developers upload source packages; they’re compiled by automatic build servers
< encodec> how?
< cjwatson> please expand on your question
< encodec> well i guess in linux its just a ./configure make script..
< cjwatson> dpkg-buildpackage  is the official entry point
< cjwatson> unpack source package, cd into unpacked tree, run dpkg-buildpackage -b
< cjwatson> that calls debian/rules with various arguments, behind the scenes
< cjwatson> and debian/rules takes care of whatever the specifics of the package are.  not everything is ./configure && make
< encodec> ok ok
< encodec> what describes the dependencies, destination paths and such things?
< cjwatson> encodec: debian/control describes dependencies, although many of them are worked out dynamically by dpkg-shlibdeps
< cjwatson> encodec: destination paths are done by a mix of things; it’s easiest to run dpkg-buildpackage on a package and watch its output
< cjwatson> sometimes it’s the upstream build scripts (Makefile or whatever), sometimes debian/*.install, sometimes manual commands written directly into debian/rules, it varies

#ubuntu-devel: < encodec> hola a todos
< encodec> me gustaria entender como funcionan los paquetes
< encodec> y con eso quiero decir..
< encodec> quien los compila
< encodec> como se agregan a los repositorios, etc
< cjwatson> encodec: los desarrolladores suben paquetes de codigo fuente (.dsc); y estos luego son compilados por servidores automatizados
< encodec> como?
< cjwatson> por favor se más concreto con tu pregunta
< encodec> bueno, yo creo que debería bastar con correr ./configure & make
< cjwatson> dpkg-buildpackage es el punto oficial de entrada
< cjwatson> luego se descomprime el paquete fuente, se mueve a la carpeta descomprimida y se corre dpkg-buildpackage -b
< cjwatson> eso llama a debian/rules con varios parametros detras de escena
< cjwatson> y debian/rules se encarga de cualquier detalle que pueda tener el paquete, no todo es ./configure && make
< encodec> ok ok
< encodec> como se describen las dependencias, el lugar donde se pondran los binarios y esas cosas?
< cjwatson> encodec: el archivo debian/control describe las dependencias, aunque muchas de ellas se descubren dinamicamente con dpkg-shlibdeps
< cjwatson> encodec: el lugar a donde se copian los binarios se conforman por una mezcla de cosas, es mas facil usar dpkg-buildpackage sobre un paquete y ver su salida para darse una idea
< cjwatson> algunas veces es el script que viene de upstream (ya sea un Makefile o cualquier otra cosa), otras veces son los archivos debian/*.install,  o puede que sean comandos a  escritos directamente en debian/rules, varia.


#ubuntu-devel: < KIAaze> what is the name of the program/script to test install/uninstall/upgrade/etc of a package?
< KIAaze> I remember reading about something like that, but I can’t find it anymore
< ScottK> piuparts?
< KIAaze> yes, that looks like it. Thanks. :)

#ubuntu-devel: < KIAaze> como se llama el script/programa que sirve para instalar/desinstalar/actualizar/etc un paquete?
< KIAaze> Recuerdo haber leido algo por el estilo, pero no puedo encontrarlo
< ScottK> piuparts?
< KIAaze> si, creo que ese es. Gracias :)


#ubuntu-packaging: < qnull> hello everybody. Is it possible to let launchpad build packages for different versions of ubuntu (lucid, maverick) from just one source package?
< geser> no, you need one upload for each release (you just need to change the upload target and modify the version slightly as each version can only be uploaded once)
< qnull> thanks for reply! You mean the target in the changelog?
< geser> yes
< qnull> It’s kinda stupid that you have to modify the source for that, isn’t it?
< geser> but also required by the archive layout. As all debs for a source package are in the same directoy, you need different file names for each release which can be acomplished by changeing the version string

#ubuntu-packaging: < qnull> hola a todos. Será posible hacer que launchpad cree paquetes para diferentes version de ubuntu (lucid, maverick), desde un solo paquete fuente (.dsc)?
< geser> no, necesitas subirlo para cada version (lo unico que tienes que cambiar es el objetivo y la versión del paquete, ya que solo puedes subir 1 vez una version determinada)
< qnull> gracias! cuando dices el objetivo, te refieres a la versión de ubuntu en el changelog?
< geser> sip
< qnull> es un tanto estupido que tengas que modificar el paquete fuente para eso, no lo creen?
< geser> pero es requerido para conservar la estructura del archivo (donde se guardan los .deb). Ya que todos los debs del mismo paquete fuente se guardan en el mismo directorio, necesitas una forma de diferenciarlo con los paquetes de las otras versiones de ubuntu, y esto se logra modificando la version en el changelog.


#ubuntu-motu: < micahg> kaushal: In Ubuntu, we generally don’t have maintainers
< micahg> kaushal: it’s in universe, so MOTU is responsible for packaging

#ubuntu-motu: < micahg> kaushal: En Ubuntu, normalmente no tenemos mantenedores
< micahg> kaushal: esta en universe, asi que el equipo MOTU es responsable del mismo


#ubuntu-motu: < slytherin> Rhonda: Is there any particular reason why you repackage upstream tarball as .tar.gz for wesnoth?
< Rhonda> Because source format 1.0 doesn’t support .tar.bz2?
< directhex> presumably for backportability
< directhex> that’s the usual reason to repack these days
< Rhonda> And the benefits of source format 3.0 are pretty minor when one is using quilt already

#ubuntu-motu: < slytherin> Rhonda: hay alguna razon particular por la que hayas recomprimido el archivo tarball de upstream de wesnoth a un .tar.gz?
< Rhonda> porque un paquete fuente  en formato 1.0 no soporta archivos .tar.bz2?
< directhex> probablemente para que sea capaz de mandarlo a versiones anteriores (backports)
< directhex> esa es la razon mas frecuente para recomprimir
< Rhonda> eso y que las facilidades que pudiera darme un formato 3.0 serian minimos si ya estoy usando quilt


#ubuntu-motu: < shadeslayer_> geser: uh… im using the new source format … the one with debian/source/format
< shadeslayer> so no need to use the get-orig-source part?
< maxb> You can use source format 1.0 with an explicit debian/source/format – that doesn’t tell us anything :-)
< shadeslayer> maxb: so what do i have to do for fomat v3 ?
< maxb> To enable use of it? Have a debian/source/format that contains “3.0 (quilt)” or “3.0 (native)”
< shadeslayer> maxb: thats what i have :P
< maxb> Right, the point was just that “the one with debian/source/format” doesn’t actually say anything
< geser> shadeslayer: no need for get-orig-source in this case (see point 4 in http://wiki.debian.org/Projects/DebSrc3.0)

#ubuntu-motu: < shadeslayer_> geser: uh… estoy usando el nuevo formato … el que se usa con debian/source/format
< shadeslayer> asi que no necesito usar la parte de get-orig-source verdad?
< maxb> puedes usar el formato 1.0 con un archivo /debian/source/format explicito – eso no nos dice nada :-)
< shadeslayer> maxb: umm, entonces que tengo que hacer para declararlo con el formato v3 ?
< maxb> para poder usarlo? debes tener un archivo /debian/source/format que contenga “3.0 (quilt)” o “3.0 (native)
< shadeslayer> maxb: eso es lo que tengo :P
< maxb> correcto, el punto era que si mencionas que tienes el formato que usa /debian/source/format no nos dices nada
< geser> shadeslayer: no hay necesidad de usar ‘get-orig-source‘ en este caso (ve el punto 4 en http://wiki.debian.org/Projects/DebSrc3.0)


#ubuntu-motu: < carstenh> gubatron: lintian is very helpful to find errors in the package, after you made this dget some/url/whatever.dsc part work and build the package locally you should run lintian -I -E –pedantic *.changes to see packaging errors and warnings
< carstenh> (or without options to see the more major ones if the list is very long)

#ubuntu-motu: < carstenh> gubatron: lintian es muy util para encontrar errores en los paquetes, despues de correrlo usa dget para descargar cualquier/url/descripcion.dsc y compilar el paquete localmente,  ejecuta lintian con las opciones -I -E –pedantic *.changes para ver que errores/advertencias de avienta
< carstenh> (o sin ellas para ver  las mas importantes en caso de que la lista sea muy larga)


#ubuntu-motu: < Laney> the orig.tar.gz should be in the parent directory of the root of your packaging
< Laney> ie debian/../..

#ubuntu-motu: < Laney> el paquete original (orig.tar.gz) deberia estar en el directorio superior de donde tienes el paquete descomprimido
< Laney> por ejemplo debian/../..


#ubuntu-motu: < gastons> Is it possible to use optional dependencies in a control file?
< gastons> Depends: openjdk-6-jre | sun-java6-jre
< micahg> gastons: yes, give a read to the policy 7.1

#ubuntu-motu: < gastons> es posible declarar dependencias opcionales en el archivo /debian/control?
< gastons> Depends: openjdk-6-jre | sun-java6-jre
< micahg> gastons: si, checate la seccion 7.1 de las normas (policy)

13:09 < shadeslayer> so no need to use the get-orig-source part?
13:09 < maxb> You can use source format 1.0 with an explicit debian/source/format – that doesn’t tell us anything :-)
13:10 < shadeslayer> maxb: so what do i have to do for fomat v3 ?
13:13 < maxb> To enable use of it? Have a debian/source/format that contains “3.0 (quilt)” or “3.0 (native)”
13:17 < shadeslayer> maxb: thats what i have :P
13:17 < maxb> Right, the point was just that “the one with debian/source/format” doesn’t actually say anything
13:21 < geser> shadeslayer: no need for get-orig-source in this case (see point 4 in http://wiki.debian.org/Projects/DebSrc3.0)

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