Porteus

Scusa beny se ti chiedo precisazioni qui in italiano ma non ho capito bene cosa volevi farmi capire in questo messaggio e preferisco chiedertelo in italiano, tanto comunque mi sembri l'unico che abbia citato yay e quindi tanto vale continuare la discussione a parte piu' comodamente.
Ho usato trizen perche' e' stato gia' incluso in nemesis e quindi in qualche modo piu'supportato.
Che differenza ci sarebbe fra usare questo e yay?
Il problema che ho, se non lo spiegato bene, e' che per scegliere quali dipendenze escludere prima di creare un modulo, dovrei considerare anche le dipendenze delle dipendenze e quindi comincia a diventare un problema un po' complesso per le mie esigue conoscenze di aur/sh

ciao ho citato yay perche e' quello che uso abitualmente non in nemesis ma con arch, con arch tu hai una parte di directory che riguardano il sistema : cito anche il readme
The Arch Build System, or ABS, is a series of tools used to obtain the PKGBUILD
scripts that make the packages in Arch Linux's official repositories and work
with them.

Included with ABS is a collection of prototype PKGBUILD files, installed to
/usr/share/pacman, for building RCS-style packages (such as CVS or SVN). These
are installed alongside the stock PKGBUILD and .install file prototypes
provided by pacman.
mnt/sdc1/var/abs/community
/mnt/sdc1/var/abs/core
/mnt/sdc1/var/abs/extra
/mnt/sdc1/var/abs/local
/mnt/sdc1/var/abs/multilib
non so se in nemesis abbiamo questo tipo di approccio, aur invece sono i pacchetti della comunita'che vengono tollerati ma quando ci sono aggiornamenti importanti nel sistema ti raccomandano di rimuoverli per evitare problemi e hai difficolta ad avere aiuto,come hai visto il pacchetto che volevi fare ha delle dipendenze che vergono prese dal repository nemesis poi quando hai installato le dipendenze parte la compilazione vera ed e' sempre cosi, poi artix non ha le versioni aggiornate come arch ma questo non e' un vero problema,per come la vedo io.. non ha senso cercare di rimuovere software che in certe condizioni puo' esserti utile,in porteus un periodo e' stato fatto uno strip massivo dei pacchetti con l'unico vantaggio che poi devi riinstallarli cosi come sono e parlo per esperienza diretta,l'unico neo per salvagurdare il tuo device cerca di usare un ssd con una enclosure piuttosto che una chiave usb o schede sd che se fai tanto build di software durano poco,se apri un pacchetto arch trovi i file del pacchetto e tre file buildinfo, mtree e pkginfo ed e' questo quello che devi guardare per le dipendenze vere del pacchetto buildinfo e' un resume dell'ambiente integrale per quel pacchetto,nemesis mi pare che li rimuove quando fa il pacchetto xzm.ok ricordati il forum nella wiki di arch magari li ci sono risposte piu' esaustive e casi complessi da vedere.

Ho letto ma devo rileggere bene perche' ci sono molte info.
Per quanto riguarda trizen credo che serve solamente a costruire e installare (non ho ancor aprovato a risponderlgi di no ma credo sia superflio) i pacchetti di arch a partire dai PKGBUILD di aur. A quel punto con pacman si installano in nua dir separata e da quella dir si fa dir2xzm.
Immagino che yay faccia qualcosa di simile.

Scusa non sono così bravo in inglese e ho bisogno di scomporre la risposta che mi hai dato nell'altro post, lo faccio qui tanto non credo che darò fastidio a qualcuno:
Qui credo che me lo stai chiedendo, ovviamente nemesis.sgn è nella directory (se ricordo bene è in /porteus adesso non sono davanti a quel pc), comunque avevo pure provato a cancellare quel file quando bootavo con i due sistemi contemporaneamente e mi sembrava che comunque andasse a caricare i moduli dentro all'harddsik non considerando quelli nella usbstick.
Qui non ho capito bene cosa dovrei notare usando fdisk -l.

Si ho provato a usare il cheatcode from ma avendo un comportamento che non mi sembra regolare non riesco a capire se funziona. Avevo anche chiesto ma la sintassi non si capisce bene (soprattutto se bisogna usare i simboli : o =).
Il problema del path è che non può essere assoluto, deve essere per forza relativo all'uuid/label perché quando inserisci e togli dischi può cambiare il nome della partizione (sda può diventare sdb o sdc per dire) e a volte anche in modo randomico quando i dischi possono avere una velocità di lettura concorrente (pensa se inserisci due usb stick). Poi a maggior ragione se usi la pennina in modo nomade, non puoi sapere quanti dischi ci siano nel computer in cui la stai ficcando, quindi la partizione cambia necessariamente path e non puoi usare quindi un path assoluto per il from.

Sinceramente il save.dat devo proprio capirlo meglio perché ad un certo punto mi era sembrato che aveva cominciato a funzionare, ma solo quando avviando da pennina avviava la distro installata su disco che però non bootava da sola. Diciamo che per ora per i salvataggi preferisco svangarmela con i moduli.xzm che dall'ultima spiegazione di ncmprhnsbl (ma quanto è difficile questo nickname...) almeno credo che riesco a gestirli (anche se ho ancora incertezze su come specificare cosa salvare).

ciao, parto da fdisk -l se fai il boot da penna nel notebook,dopo nel terminale fdisk -l come root ti da una lista completa dei device collegati e dei dischi,fai anche un check del filesystem dell'hardisk con gparted o e2fsck sdx nel terminale,qualche tempo fa ho dovuto fare delle build del kernel le directory di porteus sono limitate e arrivi a finire lo spazio disponibile con save.dat mi pare da 10giga ho potuto fare tutto il lavoro senza problemi,ma come hai notato i nomi dei dispositivi cambiano se inserisci qualcosa o addiritura se cambi la porta usb abituale, il save.dat io lo messo nella radice della chiave perche' non ha restrizioni di scrittura e di spazio hai tutto il disco disponibile,ma vuole il percorso esatto, con from fai una prova come from=/mnt/sdg1/home/beny/nemesis, nemesis e' una directory e il percorso e' di un mio disco ma prova con /mnt e anche senza nel path di from, se hai qualche changes attivo quando installi devi rinominarlo per renderlo non attivo se usi il metodo di linux installer.sh.