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

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/

Saluti

bash, ckit, projects, scripting Hide

Dunque, in questa versione si può dire che ho riscritto quasi da zero ogni singola funzione che utilizzo ripulendo il codice in lungo e in largo. Andando a ritroso devo proprio ammettere di aver sbandierato praticamente porcherie scritte senza giudizio nei post precedenti. Comunque ho cambiato un pò i comandi ed aggiunto roba segato altra riscritto quasi tutto il codice. Io dico che ora merita, ma tanto me lo dico da solo visto che sarò l’unico ad usarlo
Ad ogni modo credo di poter dire che si avvicina la prima versione stabile, il prossimo post annuncerà questo e se tutto va bene sarà pubblicato per i primi di settembre, detto ciò siori e siore ecco ckit.
Saluti.

archlinux, bash, repo, scripting Hide

Belli miei, ecco il mio capolavoro. Il vecchio ckit con l’implementazione della getopts.
E’ anche cambiata qualcosa nel codice, ho migliorato un pò di cose ed eliminate altre, sempre la solita solfa di quando si fa un programma insomma.
Non mi dilungo in inutili spiegazioni: LINK.
Più che altro ho in previsione di implementare un controllo sugli argomenti in input. Per ora il programma avvia ogni task l’utente voglia, logicamente ci sono argomenti che non ha senso passare insieme. E’ logico poter avviare -BaiA (-B build, -a tira il tarball da AUR, -i installa e -A aggiungi al repo), però non avrebbe senso lanciare un check al termine di un build.
Per il resto limitatevi a dare uno sguardo all’help raggiungibile dal -h o senza argomenti.
Saluti.

archlinux, bash, repo, scripting Hide

Aggiunta roba, migliorata dell’altra ed ecco che una bidonata di ammasso di codice inutile forse inizia a diventare qualcosa di figo: LINK. Ammè mepiasce, lo tengo in uso per un altro pò vediamo come si comporta. Forse la prima versione ufficiale e stabile 1.0 è vicina.

archlinux, bash, repo, scripting Hide

Ho dato una ripulita al codice, tutto funziona esattamente come prima. LINK.

Aggiornamento: LINK.

archlinux, bash, repo, scripting Hide

In maniera molto rudimentale però si va avanti, ho abbozzato un primissimo controllo sul repo uppato. In breve semplicemente lo invio, lo riscarico quindi controllo la dimensione di ciò che avevo e ciò che ho ottenuto segnalando lo stato del db. In caso di esito negativo consiglio l’uso di un restoredb che ripristina il repo allo stato precedente. La cosa va comunque migliorata, per ora è solo un abbozzo.

lftp_put_repo(){
cp "$repo" "$repo"_prev
lftp_run "put $repo" &>/dev/null
wgetrepo
i=$(stat -c%s "$repo")
j=$(stat -c%s "$repo"_prev)
[[ $i = $j ]] && echo " -> Fatto, controllo dimensione ok ($i)." || echo " -> OCCHIO: $i ~ $j! Potresti aver bisogno di restoredb!"
}

Lo stavo facendo con md5sum ma ho avuto noie. LINK.

archlinux, bash, repo, scripting Hide

Serviva un modo per poter aggiornare i pacchetti ottenuti dal check, quindi ho scritto una seconda funzione per la compilazione: build1. LINK.

$ sh CKIT build1
==> CKIT - Construction KIT
==> Ok, azione scelta build1.
==> Processo i pacchetti ottenuti dal check.
==> tilda-cvs: vuoi aggiornare? (y/n) y
-> Vuoi prendere il PKGBUILD da AUR? (y/n) y
-> Ti basta compilare da user? (y/n) y
-> Ok, tilda-cvs fatto
==> pidgin-facebookchat-svn: vuoi aggiornare? (y/n) n
==> pcmanfm-svn: vuoi aggiornare? (y/n) y
-> Vuoi prendere il PKGBUILD da AUR? (y/n) y
-> Ti basta compilare da user? (y/n) y
-> Ok, pcmanfm-svn fatto
==> minitube-git: vuoi aggiornare? (y/n) y
-> Vuoi prendere il PKGBUILD da AUR? (y/n) y
-> Ti basta compilare da user? (y/n) y
-> Spiacente, il pacco minitube-git non compila
==> microdia-git: vuoi aggiornare? (y/n) n
==> gnome-do-bzr: vuoi aggiornare? (y/n) y
-> Vuoi prendere il PKGBUILD da AUR? (y/n) y
-> Ti basta compilare da user? (y/n) y
-> Ok, gnome-do-bzr fatto
==> aurget-git: vuoi aggiornare? (y/n) y
-> Vuoi prendere il PKGBUILD da AUR? (y/n) y
-> Ti basta compilare da user? (y/n) y
-> Ok, aurget-git fatto
==> amarok-svn: vuoi aggiornare? (y/n) n

Spendo due paroline per descrivere la funzione. Ho aggiunto nel check due righe che aggiornano un file di testo man mano che trovo pacchetti da aggiornare.
Quindi il build1 va a scansionare questo file, richiedendo di voce in voce se scaricare il PKGBUILD da AUR e se compilare da user o root, mantenendo sempre la filosofia principale del programma. Ho inoltre nascosto l’output del makepkg perchè non è l’operazione predominante, fermo restando che per un uso verboso c’è il “build pacco flag flag”.
Per concludere, le due funzioni di compilazione usano le stesse risorse e sono perfettamente compatibili, è possibile lavorare prima con un build1 generico e successivamente con un build specifico su un pacchetto che, ad esempio, prima non compilava causa dipendenze mancanti o PKGBUILD da sistemare, per poi concludere con un unico add. L’eventuale modifica del PKGBUILD dovrà essere fatta in separata sede ed a mano.
Il programma comunque non è ancora multitasking e dubito lo sarà mai, perchè la compilazione tende ad usare gia di suo l’intera potenza della cpu.

Per ora questo è quanto. Saluti.

archlinux, bash, repo, scripting Hide