[MAXI-GUIDA] Come iniziare a compilare e buildare Android

[KlaasMad]

Effettuare il porting di una ROM usando il codice sorgente
Parte 2/2

Abbiamo tutti i sorgenti necessari, ma non è finita qui. Difatti è qui che arriva la parte complicata che varia da ROM a ROM e da device a device. Non essendo possibile trattare tutte le ROM in circolazione e non essendo possibile trattare tutti i device in circolazione, accennerò il procedimento essenziale, poi, purtroppo, cambia da caso a caso e la frammentazione è molta.
Nel caso delle CM-based, dovremo ottenere i file proprietari che andranno a piazzarsi in vendor/nomebrand/codename e lo faremo nello stesso modo in cui lo abbiamo fatto per la CyanogenMod. Colleghiamo il device al pc (nel nostro caso il Samsung Galaxy SIV) e da terminale diamo:

cd sorgenti/carbon/device/samsung/jfltevzw
./extract-files.sh

In questo modo andremo ad eseguire lo script extract-files.sh contenuto nella cartella sorgenti/carbon/device/samsung/jfltevzw. Questo andrà a creare la struttura di file proprietari in sorgenti/carbon/vendor/samsung/jfltevzw.

Adesso abbiamo i file prebuildati.

Quick tip: è possibile ottenerli anche in un altro modo: difatti possiamo recarci nel github di una ROM già sviluppata per il nostro device e forkare il vendor tree del nostro device ed aggiungerlo al local_manifest.xml (proprio come abbiamo fatto per gli altri sorgenti) secondo il path corretto (vendor/nomebrand/codename). Non è detto che funzioni, non tutti rilasciano i file proprietari nei loro sorgenti (ed è qui che ci ricolleghiamo al discorso di porting molto semplice o molto difficile).

Ora, rechiamoci nuovamente nel github della ROM che vogliamo portare, nel nostro caso la Carbon e andiamo a guardare il vendor della ROM reperibile in vendor_nomerom (essendo una CM-based sarà android_vendor_nomerom), quindi github.com/carbondev/android_vendor_carbon. Clicchiamo su commits



e scrolliamoli tutti finché non troviamo un commit relativo all'aggiunta di un nuovo device



Clicchiamoci e guardiamo la struttura del commit.
Siamo stati fortunati: in questo caso per aggiungere un nuovo device, sarà necessario soltanto aggiungere una sola riga di codice al file ~/sorgenti/carbon/vendor/carbon/vendorsetup.sh



NB. Ovviamente al codename del LG G2 dovremo sostituire il codename del nostro device.



NB. è assolutamente necessario seguire l'ortografia degli altri setup, altrimenti non builderete.

Adesso è la volta di modificare i file dentro il device tree in modo da farli combaciare col vendor tree.
Andate fisicamente col gestore file nella cartella ~/sorgenti/carbon/device/samsung/jfltevzw e spulciatevi tutti i file con estensione .mk alla volta di trovare ogni referenza alla CyanogenMod (o cm), per sostituirla con la parola "carbon" (senza virgolette ovviamente). Notate anche il file cm.mk, che è da sostituire con carbon.mk. È un'operazione lunga e tediosa e spesso porterà a diversi errori, ma purtroppo, nel caso non esista il vendor tree già bello confezionato nel github di qualche ROM, è l'unica opzione plausibilmente efficace.

È tempo di modificare anche un file all'interno dei sorgenti del kernel. Rechiamoci fisicamente col filemanager in ~/sorgenti/carbon/kernel/nomebrand/nomekernel/arch/arm/configs.
Ci saranno una serie (ma anche uno solo) di file, cerchiamo quello con la referenza al nostro device (nel caso di multipli file) e modifichiamo il nome del file secondo quanto indicato nel file ~/sorgenti/carbon/device/nomebrand/codename/BoardConfig.mk alla stringa

TARGET_KERNEL_CONFIG :=

Una volta terminata quest'operazione, da terminale rechiamoci nella root dei sorgenti:

cd ~/sorgenti/carbon
. build/envsetup.sh
lunch

Se siamo stati attenti, dovrebbe essere spuntata la voce del nostro device nel terminale, come da immagine:



Siamo pronti a buildare (si spera)!

make carbon -j7

NB. questa volta il comando di build è cambiato perché le istruzioni presenti in github.com/carbondev/android.git ce lo hanno imposto.



Se siamo fortunati, il processo di build andrà avanti e si completerà da solo, altrimenti si renderà necessaria la modifica di qualche file (saprete quale in base all'errore che il terminale vi restituisce).
Se avete degli errori dei quali non riuscite a venirne a capo, chiedete assistenza in questo thread https://www.androidiani.com/forum/in...ammazione.html.

[KlaasMad]

Come buildare il proprio kernel
Parte 1/2

Ipotesi: abbiamo già la nostra bella ROM preferita che non vogliamo modificare (o non ne ha necessità, perché no?), ma sentiamo il bisogno di modificare il kernel per migliori performance/battery life. Perché non crearci il nostro bel kernel personalizzato per poter inserire al suo interno tutte le features che vogliamo? In fondo Android poggia su una variante del kernel Linux con l'obbligo di essere open source, quindi possiamo tranquillamente metterci mano!
Vediamo come procedere.

Prefazione

Iniziamo col dire, sottolineando, che un kernel per un particolare dispositivo non va assolutamente e nella maniera più assoluta, installato/flashato su un altro dispositivo, neanche della stessa marca o vagamente simile (tipo tra i9100 e i9105), pena il brick del vostro telefono. Questo è l'errore più banale e più pericoloso da fare, quindi non mettetevi in testa di flashare un kernel di un dispositivo solo perché è simile o perché vi piace la sua struttura!

Come effetto collaterale di questa "regola" di android, c'è quello che questa guida non è e non potrà mai essere universale per ogni device. La guida qui di seguito non è intesa per qualsiasi dispositivo, ma sono linee guida generali (pensate voi di creare una guida per ogni device in circolazione, da uscirne pazzi!). Se avete problemi, potete sempre chiedere nel thread SOS di questa sezione.

La guida segue la traduzione di un'altra guida che feci a suo tempo per il mio device (i9100), riadattata per ogni device, quindi perdonatemi se non segue il trend esplicativo delle altre guide in questo thread.

Step 1. Ambiente

Abbiamo già completato questi passi, però rieseguite il codice sul terminale, magari qualche pacchetto può essere stato tralasciato nella prima fase.

A. Dovrete buildare su Linux (e questo già lo sappiamo fare).[/I]

B. Pacchetti richiesti: git-core, gnupg, flex, bison, gperf, libsdl-dev, libesd0-dev, libwxgtk2.8-dev, build-essential, zip, curl, libncurses5-dev, zlib1g-dev, lib32z1, lib32ncurses5, lib32bz2-1.0, lib32z1-dev, lib32ncurses5-dev, gcc-multilib, g++-multilib, e Adb.
Quindi per installare le dipendenze richieste, da terminale digitiamo:

sudo apt-get install git-core gnupg flex bison gperf libsdl-dev libesd0-dev libwxgtk2.8-dev build-essential zip curl libncurses5-dev zlib1g-dev lib32z1 lib32ncurses5 lib32bz2-1.0 lib32z1-dev lib32ncurses5-dev gcc-multilib g++-multilib

e per installare adb, potete installarlo via terminale:

sudo apt-get install android-tools-adb

NB. il forum storpia il codice ed inserisce una "k" ed una chiocciola "@" di troppo, per cui sarebbe android, trattino, tools, trattino e alla fine adb.

o potete trovarlo nella cartella dove avete estratto SDK, a sua volta dentro la cartella platform-tools.

Installate anche git:

sudo apt-get install git

C. Aprite un terminale (ctrl+alt+t su Ubuntu)

D. Digitate "mkdir android" (crea la cartella android) (non inserite le virgolette)

E. Digitate "cd android" (entra dentro la cartella android)

G. Digitate "mkdir kernel" (crea la cartella kernel)

F. Chiudete il terminale.

Step 2. Vostri sorgenti

A. Aprite il terminale

B. Digitate "cd android/kernel" (entra dentro la cartella kernel situata dentro la cartella android)

C. Digitate "git clone git://github.com/DooMLoRD/android_prebuilt_toolchains.git toolchains" (recupera attraverso il comando git clone, il toolchains e lo piazza dentro la cartalla toolchains)

D. Adesso arriva la parte difficile, vi serve alcuni tipi di sorgenti per il vostro kernel. Controllate i due seguenti siti per il vostro dispositivo. Una volta che li avete scaricati, devono essere estratti o clonati dentro una cartella nella tua directory del kernel

Welcome to HTCdev
Samsung Open Source Release Center
Developer World
OpenSource Code Distribution

Cos'è un toolchain? Date un'occhiata qui. Questi toolchains sono instabili e non totalmente supportati ancora. Queste sono le versioni che uso e se volete usare una versione stabile (4.5.3 as of 07/06/12) trovate il link su google.

Step 3. Modifiche

Questa è la parte che incuriosisce la gente, loro vorrebbero sapere come fare modifiche al kernel e renderlo speciale. Comincia tutto questo che viene dalla root directory (~/android/kernel) del sorgente del kernel.

Mod 1. Applicare una patch

A. Scarica la patch che vuoi applicare, in questo caso questa dovrebbe funzionare.

B. Salvate il file come "kernelPatch" nella vostra directory del kernel

C. Aprite un terminale

D. Spostate dentro la root del vostro kernel la directory del kernel che volete patchare

E. Digitate "patch -p1 < ../kernelPatch"

Spiegazione:
A. Semplice, ci serve una patch. La patch in se stessa è semplice e differisce dall'originale albero (tree) del codice del kernel.
Posterà un veloce tutoria su come creare una patch nel terzo post. La patch sopra contiene diversi governor da aggiungere al vostro kernel.

B. Si spiega da sé.
C. Si spiega da sé.
D. Si spiega da sé.
E. In pratica lanciamo il comando della patch sulla nostra sorgente usando la patch che abbiamo scaricato prima. La porzione della patch è il binario, l'opzione "-p1" ci consente di controllare il numero di successivi slash (/) da rimuovere dal percorso del file (vi servirà di guardare quest'opzione più che usare una strana struttura di directory o di applicare le patch da un posto a casaccio) L'operatore "<" dirige il contenuto del nostro file "../kernelPatch" nel comando.

Mod 2. Aggoiungere un singolo governor

A. Aprite "drivers/cpufreq/Kconfig"

B. Aggiungete le seguenti stringe in uno spazio appropriato tra gli altri governorAdd the following lines in appropriate spot amongst the other govenor's

config CPU_FREQ_DEFAULT_GOV_SMARTASS
            bool "smartass"
            select CPU_FREQ_GOV_SMARTASS
            select CPU_FREQ_GOV_PERFORMANCE
            help
              Use the CPUFreq governor 'smartass' as default.

config CPU_FREQ_GOV_SMARTASS
           tristate "'smartass' cpufreq governor"
           depends on CPU_FREQ
           help
             smartass' - a "smart" optimized governor!
             If in doubt, say N.

C. Aprite "drivers/cpufreq/Makefile"
D. Aggiungete le seguenti stringhe in uno spazio appropriato.

    obj-$(CONFIG_CPU_FREQ_GOV_SMARTASS)     += cpufreq_smartass.o

E. Create a file chiamato "drivers/cpufreq/cpufreq_smartass.c" (l'ha spiegato un po' a cazzo di cane, il file è cpufreq_smartass.c dentro la direcotry drivers/cpufreq).

F. Inserite il sequente codice in quel file
[C] Smartass Kernel Govenor - Pastebin.com

G. Aprite "include/linux/cpufreq.h"

H. Sotto la sezione "Cpufreq Default" aggiugnete

#elif defined(CONFIG_CPU_FREQ_DEFAULT_GOV_SMARTASS)
extern struct cpufreq_governor cpufreq_gov_smartass;
#define CPUFREQ_DEFAULT_GOVERNOR (&cpufreq_gov_smartass)

Ok, c'è un governor aggiunto, fate gli stessi identici step per qualunque altro governor che vogliate aggiungere.

Spiegazione:

A. Aprite un file che avete già. Il Kconfig file ci lega dentro il nostro comando "make menuconfig" più tardi, facendo sì che la nostra mod sia un'opzione selezionabile.

B. Aggiungete il codice appropriato per il nostro governor per avere il nostro file .config. Il primo trancio ci permette di settare il nostro governor come default per il nostro kernel, l'altro ci permette di rimuoverlo o aggiungerlo alla build come vogliamo.

E-F. La creazione del governor stesso, non saltate questo passo. Suggerisco di leggere attrraverso questo codice per capire come funziona, è qualcosa di strepitoso.

G-H. Apre un file e aggiunge il codice necessario per legare il nostro modulo al resto del sorgente. Senza questo non saremo capaci di compilare il dovuto resto del sorgente senza conoscere se il modulo esiste.

Step 4. Ottenere un file config

Opzione A. Prendere un config file da un kernel.

A. Agganciare un device che sta usando un kernel simile al tuo e usarlo come base.

B. Aprite un terminale.

C. Andate nella vostra directory root del kernel.

D. Digitate "adb pull /proc/config.gz"

E. Digitate "gunzip config.gz"

F. Digitate "mv config arch/arm/configs/<your_config_name>_defconfig"

Spiegazione:

A. Questo vi permetterà di prendere un file di configurazione da un kernel che sapete funzionare. È molto più facile iniziare così. Come nota, non tutti i kernel supportano quest'opzione, così devi provarne diversi prima di avere il file funzionante. Se non funziona, guarda l'opzione B.

B. Ormai siete bravi a farlo.

C. Naviga verso la parte più alta della directory del tuo kernel.

D. Usa adb per prendere una copia del file config per i tuoi sorgenti.

E. Unzippa il file di configurazione.

F. Sposta il file di configurazione che hai preso verso la directory di configo così possiamo usarlo come referenza più tardi.

Opzione B. Usare il config del produttore.

Sfortunatamente, come detto sopra, non tutti i kernel supportano il metodo "/proc/config.gz". Puoi trovare un file di configurazione tipicamente nel percorso di configurazione del produttore "arch/arm/configs". Credo che quello per il mio HTC Flyer è chiamato "flyer_hc_defconfig", così dovrebbe essere (almeno simile) per te Inoltre leggi i readme per farti un'idea di come modificarli. Io farei una copia di esso chiamata "<your_config_name>_defconfig" e usarla come mia base.

CONTINUA AL POST SUCCESSIVO

[KlaasMad]

Come buildare il proprio kernel
Parte 2/2

Step 5. Building

È tempo di partire col vero atto del building.

Part A. Step prebuild.

A. Apri un terminale e vai nella root del tuo kernel

B. Digitate "export ARCH=arm"

C. Digitate "export CROSS_COMPILE=~/android/kernel/toolchains/arm-eabi-linaro-4.6.2/bin/arm-eabi-"

Part B. La prima build.

A. Digitate "make <your_config_name>_defconfig"

B. Digitate "make menuconfig" e fate i cambiamenti richiesti per usare qualsiasi modulo avete aggiunto.

C. Digitate "make -j<maximum number of jobs>" (I jobs sono le operazioni per volta che la macchina esegue. Solitamente si fa [numero di core del pc] x2, ma tanti tengono la tesi di [numero di core del pc]+1. Io personalmente quando buildo faccio make -j8 ossia 4 core x2.)

Part C. Re-Builds

A. Digitate "make clean"

B. Digitate "make oldconfig"

C. Digitate "make -j<maximum number of jobs>"

Part D. Building i moduli

Avete due opzioni:

A. Digitate "make modules"

B. Digitate "make path/to/your/module.ko"

Spiegazione:

Parte A. (Questi step sono richiesti ogni volta che chiudi il terminale e lo riapri)

A. Ok, non lo spiego più.

B. Questo comando setta il tuo obbiettivo dell'architettura (arm, x86, powerpc etc)

C. Definisce il percorso per il toolchain che stiamo per usare per compilare il kernel. Puoi cambiarlo indicando il percorso di qualunque toolchain hai scaricato o ti senti di usare. Il modo in cui è configurato è per usare il toolchain Linaro usato sopra.

Parte B. (Questi devono essere eseguire la prima volta che buildi il kernel)

A. Carica il tuo file di configurazione da prima.

B. Apri un meno per configurare il kernel. Userà il file di config caricato nel precedenti step come basi.

C. L'inizio del build. Tipicamente permetto un job per core, così sulla mia macchina quad core metto "make -j4". Aumentare il numero non renderà la build più velocemente, il tuo processore deve essere in grado di supportare i jobs che gli stai assegnando.

Parte C. (usate i comandi quando build qualsiasi volta che non sia la prima)

A. Questo comando soddisfa ogni vecchio binario o modulo che avete compilato prima e iniziamolo daccapo. Mi piace eseguirlo ogni build, a meno che i miei cambiamenti piccoli e localizzati.

B. Un meraviglioso comando: analizza quello che ha cambiato e ti conduce verso le nuove opzioni.

C. Vedi la spiegazione per la parte C sopra.

Parte D.(usa questi per buildare i moduli del kernel

A. Quest ribuilderà tutti i moduli.

B. Rebuilderà solo il modulo che ti serve. Utilissimo quando dovrai rebuildare il modulo wifi.

Step 6. Ed ora?

Ok, abbiamo cominciato a buildare ed aspettiamo che finisca. Quali sono i possibili risultati?

Risultato A. La build riesce

Grande! Hai buildato il tuo primo kernel dai sorgenti! Ci sono un paio di cose che ti serviranno per usare questo kernel nel tuo device: qualsiasi modulo ".ko" (kernel object) e i binary zImage. Se presti attentione all'output del compilatore, vedrai la locazione di questi oggetti. Comunque i seguenti comandi ti renderanno la vita un pelo più semplice:

A. Aprite un terminal

B. Andate nella root directory del kernel

C. Digitate "mkdir ../<tuo_kernel>_output"

D. Digitate "cp arch/arm/boot/zImage ../<tuo_kernel>_output/zImage"

E. Digitate "find . -name "*.ko" -exec cp {} ../<your_kernel>_output \;"

Spiegazione:

A-C. Si spiegano da sé

D. Spostate i binari del nostro kernel nella cartella di output

E. Questo tocco di magia trova tutti i moduli .ko e li copia nel file di output.

Vi servirà inoltre di assemblare l'immagine del kernel contenente gli iniramfs per il vostro device, assieme ai binari del kernel. Quello comunque è oltre lo scopo di questa guida. Per iniziare, provate a cercare le sequenti frasi.

building android kernel image
xda build kernel image
xda unpack boot.img

Risultato B. La build fallisce

Oh, è fallita. Beh, sai cosa, succederà un sacco di volte. Googla e sperimenta diverse soluzioni. I seguenti consigli cercheranno di aiutarti nel debug.

Esegui una build pulita.

A. Backuppa il tuo file di config (digitate "cp .config ../backupConfig")
B. Ri-eseguite il processo di build usando il vostro defconfig dall'inizio.

Limitate l'output

A. Un altro buon consiglio è quello di eseguire "make -j1" per capire dove sta l'errore, così il testo di output nel terminale sarà più lento e potrete scovarlo.

Potete comunque postare nel thread di SOS development per provare a risolvere insieme agli altri utenti.
Il bello è comunque provare e riprovare! Non vi aspettate nella maniera più assoluta di riuscire al primo colpo, ricordate quello che ho scritto all'inizio di questa maxiguida, gli errori del terminale saranno i vostri compagni più fedeli, saranno sempre lì, per aiutarvi a crescere, fateli vostri amici!

[KlaasMad]

Post riservato per eventuali aggiunte riguardo al building del kernel.

[KlaasMad]

Il comando Git e la sua integrazione con Github

Prefazione

Immaginate di dover scrivere un breve programma in java che vi restituisca a video il vostro nome. Peserà a mala pena 15KB e vi occuperà lo spazio di un file in estensione .java in una cartellina remota (uhm termine inappropriato per questa parte della guida, diciamo sperduta) del vostro pc. Spostarla da un pc ad un altro vi costerà in termini di tempo, più nel prendere fisicamente la pen drive che nello spostamento in sé. Ora, immaginate di avere il file su una cartella locale in file sharing (tipo una cartella su DropBox) e che sullo stesso ci lavoraste su in due persone da due pc diversi: data la minutezza del file e la semplicità di esso, non avreste problemi a coordinarvi per sapere cosa modificare e quando modificare, in modo da non accalcarvi in due sullo stesso punto del progetto e non sovrascrivere eventuali cambiamenti fatti da una o dall'altra parte.
Ma ciò è possibile su un piccolo file da 15KB. Ecco, ora immaginate di lavorare su una build di una ROM android, quindi con dei sorgenti da 12GB con una miriade di file che constano in una miriade di righe di codice e siete un team che sta modificando il framework dei settings. Ad un certo momento, in 4 persone (i membri del vostro team) decidete di salvare e non sapevate di lavorare sullo stesso file. I cambiamenti fatti verranno sovrascritti dall'ultimo che salva il file, facendo perdere il lavoro fatto dagli altri fino a quel momento, che può constare di qualche riga di codice, ma che può constare anche di diverse centinaia di righe!
Avreste perso un corposo lavoro e, soprattutto la sanità mentale del membro al quale avete cancellato il lavoro!

A cosa serve questo preambolo? No, non è un delirio, è il concetto di fondo sul quale si basa Github ed il comando sul quale è basato Github stesso, ossia Git!

Due righe di riferimento storico su Git è necessario spenderle, visto che è stato creato dal padre del kernel Linux stesso, Linus Torvalds a creare questo utilissimo comando. Git è un sistema di controllo di versione, direttamente usabile da riga di comando (ossia usando il vostro terminale) e permette di tenere degli "snapshots" del vostro lavoro, in modo da tornare tranquillamente indietro (nel caso quel che avete fatto è solo un abominio di programmazione o, per dire, se capite che non sia utile ciò a cui avete lavorato). Inoltre, citando l'esempio fatto prima sul piccolo programma in java condiviso, è possibile lavorare in due (o più) sullo stesso file su locale e, una volta uploadato, git tiene in conto entrambe (o più) le versioni del file e fa decidere all'utente se e quando unirli (merge) e se e quando scartarli (discard).
Prima di addentrarci nel mondo dei comandi git, è necessario introdurre un concetto fondamentale, il concetto di commit: il commit è, appunto, lo snapshot o, per dirla in maniera videoludica, il checkpoint dove arrivate e salvate, per poi tornate indietro in caso di errore/perdita di dati/sovrapposizione di scrittura. In pratica è quel che rende git il grandioso strumento che è!

Parimenti, introduciamo github. Sebbene ne abbiamo ampiamente parlato nei precedenti step della guida, adesso ne approfondiamo la conoscenza perché sarà un altro dei nostri grandi alleati nella conquista delle capacità di buildare una ROM.
Github è un social network (avete letto bene) dove è possibile uploadare il proprio codice sorgente (in pienissimo spirito open source), mostrarlo al pubblico, seguire e farsi seguire da altri developer. È controllato da git per l'integrazione del codice e quindi, riprendendo l'esempio del team che lavora su una ROM, posto che 4 persone lavorano sullo stesso file sulla copia locale dei sorgenti (scaricata mediante il comando repo sync, ricordate?), è possibile salvare uno snapshot attraverso il comando git commit, uploadare i file e tenere 4 copie del file stesso che poi si deciderà se fargli eseguire il merge o cancellare/modificare qualcosa.
Premettiamo un concetto che può sembrare banale, ma che in realtà non lo è per chi non è avvezzo di programmazione e simili. Github è un grandioso strumento perché contiene il codice sorgente di programmi/sistemi operativi/kernel ed in generale tutto software. Cosa significa? Avere il codice sorgente non significa avere il software già bello "assemblato" (perdonate il termine), ma solo i "pezzi" ed è da costruire. Noi possiamo assemblare il software, ma possiamo anche cambiarlo, modificarlo, ridurlo, aumentarlo, possiamo farci tutto quello che vogliamo. Discorso contrario se avessimo solo e soltanto il software già bello che costruito. In questo caso non potremo farci nulla, solo eseguirlo, senza poter vedere com'è fatto dentro, senza sapere il funzionamento. Esistono dei tool per decompilare ma non sono sempre estremamente precisi e comunque, funzionano (quando funzionano) su software semplici.

Quindi, cosa fa Github? Vi mette a disposizione i pezzi del vostro puzzle (i sorgenti, come quelli che abbiamo scaricato come prova per la rom), ma sta a voi metterli insieme!
Iscriversi non è molto diverso da come fareste per qualsiasi social network, Facebook, Google+ o Twitter che sia, ma richiede qualche passo aggiuntivo mediante il vostro beneamato strumento, chiamato terminale.

Iscrizione a Github

Recatevi nella home di github ed avrete questa schermata davanti



Non sto a spiegarvi come compilare i campi ovviamente.
Successivamente, aprite il vostro fidato terminale ed installiamo git (lo abbiamo già fatto seguendo la prima parte di questa maxiguida, ma per chi si imbattesse qui ed è solo interessato a github, ecco):

sudo apt-get install git

Configuriamo git con l'email usata per registrarci:

git config --global user.name "Vostro nome"
git config --global user.email "vostraemail@vostraemail.com"

Creiamo una keygen che ci servirà da firma digitale:

ssh-keygen -t rsa -C "vostraemail@vostraemail.com"

Vi chiederà di inserire una passphrase, questa dovrete deciderla voi e cercate di tenerla in mente (o comunque segnatevela da qualche parte).

Il responso del terminale sarà qualcosa del genere:

# Your identification has been saved in /c/Users/you/.ssh/id_rsa.
# Your public key has been saved in /c/Users/you/.ssh/id_rsa.pub.
# The key fingerprint is:
# 01:0f:f4:3b:ca:85:d6:17:a1:7d:f0:68:9d:f0:a2:db vostraemail@youremail.com

Adesso da terminale digitate:

cd ~/.ssh && gedit id_rsa.pub

Questo comando vi porterà nella cartella nascosta .ssh e aprirà con gedit il file id_rsa.pub. Lasciatelo aperto e recatevi su https://github.com/settings/ssh, cliccate su Add SSH key:



Tornate sul vostro gedit e copiate il contenuto del file, incollandolo nella casella in basso:



Da terminale controllache che funzioni tutto digitando:

ssh -T git@ssh.github.com

Vi richiederà la vostra passphrase secondo la chiave id_rsa.pub che avete inserito prima. Se non riuscite ad accedere via ssh, da terminale digitate:

gedit ~/.ssh/config

Ed inserite il seguente testo nel file che vi si aprirà

Host github.com
  Hostname ssh.github.com
  Port 443

Salvate ed uscite.
Da terminale testate se riuscite ad accedere digitando:

ssh -T -p 443 git@ssh.github.com

Dovreste visualizzare qualcosa del genere:

# Hi vostronome! You've successfully authenticated, but GitHub does not
# provide shell access.

Avete configurato Github!


Work in progress...