[Silvan]

Giusto, per rimuoverlo devi attendere l’aggiornamento di desktop-base-gnome, che dovrebbe già essere disponibile.

[Silvan]

Perfetto, ho rimosso il requirement per nsplugin in desktop-base-gnome per la prossima snapshot, mentre tu puoi verificare che tutto sia a posto rimuovendo a mano nsplugin e kdebase-runtime. Per gufw, bene, ho corretto anche libatk. Per l’installer, il problema non è bloccante e si risolverà quando si rifarà l’interfaccia grafica.

[Silvan]

Ok, allora prova a fare rpm -e kdebase-runtime, effettivamente knetattach per kde4 è anche lì.

Per gufw ho corretto anche libgdk-pixbuf e ora puoi installare libgdk-pixbuf-devel per vedere se ci sono altri problemi.

Per l’installer, lo script basato su kommander ha dei problemi noti quando si fanno alcune operazioni sulla finestra (ad esempio minimizza e riapri), per cui puoi verificare se provando di nuovo senza fare particolari operazioni sulla finestra, si blocca ancora nello stesso punto o meno.

[Silvan]

Scusa, prova con rpm -e kdebase3.

Per gufw, dovrebbe risolversi installando libpango-devel. Sto producendo un aggiornamento per spostare il file /usr/lib/girepository-1.0/Pango-1.0.typelib dal pacchetto -devel a quello principale, essendo questo la causa del problema.

[Silvan]

gufw: se installi pygobject2 funziona?

xscreensaver: ok, sto ricompilando il pacchetto togliendo l’opzione passata a configure con la directory di kde

Grazie!

[Silvan]

Per quanto riguarda knetattach, si trova dentro il kdebase vecchio (3.5.10). Al momento non capisco però perchè sia installato, se provi a rimuoverlo con rpm -e kdebase te lo fa fare o c’è qualche altro pacchetto che lo richiede? E se lo rimuove poi parte ancora l’installer?

[Silvan]

Bene per la modifica di mambatray per supportare il proxy di Gnome, puoi guardare se la patch che ho inviato basta? Perchè la modifica alla riga 30 mi sembra inutile essendoci già prima:

desktop_session = QtCore.QString(os.getenv('DESKTOP_SESSION')

[Silvan]

Ciao. Sì una cosa utile per velocizzare il rilascio delle version stabili può essere aggiungere alla propria installazione milestone2 i repository milestone2-kde4, milestone2-xorg e milestone2-makedist. I pacchetti che vedi in questi repository non sono stati importati perchè prima bisogna essere sicuri che non causino problemi, per esempio c’è il nuovo LibreOffice o il plasmoide di kde per la gestione della rete (che per esempio sulla mia installazione milestone2 causa qualche problema dopo il resume). Oltre al changelog dei pacchetti indicato da Ercole (utile per i repository che ho citato), un altro posto utile per capire cosa si sta facendo è il git di openmamba in cui guardando il changelog degli ultimi commit si vedono le cose potenzialmente nuove, per esempio ultimamente ci sono stati vari aggiornamenti di initscripts per supportare lo splash screen nell’installazione su tablet, senza initramfs e bisognerà controllare che non ci siano effetti collaterali nelle installazioni standard. Lo sviluppo va avanti, in questo momento è concentrato su arm, per cui alcune altre cose vanno un pò più lentamente, per fare un rilascio finale bisogna avere qualche giorno libero per fare dei test per bene, a questo punto credo che il prossimo passo sia la 2.0pre8, perchè dalla versione LinuxDay sistema la gestione dei permessi dell’utente live e quindi la difficoltà di dover impostare la password (l’utente live ha tutti i permessi con sudo). Dopo questo rilascio se ci saranno sufficienti feedback si potrà rilasciare a breve la 2.0 finale, magari intorno a fine anno ci sarà più tempo per fare questo. Anche perchè il devel sta iniziando a divergere e gcc 4.6 è lì che aspetta di entrare (altro problema è che bisognerebbe avere un build server per la versione stabile, mentre ora i build avvengono per lo più sulla devel essendo ancora compatibile a livello di ABI). E poi sarà molto interessante passare dal sistema di init multithread fatto in casa a systemd, un’altra cosa di openmamba che verrà gestita upstream con vantaggi di funzionalità e probabilmente anche di performance, ma anche questo è un todo per il dopo.

[Silvan]

Se funziona su ubuntu allora si può facilmente capire quale driver sta usando.

Per fare questo potresti aprire una finestra di terminale e digitare i seguenti comandi:

sudo cat /proc/asound/* > /tmp/ubuntu.txt

sudo cat /proc/asound/card*/* >> /tmp/ubuntu.txt

sudo lsusb -v >> /tmp/ubuntu.txt

sudo lsmod >> /tmp/ubuntu.txt

Il file /tmp/ubuntu.txt lo puoi allegare qua o inviare a reports at openmamba.org.

In openmamba sono supportati tutti i driver inclusi nel kernel e nel progetto alsa. Se ci sono dispositivi che richiedono altri driver li supportiamo quando ne veniamo a conoscenza se abbiamo le informazioni necessarie o il dispositivo a disposizione. Se poi si scopre che il dispositivo è supportato da alsa ma non viene riconosciuto in openmamba vediamo di capirne il motivo, in quest’ultimo caso probabilmente ci torna utile avere un report di openmamba come suggerito inizialmente da michiamophil, essendo un dispositivo audio esterno e secondario non escludo che potrebbe esserci quale problema per questo motivo.

[Silvan]

Già, confermo che sembra che un driver per linux non esista. In rete si trova solo l’implementazione di un driver per la versione mbox2: http://www.zamaudio.com/?p=97

[Silvan]

La cosa strana che vedo è un riferimento ad un path dell’ambiente di build dove sono stati compilati gcc e glibc (/mnt/sdc1/autodist), ma il file video.c contiene un main? E se compili senza o con meno opzioni?

Il problema con flash dovrebbe essere stato risolto con gli aggiornamenti, per quanto riguarda libreoffice, è un problema già segnalato e poco chiaro. Il meccanismo utilizza le priorities di smart generate dallo script /etc/smart/distro.d/95-virtual-packages-select.py. Installando libreoffice senza la linuga si rompe un requirement (libreofficei18n) per cui mi sembra un bug di smart:

$ smart priority --show|grep libre

libreoffice-i18n-it            *                    10

libreoffice-i18n-it_IT         *                    15

[Silvan]

Ad autospec devi sempre passare il file .spec, non il file .rpm. Quindi nei comandi sopra sostituisci RPMS/i586/sorgente-versione.rpm con SPECS/sorgente.spec.

Io comunque preferisco lavorare nella cartella /usr/src/RPM/SPEC anzichè come fai tu in /usr/src/RPM. In questo caso basta dare (ad esempio):

autospec -u sorgente -a5

autospec -u sorgnete -a6

autospec -u sorgente -a5 --nosrpm --force

autospec -u sorgente -a10 --server 2

(ovvero autospec cerca automaticamente sorgente.spec se gli si passa solo sorgente).

[Silvan]

Bisogna fare una patch, guarda questa pagina del wiki.

Sì, guardando il tuo repository vedo che ci stai prendendo gusto 🙂

Per importare senza modifiche, quindi rapidamente, i tuoi contributi ti dò alcuni suggerimenti dopo aver guardato gli specfile dei pacchetti che hai fatto:

• la lista dei build requirement generata con autospec -a6 va copiata a mano nello specfile dove vedi queste righe:

  ## AUTOBUILDREQ-BEGIN
  
  ## note: run 'autospec -u -a6 geany' to get the list of build requirements.
  
  ## AUTOBUILDREQ-END

• gli specfile si devono chiamare nomepacchetto.spec, dove nomepacchetto è uguale al campo Name: in cima allo specfile. Di solito si chiamano come l’archivio sorgente (es. bochs-2.5.tar.gz -> bochs)
• bochs: questo pacchetto esiste già nel repository devel per cui non devi ricrearlo ma aggiornarlo con il comando:

  autospec -u bochs -a1,3,4 2.5

• il pacchetto geany contiene una libreria e dei file di sviluppo in /usr/include, questi file vanno messi in un sottopacchetto con estensione -devel. Al momento manca il template di autospec che sarebbe più giusto (geany, geany-devel) ma prova a partire creando uno specfile di tipo library (libgeany,libgeany-devel,geany-tools):

  autospec -s http://download.geany.org/geany-0.21.tar.bz2 -o geany.spec -t library -n libgeany

• vedendo l’ultimo (icewm) mi sembra che alcune cose scritte sopra le hai già capite da solo

[Silvan]

Gli errori La configurazione è in sola lettura. sono dovuti probabilmente al fatto che quando viene eseguita l’installazione dei pacchetti base è in corso la ricerca di aggiornamenti di kpackagekit.

Per flash al momento mi pare che non funzioni proprio il download del plugin flash (Linux,32bit,tar.gz) dal sito della Adobe (http://get.adobe.com/it/flashplayer/otherversions/).

[Silvan]

Hai ragione, bisogna aggiungere l’opzione --force in quanto l’SRPM è già esistente. Ho effettuato la correzione nel wiki. Il comando in sostanza è equivalente a

rpmbuild -bs specfile.spec

[Autore]

Articoli