[19:58] quit [20:29] ciao Dolasilla :) [20:31] * warp10 saluta [20:31] hola warp10 [20:31] vietta: o/ [20:31] XD [20:33] ciao vietta!! :) [20:33] Ok, a parte gli assenti giustificati manca solo una persona dei 6 iscritti, quindi aspettiamo qualche minuto [20:33] * Dolasilla stava già dormendo...pessimo inizio [20:34] Dolasilla, XD [20:34] warp10, hai portato la forchetta? [20:34] * warp10 apre una fialetta puzzolente vicino a Dolasilla per tirarla su [20:34] vietta: ho solo armi chimiche [20:35] lol warp10 armi chimiche antisonno? [20:35] * Dolasilla rinsavisce per un attimo ma poi ricrolla [20:35] hahahah [20:42] ciao a tutti [20:42] bene [20:42] scusate in ritardo [20:42] ciao Mony_ [20:42] Direi che possiamo partire [20:42] ché tanto si sa che gli assenti hanno sempre colpa :P [20:42] :P [20:43] :) [20:43] Allacciate le cinture di sicurezza, mettete lo schienale della poltrona in posizione verticale, chiudete il tavolino di fronte a voi, seguite le indicazioni degli assistenti di volo e ricordate che per tutta la durata del volo non potrete usare apparati elettronici [20:43] A meno che non sia il vostro computer, ovviamente :) [20:43] XD ahhh mbhè [20:43] E ricordate anche che questo canale è loggato, e che tutto quello che direte sarà usato contro di voi quando meno ve lo aspettate :) [20:44] lol [20:44] ecco così nessuno farà più domande [20:44] spventatore di masse che non altro XD [20:44] Sorvoliamo sulle presentazioni, che tanto bene o male credo che ci conosciamo tutti. Facciamo come nei meeting seri e dichiariamo nome e cognome così: [20:44] * warp10 <-- Andrea Colangelo [20:44] ehm... [20:45] * vietta <-- vietta [20:45] <-- Monia Spinelli [20:45] alias silvia [20:45] * Dolasilla = Silvia Bindelli [20:45] Bene. Oggi quindi parleremo di packaging e di sviluppo di Ubuntu. [20:46] La prima parte del tempo che trascorreremo insieme sarà più teorico e discorsivo, nella seconda parte (e nelle prossime puntate, magari) ci sporcheremo un pò le mani, invece :) [20:46] Cosa sono i pacchetti, quindi? [20:46] Beh, il discorso è molto semplice [20:46] I pacchetti sono delle specie di contenitori dentro i quali ci sono tutti i file già compilati e pronti per essere installati ognuno nella posizione giusta all'interno del filesystem [20:46] Credo che questo sia già abbastanza chiaro a tutti [20:47] Piuttosto che scaricare la tarball e fare il solito ./configure, make, make install, con tutte le dipendenze rotte, le compilazioni fallite e bla bla bla, arriva un oggetto già cucinato e pronto [20:47] Un pacchettino comodo e pieno di fiocchetti che piacciono a Dolasilla [20:48] \o/ [20:48] Non solo semplificano la vita dell'utente che ha un attacco di panico quando sente parlare di Makefile, quindi, ma permettono di gestire in maniera automatica le dipendenze, permettono delle disinstallazioni pulite, e tanti altri vantaggi. [20:48] Insomma, i pacchetti ci piacciono da morire, sono una delle più grandi invenzioni dell'umanità dopo la ruota, la stampa e il telepass, e non vogliamo assolutamente farne a meno. [20:49] L'utente che vuole installare un programma non deve fare altro che lanciare USC, oppure synaptic, oppure apt-get, oppure quello che vuole, e il suo programma preferito tirerà giù dall'archivio il pacchetto, insieme a tutte le sue dipendenze, e installerà il tutto senza fare domande difficili (e anche senza fare il difficile, come nella compilazione a mano). [20:49] Ora, che cos'è l'archivio? [20:49] Puntate il vostro browser su http://archive.ubuntu.com e sarete entrati all'interno dell'archivio di Ubuntu! [20:50] (Pulitevi bene le scarpe sullo zerbino e non fate fotografie, è vietatissimo) [20:50] Organizzati secondo una gerarchia di cartella ben precisa, e che in realtà ci interessa molto poco approfondire, dentro la cartella ubuntu/ e nelle varie sottocartelle, ci sono *tutti* i pacchetti che compongono la nostra distribuzione preferita. [20:51] Se volete vedere i pacchetti veri e propri, andate su ubuntu/pool/ e scoprirete che lì ci sono 4 sottocartelle: main, restricted, universe, multiverse [20:51] Il nostro archivio infatti è quadripartito secondo uno schema ben preciso: [20:51] - main contiene software libero supportato direttamente da Canonical (ma anche dalla comunità): alcune centinaia di pacchetti (sopra la migliaia, IIRC) [20:51] - restricted contiene software non libero supportato direttamente da Canonical (ma anche dalla comunità): poche unità di pacchetti [20:52] - universe contiene software libero gestito principalmente dalla comunità: svariate migliaia di pacchetti [20:52] - multiverse contiente software non libero gestito principalmente dalla comunità: qualche decina di pacchetti [20:52] Qualcuna sa quanti pacchetti in totale ci sono nel nostro archivio? [20:53] 42? [20:53] * Dolasilla torna a dormire prima di essere cazziata [20:53] Dolasilla: quello è il QI di alcuni che bazzicano #ubuntu-it-chat [20:54] La risposta ce la dà Launchpad (un sito web estremamente importante per i MOTU, lo vedremo), che ci dice che in Precise (la versione di Ubuntu in fase di sviluppo) ci sono quasi 20.000 source package e oltre 38.000 binary package (cfr.: https://launchpad.net/ubuntu/precise) [20:54] (La differenza tra source package e binary package la vedremo tra breve) [20:54] Capite bene che, a parte restricted e multiverse che contano veramente poco (anche se ci sono dei pacchetti che, purtroppo, sono indispensabili per molti), il grosso è in main (dove ci sono pacchi assolutamente essenziali) e in universe (da dove viene la stragrande maggioranza del nostro software). [20:55] Purtroppo, l'archivio è una bestia difficile da domare. [20:55] Dentro all'archivio possono succedere cose spiacevoli come inconsistenze, pacchetti che non buildano, altri che hanno dipendenze incrociate, altri che non hanno una dipendenza buildata e non sono installabile, e così via, il tutto per tacere dei singoli pacchetti, che possono avere bug più o meno gravi, legati al packaging, nati in Debian o arrivati direttamente da upstream. [20:56] Uhm... avete chiaro cosa intendo quando parlo di "upstream"? [20:56] * vietta sì [20:56] no, l'ultima cosa non mi è del tutto chiara [20:57] Mony_: upstream è lo sviluppatore del software [20:57] Mony_: e in generale, è quello che sta "sopra" di noi [20:57] Mony_: anche debian, da cui derivano molti dei pacchetti dell'archivio è un nostro upstream [20:57] ok chiaro, grazie [20:58] Mony_: gli autori di Firefox, o di GNOME, o di quell'altro con la K, o di chromium, etc., sono il nostro upstream [20:58] Il concetto di upstream è importante, lo useremo spesso [20:58] Nota a latere: interrompete in qualsiasi momento, quando avete dubbi... nisciuno è nato imparato! (cit.) :) [20:59] * Dolasilla chiarisce per tutti e che "quell'altro con la K" è proprio KDE [20:59] * warp10 ricorda che KDE ormai lo usa solo Dolasilla e altri due sventurati [20:59] Insomma, dicevamo dell'archivio e del gran caos che c'è lì dentro [20:59] per gestire tutto questo gran casino servono delle persone di assoluta integrità morale, dei supereroi che non hanno paura di nulla e che lottano per il Bene contro il lato oscuro della forza: gli Ubuntu Developer [20:59] * vietta ricorda a warp10 che mooolti prog per kde sono migliore di quelli per gnome esempio su tutti kate :P gedit bleah [21:00] * warp10 ricorda a vietta che esiste solo vim. E basta. [21:00] Gli Ubuntu Developer sono quei loschi figuri semisconosciuti ai più che tengono a bada pacchetti e archivio, facendo in modo che Ubuntu abbia sempre programmi aggiornati, ben installabili, ben funzionanti e senza bug. [21:00] * vietta dice... casomai vi [21:00] (Se avete installato Oneiric, forse converrete con me che non sempre questi risultati sono stati raggiunti :)) [21:01] Sono personaggi misteriosi, che lavorano nell'ombra, senza ricevere mai un grazie da nessuno quando le cose vanno bene, ma che prendono tanti insulti quando le cose vanno male. [21:01] Avete visto il film "Bastardi senza gloria"? Ecco, il titolo è ispirato esattamente dagli Ubuntu Developer. :) [21:01] Scherzi a parte, il "lavoro" di Ubuntu Developer è estremamente divertente, e anche gratificante. [21:02] Tutto sommato è anche un'attività molto formativa ed educativa: io ho imparato un sacco di cose che non riguardano strettamente il packaging, facendo il packager. [21:02] Piccola curiosità: gli UD sono anche noti come MOTU, acronimo di Master Of The Universe (+1 punto per chi coglie il gioco di parole, +2 punti per chi coglie anche il riferimento fumettistico). [21:03] (Precisazione: UD non è strettamente sinonimo di MOTU. In realtà i MOTU sono un sottoinsieme degli UD, che hanno accesso solo a universe e multiverse. I privilegi di accesso all'archivio sono distribuiti su varie categorie. Cfr. https://wiki.ubuntu.com/UbuntuDevelopers per tutti i dettagli) [21:03] Ma insomma, cosa fanno di preciso gli Ubuntu Developer? [21:03] Developer significa Sviluppatore. Ebbene, gli Sviluppatori di Ubuntu in realtà sviluppano ben poco :) [21:04] Il nostro "lavoro" è più che altro legato al bugfixing e ai nostri rapporti con Debian e con gli upstream. [21:04] Spenderò poche parole su Debian, ma sono parole fondamentali: il rapporto con Debian è probabilmente la cosa più importante del nostro lavoro, sia dal punto di vista tecnico che da quello "politico". [21:05] Circa i 3/4 del nostro archivio arrivano da Debian senza alcuna modifica. Buona parte del quarto rimanente è formato da pacchetti che arrivano da Debian e che noi modifichiamo per creare l'identità della nostra distribuzione. [21:05] Anche dal punto di vista "politico", come dicevo, è importante mantenere delle buone relazioni con i nostri colleghi Debian Developer, per poter collaborare insieme in maniera fattiva. [21:05] E questo non vale solo per i MOTU e gli UD in generale, anche voi come contributori avrete a che fare con Debian, molto presto [21:06] Vi rivelerò una notizia forze sorprendente: un buon UD non è necessariamente uno strepitoso programmatore, un grande tecnico e/o un eccezionale informatico. [21:06] Ci sono molti UD che fanno un gran lavoro senza conoscere granchè in fatto di programmazione. [21:07] Un UD deve avere grandi doti come investigatore: capire subito dove sta il problema e intuire subito qual è la strategia migliore per risolverlo. [21:07] Un UD è soprattutto un buon comunicatore. L'UD è in una posizione tremendamente difficile, al centro di un pentacolo che ha ai vertici: 1) gli utenti; 2) i colleghi UD; 3) Debian; 4) Upstream 5) Downstream [21:08] Nota: I nostri Downstream sono le distribuzioni derivate, come Mint o altra analoghe. Ubuntu è un downstream di Debian, per dire. (Come vedete i concetti di up- e down- stream sono molto relativi) [21:08] Un buon UD riesce a far dialogare tra di loro i 5 vertici del pentacolo e a farli lavorare bene, ungendo adeguatamente gli ingranaggi che muovono il meccanismo (che spesso sono assai arrugginiti). Servirebbe qualche esempio pratico per spiegare queste parole, ma lo vedremo più avanti. Per ora fidatevi :) [21:09] Ovviamente, un UD possiede anche delle nozioni tecniche indispensabili per poter fare il proprio lavoro, e le basi di queste nozioni sono proprio le cose che vedrmo tra pochissimo. [21:09] * vietta inizia a preoccuparsi [21:09] Un'altra cosa su cui spendo poche righe ma che è importantissima: non è indispensabile essere un UD per contribuire allo sviluppo di Ubuntu. [21:10] * warp10 tranquillizza vietta: è tutta roba semplice... tanta, ma semplice :) [21:10] Chiunque di voi può fare del lavoro utile senza avere accesso all'archivio, sfruttando il meccanismo della sponsorizzazione. [21:10] Qualcuna di voi si è già fatta sponsorizzare qualcosa in archivio? [21:10] di altre distro sì [21:11] in cosa consiste la sponsorizzazione? [21:11] Allora vietta sa già che sponsorizzare significa che un UD verificherà il vostro lavoro e lo caricherà in archivio in vostra vece. [21:12] Voi fate il lavoro e ve ne prendete tutti i meriti e i riconoscimenti, l'UD verificherà che sia tutto a posto e userà la sua chiave magica per aprirvi la porta dell'archivio [21:12] Tutto sommato, un UD è soltanto una persona che, lavorando assiduamente nel tempo, ha dimostrato che in lui si può riporre sufficiente fiducia da consegnargli la chiave di cui sopra, senza temere che appena arrivato sfascerà tutto [21:12] Tuttavia per contribuire felicemente ad Ubuntu il possesso di questa chiave è del tutto non è necessaria! [21:12] ho caricato molti pacchetti e bugfix in Debian, ma non sono un Debian Developer! [21:13] E che ve lo carichi un UD, o che lo carichiate voi stessi, la sensazione di vedere il vostro nome nelle mail automatiche che annunciano i nuovi upload, e la consapevolezza di aver restituito un contributo concreto ad un progetto che voi e milioni di altre persone utilizzano quotidianamente, beh, è impagabile. :) [21:13] Così come è impagabile l'emozione di andare in giro per aeroporti, università, bar e tanti altri luoghi, e vedere perfetti sconosciuti che aprono il portatile con Ubuntu (o con Debian, perchè no?), e tu sai che un pezzettino piccolo di quello che loro stanno usando l'hai fatto tu. Dopo 3 anni che sono UD, io mi emoziono ancora quando mi capita :) [21:14] warp10, tenerone lol [21:14] Insomma, il perfetto contributore ha tanto buon senso, molto acume, è un grande comunicatore, e conosce bene gli aspetti tecnici del packaging [21:14] Per poter contribuire ad Ubuntu è necessario conoscere bene come funzionano i pacchetti e come si costruiscono [21:15] E' un bagaglio di conoscenze abbastanza consistente e numeroso, e all'inizio la sensazione è di grande confusione, lo so... ci sono passato anch'io :) [21:15] Noi però affronteremo il discorso in maniera molto "easy" [21:15] Tutto chiaro fin qui? [21:16] Non abbiamo detto nulla di sconvolgente, tutto sommato [21:16] tutto chiaro ;) [21:16] Bene. La prima cosa importante da capire è la distinzione tra i source package e i binary package: sorgenti e binari. [21:17] Dicevamo prima che normalmente si prendono le tarball (sorgenti) e poi si compilano per ottenere il programma eseguibile (binari), giusto? [21:17] Bene, il parallelismo è perfettamente conservato: il source package è la tarball originale che arriva da upstream condita con le istruzioni legate al packaging. Il binary package è il prodotto finito, il file .deb che gli utenti installano (o a mano con dpkg/gdebi/USC/etc., o automaticamente con synaptic/apt-get/USC/etc.) [21:18] Come packager, nel 99% del tempo noi lavoriamo solo ed esclusivamente sul source package. Il .deb ci serve solo come verifica finale che tutto sia andato a posto, ma non modificheremo *mai* nulla lì dentro. [21:18] Anche perchè in archivio si caricano solo i source package, e non i binari, e quelli sono generati dai build daemons. Quindi, una volta creati, non si toccano più [21:19] Perciò le cose devono funzionare bene da subito, le manipolazioni sui .deb sono impossibili [21:19] Per le più curiose, vi invito ad aprire un file .deb e a vedere cosa c'è dentro: è un banale archivio in formato ar (non "tar", proprio "ar"), e dentro ci sono due categorie di cose: 1) i file che saranno installati fisicamente sull'hard disk; 2) una serie di metadati che servono a gestire il pacchetto, cose come nome, numero di versione, dipendenze, etc [21:20] 1 binary package è composto da 1 file .deb quindi, e contiene i binari compilati. Piuttosto semplice, no? [21:20] Il source package è un oggetto più articolato, perchè è composto da 3 file distinti. Questa terna di file è inscindibile. Non ha senso parlare di uno di questi file se non congiuntamente agli altri. Uno e trino, come altre cose di stretta attualità nei giorni del Santo Natale. :) [21:21] Cerchiamo di capire bene cosa sono questi tre file e cosa rappresentano, perchè sono il nostro pane quotidiano: [21:21] - 1 file ha estensione .orig.tar.gz, ed è lo stesso identico file che si tira giù dal sito web upstream, semplicemente rinominato secondo uno schema opportuno (ovvero: _.orig.tar.gz) [21:21] (ovvero è la stessa tarball che ci insegue dall'inizio, quella su cui dovremmo fare ./configure, make, make install) [21:22] o/ [21:22] E ora, signore e signore, permettetemi di introdurvi l'affascinante gaspa [21:22] buon amico e eccellente ubuntu developer, che viene a dare man forte [21:23] gaspa: arrivi giusto in tempo, cominciavamo a sporcarci le mani con noiosissime robe tecniche [21:23] buonaseeeeeera. (puntualissimo, eh?) [21:23] ciao gaspa [21:23] gaspa, :-* [21:23] ciao gaspa [21:23] :) [21:24] gaspa: si parlava di source package [21:24] gaspa: e della sacra terna di file [21:24] * gaspa era qui per imparare qualcosa... [21:24] il primo file quindi è la tarball che arriva da upstream, e non si tocca: si rinomina solo [21:25] - 1 file ha estensione .dsc, è un file di testo, e contiene una serie di metadati che riguardano il pacchetto. In un certo senso, è il file "principale" dei tre. [21:25] se gaspa vuole farmi vedere un suo lavoro può mettere il source package (i tre file) su internet da qualche parte, poi gli basta darmi il link del .dsc, e il tool dget farà tutto, lo vedremo presto [21:26] - 1 file con estensione .diff.gz (oppure .debian.tar.gz, vedremo dopo la differenza), che contiene un file di testo compresso che altro non è che una patch che viene applicata al contenuto del file .orig.tar.gz. Questa patch contiene tutte le modifiche che noi facciamo per il packaging, e che tipicamente sono contenute in una serie di importantissimi file all'interno della cartella debian/ [21:26] Avete le idee sufficientemente chiare su questi 3 file? Presto li vedremo in azione, ma se avete dubbi parlate ora (o tacete per sempre) [21:28] O siete tramortite o è tutto chiaro... propendo per la seconda :) [21:28] Ogni volta che tirate giù un source package, scaricherete questi tre file. Per poterci poi lavorare su dovete fare tre cose: 1- controllare l'hash dei file per assicurarvi della loro integrità; 2- decomprimere il file .orig.tar.gz (creerà una cartella chiamata - con dentro tutti i file originali); 3- decomprirmere il file .diff.gz (o .debian.tar.gz) e applicarlo alla cartella creata al punto 2. [21:29] A questo punto avremo nella root del source tree (ovvero nella cartella -) una cartella debian/ con una serie di file su cui lavoreremo e faremo le modifiche del caso. [21:29] Quindi, alla fine la cosa che ci interessa davvero è questa cartella debian/ e soprattutto i file che sono lì dentro. [21:29] Per approfondire l'argomento, tiriamo giù un pacchetto dall'archivio e vediamo cosa c'è dentro, così cominciamo a sporcarci le mani sul serio. [21:30] Aprite un terminale, create una cartella qualsiasi, diciamo che la chiamiamo packaging/, entrateci dentro e lanciate questo comando: [21:30] apt-get source tennix [21:30] Il comando apt-get quando viene lanciato con l'opzione source non installa alcun binary package, bensì scarica il source package indicato (tutti e tre i file, ovviamente), ed esegue automagicamente tutte le operazioni che vi ho indicato sopra [21:31] In questo caso quindi, vi ritroverete scaricato il source package di tennix, un giochino di tennis banalotto ma simpatico. E' un pacchetto al quale sono sentimentalmente legato: è stato il mio primo pacchetto creato da zero e caricato in Debian. :) [21:31] Avete scaricato tutte il source package di tennix? [21:31] Se avete una connessione a criceti come quella che ho io qui, potrebbe volerci qualche secondo in più [21:32] scaricato [21:32] Bene. Mony_? Dolasilla? [21:33] sta scaricando [21:33] dalla sicilia ci vuole un po [21:33] :P [21:33] scaricato [21:33] Mony_: criceti anche tu, eh? [21:33] benone [21:33] Dolasilla è in Francia e ci mette tanto tempo, ma noi la ignoriamo bellamente [21:34] Dolasilla è a scoppio ritardato [21:34] ma ora sta scaricando [21:34] Se adesso fate ls, scoprirete che ci sono esattamente i tre file del source package (.orig.tar.gz, .debian.tar.gz e .dsc) e una cartella. Notate anche che i nomi dei file non sono casuali, bensì rispettano una sintassi ben precisa (che vi ho già accennato) [21:34] ;) [21:34] Dolasilla: s/a\ scoppio// [21:35] La cartella altro non è che è il file orig spacchettato al quale sono state aggiunte le modifiche inserite nel file .debian.tar.gz (che, vi ripeto, è una normalissima patch e può essere aperta con un qualsiasi editor di testo) [21:35] Entriamo dentro la cartella per vedere che cosa c'è, sempre da terminale. [21:36] cd tennix-1.1/ [21:36] Vedete che c'è una marea di file, molti .c, .cc e .h che compongono il sorgente del programma, un pò di file di testo con informazioni assortite, un paio di cartelle che contengono documentazione e alcune immagini. Ma soprattutto c'è la cartella debian/ [21:37] Tutti i file che vedete, tranne debian/, sono il contenuto del file .orig.tar.gz, che, vi ripeto, viene dritto dritto dal buon Thomas Perl, lo sviluppatore upstream di tennix. debian/ invece l'abbiamo creata noi ed è lì che come packager abbiamo totale dominio. [21:37] Noi non modifichiamo nessun file al di fuori di debian/ infatti, e quando dobbiamo farlo per correggere qualche bug upstream usiamo una particolare metodica che fa sì che comunque la nostra patch sia contenuta in debian/. Ma questo è un argomento più avanzato e lo tratteremo in una prossima puntata. [21:38] Tutto chiaro fin qui? Se qualcuno ha le idee confuse, chiariamoci per bene ora prima di andare avanti, mi raccomando. Queste cose anche se sono semplici tendono ad essere confusionarie. Domande? [21:38] per me tutto ok [21:38] tutto chiaro [21:38] o/ [21:38] domanda [21:39] Dolasilla: spara [21:39] niente [21:39] ho letto l'avevi detto sopra [21:39] bene, poche idee ma confuse [21:39] nella cartella vedevo il diff.gz, non il debian.tar.gz [21:39] ma rileggendo il log ho visto che è lo stesso [21:40] Dolasilla: tra pochi istanti spiego la differenza, che é importante [21:40] k [21:40] allora non ci rimane che entrare dentro la misteriosa debian/ e vedere cosa c'è dentro. [21:40] cd debian/ [21:41] Vedete che ci sono un pò di file sparpagliati. Alcuni di questi (4, per la precisione) sono sempre obbligatori, e un pacchetto non builda se non ci sono. Altri sono facoltativi e la loro presenza dipende dalla tipologia del pacchetto. [21:41] Cominciamo da uno dei file facoltativi: source/format (ovvero il file format nella cartella source/, sempre da dentro debian/) [21:42] Se lo aprite vedete che c'è scritto 3.0 (quilt). Questa informazione riguarda il formato del source package. Nel corso del tempo ci sono state delle evoluzioni nel formato del source package, e la versione 3.0 è particolarmente succosa di novità piacevoli per noi packager. Tra l'altro, ecco svelato l'arcano sull'estensione del secondo file: dalla versione 3.0 si chiama .debian.tar.gz, nella versione precedente (la 1.0) si chiamava .diff [21:42] .gz [21:42] * Dolasilla non trova la cartella source dentro a /debian... :-/ [21:43] nemmeno io [21:43] il concetto di formato del source package non vi suoni troppo strano... è normale che il protocollo per fare qualcosa abbia delle evoluzioni nel tempo. Lo stesso vale per i source package [21:43] non c'è [21:43] :D [21:43] su quale versione di Ubuntu siete? [21:43] 10.10 [21:44] 10.10 [21:44] arch XD [21:44] vietta: arch? [21:44] warp10, lo so non ho avuto tempo di bootare ubuntu [21:45] vietta: scusa, e come l'hai scaricato il source package? [21:45] sourceforge [21:45] :P [21:45] vietta: su sourceforge non ci sono i source package di ubuntu [21:47] Mony_, Dolasilla: quanto a voi, a parte ricordarvi che nel frattempo la Terra ha fatto un altro giro intorno al sole... :) [21:47] warp10 :( [21:47] warp10, :P prrrr [21:47] Mony_, Dolasilla: voi avete scaricato il source package di Ubuntu 10.10, che aveva ancora il format 1.0, nel quale quel file non esiste [21:47] warp10, io e Mony_ siamo tradizionaliste [21:48] si è vero [21:48] :D [21:48] warp10, il che spiega anche perché vedevo il diff invece che il debian.tar [21:48] Dolasilla: brava, esattamente [21:48] Ne approfitto per farvi vedere come si scarica un source package a mano [21:49] Per la cronaca, le sorgenti dei source package sono indicati nel file /etc/apt/sources.list [21:49] le righe che cominciano per deb-src gestiscono i source package [21:49] warp10, (shhhhhh che ho una virtual machin) [21:49] se al posto di maverick ci mettete oneiric, per dire, apt-get source vi scaricherà il sorcio di oneiric [21:50] ma diciamo che siccome siamo... ehm... "tradizionaliste" non vogliamo cambiare quel file [21:50] dobbiamo rifarlo quindi? [21:50] Mony_: per stavolta no, anche se alla fine basta fare una sostituzione in poche righe [21:51] basta andare su http://packages.ubuntu.com/source/oneiric/tennix [21:51] e alla fine di quella pagina ci sono i link ai tre file del source package [21:51] due possibilità: [21:52] - i comuni mortali scaricano i tre file uno alla volta con wget [21:52] - noi però usiamo un programmillo che si chiama dget! [21:53] a dget si passa come argomento solo il link al .dsc (ricordate? lo dicevo prima quando citavo l'esempio con gaspa) [21:53] e lui tira giù da solo tutto quanto [21:53] quindi, tornando alla cartella packaging nella home e date: [21:53] get http://archive.ubuntu.com/ubuntu/pool/universe/t/tennix/tennix_1.1-1.dsc [21:53] ops [21:53] dget http://archive.ubuntu.com/ubuntu/pool/universe/t/tennix/tennix_1.1-1.dsc [21:54] se alla fine vi dà un errore con le chiavi gpg non preoccupatevi, è normale [21:54] dget dopo aver scaricato decomprime la tarball e applica il diff [21:54] mi dice "permesso negato" [21:54] ma lo fa solo se avete installato ubuntu-keyring [21:55] Dolasilla: lo dice dopo aver scaricato? [21:55] a me ha dato solo il problema sulle chiavi [21:56] dget: retrieving http://archive.ubuntu.com/ubuntu/pool/universe/t/tennix/tennix_1.1-1.dsc [21:56] tennix_1.1-1.dsc: Permesso negato [21:56] Dolasilla: uhm... non è che sei dietro qualche firewall strano, o un NAT, o qualcosa di zozzo del genere? [21:56] no no ok [21:57] più facile [21:57] e risolto [21:57] Dolasilla: benone [21:57] o stai salvando in una directory di root? :) [21:57] gaspa: eh, molto più probabile, mi sa [21:57] gaspa, fuochino, ero rimasta nella cartella /debian ;-) [21:57] Ad ogni modo, se installate il pacchetto ubuntu-keyring, dget vi estrarrà anche la tarball [21:58] noi stavolta lo facciamo a mano con l'opzione -x (eXtract) di dpkg-source: [21:58] dpkg-source -x tennix_1.1-1.dsc [21:58] notate due cose: [21:58] 1- spesso e volentieri le operazioni sul source package si fanno col file .dsc [21:59] 2- notate l'output di dpkg-source: ha spacchettato i due file compressi, e ha applicato il file di patch [21:59] se ora entrate in tennix-1.1/debian/ troverete questo file source/format :) [22:00] Confermate? [22:00] siii! :) [22:00] source si [22:00] La procedura di download del source package con dget è molto importante per tirare giù pacchi da debian o da altre distroseries [22:01] Io sul mio sources.list per esempio ho precise come distroseries per i deb-src [22:01] perchè ovviamente lavoro sui pacchetti della distro in fase di sviluppo, che è precise [22:01] se devo prendere pacchi da altre parti, vado di dget [22:01] quindi bene che siate "tradizionaliste", così abbiamo imparato 'sta cosa :) [22:02] ;) [22:02] Allora, dicevamo [22:02] source/format dice solo il formato del sorcio, e non è obbligatorio (se non c'è, passa automaticamente al format 1.0) [22:02] Noi però siamo fighissimi e lavoriamo col formato 3.0, nuovo e scintillante [22:03] Passiamo a vedere i file obbligatori. Sono 4, ed è importante conoscerli bene [22:03] Il primo, e forse più importante, è control. Apritelo col vostro editor preferito [22:03] * warp10 si chiede nel frattempo a che punto sia vietta [22:03] Qui dentro ci sono una serie di metainformazioni, molte di queste sono usate per generare il file .dsc e sono poi inserite nel file .deb [22:04] vi control [22:04] Vedete che è composto da due stanze separate da una riga vuota: la prima riguarda le informazioni del source package, la seconda riguarda le informazioni del binary package. [22:04] Ci sono campi che riguardano il nome del pacchetto (e il nome del pacchetto binario, che può avere un nome diverso), sezione di pertinenza dell'archivio, importanza, il nome del maintainer del pacchetto (la persona che "gestisce" il pacchetto), l'elenco dei pacchetti necessari per compilare il pacchetto sorgente (le build-depends) e l'elenco dei pacchetti necessari per eseguire il pacchetto binario (le depends nella seconda stanza), descr [22:04] izione breve e lunga del pacco (quella che appare anche in USC) e altro ancora [22:04] Ci possono essere anche stanze supplementari, perchè un singolo source package può generare tanti binary package diversi, dipende dai casi [22:05] Ad esempio, il gioco pippo può generare i binary package 1) pippo, col binario del gioco; 2) pippo-data con le immagini e audio; 3)pippo-doc col manuale del gioco [22:05] Non ci soffermiamo troppo sui dettagli, ma chi vuole approfondire può leggere questa pagina della Debian Policy (che è la nostra Sacra Bibbia): http://www.debian.org/doc/debian-policy/ch-controlfields.html [22:06] Notate che non c'è alcun numero di versione in quel file? [22:06] c'è nella stanza del source [22:07] Mony_: ti riferisci a Standards_Version? [22:07] si scusa tu ti riferisci alla versione del programma [22:07] Mony_: quella non è la versione del pacchetto, bensì la versione della Debian Policy rispetto alla quale io dichiaro di aderire [22:08] Mony_: la Debian Policy viene rinnovata periodicamente con regolette nuove, in un mondo perfetto quel campo corrisponde sempre all'ultima versione [22:08] warp10: ok [22:08] Quindi, niente numero di versione nel control, perchè questo viene preso dal secondo dei file obbligatori, il file changelog. Apritelo, please. [22:08] warp10, è d'obbloco dichiararla? [22:09] vietta: no, la Debian Policy stabilisce quel campo come "recommended" [22:09] vietta: se non la metti, builda lo stesso [22:09] ok tnx [22:09] vietta: ma se non la metti, i tuoi colleghi packager ti guardano in cagnesco :) [22:10] lol xd [22:10] capito [22:10] Il changelog, quindi [22:10] E' semplicemente il diario di quel pacchetto, con tutti gli interventi e i ritocchi che ha subito nel corso del tempo. [22:10] Tutti i bravi programmatori conservano un log di quello che fanno sul loro codice, in un modo o nell'altro, e noi non siamo certo da meno. [22:11] La prima riga è molto importante: c'è il nome del pacchetto, la versione e la distroseries in cui deve buildare. Lì c'è unstable perchè il pacchetto è stato caricato in debian e poi copiato (syncato, in gergo tecnico) in ubuntu. Potreste trovarci oneiric, o precise, o natty, etc, nel caso fosse stato caricato direttamente in ubuntu [22:11] Mi accorgo ora che ho usato spesso la parola distroseries: avete un'idea precisa di cosa sia? [22:12] precisa, no, ho intuito dal contesto [22:12] ogni release di ubuntu è una distroseries, grossolanamente [22:13] in certi VCS si fa un tag del trunk quando si vuole freezare lo sviluppo ad una certa versione, no? [22:13] una distroseries è qualcosa del genere [22:13] k [22:14] ma l'immagine distroseries == release è piuttosto efficace [22:14] Spendo qualche parola sul numero di versione, c'è una importante convenzione da sapere (e che vi fa comodo conoscere a prescindere) [22:15] In debian lo standard per le versioni dei pacchi è: -, dove debianRevision è un numero progressivo che indica gli upload successivi della stessa versione upstream. Qui vedete 1.1-1, ovvero versione 1.1 upstream, prima revision Debian. Se correggessi un bug sulla versione 1.1, caricherei la versione 1.1-2, e così via [22:15] Questo pacchetto è stato syncato da Debian senza modifiche, quindi il numero di versione è immutato rispetto a Debian [22:15] In ubuntu lo standard è: ubuntu. La parte "ubuntu" ovviamente riguarda solo i pacchetti modificati in Ubuntu (tennix è stato copiato senza modifiche, come dicevo, e infatti non ce l'ha) [22:16] Tanto per fare un esempio, unity in oneiric è alla versione 4.22.0-0ubuntu3: versione upstream 4.22.0, debian revision 0 (perchè non c'è unity in debian), ubuntu revision 3 (cfr: http://packages.ubuntu.com/search?keywords=unity) [22:16] Ci possono essere piccole variazioni, ma la sostanza è questa [22:16] Poco da dire sul changelog insomma, ma qualche curiosità in più è sulla Bibbia: http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog [22:16] Ora, un file complicatissimo [22:16] Attenzione, questo è davvero difficile [22:16] E' il file compat. Apritelo, prego [22:17] Ebbene, sì: c'è solo un numero lì dentro [22:17] lol [22:17] Nella creazione dei pacchetti ci sono alcune procedur standardizzate e ripetitive che devono essere eseguite ogni volta. Siccome noi informatici siamo pigerrimi, piuttosto che rifare tutto da zero un'anima pia ha creato un programmino che gestisce automaticamente tutta questa procedura, e si chiama debhelper. Se notate, è una delle build-depends inserite in control [22:17] Di debhelper sono state create versioni successive con funzionalità sempre maggiori, e quindi ci sono diversi livelli di compatibilità. Il file compat dichiara qual è il livello di compatibilità minimo (debhelper 7, in questo caso). [22:18] Nient'altro da dire: se non volete usare debhelper questo file non serve a nulla. Ma fidatevi: debhelper volete usarlo sempre, ed è il vostro migliore amico :) [22:18] Ora un file che io odio profondamente, il file più importante di tutti ma che non fa nulla di utile: il file copyright [22:18] Chi crea il pacchetto deve compilare questo file, nel quale raccoglie tutte le informazioni legali su copyright, autori e licenze, presi dai singoli file sorgenti. [22:18] warp10 [22:19] aspetta [22:19] dimmi Mony_ [22:19] a cosa serve debhelper? [22:19] anche solo un accenno [22:19] Mony_: hai ragione, sono stato piuttosto oscuro [22:19] Mony_: lo vedremo bene parlando del file rules, ma debhelper è una collezione di programmi che aiutano il build del pacchetto [22:20] Mony_: eseguono una serie di procedure standard che vanno fatte più o meno sempre [22:20] Mony_: procedure noiose e ripetitive, come dicevo prima, che sarebbe noioso e assurdo re-implementare di volta in volta [22:20] warp10: grazie :) [22:20] Mony_: scenderò nei dettagli tra 2 minuti, appena arriviamo al rules [22:21] Scrivere il file debian/copyright è una gran rottura, per fortuna fatto una volta poi non si tocca per un bel pò, di solito. E però è un lavoro importantissimo: se questo file non è compilato correttamente il pacchetto viene rimosso all'istante dall'archivio (o non ci entra affatto, se è un pacchetto nuovo). [22:21] Pochissimo da dire sul copyright, ma ormai avete capito che su http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgcopyright trovate qualche informazione in più. :) [22:21] L'ultimo file obbligatorio è invece il file più divertente, e anche il più "tecnico": è il file rules. [22:21] Sapete già che cos'è un Makefile? [22:22] si [22:23] * Dolasilla stacca [22:23] Bene, il rules è nient'altro che un makefile in piena regola [22:23] serve a generare degli eseguibili [22:23] ma voi continuate! poi leggo i log! [22:23] ciao Dolasilla [22:23] ciao Dolasilla [22:23] Mony_: esatto. E anche molto di più, genera documentazion, o installa i file sull'ardisco, o in generale fa qualsiasi cosavogliate, è uno strumento potente [22:23] * warp10 saluta Dolasilla con la manina [22:24] Dolasilla: o/ [22:24] Durante la fase di build del pacchetto le istruzioni contenute lì dentro saranno utilizzate per buildare opportunamente il pacchetto stesso (tipicamente il rules usa a sua volta il Makefile upstream). [22:24] infatti vi faccio notare che il rules di tennix comincia proprio con l'hashbang "#!/usr/bin/make -f" [22:25] proprio perchè è make ad eseguirlo, come tutti i Makefile [22:25] Se sapete scrivere, o almeno leggere un Makefile, siete a cavallo, c'è ben poco da imparare [22:25] In effetti i Makefile sono strumenti molto semplici, se vogliamo, e da debheper 8 il Makefile è un oggetto davvero semplicissimo. [22:25] Talmente semplice che certe volte, quando vi va proprio di lusso, tutto quello che serve sono quelle ultime due righe del rules di tennix: [22:25] %: [22:25] dh $@ [22:26] Lì dentro debhelper scatena tutta la sua magia nera. :) [22:26] Qui invece vedete che ci sono anche due override di due programmi di debhelper. Cerco di spiegarvi un attimo cosa significa tutto ciò, e così rispondo anche alla domanda di Mony_ su debhelper [22:27] Nella migliore tradizione Unix, in cui ogni programma fa una sola cosa e la fa bene, debhelper è una suite di tanti piccoli programmi diversi. Li trovate dentro /usr/bin, cominciano tutti con dh_, sono circa un 70ina [22:27] Quando parte il build del pacchetto, il comando dh (che ovviamente sta per DebHelper, ed è il "coordinatore" di tutti quanti) scatena in sequenza, l'uno dopo l'altro, tutti i comandi dh_*, nell'ordine giusto [22:28] Un dh_ lancia la compilazione, uno controlla certe cose, uno installa i file compilati nel .deb, un'altro configura, etc. etc. [22:28] La lettura dei singoli man vi dirà un sacco di informazioni su cosa farà il singolo comando, ed è consigliata, almeno per quelli più importanti [22:29] ehm warp10 riavvio su ubuntu torno subito [22:29] * warp10 si freeza per aspettare vietta [22:32] Andrà a carbonella il computer di vietta? [22:33] * warp10 inganna il tempo tirando il codino di gaspa [22:34] Mony_: quanto tempo a disposizione hai ancora? [22:34] infinito [22:34] finchè gli occhi reggono ovviamente [22:34] ;) [22:35] Mony_: :D [22:35] Mony_: allora aspettiamo altri 2 minutini, magari la carbonella è fredda [22:35] warp10: nessun problema [22:36] prrr [22:37] warp10: stavo pensando, ma se raccolgo tutto quello che hai scritto e lo trasformo in documentazione con magari qualche screen? [22:37] * gaspa schiva warp10 con un doppio front flip [22:37] Mony_: a me pare un'ottima idea :) [22:37] Mony_: beh, perchè no? [22:38] Mony_: ci puoi estrarre anche un articolo per qualche blog [22:38] ok [22:38] Mony_: insomma, certo, senz'altro [22:38] Mony_: magari aiuta anche a fissare i concetti a te, se ci lavori sopra [22:38] warp10: ne parlerò con Silvia per l'articolo [22:38] Ad ogni modo, la carbonella si è scaldata ed è tornata vietta [22:38] Mony_: yeah [22:39] sorry... [22:39] Eravamo rimasti ai programmi di debhelper [22:39] e al rules, che invoca dh, che a sua volta invoca tutti i vari dh_* [22:39] Se tutto va bene, nessuna modifica al rules è necessaria, bastano quelle due righe misteriose e vissero tutti felici e contenti. [22:40] warp10: domanda [22:40] A volte però è necessario dare delle istruzioni aggiuntive ai singoli programmi di debhelper, o fargli fare delle cose extra, e allora basta mettere un override per quel debhelper nel rules. [22:40] Mony_: dimmi [22:40] warp10: dove stanno tutti i dh generalmente? [22:40] Mony_: in /usr/bin [22:41] Mony_: se scrivi dh e fai doppio tab veloce nel terminale li vedi tutti [22:41]