El passat cap de setmana va tenir lloc l’Ubuntu Global Jam i l’equip català d’Ubuntu va aportar-hi el seu granet de sorra. Així, va tenir lloc una marató de traducció i, per la tarda, també es va fer una mica d’introducció a l’empaquetament de programes amb un exemple pràctic: com arreglar un paquet que no compila. Seguint el suggeriment de l’Alex Muntada de fer un resum d’aquesta darrera activitat, m’he decidit a escriure una sèrie d’apunts sobre el tema.

Prefaci

Inauguro la sèrie amb aquest primer apunt, on tot seguit explicaré conceptes generals en quant als “paquets que no compilen” i que fer amb ells; en successius apunts, i per tal de deixar-ho tot ben clar, explicaré els passos necessaris per a arreglar diferents paquets concrets. Depenent de la resposta que rebin aquests escrits, pot ser que més endavant enceti una sèrie nova que tracti algun altre tema relacionat amb els paquets, a partir dels coneixements adquirits amb aquesta.

Introducció

Si esteu llegint això ja deveu saber que en l’Ubuntu els programes venen preparats en forma de paquets; gestors de paquets (com ara l’Afegeix/Elimina, el Synaptic o l’Apt) us proporcionen una llista de tots els paquets disponibles i simplement esperen les vostres indicacions per tal de descarregar, insta?lar i mantenir actualitzats els paquets que us interessin. Ara bé, per increïble que pugui semblar, aquests paquets no apareixen del no-res, sinó que hi ha una munió de gent dedicant temps a crear-los i actualitzar-los.

Quan hom crea un paquet el que fa és agafar el codi font del programa (amb petites modificacions, si convé, com ara arreglar-ne algun error) i afegir-hi la informació necessària per a crear un programa. Un cop això està fet, el paquet font (source package) resultant és enviat al Launchpad (servidor d’Ubuntu), on és compilat per a les diferents arquitectures, tot creant els paquets binaris (.deb) que tots coneixem. Pot ocórrer que un paquet font no compili correctament (i no es creïn els paquets .deb) per a una o més arquitectures; en aquest cas, cal trobar quin és el problema i enviar una nova revisió del paquet al Launchpad. Del fet que un paquet no compili correctament se’n diu FTBFSFails to Build From Source»).

Normalment, poc abans que surti una nova versió de l’Ubuntu, s’intenta tornar a compilar tots els paques dels dipòsits oficials per tal de comprovar que encara compilin correctament. Aquesta operació acaba donant un llarg llistat de paquets que fallen i que convé arreglar. Els motius que els paquets no compilin correctament són diversos, i poden ser coses com ara: l’ús d’una nova versió més estricta d’un compilador (com passa sovint amb el gcc), canvis en les dependències de construcció del paquet (és a dir, en els paquets de que cal disposar per crear-lo, «build dependencies»; pot ser un canvi en el contingut d’algun d’aquests paquets el que provoqui el problema, que hagi canviat el nom d’algun d’ells i ara no el trobi…), etc.

La llista de paquets que no compilen correctament a la Karmic es troba aquí: Build status for Ubuntu Karmic. Passem a veure, en termes generals, que fer amb aquests paquets.

0. Preparació abans de tractar amb paquets (això només cal fer-ho el primer cop)

Abans de posar-nos mans a la obra ens cal preparar el nostre sistema, instal·lant-hi unes quantes eines.

sudo aptitude install ubuntu-dev-tools devscripts debhelper cdbs patchutils pbuilder build-essential

Fem saber el nostre nom a aquestes eines, obrint el fitxer .bashrc i afegint les dues línies següents al final (tot substituint les dades per les nostres pròpies, és clar!):

export DEBEMAIL=usuari@proveidor.com
export DEBFULLNAME="Nom Cognom"

[En cas que disposem d’una clau PGP, convé escriure el mateix nom i l’adreça de correu electrònica tal com els tenim a la clau, tot posant el comentari -si n’hi ha- entre parèntesis i a continuació del nom.]
També crearem un entorn Ubuntu mínim on podem provar de compilar els paquets sense que afectin (ni siguin afectats) pel nostre sistema. [Si no estem utilitzant la Karmic, cal insta?lar el paquet debootstrap del dipòsit -backports corresponent a la versió que utilitzem. També és recomanable agafar la última versió de l’ubuntu-dev-tools.]

sudo ln -s /usr/bin/pbuilder-dist /usr/local/bin/pbuilder-karmic
sudo chmod +x /usr/local/bin/pbuilder-karmic
pbuilder-karmic create

Haurem d’esperar una estona fins que tot el sistema base sigui insta?lat i actualitzat. Per acabar, ens hem d’assegurar que tinguem una línia deb-src per a la Karmic (encara que estiguem utilitzant la Jaunty o l’Intrepid, al ser de codi font això no té importància) al fitxer /etc/apt/sources.list i la llista de paquets actualitzada (sudo aptitude update).

1. Comprovació de l’estat de l’error: ja hi està treballant algú?

Un cop hem triat quin paquet volem arreglar, anem a https://launchpad.net/ubuntu/+source/nom_paquet, comprovem que la última versió indicada sigui la mateixa que a la llista de FTBFS, i comprovem els informes d’error per si ja n’hi ha algun sobre el problema en qüestió. Si és així, comprovem que no estigui assignat a ningú (si ho està, deixem el paquet per ell i ens en busquem algun altre, per no duplicar la feina), mirem si l’informe conté alguna informació rellevant, i ens l’assignem a nosaltres, canviant a  més l’estat a In Progress. Si no hi ha cap informe d’error sobre el FTBFS, en creem un i igualment ens l’assignem a nosaltres i el marquem com a en progrés.

Fet això, comprovem també http://packages.qa.debian.org/nom_paquet, on ens assegurem que a Debian no hi hagi ja una versió nova del paquet que solucioni l’error ni un informe d’error amb informació que ens pugui ser útil. Si fos el cas que a Debian el paquet ja ha estat arreglat, depenent de la situació en tindríem prou amb demanar que sigui sincronitzat a l’Ubuntu (veure sync requests) o bé, si el paquet d’allà té altres canvis que en aquest moment no volem (per exemple una versió amb funcionalitats noves, ja entrada en vigor la Feature Freeze), podem agafar la solució de Debian de forma isolada per aplicar-la al nostre paquet.

2. Obtenció del paquet font

Ara que hem comprovat que el problema encara no ha estat solucionat, potser hem trobat alguna informació útil, i que hem indicat que estem treballant en arreglar-lo, procedim a baixar el paquet font:

apt-get source nom_paquet

Això baixarà tres fitxers al nostre directori actual: nom_paquet_versió.orig.tar.gz, nom_paquet-versió-revisió.diff.gz i nom_paquet-versió-revisió.dsc. El primer és el codi font agafat de l’autor original (<em>upstream</em>), sense modificacions; el segon fitxer és un fitxer de diferències que conté la informació necessària per crear al paquet (que serà posada en un directori anomenat «debian» dins del codi font) i en alguns casos també canvis al codi original, i l’últim fitxer simplement serveix per verificar que els altres dos són correctes (que no ha estat modificats o corromputs pel camí). Automàticament, també descomprimirà el contingut del .tar.gz i li aplicarà els canvis del .diff.gz, de manera que trobarem un directori nom_paquet-versió on treballar.

[En el paràgraf anterior, «nom_paquet» es refereix al nom del paquet font, «versió» al número de versió que li ha posat l’autor original, i «revisió» al número de revisió del paquet, que pren la forma XubuntuY, on X és la revisió de Debian i Y la revisió d’Ubuntu -si el paquet ve directament de Debian, simplement serà X-].

Arribats a aquest punt, podem verificar que realment el paquet no compila correctament, tot intentant-ho amb:

pbuilder-karmic build nom_paquet-versió-revisió.dsc

Per a continuar, ens situarem dins del directori descomprimit:

cd nom_paquet-versió

3. Solució del problema

Ara que tenim el paquet de codi font, hem de trobar la solució al problema. Per a això ens és útil llegir el registre de l’intent de creació del paquet fallit, cercar informació als informes d’error d’Ubuntu i Debian (com ja s’ha mencionat abans) i del lloc web de l’autor original, llegir el registre de canvis del paquet (el fitxer debian/changelog dins del directori de codi font) per si hi ha referències útils, etc. Aquest constitueix el pas crític i més important, ja que si no sabem com solucionar l’error poc podrem fer.

[En cas que trobem un canvi al debian/changelog que sembli rellevant al problema actual, però no l’acabem d’entendre, preguntarem a la persona que l’hagi fet, ja sigui enviant-li un missatge de correu electrònic o cercant-lo a l’IRC (canal #ubuntu-motu o #ubuntu-devel a irc.freenode.org.]

Un cop haguem trobat com solucionar el problema, apliquem els canvis necessaris. Aquests acostumen a consistir en una modificació al fitxer debian/rules (per corregir les instruccions de creació del paquet), debian/control (per corregir les dependències de construcció) o als fitxers de codi font; les modificacions a aquests darrers cal fer-les utilitzant un sistema de pegats, en cas que el paquet ja disposi d’un (podem veure-ho amb l’ordre what-patch), o bé modificant els fitxers directament en cas contrari.

Fet això, haurem d’afegir a la informació del paquet una nova revisió. Per a això executarem «dch -i» i, a l’espai on descriure els canvis, explicarem detalladament què hem fet i perquè. També hi inclourem una referència a l’informe d’error que hem obert (o trobat) anteriorment, de la forma «(LP: #número)». Usualment el format utilitzat és d’aquest tipus:

  * debian/control: Add foo as a build dependency, because the build system invokes command bar provided by the former; this fixes a FTBFS (LP: #123456).

Com veieu, es comença posant el nom del fitxer (o els fitxers) modificat, dos punts, i a continuació s’expliquen detalladament els canvis; cada canvi es posa en una línia separada (començant per « *»).

4. Regenerant el paquet font

Hem arreglat el problema i hem documentat tot en una entrada nova al fitxer debian/changelog. Ara podem procedir a crear un paquet font per a la nova revisió; això ho farem amb l’ordre següent

debuild -S

[És estrany, però pot ser que algun paquet requereixi la insta?lació de part de les dependències de construcció per tal de crear el paquet font. Quan aquest sigui el cas, n’hi ha prou amb insta?lar les dependències mancants i repetir l’ordre.]

Si tot va bé, ara podem tornar al directori pare del codi font (<em>cd ..</em>) i ens trobarem amb dos fitxers nous: un <em>.diff.gz</em> i un <.dsc> per a la nova revisió (l'<em>.orig.tar.gz</em> no ens cal, ja que la versió de l’autor original és la mateixa que abans).

Ara podem tornar a provar de construir el paquet, i si hem fet bé la nostra feina aquest cop funcionarà (i deixarà un o més paquets binaris a ~/pbuilder/karmic_result/):

pbuilder-karmic build nom_paquet-versió-revisió_nova.dsc

Si ha funcionat, felicitats! Per acabar, crearem un fitxer de diferències amb els canvis entre la revisió actual de l’Ubuntu i la nova que hem preparat, tot fent:

debdiff nom_paquet-versió-revisió_original.dsc nom_paquet-versió-revisió_nova.dsc > nom_paquet-versió-revisió_nova.debdiff

El fitxer .debdiff l’obrirem amb un editor de text per comprovar que no s’hi hagi colat cap canvi que no haguem fet. [Si hi ha alguna cosa que no volem, haurem de desfer el canvi al directori del codi font i tornar a regenerar el paquet font, no s’hi val editar el fitxer .debdiff a mà ja que això segurament l’espatllarà.]

Enviant els canvis a l’Ubuntu

Un cop estiguem satisfets amb la nostra solució i haguem provat que funciona, adjuntarem el fitxer .debdiff a l’informe d’error que hem trobat o creat al Launchpad i només ens faltarà que un desenvolupador d’Ubuntu el comprovi i el pugi a l’Ubuntu. Per a això haurem de mirar en quin dipòsit està el paquet, fent:

apt-cache madison nom_paquet

Si la penúltima paraula és «universe» o «multiverse», subscriure’m l’equip «ubuntu-universe-sponsors» a l’informe d’error utilitzant l’opció que trobarem al Launchpad a la dreta; si, en cavi, és «main» o «restricted», subscriure’m l’equip «ubuntu-main-sponsors». Ara, tot és qüestió d’esperar que algú revisi els nostres canvis i els apliqui o bé proposi possibles millores.

Quan els nostres canvis hagin estat acceptats, també els enviarem a Debian, en cas que allà també hi siguin rellevants. Per això simplement enviarem un mail a número_de_l’informe_d’error@bugs.debian.org si ja existeix un informe d’error, o n’obrirem un de nou si no n’hi ha.

Conclusió

Si heu llegit tot això, us felicito, ja que realment heu mostrar voluntat. Com he promès al prefaci, els propers dies escriure uns quants apunts més explicant (de forma més breu) com arreglar alguns paquets particulars, tot veient solucions a diferents problemes.

You are reading: Com arreglar paquets de l'Ubuntu que no compilen?