MiniDebconf2010/Materiales
MinidebConf Panamá 2010:
Aspectos básicos de 3.0 Quilt
Josué Abarca, Guatemala (jmaslibre): Abarca_3_0_quilt
Notas:
Los parches se crean tradicionalmente usando diff.
Sistemas de parches para facilitar el proceso: dpatch, quilt.
Para crear un nuevo parche: quilt new {patchName} Añadir un archivo a un parche: quilt add filePath Modificar el archivo. Actualizar el parche: quilt refresh Retirar uno/todos los parches: pop [-f] [-a]. Pero el parche sigue existiendo en el archivo. Aplicar uno/todos los parches: push [-f] [-a]
En paquetes Debian: export QUIT_PATCHES igual a debian/patches (ubicación de los parches) quilt push -a quilt new nuevo.patch quilt add archivo_a_modificar vim archivo_a_modificar quilt refresh quilt pop -a Hacer debian/rules para que utilice quilt.
3.0 quilt
al generar el deb obtenemos con dpkg-buildpackage -rfakeroot archivo .deb archivo orig.tar.gz archivo debian.tar.gz (incluye la carpeta patches) archivo dsc
Ya no genera .diff.gz
Para hacer la conversión: En debian/source/format ponemos dpkg-source 3.0 quilt
Ventajas: Parches separados y bien documentados. NMU más fáciles. debian/rules más sencillo múltiples tarballs soporta bzip2, lzma y gzip soporta la inclusión de archivos binarios.
Desventajas: dpatch permite agregar scripts dentro de parches y quilt no. es nuevo y algunas herramientas no lo soportan a algunas personas no les gusta quilt
Involucramiento en el Software Libre
Víctor Ostorga, El Salvador (vostorga): Involucramiento en el SL - Victor Ostorga
Reportar Bugs a Debian
Marcelo Magallón, Costa Rica (mem): Magallon_reportarbugs.tar
Notas:
¿Qué es un bug? Un error o defecto en un programa, sistema o máquina.
En Debian, es una entrada en el Bug Tracking System que identifica un defecto, un cambio deseado, una tarea pendiente. Vamos a referirnos a los defectos.
En debian hay un paquete llamado reportbug que facilita el reporte de bugs.
reportbug paquete reportbug -f archivo
Existe para que los usuarios provean la información mínima necesaria para que el mantenedor del paquete pueda hacer algo con el reporte.
reportbug genera una plantilla de correo para ser enviada a submit@bugs.debian.org
Agrega información sobre el sistema en el que sucedió el error. Por esto es importante hacer el reporte en el mismo sistema que se manfiesta el error.
Cosas como la versión de debian, información sobre apt, la arquitectura, el kernel usado, configuración de localización, el shell. Quien mantiene el paquete incluso puede incluir scripts que se ejecutan a la hora de hacer un reporte con reportbug.
Todo reporte debe tener la siguiente información en el pseudo-encabezado:
Package: paquete Version: versión Línea en blanco Descripción del problema.
Severidad: ¿qué tan serio es un bug?
Severity: severidad.
Puede ser:critical, grave, serious, important, normal, minor, wishlist. No se refiere a una prioridad. Es una clasificación para decir en qué forma afecta el bug al sistema.
critical, grave, serious quieren decir que puede tener un impacto en el release.
critical: software no relacionado con este paquete se ve afectado. O afecta la seguridad del sistema como un todo. grave: el paquete se torna inutilizable pero no afecta la funcionalidad del resto. O genera un problema de seguridad pero no tan crítico, no le da control absoluto sobre el sistema. serious: es una violación de política. O quien mantiene el paquete considera que no es apto para un release.
reportbug trata de persuadir a los usuarios para qaue no envíen reportes por encima de important. Si no está seguro de la severidad, es mejor no indicarla y el mantenedor luego la agregará. Si está seguro de la severidad, indiquen en el correo cómo llegaron a esa conclusión.
Tags para clasificar bugs: Generales: patch, wontfix, moreinfo unreproducible help pending fixed security upstream confirmed fixed-upstream fixed-in-experimental De uso especial: d-i, ipv6 lfs l10n ... Para identificar distribuciones afectadas: woody sarge edge ... Usertags: agregar tags del usuario.
¿Qué no hacer? - Reportar múltiples errores en el mismo bug. - Omitir información como paquete, versión, distribución, arquitectura ... - Reportar bugs de otras distribuciones. - Reportar bugs en paquetes para debian pero que no son mantenidos por debian. - No ver si el bug fue reportado con anterioridad.
Un bug encontrado en debian puede ser originado por debian o por el desarrollador original del software. Diferenciar puede ser muy dificl.
Generalmente el mantenedor tiene una mejor relación con los autores. Y al usuario no le interesa saber si un problema está resuelto arriba. Es importante ver en qué rama de debian está el error y qué impacto tiene en Debian.
¿Qué incluir?
el texto exacto y completo de los mensajes de error disponibles. Instrucciones de qué hacer para demostrar el problema. Una descripción del comportamiento incorrecto: qué esperaba y que observó. Una sugerencia o parche de cómo resolver el problema, si los tiene. La configuración del programa. Las versiones de las dependencias.
¿Luego de reportar un bug? Primero: espere el mensaje de confirmación del BTS. Luego, cuide sus bugs. Si encuentra más información que pueda ayudar a solucionar el problema, envíela a nnnnn@bugs.debian.org (dirección recibida en la confirmación del bts)
Licenciamiento
Marcelo Magallón, Costa Rica (mem): Magallon_licenciamiento.tar
Notas:
En debian todos los paquetes tienen un archivo de copyright.
Una licencia es un contrato entre el autor y el usuario. En el mundo hay 4 grandes sistemas de derecho distinto. Los dos más usados son derecho romano y common law. El derecho romano funcina por jurisprudencia. Common Law por precedente.
El licenciamiento se inscribe dentro de las leyes de derechos de autor y derechos conexos, de forma que el autor tiene todos los derechos sobre su obra.
En los años 80 Stallman empieza a pensar en la definición de software libre en los términos que los conocemos, las 4 libertades.
En Debian existe el DFSG (Debian Free Software Guidelines) 1. free retribution 2. source code 3. derived works 4. integrity of the author's source code 5. no discrimination agains persons or groups 6. no discrimination agains fields of endeavor 7. distribution of license 8. license must not be specific to debian 9. license must not contaminate other software
Desde el punto de vista de debian tenemos una división entre libre y no libre. Esta se separa en seis secciones: -> main (free) -> contrib (free pero depende de algo en non-free) -> non-free (la posición oficial del proyecto es que esto no es parte de Debian, existe para hacer la vida más fácil a algunos usuarios) -> non-US/main -> non-US/contrib -> non-US/non-free
Los non-US son porque US tiene restricciones de exportación de armamento. Y algún software es considerado por ellos como armamento. Por ejemplo, algoritmos de cifrado fuertes. PGP se desarrollaba fuera de estados unidos y debian lo distribuia desde un servidor en europa. Hoy en día existe una cantidad mínima de software que no se puede exportar de estados unidos.
Debian-legal: una lista de correo que trata con copyright, licencias y patentes.
Debian-legal tests: escenarios en los que dfsg deben cumplirse para decir que un software es libre. - la isla decierta: Imagine a un naúfrago en una isla desierta con una computadora almacenada cno energía solar. En esas condiciones es imposible cumplir con requisitos tales como: los cambios deben publicarse, los parches deben ser enviados a... incluso si estos requisitos son solo en caso de ser solicitados.
- el disidente: en un estado totalitario, si la persona se viera forzada a publicar las modificaciones que hace puede ver su vida en peligro.
- los tentáculos del mal: Mauro trabaja en su empresa y desarrolla programas. Llega una compañía y tiene interés en esos programas. Contrata a Mauro y le paga para que siga desarrollando. Mauro firma con la empresa y por las leyes el trabajo que hace Mauro le pertenece. Una vez que tiene controlados a los autores la compañía hace que los autores modifiquen las condiciones de la licencia para hacerlos no libres. Lo que debian no permite es el cambio retroactivo. O sea, que las libertades que se le habían otorgado a los usuarios se pierdan. Mantener las libertades a futuro sí depende de los autores.
ftp-master es el grupo de desarrolladores que tienen a su cargo la administración del archivo. Ellos se encargan de tomar las cosas que están en new, examinarlas y verificar que cumpla con dfsg.
usualmente faltan manos y es una tarea ingrata. Vetan que entra y que no entra, con criterios mayormente legales pero también técnicos. Muchos desarrolladores los perciben como "enemigos".
mplayer duró entrando a debian cerca de 8 años. La primera razón era estrictamente legal. Por la forma en que utiliza el código, el problema era que no se podía distribuir. Luego de solucionar los problemas legales, el problema fue que estaba feo.
ftp-master trata de errar del lado de la cautela.
El problema más común es compatibilidad. Código que no es posible combinar en un nuevo trabajo, porque no es posible cumplir las condiciones en forma simultánea.
Si una de las dos licencias es la GPL, los términos de la otra licencia no pueden modificar en nada los términos de la GPL.
Licencias duales: poner múltiples licencias al mismo código. Un caso usual es una licencia libre y una no libre.
Tierno, bonito, divertido es diferente de libre. Condiciones como estas hacen al software no libre: - enviarme una postal si le gusta el software - si usted distribuye este software debe acariciar un gato - los usuarios deben sonreirle a alguien que se vea triste
Buenas intenciones es diferente de libre. Condiciones como estas hacen al software no libre: - los cambios deben ser enviados al autor original - si usted encuentra problemas de seguridad no los va a utilizar para aprovecharse de los demás usuarios. Va a reportarlos.
99% libre no es libre
Si dice que los usuarios de este software deben hacer algo, no es libre.
Licencias mutantes: reservo mi derecho de retirar la licencia a los usuarios en el momento que yo quiera.
Introducción a GNUpg
Fernando Estrada, México (fcestrada): Estrada- Introducción a GnuPG
Notas: La criptografía nace de una aplicación militar. Cómo transmitir un mensaje a alguien tomando en cuenta que puede ser interceptado.
Clave simétrica: se comparte una clave. Cifrado asimétrico: consiste en una clave pública y una privada. La pública se distribuye y la privada se oculta.
GNUPG reemplazo libre de PGP para cifrado y firma de mensajes.
GPG cifra los mensajes usando pares de claves individuales.
Para instalar la aplicación: sudo aptitude install gnupg
Con el paquete instalado, para genera una clave: gpg -gen-key
Luego les va a preguntar cuál algoritmo quieren utilizar. Vamos a utilizar RSA, porque permite tanto cifrar como firmar.
Luego va a preguntar el tamaño de las claves que quiren generar. El tamaño es el nivel de seguridad de la clave. Aún no hay pruebas de que se haya comprometido la seguridad de las claves de 2048. Pero recomiendo usar 4096.
Luego pregunta en cuanto tiempo quiere que caduque la clave. La mayoría pone que nunca expire, pero no es muy recomendable. Esto luego se puede modificar.
Luego nombre, correo y un comentario sobre la clave.
Después de la confirmación genera la clave.
Si se escoge un tamaño muy grande, la computadora no va a tener suficiente entropía para generar la clave.
Generardo un certificado de revocación:
Inmediatamente después de generar la clave se debe generar un certificado de revocación. Si la clave queda comprometida, se puede utilizar para revocarla y que todos los que la tengan se enteren que ya no es válida. Es recomendable imprimirla o guardarla en un CD o USB, y almacenarla en un lugar seguro.
Con gpg se puede firmar y cifrar información. Firma: Si se quiere transmitir un mensaje y que la persona que lo recibe tenga la certeza de que el mensaje llegue integro. Cualquiera podría ver el mensaje. Cifrar: Quiero que solo el destinatario vea el mensaje.
Se puede cifrar y firmar a la vez.
gpg -edit-key IDClave para administrar las claves.
Servidores de claves Utilizar servidores de claves para que todo el mundo pueda obtener nuestra clave pública. Y podemos hacer una petición para recibir la clave de cualquier persona.
Firmar claves: Si firmamos una clave estamos diciendo que esa persona es quien dice ser. Que la conocemos, y la hemos validado por medio de una identificación oficial como cédula o pasaporte. Sirve para aumentar el círculo de confianza.
¿GNUPG en Debian? El primer requisito para ser desarrolladores es tener la clave firmada por almenos un desarrollador de Debian. Se utiliza para firmar los paquetes, emitir votos y demás actividades que requieren autenticación.
Signing Party: Se intercambian claves públicas. Las claves tienen un fingerprint. Eso es lo que se intercambia.
paquete signing party. gpg-key2ps
Mantener paquetes Debian en equipo
Alejandro Ríos, Colombia (alerios): alerios_mantener paquetes
Notas: Paquetes necersarios: aptitude install build-essential lintian fakeroot debhelper dh-make dpkg-dev devscripts
Las tareas de empaquetamiento son más de gestión que técnicas.
Descargar, descomprimir y explorar: mkdir hello cd hello wget http://ftp.gnu.org/gnu/hello/hello-2.3.tar.gz tar -xzvf hello-2.3.tar.gz cd hello-2.3
Debianización inicial: dh_make -s -c gpl -f ./hello-2.3.tar.gz Edición de scripts en ./debian/: -copyright: Derechos de autor y licencia. -control: Dependencias y descripción. -compat: Versión del sistema de empaquetado. -changelog: Información sobre cada versión. -rules: Reglas para compilación e instalación. -README.Debian: Doc. específica de Debian.
Construcción:
dpkg-buildpackage -rfakeroot
Verificación:
cd .. lintian -i *.changes lesspipe hello_2.3-1_i386.deb | less
Instalación y pruebas:
dpkg -i hello_2.3-1_i386.deb hello
Debian Package Internals
René Mayorga
Notas:
Entender qué es un paquete .deb y cómo funciona.
¿Qué es un .deb? Es un contenedor ar. Contienen varios archivos como debian-binary, control.tar.gz y data.tar.gz.
Estos contenedores son archivos precompilados para una arquitectura y archivos de control y configuración.
Tipos de paquetes: Single-binaries: Contienen solo un binario con su documentación y archivos. Multiple-binaries: paquetes fuente que generan varios binarios de un mismo tarball. Meta packages: (como los de gnome y kde) sólo crean una dependecia a los paquetes que instala. Source packages: el paquete fuente, compuesto de orig.tar.gz, diff.gz y .dsc. Cambiará mucho con la introducción de 3.0.
Versiones de los .deb. Nombre epoch upstream-version revisión-inicial indicador-numero-nmu indicador-numero-binNMU arquitectura
epoch: (agregado por debian) Se usa cuando el número de versión de upstream cambia radicalmente, para darle una secuencia numérica ascendente. Por default es 0.
nmu: non-mantainer upload.
Tips para descifrar las versiones: dpkg --compare-versions 5.2.0 gt 5.2.1 gt para ver si una es mayor que otra.
Contenido. Deb file
-> control.tar.gt Son archivos de control, no es el software que se instalará. --> confiles: lista de archivos de configuración. Los designa el mantenedor para que dpkg los mantenga y pregunte si deben ser sobreescritos en las actualizaciones (Debian policy 10.7.3). --> control file: muestra las dependencias y mucha más información del paquete. --> debconf: conserva partes como templates y el archivo config. Los templates mantienen las traducciones para las preguntas de debconf y el config es el script que genera las acciones y preguntas. --> mantainer scripts: encargados de configurar el paquete en actualizaciones, instalaciones y desintalaciones. (prem, postrm, preinst, postint)
-> data.tar.gz El contenido binario de todo lo que se va a instalar. Con base a esto se genera el package.list.
ar -x para descomprimir un paquete.
Apt o aptitude gestiona cómo se va a instalar el paquete. Determina si tiene dependencias, conflictos y si puede ser instalado. Primero instala todas las dependencias. Almacena el paquete y utiliza dpkg para instalarlo.
Depends: dependencias del paquete con versiones específicas. Suggests: sugerencias de paquetes extra (no instalado de forma predeterminada) Recommends Conflicts Provides Replaces Debian policy 7.2
Estados de los paquetes en dpkg:
Se especifican con base a la salida de los mantainer scripts.
not-installed config-files: en el sistema solo existen los archivos de configuración half-instaled: la instalación del paquete no se completó unpacked: los archivos fueron desempacados pero half-configured: installed
Los mantainer script son posix scripts que se ejecutan en diferentes fáses del proceso de instalación. Crear/eliminar usuarios detener/ejecutar servicios fijar permisos de archivos crear bases de datos
Si algo falla, dpkg puede tomar acciones con base en los mantainer scripts.
Kernel a la Debian-way
Hector Colina
Notas:
¿Qué es el kernel? interfaz de comunicación con el hardware para administrar sus recursos. Está compuesto por cientos de módulos y muchos scripts.
¿Quién hace el kernel? Voluntarios, empleados de empresas, investigadores.
¿Dónde consigo el kernel? En el sistema de paquetes de su distribución. Algunos sitios especializados. Hay personas que se dedican a configurar kernels para ciertas cosas especializadas.
¿Qué herramientas necesitamos? make, gcc, libncurses5-dev (no necesario, pero más cómodo), bzip2 lspci y kernel-package
Forma tradicional: descargar el archivo bz2 a /usr/src tar xvfj kernel cd kernel make config (la forma masoquista) o make menuconfig (requiere libncurses) o make xconfig (con gui) make bzImage (puede tardar 3 horas en una máquina lenta y 1 en una rápida); make modules; make modules install copiar el kernel resultante a /boot agregar el nuevo kernel en el gestor de boot. reiniciar y rezar.
Debian way: make-kpkg --initrd kernel_image Crea un .deb que al ser instalado instala los módulos, el kernel y lo agrega al menú de boot.
pbuilder
Héctor Colina
Notas:
pbuilder constructs a chroot system, and builds a package inside the chroot. It is an ideal system to use to check that a package has correct build-dependecies. It uses apt extensively and a local mirror or a fast connection to a Debian mirror is ideal, but not necessary.
Porque descarga un ambiente limpio de Debian (unos 100MB) y otras dependecias que podrían ser 200MB adicionales.
Lo usan desarrolladores del proyecto y aspirantes.
Errores típicos que detecta: make mal hecho, falta de bibliotecas, archívos de debian mal construidos...
aptitude install pbuilder pbuilder archivo.dsc
Traducción e internacionalización en el proyecto Debian.
Luis Uribe
Notas:
Para tener un sistema operativo universal deberíamos tener el sistema disponible para personas que hablen cualquier idioma. Eso facilita al usuario nuevo el ingreso al proyecto.
Datos a tener en cuenta: No hacer traducciones literales. Trato formal al lector. Utilizar tiempos verbales más utilizados en español, no necesariamente es la traducción directa del inglés. Separadores numéricos según la región. Seguir las reglas del uso de las comillas tipográficas del español. Utilizar un corrector ortográfico.
Existe un glosario de Debian, con las traducciones utilizadas en palabras comunes o conflictivas. No está escrito en piedra, es una discusión muy abierta para buscar una traducción correcta.
Proceso de traducción: Un traductor avisa que se va a hacer cargo de algo. El traductor envía una versión para revisión. Retroalimentación y resolución de dudas entre el grupo. Se añade la traducción al paquete. El traductor termina el proceso.
Estados de la traducción: ITT (Intent to translate: intención de traducción) RFR (Request for review: solicitud de revisión) ITR (Intend to review: intención de revisión) LCFC (Last chance for comments: ultima oportunidad para embiar comentarios) BTS (Bug tracking system) DONE (traducción terminada)
¿Qué le hace falta al robot de traducciones? Que se puedan enviar los po comprimidos en los correos. Permitir múltiples adjuntos Analizar el po adjunto
La idea para squeze es que hayan 66 lenguajes completamente traducidos en el debian instaler.
Por dónde comienzo?
Leer las normas, seleccionar el área en la que quiero colaborar, traducir, revisar traducciones de los demas. Divertirse, principalmente.
Propuesta de proyecto de colaboración de hispanoamérica.
Notas:
La motivación principal fue encontrar un hilo que nos una de aquí hasta la próxima cita. Debemos sistematizar lo que tenemos aquí. Por ejemplo, el equipo que organizó el evento por el conocimiento y la experiencia que obtuvieron. El equipo de video también tuvo problemas, que es información valiosa.
Propuesta de equipo de infraestructura: Hosting con un CMS (wiki y rss bidireccional) Lista de correo Canal IRC Articulación: inclusión de otros grupos (PoSOL, GissTV) Propuesta de nombre de dominio: ¿sugerencias?
Equipo de video: Equipo necesario (cámara, micrófono, computadora, disco duro). Se puede hablar con el videoteam de debian, buscar préstamos, patrocinios... Respuestas conseguidas: se puede usar giss.tv con gstreamer, giss.tv tiene muchos scripts pero se pueden empaquetar. Se necesita infraestructura: conexión, etc. Sitio para organizar la información.
Equipo de contenidos: IRC: ¿charlas mensuales? Podcast: ¿charlas frecuentes? ¿noticias semanales de latinoamerica? ¿documentación?
¿Próxima cita? Apoyarnos en el equipo que hizo esta cita y a partir de eso buscar la próxima sede.
