[Silvan]

Per clonare:

$ git clone ssh://git@git.openmamba.org:4444/usbinstall.git

Se hai fatto il clone diversamente prova a reimpostare l’url remota;

$ git remote rm origin

$ git remote add origin ssh://git@git.openmamba.org:4444/usbinstall.git

[Silvan]

Non l’ho ancora provato ma ho caricato il progetto su git.

Per la dimensione delle icone grazie per la segnalazione, correggo.

[Silvan]

Nota aggiuntiva: i core dumps vengono generati solo per i processi eseguiti da una shell o sessione di root, infatti il file /etc/profile contiene

[ "$UID" = "0" ] && ulimit -S -c 1000000 > /dev/null 2>&1

Per disattivare la creazione di tali file dovrebbe bastare aggiungere il comando:

ulimit -S -c 0 >/dev/null 2>&1

in un file richiamato all’avvio di una shell della cartella root, ad esempio /root/.bashrc o /root/.bash_profile.

[Silvan]

Per me la soluzione migliore rimane di fare uno script unico lanciato in background che comunica con il programma padre attraverso dbus. Gestire script esterni è meno facile di quello che sembra e lanciarne uno solo è meglio, altrimenti poi se scappa la gestione del programma padre ci si ritrova con dei processi che si sovrappongono e casini del genere con effetti imprevedibili. Bisogna controllare che gli script siano in esecuzione, prima di lanciare i successivi, farne il kill ecc. tanto vale in questo caso farne uno solo e controllare solo quello, visto che tanto per la progress bar deve comunque comunicare tramite dbus.

Il tuo programma probabilmente lo trovi su dbus perchè comunica con udisk, ma perchè sia in grado di ricevere segnali dall’esterno devi creare un event loop. Nel dettaglio ora non so dirti e farti un esempio preciso, ma qui è spiegato: http://dbus.freedesktop.org/doc/dbus-python/doc/tutorial.html#receiving-signals

[Silvan]

Come avrai visto questa discussione è già stata affrontata nelle liste di chromium con gente parimenti incazzata. Io stesso nell’ultima release dei livecd di openmamba ho modificato il modo in cui funzionano per farli girare come utente e non come root, cosa che comunque è meglio ed era da fare da tempo.

Secondo me il problema non è di un abuso di potere di Google, la spiegazione tecnica è nel fatto che lanciando chromium come root in una sessione aperta come utente, questo distrugge la configurazione dell’utente. Infatti il workaround (dicono, non l’ho testato perchè non mi interessa per i miei scopi), consiste nel lanciare chromium con una directory udente diversa da quella di default, esempio:

chromium --user-data-dir=/root/.chromium_as_root

Comunque usare openmamba da root chi vuole ovviamente lo può fare, ma non è supportato e ci sono altri problemi noti (il mondo degli sviluppatori open sorce generalmente concorda nel fatto che non sia una buona pratica e da questo ne consegue che alcune cose non sono supportate e anche altri software oltre a chromium si rifiutano di partire come root, non per imposizione, quando il software è aperto nulla può essere imposto, ma per evitare condizioni non testate). Ci sono altre possibilità, come configurare sudo per non chiedere la password, oppure lavorare dentro una sessione usando una finestra di terminale come root.

Per firefox 7 grazie per la segnalazione, verificherò.

[Silvan]

Per richiedere la cancellazione ti prego di scrivere a info <at> openmamba.org. I post inseriti saranno associati ad un utente anonimo/deleted e saranno eventualmente modificati per oscurare il nome utente ed altre informazioni personali.

[Silvan]

Se sei d’accordo a rilasciare l’immagine secondo i termini di una licenza Open Source compatibile con openmamba, ti chiedo se puoi inviare l’immagine in un formato sorgente (per esempio il formato di Gimp con i livelli) che possibilmente ne permetta il mantenimento per eventuali modifiche future. Grazie!

mambawelcome e l’installer sono scritti con kommander per KDE3, un tool che purtroppo è diventato obsoleto in quanto non è stato portato su KDE4. I file .kmdr possono essere modificati con kmdr-editor e vengono eseguiti con kmdr-executor.

[Silvan]

Ottimo, l’interfaccia è graficamente così gradevole e curata che stonerà insieme agli attuali mambawelcome e installer che andranno rifatti anche quelli al più presto 🙂

Magari per una milestone2 2.1. Sto pensando di usare il tuo lavoro grafico per lo splash screen di libreoffice che sto finendo (spero) di pacchettizzare.

Per l’usbinstall.sh, bisogna modificarlo, penso sia abbastanza semplice, in modo che prenda in ingresso i parametri che servono e quindi lasciare solo la parte che fa l’installazione, così lo puoi lanciare ad esempio in questo modo:

usbinstall.sh /dev/sdb /tmp/openmamba-milestone2-bootusb...cpio.gz /tmp/openmamba-milestone2-livedvd...iso

Il problema è che il frontend grafico dovrebbe comunicare con lo script per conoscere lo stato di avanzamento dell’installazione, questo in teoria sarebbe da fare sempre con dbus, se non viene in mente niente di meglio. Lo script può usare la linea di comando per mandare le informazioni al frontend tramite dbus, però il frontend si deve mettere in ascolto registrandosi. Ora non ho tempo di guardare ed essere più preciso ma nel frattempo magari riesci ad andare avanti recuperando qualche esempio o informazione in rete.

[Silvan]

Questo esempio mi sembra più calzante:

http://stackoverflow.com/questions/5067005/python-udisks-enumerating-device-information

[Silvan]

Usare lo script per l’installazione finale può essere una buona idea ma per la selezione dei dispositivi nell’interfaccia grafica sarebbe meglio parlare con udisks attraverso dbus. Come? Prova a lanciare qdbusviewer, vai nel tab System Bus e cerca e clicca su org.freedesktop.UDisks. Sulla destra trovi i metodi con tutte le informazioni disponibili. Il secondo passo è esplorare questi metodi con PyQt4, su questo penso si trovino molte cose in rete. Questa si riferisce a KDE ma tanto i metodi usati per dbus non fanno parte di kde:

http://techbase.kde.org/Development/Languages/Python/PyKDE_DBus_Tutorial#DBus

[Silvan]

Per lo sfondo dovrebbe risolversi con l’aggiornamento di gnome-theme-openmamba. Avevo preso l’esempio sbagliato e impostato la chiave di gconf come mandatory. Per vedere le chiavi e quello che si può fare modificandole potete installare gconf-editor.

Ho anche fatto un aggiornamento di mambatray dopo aver notato che i testi inseriti nel codice sono in italiano, mentre sarebbe una buona regola scrivere nel codice i testi in lingua inglese e poi usare i file .po per le traduzioni, almeno di solito e in openmamba si fa così essendo un sistema multilingue.

Notte.

[Silvan]

Per distrowatch penso che le modifiche le faranno quando uscirà la versione stabile o comunque manderò una segnalazione per le informazioni mancanti.

Per la home di liveuser, non avevo visto, bello…comunque ho fatto questa modifica all’ultimo momento prima del rilascio della 2.0pre6, in quanto precedentemente i supporti live giravano come utente ‘root’, ma chromium si rifiuta di partire in questo modo, questo mi sa che devo sistemarlo io negli script di makedist.

Per le password, anche qui la modifica per liveuser cambia un pò le cose, nessuna password è impostata per sicurezza, comunque con VirtualBox si può switchare premendo il tasto di controllo (quello che è nelle tue impostazioni, ALT, Windows, ALTGR..) insieme ad F2.

Un collegamento alla homepage si può senz’altro mettere, bisogna creare un file .desktop che lancia xdg-open http://www.openmamba.org e/o altri con i link al forum e al wiki. Se puoi creare e testare questo o questi file desktop e poi me li mandi, li aggiungo rapidamente. Grazie.

[Silvan]

Epiphany rimosso.

Il browser predefinito direi che è Chromium, Opera non essendo open source non lo considero per un’installazione predefinita, se non erro la licenza non permette neanche di distribuirlo su target embedded.

Phil: cosa c’è di troppo nella cartella home? Dovrebbe esserci solo la cartella Desktop e un pò di cartelle nascoste per la configurazione dei programmi. Per i menù, sì per modifiche generali bisogna agire su /etc/xdg/menus. Per lo sfondo, quello che ho fatto è semplicemente questo (nel %post di gnome-theme-openmamba):

gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type string --set /desktop/gnome/background/picture_filename /usr/share/pixmaps/backgrounds/gnome/openmamba-green/openmamba-green.jpg

Ovvero ho impostato lo sfondo predefinito nella configurazione generale di Gnome, ed infatti non mi aspettavo che poi l’utente non potesse modificarlo nella sua configurazione personale.

[Silvan]

Bello lo screenshot di usbinstall, vedo che stai facendo una cosa per bene anche dal punto di vista grafico, ottimo.

Per quanto riguarda le icone che sono uscite nella 2.0pre6, non sono quelle previste, in quanto nella preview video vedo che nel menù non compare il logo di openmamba ma quello di gnome, quindi dovrò verificare.

Riguardo agli altri suggerimenti vediamo quello che si riesce a fare, la 2.0 vorrei che uscisse con minime modifiche entro un paio di settimane, altrimenti si rischiano altri mesi dopo anni di ritardo, ed essendo gnome un nuovo target secondario e non previsto inizialmente per la milestone2, sopporteremo se livecd-gnome non sarà perfetto al rilascio. Ovviamente io parlo di quello che penso che riuscirò a fare, ma chiunque può contribuire per raggiungere più in fretta obiettivi più ambiziosi 🙂

Per i programmi di default (quelli nel livecd e poi installati con mambabase) e il menù accetto suggerimenti. Il menù comunque continua a differire a seconda del tema di icone installato, quindi intanto devo verificare il problema di cui sopra per essere sicuro che parliamo della stessa cosa.

[Silvan]

Per la versione 2.0 non è pensabile di cambiare il logo in quanto è un lavoro molto grosso e il rilascio, spero, è prossimo.

Però si può iniziare a discuterne per la versione milestone3, in realtà la mia idea principale era di cambiare il logo basato sulla ‘S’ in ‘O’ o ‘M’. La ‘S’ è presa dal logo di mambaSoft ma non ha riferimenti diretti con openmamba ed inoltre so che qualcuno ha pensato che potesse essere un riferimento al mio nome, cosa non voluta.

Il logo ‘S’ è stato realizzato da un amico grafico ai tempi della fondazione di mambaSoft, 5 anni fa, mentre il tema grafico della versione 2.0 è stato frutto di un accurato lavoro di un’amica collaboratrice, 2 anni fa.

Per la versione milestone3 bisognerà innanzitutto considerare se si trova la disponibilità a contribuire in tal senso e credo che molto dipenderà dall’interesse successivo al rilascio della milestone2, versione stabile rilasciata dopo 2-3 anni dalla prima, durante il quale il lavoro è stato prettamente orientato agli aspetti tecnici e di mantenimento, cosa che ha senz’altro condizionato e limitato l’interesse a partecipare per nuovi contributori. Ora che i meccanismi di gestione sembrano più efficienti ci potrà concentrare di più sugli aspetti orientati alla comunità di sviluppo accrescendo sperabilmente l’interesse e la partecipazione in questo senso.

[Autore]

Articoli