Cercherò di spiegare alla meglio l’utiità delle cartelle e dei log usati in ckit. Ammetto che è una pecca non aver fornito in alcun modo uno straccio di documentazione su queste cose quindi inizio dal semplice blog per poi elaborare meglio per un futuro wiki con la speranza che ci si riduca ai minimi termini sull’uso delle risorse.

Comincio dalle cartelle:
mkdir -p "$builddir" "$repodir" "$cachedir"
$builddir è il workspace vero e proprio, conterrà le cartelle con i PKGBUILD dei programmi ossia le loro $startdir, solo per i casi di pacchetti devel conterrà anche i sorgenti.
$repodir è una cartella di transito, ckit copierà i pacchetti man mano che compila, vedere post_build(). Questa cartella in più conterrà anche i log che probabilmente starebbero più comodi in una ~/.ckit, magari più in la sposteremo, per ora 0.58 stanno ancora qui dentro.
$cachedir è la cartella deposito, ad ogni add() ckit sposterà i pacchetti __$aggiunti__ al repo (dove per aggiunti intendo un livello di astrazione su repo-add ed upload con rimozione versione precedente). Questa cartella __NON__ verrà mai svuotata in automatico perché non si può prevedere quando un pacchetto si compila ma “non funziona”, in tal caso sarà disponibile al volo la cache ma si dovrà procedere a mano per copiare dentro $builddir ed inserire il pacchetto nel lista dei build fatti, di questa lista ne parlerò tra brevissimo. L’unico modo per svuotare questa cache sarà con ckit -H e SOLO quando lo sviluppatore ne riterrà opportuna l’azione.

Parliamo dei log, esistono 4 log, dei quali 2 fissi e 2 volatili. I due log volatili sono quelli più usati ossia il $buildlog e $checklog mentre i due log fissi sono $deletelog ed $updatelog.
$buildlog è valorizzato dalla build() in particolare post_build(), e contiene la lista dei pacchetti presenti nella $repodir quindi i pacchetti prossimi ad essere aggiunti. Se pensate che è ridondanza vi do ragione, è proprio così infatti c’è in progetto l’eliminazione ma per ora 0.58 esiste. La potenza di ckit è data anche da questo log, hai la possibilità di dare sempre makepkg a mano per cavoli tuoi, puoi farlo fare ad un amico te lo giri via rete o con penna un modo qualsiasi, l’importante è che lo copi in $repodir e __PER_ORA__ inserire il nome in $buildlog a mano in un posto qualsiasi purché a capo di una riga vuota e seguito da un Invio (credo carrage return e line feed nell’atto pratico) quindi dare ckit -A che man mano che __$aggiunge__ (n.b. sul significato di aggiungere spiegato poco sopra) sposterà i pacchetti nella cache e solo al termine eliminerà il log, che non servirà più evidentemente.
$checklog è valorizzato dalla check() e contiene i pacchetti ottenuti dalla funzione stessa, ossia i pacchetti che necessitano aggiornamento perché outdated. Non ci sarà differenza tra stabili e devel, non a livello di log certo, ma a livello di check(). Per come è progettato ckit la check() non terrà conto dei pacchetti devel che non sono presenti nel workspace, perché questo? Si tenga d’occhio che i pacchetti stabili hanno un riscontro immediato da AUR, e sebbene ciò può tecnicamente avvenire anche per i devel questo non è affidabile. Come risolve ckit? Bene, ad ogni check() lui esegue questo controllo:
if [[ "$develcheck" == "0" ]] && is_devel "$pkg" && [[ -d "$builddir/$pkg" ]]; then
dove il primo argomento indica l’espresso consenso dello sviluppatore nel voler processare i pacchetti devel, il secondo indica l’effettiva presenza della versione devel mentre il terzo indica l’effettiva presenza della cartella nel workspace. In questo modo si consente esplicito consenso nel seguire l’andamento della versione devel, quindi ckit provvederà a __capire__ lo stato del repository dei sorgenti con un makepkg a vuoto che sincronizzerà il repository remoto
makepkg -o 2>&1 | awk -v "pkg=$pkg" '$0 ~ pkg {print $6}'
Nel caso sia presente un ipotetico pacchetto “voluminoso” quale un xbmc-svn con ben 5 giga di sorgenti, lo sviluppatore potrà non seguirne l’andamento semplicemente non avendone la cartella, o eliminandola, in workspace. Lo sviluppatore potrà cominciare a seguire quel pacchetto semplicemente __$installando__ nel suo workspace la cartella con il PKGBUILD di quel pacchetto con ckit -U xbmc-svn. Con questa particolare speigazione sono uscito un pelo fuori traccia, ma penso sia stato utile per capire il fatto delle cartelle del workspace.
Passiamo ai due log fissi, questi log sono stati introdotti con lo scopo di colmare lacune di ckit. Ebbene si, ckit ha lacune, ma che non sono proprie dello script quanto dei pacchetti. Servono ad intridurre elasticità sui PKGBUILD, in realtà è più una falla dei PKGBUILD fatti male che limitano l’effettivo lavoro di building, quindi ckit prevede che ci possono essere PKGBUILD fatti coi piedi e si prepara a superare questa lacuna.
$deletelog contiene alcuni pacchetti inseriti __SOLO__ manualmente dallo sviluppatore che necessitano di essere svuotati dei sorgenti. Ad esempio, amule-devel è devel quindi ckit non gli segherà i sorgenti però ha un carattere stabile a snapshots notturni ed ogni archivio è standalone quindi è inutile conservare l’archivio dei sorgenti della release precedente. In tal caso lo si potrà scrivere nel $deletelog per poi dare ogni tanto a discrezione dello sviluppatore ckit -DL (o anche ckit -D amule-devel). Altro problema l’ho notato a suo tempo su gnome-do-bzr, il PKGBUILD fatto coi piedi non riusciva a superare alcune copie ed un modo efficace era rimuovere a mano alcune robe, detto a spiccioli bastava anche un makepkg -c ad ogni build() ma questo comportava inserire un paramertro delegando allo sviluppatore mentre un modo per farlo in automatico (o semi-automatico) era mediante $deletelog (o in alternativa sempre ckit -D foo-bar-baz). Ho subito notato una possibilità di far cooperare -D e -B ma di primo acchito ho notato conflitti nell’uso delle risorse, magari prossimamente si potrebbe risolvere.
$updatelog viene sempre e __SOLO__ scritto a mano dallo sviluppatore, e contiene i pacchetti che necessitano di un aggiornamento manuale da AUR. Questo viene in soccorso per colmare la lacuna dei PKGBUILD non proprio fatti male, ma che sono devel e conservano un carattere stabile, ad esempio xbmc-svn che nonostante sia devel viene aggiornato solo a commit che compilano saltando i commit intermedi. Altro esempio è su gnome-do-bzr che a mio parere è proprio un pacchetto fatto coi piedi e conserva tutte le lacune previste, sia per la sincronizzazione dei sorgenti che per la compilazione. Ma non ho intenzione di correggere PKGBUILD, ne tantomeno si richiede che vengano corretti. ckit accetta tutto volente o nolente semplicemente si adatta e amen, quindi in questi termini la check() verrebbe sempre lanciata con -ULCd o -ULC (n.b. i riferimenti ai PKGBUILD per lo meno di gnome-do-bzr sono relativi al periodo di quando ho iniziato a seguirne lo sviluppo, attualmente non so come procede se hanno migliorato o peggiorato non mi importa ho iniziato così ho notato irregolarità quindi frega niente, si va avanti così male non fa e questo non implica l’utilità dei log fissi se ce n’è / ce n’è stato almeno uno, ce ne possono essere altri quindi i log possono servire sempre).

Questo è quanto, vorrei solo concludere con una nota sull’ultima funzione aggiunta relativa alla manutenzione del workspace. Dopo un po di tempo, mesi o settimane, aggiungendo o droppando pacchetti si potrebbe raggiungere un certo livello di occupazione su disco del workspace. In tal caso nasce un problema, se do un bel rm -rf /foo/bar/baz/workspace poi mi tocca ricordarmi tutti i pacchetti devel che seguivo per averne le cartelle? La risposta ovviamente è si, ma ho introdotto proprio di recente una nuova interfaccia -S che chiama aurdevelsync(), che scorre la lista dei pacchetti saltando quelli stabili, di volta in volta verrà chiesto foo-devel: update? (y/n) quindi si potrà procedere alla __$installazione__ nel workspace per procedere con i successivi check().

Detto ciò, chiudo. Saluti.

ckit, docs Hide

Dopo tanto lavoro prove e sbattimenti vari abbiamo il primo rilascio ufficiale di ckit!
Ringrazio Luca ‘Nss’ e Giovanni ‘voidnull’ per l’insostituibile contributo, e per aver creduto nel progetto.
Il lavoro non è certo finito, anzi ora viene il bello, appena ho tempo libero devo aggiungere alcune nuove funzioni e ristrutturarne altre. Sarà dura ma si tirerà avanti. Alla prossima!

bash, ckit, github, scripting Hide

[dax@feeder ~]$ ./ckit_unarch -ULC
==> Updating local PKGBUILD from AUR
-> Getting xbmc-svn from AUR... done
==> Getting db
-> unarch.db.tar.gz... 100% done
==> Checking for outdated packages
-> amarok-git REPO:20100118-1 LOCAL:20100118-1 AUR:20090921-1 DEVEL:20100128-1
-> aurget-git REPO:20100118-1 LOCAL:20100118-1 AUR:20090623-1 DEVEL:20100128-1
-> fotowall-git REPO:20100118-1 LOCAL:20100118-1 AUR:20090725-2 DEVEL:20100128-1
-> handbrake-svn REPO:3077-1 LOCAL:3077-1 AUR:3054-1 DEVEL:3087-1
-> kdenlive-svn REPO:4231-1 LOCAL:4231-1 AUR:3497-2 DEVEL:4250-1
-> microdia-git REPO:20100122-1 LOCAL:Null AUR:20100106-1 DEVEL:20100128-1
-> minitube-git REPO:20100118-1 LOCAL:20100118-1 AUR:20091116-1 DEVEL:20100128-1
-> mpd-git REPO:20100122-1 LOCAL:20100122-1 AUR:20100125-1 DEVEL:20100128-1
-> skype4pidgin-svn REPO:569-1 LOCAL:569-1 AUR:568-1 DEVEL:573-1
-> tilda-cvs REPO:20100125-1 LOCAL:20100125-1 AUR:20080506-1 DEVEL:20100128-1
-> xbmc-svn REPO:26936-1 LOCAL:26936-1 AUR:27229-1 DEVEL:27229-1
[dax@feeder ~]$ ./ckit_unarch -LBain
==> xbmc-svn
-> Getting xbmc-svn from AUR... done
..
...
....
==> Compilazione terminata: amarok-git 20100128-1 i686 (gio 28 gen 2010, 13.17.10, CET)
==> Installing package amarok-git with pacman -U...
caricamento dei dati in corso...
controllo delle dipendenze in corso...
(1/1) controllo dei conflitti in corso [#########################################] 100%
(1/1) aggiornamento in corso di amarok-git [#########################################] 100%
==> Yo, amarok-git done
==> Packages waiting to be added:
-> amarok-git
-> aurget-git
-> fotowall-git
-> handbrake-svn
-> kdenlive-svn
-> microdia-git
-> minitube-git
-> mpd-git
-> skype4pidgin-svn
-> tilda-cvs
-> xbmc-svn
[dax@feeder ~]$ ./ckit_unarch -A
==> Locking ftp to prevent jumble between maintenances
-> lock.lk... 100% done
==> Getting db
-> unarch.db.tar.gz... 100% done
==> Deleting previous packages
-> amarok-git-20100118-1-i686.pkg.tar.gz... done
-> aurget-git-20100118-1-i686.pkg.tar.gz... done
-> fotowall-git-20100118-1-i686.pkg.tar.gz... done
-> handbrake-svn-3077-1-i686.pkg.tar.gz... done
-> kdenlive-svn-4231-1-i686.pkg.tar.gz... done
-> microdia-git-20100122-1-i686.pkg.tar.gz... done
-> minitube-git-20100118-1-i686.pkg.tar.gz... done
-> mpd-git-20100122-1-i686.pkg.tar.gz... done
-> skype4pidgin-svn-569-1-i686.pkg.tar.gz... done
-> tilda-cvs-20100125-1-i686.pkg.tar.gz... done
-> xbmc-svn-26936-1-i686.pkg.tar.gz... done
==> Adding packages queued
-> amarok-git-20100128-1-i686.pkg.tar.gz... done
-> aurget-git-20100128-1-i686.pkg.tar.gz... done
-> fotowall-git-20100128-1-i686.pkg.tar.gz... done
-> handbrake-svn-3087-1-i686.pkg.tar.gz... done
-> kdenlive-svn-4250-1-i686.pkg.tar.gz... done
-> microdia-git-20100128-1-i686.pkg.tar.gz... done
-> minitube-git-20100128-1-i686.pkg.tar.gz... done
-> mpd-git-20100128-1-i686.pkg.tar.gz... done
-> skype4pidgin-svn-573-1-i686.pkg.tar.gz... done
-> tilda-cvs-20100128-1-i686.pkg.tar.gz... done
-> xbmc-svn-27229-1-i686.pkg.tar.gz... done
==> Putting db
-> unarch.db.tar.gz... 100% done
==> Getting db
-> unarch.db.tar.gz... 100% done
-> Size test ok (20212)
==> Uploading packages
-> amarok-git-20100128-1-i686.pkg.tar.gz... 100% done
-> aurget-git-20100128-1-i686.pkg.tar.gz... 100% done
-> fotowall-git-20100128-1-i686.pkg.tar.gz... 100% done
-> handbrake-svn-3087-1-i686.pkg.tar.gz... 100% done
-> kdenlive-svn-4250-1-i686.pkg.tar.gz... 100% done
-> microdia-git-20100128-1-i686.pkg.tar.gz... 100% done
-> minitube-git-20100128-1-i686.pkg.tar.gz... 100% done
-> mpd-git-20100128-1-i686.pkg.tar.gz... 100% done
-> skype4pidgin-svn-573-1-i686.pkg.tar.gz... 100% done
-> tilda-cvs-20100128-1-i686.pkg.tar.gz... 100% done
-> xbmc-svn-27229-1-i686.pkg.tar.gz... 100% done
==> Unlocking ftp
-> lock.lk... done
==> Repository updated! Gj, see ya.
[dax@feeder ~]$ ./ckit_unarch -C
==> Getting db
-> unarch.db.tar.gz... 100% done
==> Checking for outdated packages
-> oxygenrefit2-icon-theme REPO:2.4.0-3 LOCAL:2.4.0-3 AUR:2.4.0-4 DEVEL:Null
[dax@feeder ~]$ ./ckit_unarch -ALBain
==> oxygenrefit2-icon-theme
-> Getting oxygenrefit2-icon-theme from AUR... done
==> Creazione del pacchetto: oxygenrefit2-icon-theme 2.4.0-4 i686 (gio 28 gen 2010, 14.08.37, CET)
==> Controllo delle dipendenze per l'esecuzione in corso...
==> Controllo delle dipendenze per la compilazione in corso...
==> Download dei sorgenti in corso...
-> Download di OxygenRefit2-2.4.0.tar.bz2 in corso...
..
...
....
==> Installing package oxygenrefit2-icon-theme with pacman -U...
caricamento dei dati in corso...
controllo delle dipendenze in corso...
(1/1) controllo dei conflitti in corso [#########################################] 100%
(1/1) aggiornamento in corso di oxygenrefit2-ic... [#########################################] 100%
==> Yo, oxygenrefit2-icon-theme done
==> Cleaning oxygenrefit2-icon-theme directory
-> /home/dax/pkg/workspace/oxygenrefit2-icon-theme/src removed
-> bz2 removed
==> Packages waiting to be added:
-> oxygenrefit2-icon-theme
==> Locking ftp to prevent jumble between maintenances
-> lock.lk... 100% done
==> Getting db
-> unarch.db.tar.gz... 100% done
==> Deleting previous packages
-> oxygenrefit2-icon-theme-2.4.0-3-i686.pkg.tar.gz... done
==> Adding packages queued
-> oxygenrefit2-icon-theme-2.4.0-4-i686.pkg.tar.gz... done
==> Putting db
-> unarch.db.tar.gz... 100% done
==> Getting db
-> unarch.db.tar.gz... 100% done
-> Size test ok (20222)
==> Uploading packages
-> oxygenrefit2-icon-theme-2.4.0-4-i686.pkg.tar.gz... 100% done
==> Unlocking ftp
-> lock.lk... done
==> Repository updated! Gj, see ya.


ckit, repo, script, unarch Hide

Con la 0.2 di ckit sono state introdotte novità, la principale è il client ftp in ruby fatto da Nss che ha portato ad una conseguente modifica delle interfacce pubbliche e private relative all’accesso remoto, è stato finalmente eliminato il fantomatico glob rm, ed infine alcuni piccoli ritocchi al codice ed ai messaggi.
Con la 0.3 è tutt’altra storia, ho separato il config! Oltre al client ftp di zio Nss ora si può tenere una volta per tutte in santa pace i dati. Venendo da 0.2 bisogna cancellare .ckit e rifarla con la nuova, non sono previste altre modifiche.

Parallelamente a questo progetto ne sto portando avanti un secondo, un repo. L’idea fondamentale è creare un repo che sia ospitato su un server che dia la possibilità di creare account, ed a questo ha risposto il server di Nss dandomi subito 3 giga di spazio. Io personalmente sto mettendo qualche pacchetto per i686, l’idea è sempre offrire supporto alle versioni di sviluppo e le intenzioni sono di avere non più di 3-4 sviluppatori. Il repo l’ho temporaneamente chiamato unarch, dove “un” sta per unofficial. Diciamo che un repo a volte può suonare come tentativo di accaparrarsi gloria personale, e l’idea di ospitare il repo sul mio sito non mi piaceva tantissimo proprio per questo motivo. A me interessa proprio offrire supporto non guadagnare (anche perché tecnicamente il repo è una pura sanguisuga, non da ne guadagno pagerank ne tanto meno adsense), era da un pò che mi frullava l’idea di poter creare qualcosa di sbrandizzato, ed ecco ora che viene Nss con il suo server e mi da spazio ed account.
Per ora è da considerare solo un’anteprima, a breve arriveremo sul forum con le coordinate, e sarà comunque una prova. Nel caso il repo si mostrerà utile ed utilizzato, allora e solo allora si potrà procedere con l’acquisto di un dominio che punti sul server di Nss.
Per ora vorrei sapere cosa ne pensate del progetto, per lo meno vorrei sapere cosa ne pensano gli interepidi che si affidano al repo deelab gia, ma anche tutti gli altri, e vorrei un pò capire se l’idea parte moribonda oppure se piace a qualcuno. Vorrei radunare i maggiori repo italiani in un unico indirizzo, ed il tutto in maniera stand alone da siti personali. Qui il movente non è la gloria ma qualcosa che possa in qualche modo aiutare gli arcieri, penso personalmente che sarebbe utile poter avere un repo dove pescare qualche versione di sviluppo senza perdere tempo per compilarla.
Attendo commenti, spero che il post non resti nel chiaroscuro senza commenti perché sarebbe stato solo inutile averlo scritto. Perlomeno sforzatevi di scrivere “no, è una cosa inutile non lo seguirò mai” se non siete d’accordo.
Chiudo con un mega ringraziamento ad Nss per tutto quello che ha fatto, grazie lo stesso anche nel caso di fallimento del progetto. Saluti.

archlinux, bash, ckit, repo Hide

Da considerare deprecata la pagina su googlepage, ckit è tornato a casa e lo ospito direttamente io qui.
Sistemate cosucce ed introdotta la versione. È in prova da una settimana rispetto alle ultime funzioni aggiunte e pare vada bene, posso dire che si può iniziare a pensare alla fusione con repoman.

Come non saprete, ckit è un lavoro sperimentale quasi una scommessa che io ho fatto con delle idee che avevo e che ho maturato durante lo sviluppo di repoman, ma che ho iniziato a mettere in pratica senza alcun traguardo od ambizione nei momenti morti. Con il tempo l’idea si è raffinata fino a diventare senza nessuna aspettativa, un bello scriptino funzionale e pulito, imho nella filosofia arciera. È un progetto nato per morire però, nel caso fosse andato bene si avrebbe potuto iniziare a parlare di fusione con repoman, nel caso fosse andato male sarebbe rimasto li e cancellato.

Perché non fate domani la fusione? La risposta è semplice, ckit ha forse troppe interfacce pubbliche, siccome non ho tanto tempo da dedicargli e non mi sono mai messo con carta e penna a perdere le giornate per capire come migliorargli l’usabilità lato utente (certo sempre utente-sviluppatore non utente-utonto), lo studio durante l’utilizzo cercando di capire se questo lo facessi così come verrebbe? Vi dirò di più questo script è stato fatto praticamente a runtime, tutte le sue funzioni sono state scritte un minuto prima di usarlo e anche durante, e poi raffinate nei giorni successivi con correzzioni semantiche e pulizia del codice. Sapete benissimo che in bash puoi fare una cosa in mille mila maniere e c’è sempre una strada più pulita per fare qualunque cosa, bisogna solo mettersi a pensare un pò. È questo il lavoro che faccio quando dico “lo tengo in prova per una settimana”, altro non è che guardare il codice e farsi venire idee su come si potrebbe migliorare, sempre nei momenti morti che può essere mezz’ora la mattina dopo le 12 oppure un’oretta la sera dopo le 8, a seconda che abbia allenamenti di boxe o no. Dico questo per giustificare la qualità e la lentezza nello sviluppo.

Detto ciò penso che il post sia completo, dalla pagina del progetto su deelab c’è qualche altra spegazioncina. Se notate strafalcioni di inglese datemi voce, avevo chiesto ad alcuni amici di darci una letta ma pare che stavolta nessuno abbia avuto tempo libero (il che rispecchia esattamente le mie richieste).

archlinux, bash, ckit Hide

Aggiunto il –skipinteg, pulito il codice e creata una pagina da zio google come home del progetto.
Niente di che, sempre tutto casereccio, rustico e semplice semplice.
http://archlinuxckit.googlepages.com/
N.B. hostato qui.

Saluti

bash, ckit, projects, scripting Hide