Forum Ubuntu-it

Con questo post mi rivolgo a chi di voi ha già un po' di dimestichezza con i pacchetti e cerca un'attività alternativa ai classici bugfix. Mi riferisco ai NBS (Not Build from Source), pacchetti binari che non sono più compilati da un dato pacchetto sorgente per vari motivi (FTBFS, versioni più aggiornate, ecc...) ma che vengono mantenuti nell'archivio dato che hanno delle dipendenze inverse (un altro pacchetto dipende da un pacchetto NBS).

Una delle attività da svolgere è cercare di eliminare questi pacchetti, non più utili, effettuando rebuild delle dipendenze inverse in modo che vengano compilati usando le nuove versioni. Per agevolare il tracciamento di questi pacchetti, è disponibile questa pagina, la quale elenca tutti i NBS con i vari pacchetti che hanno una dipendenza esplicita. Facciamo un esempio pratico con xserver-xfree86, rimosso da xorg ma che è dipendenza esplicita di xfree86-driver-synaptics. In questo caso, occorre modificare il debian/control rimuovendo il riferimento a xserver-xfree86, lasciando solo xserver-xorg. In moltri altri casi, è sufficiente un rebuild, un upload contenente solo la voce di changelog, spesso definito come no-change upload.

Se siete interessati all'argomento, cimentatevi in questa attività, non sono richieste abilità particolari, solo un po' di attenzione ai dettagli.

quei pacchetti sono per hardy...
ma presumo che essendo ancora in fse embrionale siamo in pratica identici a gusty...

volevo chiederti:

ho dato un occhiata e avendo già fatto un paio di rebuild semplicemente modificando il debian/control immettendo la versione più aggiornata della dipendenza richiesta che bloccava l installazione potri provare a fare la stessa cosa con questi, ma...

alcuni pacchetti non mi danno errore in fase di installazione come ad esempio foomatic-db-gimp-print.

in questo caso dovrei installarlo e cercare di rmuoverlo per avere qualche riscontro o è stato già sistemato?



edit: installato e rimosso senza alcun problema, quindi credo che il pacchetto "foomatic-db-gimp-print" non abbia problemi

foomatic-db-gimp-print era un pacchetto transitorio ed è stato rimosso. printconf, il pacchetto che dipende da foomatic-db-gimp-print ha una dipendenza opzionale anche su foomatic-db-gutenprint, in questo caso sarebbe buona cosa segnalare al maintainer di rimuovere la dipendenza opzionale a foomatic-db-gimp-print, ormai inutile.

dimmi se va bene.

l ho compilato da sorgente visto che non riuscivo a ricostruire il .deb

ho solamente levato la dipendenza foomatic-db-gimp-print nel control.

p.s. ho rinominato il pacchetto in printconf_0.7.7.1_all.deb ma non ho modificato il changelog.

ho provato ad installarlo con GDebi e non mi chiede la dipendenza in questione  (good)

Il pacchetto .deb mi è poco utile in questo caso, perchè non posso vedere le modifiche che hai fatto (anche se le hai spiegate correttamente).

Se vuoi, possiamo fare tutta la trafila in via ufficiale:

• Apertura del bug su Launchpad
• Pubblicazione del debdiff
• Upload negli archivi

Fammi sapere

facciamo come meglio credi.

non ho fatto niente di speciale, anzi è stato facilissimo (il .deb non riuscivo a ricostruirlo)

quindi:

scaricato il sorgente da http://packages.ubuntu.com/gutsy/utils/printconf
modificato il control levando la dipendenza a partire da:

| foomatic-db-gimp-print

dh_make
debuild binary

tutto quì, questo pacchetto è stato una passeggiata... (speriamo anche con gli altri  )
non ho modificato nient altro.

comunque io ti uppo il control modificato.

visto che ci siamo....

nella tua lista non c' era printconf, ma hai solo menzionato le dipendenze che danno problemi.

potresti stilare una lista dei pacchetti e magari le dipendenze annesse che danno problemi magari evidenziandoli?

in questo modo è più facile capire dove mettere mani e si può velocizzare il tutto.

vediamo fin dove riesco ad arrivare...


es: gnustep-back0.11. http://packages.ubuntu.com/gutsy/libs/gnustep-back0.11
quali sono le dipendenze che devono essere modificate?

steveacab ha scritto: potresti stilare una lista dei pacchetti e magari le dipendenze annesse che danno problemi magari evidenziandoli?
in questo modo è più facile capire dove mettere mani e si può velocizzare il tutto.

Ho creato uno script che se ne occupa, l'output è qui: http://people.ubuntuwire.com/~dktrkranz/NBS/.

steveacab ha scritto: es: gnustep-back0.11. http://packages.ubuntu.com/gutsy/libs/gnustep-back0.11
quali sono le dipendenze che devono essere modificate?

I pacchetti che dipendono da GNUstep seguono una procedura più complessa descritta qui.

ok, vedo di riuscire a correggere qualche altro pacchetto.

con questo cosa facciamo?
Apertura del bug su Launchpad?
Io non so come strutturare il tutto, se magari mi guidi te o apri te la discussione su launchpad è meglio

Siccome ci sono dei problemi sui buildd, possiamo tranquillamente attendere qualche giorno.

ok.

ah, non ho capito come funziona il tuo script

idem cosa si dovrebbe fare con gnustep.

Ok, problemi risolti e pronti per ricominciare.

Discorso GNUstep: ho iniziato a lavorarci ma conviene attendere sviluppi sul fronte Debian siccome le modifiche da effettuare sono più invasive rispetto al previsto. In ogni modo, ci sono alcuni pacchetti in coda di approvazione e non dovrebbe mancare troppo all'ultimazione del tutto. Già metà del lavoro è stato completato, per la cronaca.

Discorso printconf (foomatic-gui): ho aperto un bug in Debian, ma ho qualche dubbio sulla sua risoluzione in tempi brevi. Propenderei per la trafila classica (apertura bug su Launchpad, pubblicazione del debdiff e sponsorizzazione), se riusciamo a trovarci in IRC, vediamo di concludere.

DktrKranz ha scritto: Ok, problemi risolti e pronti per ricominciare.

Discorso GNUstep: ho iniziato a lavorarci ma conviene attendere sviluppi sul fronte Debian siccome le modifiche da effettuare sono più invasive rispetto al previsto. In ogni modo, ci sono alcuni pacchetti in coda di approvazione e non dovrebbe mancare troppo all'ultimazione del tutto. Già metà del lavoro è stato completato, per la cronaca.

Discorso printconf (foomatic-gui): ho aperto un bug in Debian, ma ho qualche dubbio sulla sua risoluzione in tempi brevi. Propenderei per la trafila classica (apertura bug su Launchpad, pubblicazione del debdiff e sponsorizzazione), se riusciamo a trovarci in IRC, vediamo di concludere.

per me va bene...
dimmi su che canale e quando (possibilmente di sera, diciamo verso le 8 va bene).

#ubuntu-it-dev su Freenode, la sera va benissimo (anche perchè il mio server di sviluppo è down e non ho la chiave GPG con me per firmare i pacchetti).