ciao a tutti, volevo segnalare alcuni problemi che ho riscontrato nell' utilizzo dei pacchetti mib.
e dai tempi della 2008.0 che uso pacchetti mib, sono sempre stato soddisfatto,ottimi veramente!, però, dalla 2009.0 ho visto tali pacchetti, specialmente quelli vitali, e quelli del gruppo kde-apps. cosa che si e aggravata molto di piu con la 2009.1
le mie macchine in linea generale sono queste:
laptop: HP Pavilion dv6276ea,Intel Core 2 Duo T5500,1,66 GHz, 2 MB L2, 2048 MB (2 x 1024 MB),geforce go 7400.
Desktop: intel pentium dualcore e2180,2.0ghz default lieve oc 2,2ghz fsb 218 vs 200,1MB L2,2gb ddr2 800mhz,asus p5b-MX/WIFI-AP(intel GMA x3100)
ultimi prboblemi che ho avuto e stato con il ernel 2.6.29.4 in cui a causa di dipendenze e pacchetti mancanti non era possibile installarlo.
in definitiva il problema che affliggei pacchetti mib sono le dipendenze, per il resto ok
un mio consiglio e quello di controllare bene le dipendenze, e fare del testing su varie macchine. prima di includerlo nei repo mib ufficiali, esempio tramite un repository a parte di testing per chi vuole collaborare.
Affidabilità pacchetti mib (critica costruttiva)
Re: affidabilità pacchetti mib (critica costuttiva)
Ho installato il kernel 2.6.29.4 mib
su una ventina di diverse installazioni, ed in nessuna ho mai riscontrato alcun problema,
di nessun genere, e dopo l'installazione sinceramente il PC va leggermente piu' spedito!
I Logs portano qualche migliaio di scaricamenti internazionali, e moltissimi usano quel
kernel con soddisfazione, senza avere avuto problemi, quindi non trattandosi di alieni...
Non si puo' far passare dei problemi personali per dei problemi generali.
Uniche cose da conoscere e' che se si vogliono usare drivers proprietari (Ati/Nvidia),
occorre installare anche il
kernel-desktop-devel-latest
oppure un
kernel-source-latest
e assicurarsi di avere già installati i corrispondenti in dkms (dkms-nividia..., dkms-fglrx...),
ma questo e' qualcosa che riguarda il sistema di driver di Mandriva, e quindi trovo che sia
un errore in mandriva non aver installato almeno un kernel-desktop-devel-latest
in maniera che poi gli altri si sarebbero così richiamati ed aggiornati da sè:
In presenza di driver video non proprietari (Intel, S3, SIS, Vesa, ecc.) il file non occorre
Quindi non bisogna confondere gli errori e/o dimenticanze di Mandriva con il MIB,
e la stessa cosa vale per il programma di gestione pacchetti grafico che spesso perde
le dipendenze che sono gia' presenti sui repository, addirittura in quelli di main/release
e non solo, adesso non riesce più neanche a riconoscere i pacchetti dal suffisso, così
non è più possibile cercando la parolina mib, vedere quali programmi sono disponibili,
e sembrerebbe che non ve ne sia neanche uno... e anche questo è colpa del MIB?
Quindi non bisogna confondere gli errori e/o dimenticanze di Mandriva con il MIB
Noi consigliamo sempre di utilizzare il metodo di aggiornamento da Konsole di root, con
il comando urpmi
Quando qualcuno ha avuto il problema di cui non era a conoscenza ha scritto sul Forum
e con le nostre risposte ha risolto ed adesso ha, cosa soprattutto migliore, capito e così
non avrà lo stesso problema la prossima volta che si imbatterà nella stessa cosa.
Per gli altri programmi, effettuiamo dei test, attraverso tutti i membri del MIB Team, e che
se dicono che tutto e' OK, significa se su un PC ben configurato, il programma si installa
e funziona correttamente,
niente possiamo invece fare se un PC non e' ben configurato, non siamo in grado di simulare
queste situazioni
MIB si appoggia sempre sui repo uficiali, che poi integra e arricchisce
con ulteriori nuovi titoli e/o titoli esistenti ma in versioni più aggiornate
La configurazione dei repo ideale da noi consigliata, quella dei test, è:
Configurazione repo Mandriva (in totale attivati 9)
main -----> attivati - /release - /updates - /backports
contrib --> attivati - /release - /updates - /backports
non-free > attivati - /release - /updates - /backports
Configurazione repo PLF (in totale attivati 4)
plf-free -----> attivati - /release - /backports
plf-nonfree > attivati - /release - /backports
I repo MIB (in totale attivati 2 (x mdv2009.1))
come suggerito direttamente nelle nostra pagina repository
Ogni pacchetto ha, tra realizzazione, building e testing finale una media di 8 ore di lavorazione,
viene effettuato sacrificando il tempo libero di ognuno dei MIB Team, e viene fatto con passione,
dal momento che i primi ad utilizzarlo sono gli stessi membri del MIB Team cui funziona tutto:
E nessuno di essi, ti assicuro, è un alieno...
su una ventina di diverse installazioni, ed in nessuna ho mai riscontrato alcun problema,
di nessun genere, e dopo l'installazione sinceramente il PC va leggermente piu' spedito!
I Logs portano qualche migliaio di scaricamenti internazionali, e moltissimi usano quel
kernel con soddisfazione, senza avere avuto problemi, quindi non trattandosi di alieni...
Non si puo' far passare dei problemi personali per dei problemi generali.
Uniche cose da conoscere e' che se si vogliono usare drivers proprietari (Ati/Nvidia),
occorre installare anche il
kernel-desktop-devel-latest
oppure un
kernel-source-latest
e assicurarsi di avere già installati i corrispondenti in dkms (dkms-nividia..., dkms-fglrx...),
ma questo e' qualcosa che riguarda il sistema di driver di Mandriva, e quindi trovo che sia
un errore in mandriva non aver installato almeno un kernel-desktop-devel-latest
in maniera che poi gli altri si sarebbero così richiamati ed aggiornati da sè:
In presenza di driver video non proprietari (Intel, S3, SIS, Vesa, ecc.) il file non occorre
Quindi non bisogna confondere gli errori e/o dimenticanze di Mandriva con il MIB,
e la stessa cosa vale per il programma di gestione pacchetti grafico che spesso perde
le dipendenze che sono gia' presenti sui repository, addirittura in quelli di main/release
e non solo, adesso non riesce più neanche a riconoscere i pacchetti dal suffisso, così
non è più possibile cercando la parolina mib, vedere quali programmi sono disponibili,
e sembrerebbe che non ve ne sia neanche uno... e anche questo è colpa del MIB?
Quindi non bisogna confondere gli errori e/o dimenticanze di Mandriva con il MIB
Noi consigliamo sempre di utilizzare il metodo di aggiornamento da Konsole di root, con
il comando urpmi
Code: Select all
urpmi --auto-update --auto-select
e con le nostre risposte ha risolto ed adesso ha, cosa soprattutto migliore, capito e così
non avrà lo stesso problema la prossima volta che si imbatterà nella stessa cosa.
Per gli altri programmi, effettuiamo dei test, attraverso tutti i membri del MIB Team, e che
se dicono che tutto e' OK, significa se su un PC ben configurato, il programma si installa
e funziona correttamente,
niente possiamo invece fare se un PC non e' ben configurato, non siamo in grado di simulare
queste situazioni
MIB si appoggia sempre sui repo uficiali, che poi integra e arricchisce
con ulteriori nuovi titoli e/o titoli esistenti ma in versioni più aggiornate
La configurazione dei repo ideale da noi consigliata, quella dei test, è:
Configurazione repo Mandriva (in totale attivati 9)
main -----> attivati - /release - /updates - /backports
contrib --> attivati - /release - /updates - /backports
non-free > attivati - /release - /updates - /backports
Configurazione repo PLF (in totale attivati 4)
plf-free -----> attivati - /release - /backports
plf-nonfree > attivati - /release - /backports
I repo MIB (in totale attivati 2 (x mdv2009.1))
come suggerito direttamente nelle nostra pagina repository
Ogni pacchetto ha, tra realizzazione, building e testing finale una media di 8 ore di lavorazione,
viene effettuato sacrificando il tempo libero di ognuno dei MIB Team, e viene fatto con passione,
dal momento che i primi ad utilizzarlo sono gli stessi membri del MIB Team cui funziona tutto:
E nessuno di essi, ti assicuro, è un alieno...
.
--- Professional experience ---
Kernel designer, engineer, maintainer and tester for ROSA Desktop and OpenMandriva Lx O.S.
--- currently I'm playing with ---
LTS Kernels > Linux 4.1.12-nrjQL <<< Linux 3.18.17-nrjQL <<< Linux 3.14.46-nrjQL
EOL Kernels > Linux 3.19.8-nrjQL <<< Linux 3.17.8-nrjQL <<< Linux 3.15.10-nrjQL
--- Professional experience ---
Kernel designer, engineer, maintainer and tester for ROSA Desktop and OpenMandriva Lx O.S.
--- currently I'm playing with ---
LTS Kernels > Linux 4.1.12-nrjQL <<< Linux 3.18.17-nrjQL <<< Linux 3.14.46-nrjQL
EOL Kernels > Linux 3.19.8-nrjQL <<< Linux 3.17.8-nrjQL <<< Linux 3.15.10-nrjQL
- rugyada
- Amministratore
- Posts: 1562
- Joined: 14 July 2008, 22:58
- ROSA: ROSA.Fresh R8 64bit
- OpenMandriva: OMLx 4.2
- Kernel: kernel-release
- Desktop: KDE tutta la vita
- country: Italy
Re: Affidabilità pacchetti mib (critica costruttiva)
ciao,
In caso contrario viene aggiunta una nota di avvertimento nella scheda, ben visibile, solitamente in rosso.
http://mib.pianetalinux.org/2008.1/i586 ... e_testing/
http://mib.pianetalinux.org/2008.1/i686/testing/
http://mib.pianetalinux.org/2008.1/i686 ... e_testing/
http://mib.pianetalinux.org/2008.1/x86_ ... e_testing/
http://mib.pianetalinux.org/2008.1/x86_64/testing/
http://mib.pianetalinux.org/2009.0/x86_64/testing/
http://mib.pianetalinux.org/2009.0/i586/testing/
http://mib.pianetalinux.org/2009.0/i686/testing/
http://mib.pianetalinux.org/2009.1/x86_64/MIB-testing/
http://mib.pianetalinux.org/2009.1/i686 ... a-testing/
http://mib.pianetalinux.org/2009.1/i686/MIB-testing/
...e ho omesso quelli che al momento non contengono pacchetti.
Tutti i pacchetti vengono testati dai membri del MIB, come già ha detto nicco e come già è stato spiegato molte volte.ilario wrote:...un mio consiglio e quello di controllare bene le dipendenze, e fare del testing su varie macchine ...
In caso contrario viene aggiunta una nota di avvertimento nella scheda, ben visibile, solitamente in rosso.
http://mib.pianetalinux.org/2008.1/i586/testing/ilario wrote:... prima di includerlo nei repo mib ufficiali, esempio tramite un repository a parte di testing per chi vuole collaborare.
http://mib.pianetalinux.org/2008.1/i586 ... e_testing/
http://mib.pianetalinux.org/2008.1/i686/testing/
http://mib.pianetalinux.org/2008.1/i686 ... e_testing/
http://mib.pianetalinux.org/2008.1/x86_ ... e_testing/
http://mib.pianetalinux.org/2008.1/x86_64/testing/
http://mib.pianetalinux.org/2009.0/x86_64/testing/
http://mib.pianetalinux.org/2009.0/i586/testing/
http://mib.pianetalinux.org/2009.0/i686/testing/
http://mib.pianetalinux.org/2009.1/x86_64/MIB-testing/
http://mib.pianetalinux.org/2009.1/i686 ... a-testing/
http://mib.pianetalinux.org/2009.1/i686/MIB-testing/
...e ho omesso quelli che al momento non contengono pacchetti.
ciauu ciauu, ruru
MIB... e le stelle stanno a guardare.
«E' bello avere delle certezze, tipo la terra gira, il sole è caldo, se ti prendi con quelli del MIB vieni fanculizzato. Cose semplici, in fondo» (M.C.)
- othoth-tux
- Collaboratore
- Posts: 338
- Joined: 4 February 2008, 19:55
- OpenMandriva: OpenSuse 12.2
- Kernel: 3.4.x
- Desktop: Gnome3
- country: Italy
Re: Affidabilità pacchetti mib (critica costruttiva)
ciao ilario,
oltre tutto quello già detto da nicco e rugyada, vorrei aggiungere l'importanza di dare il proprio feedback quando si aggiorna o si installa un nuovo programma e si riscontrano problemi, così si cerca di risolverli.
anche un semplice commento come "2009.1 32bit tutto ok" è utile, specialmente agli utenti che magari vogliono sapere se è tutto a posto e il pacchetto funziona.
oltre tutto quello già detto da nicco e rugyada, vorrei aggiungere l'importanza di dare il proprio feedback quando si aggiorna o si installa un nuovo programma e si riscontrano problemi, così si cerca di risolverli.
anche un semplice commento come "2009.1 32bit tutto ok" è utile, specialmente agli utenti che magari vogliono sapere se è tutto a posto e il pacchetto funziona.
- ilario
- Utente junior
- Posts: 23
- Joined: 1 May 2009, 8:19
- OpenMandriva: 2010.2
- Kernel: 2.6.3x
- Desktop: kde4
Re: Affidabilità pacchetti mib (critica costruttiva)
ok, non sapevo dei repo testing, cercherò di seguire i vostri consigli. spero che in futuro non mi si presentino più problemi nei repo ufficiali mib
un cordiale saluto, ilario
un cordiale saluto, ilario
Re: Affidabilità pacchetti mib (critica costruttiva)
Affidabilità dell'installazione dei pacchetti mib, dipende quasi esclusivamente dal gestore grafico dei pacchetti mandriva presente nel Centro di Controllo. Funzionando esso male, e andando sempre di male in peggio, il MIB ha consigliato sempre, in sostituzione, l'uso del comando urpmi da Konsole
Dalla 2008.0 in poi,
i gestori di pacchetti hanno subito un po' po' di modifiche e i bachi e le incongruenze sono aumentati a dismisura!
Cito alcune cose, che adesso non vanno nel'installer grafico, ma che prima funzionavano anche bene:
1>Incapacità di vedere bene a volte, così dice assenti alcune dipendenze invece presenti sui repo
2>Incapacità di visualizzare i pacchetti per sorgente, oppure per particelle (mib, mud, mcnl, ecc.)
3>Incapacità di rispettare la skip.list
se editiamo il file
/etc/urpmi/skip.list
aggiungiamo due nomi di file che non vogliamo vengano aggiornati, per esempio:
kernel
nvidia
a>se aggiornando usiamo l'installer grafico, la nostra skip list verrà ignorata, e i pacchetti kernel e nvidia verrano contrariamente e quanto Noi specificato, scaricati ed installati
b>se aggiornando usiamo urpmi, i pacchetti kernel e nvidia saranno ignorati, come da noi desiderato
4>Incapacità di deselezionare con effetto reale: in modalità aggiornamento, se deselezioniamo alcuni pacchetti che non vogliamo aggiornare e sostituire, i pacchetti sembrano deselezionati, ma poi l'installer grafico ce li installa lo stesso, fregandosene del nostro volere!!!
Ecco quindi delle gran belle incongruenze, che fanno sì che il comportamento del gestore pacchetti
grafico sia discordante dal comando urpmi, che e' quello che fortunatamente funziona ancora benino
Dalla 2008.0 in poi,
i gestori di pacchetti hanno subito un po' po' di modifiche e i bachi e le incongruenze sono aumentati a dismisura!
Cito alcune cose, che adesso non vanno nel'installer grafico, ma che prima funzionavano anche bene:
1>Incapacità di vedere bene a volte, così dice assenti alcune dipendenze invece presenti sui repo
2>Incapacità di visualizzare i pacchetti per sorgente, oppure per particelle (mib, mud, mcnl, ecc.)
3>Incapacità di rispettare la skip.list
se editiamo il file
/etc/urpmi/skip.list
aggiungiamo due nomi di file che non vogliamo vengano aggiornati, per esempio:
kernel
nvidia
a>se aggiornando usiamo l'installer grafico, la nostra skip list verrà ignorata, e i pacchetti kernel e nvidia verrano contrariamente e quanto Noi specificato, scaricati ed installati
b>se aggiornando usiamo urpmi, i pacchetti kernel e nvidia saranno ignorati, come da noi desiderato
4>Incapacità di deselezionare con effetto reale: in modalità aggiornamento, se deselezioniamo alcuni pacchetti che non vogliamo aggiornare e sostituire, i pacchetti sembrano deselezionati, ma poi l'installer grafico ce li installa lo stesso, fregandosene del nostro volere!!!
Ecco quindi delle gran belle incongruenze, che fanno sì che il comportamento del gestore pacchetti
grafico sia discordante dal comando urpmi, che e' quello che fortunatamente funziona ancora benino
.
--- Professional experience ---
Kernel designer, engineer, maintainer and tester for ROSA Desktop and OpenMandriva Lx O.S.
--- currently I'm playing with ---
LTS Kernels > Linux 4.1.12-nrjQL <<< Linux 3.18.17-nrjQL <<< Linux 3.14.46-nrjQL
EOL Kernels > Linux 3.19.8-nrjQL <<< Linux 3.17.8-nrjQL <<< Linux 3.15.10-nrjQL
--- Professional experience ---
Kernel designer, engineer, maintainer and tester for ROSA Desktop and OpenMandriva Lx O.S.
--- currently I'm playing with ---
LTS Kernels > Linux 4.1.12-nrjQL <<< Linux 3.18.17-nrjQL <<< Linux 3.14.46-nrjQL
EOL Kernels > Linux 3.19.8-nrjQL <<< Linux 3.17.8-nrjQL <<< Linux 3.15.10-nrjQL
- SymbianFlo
- Utente sostenitore
- Posts: 1493
- Joined: 7 December 2007, 20:07
- OpenMandriva: 2010.1 x86_64
- Kernel: 2.6.33.5-nrj-69mib
- Desktop: kde4.5.rc1
- Location: Pordenone
- Contact:
Re: Affidabilità pacchetti mib (critica costruttiva)
aggiungo
-impossibilità di aggiungere repository in modalità grafica ( ad eccezione mdv e plf )
-impossibilità di abilitare/disabilitare alcune voci ( almeno che non si usi drakrpm-edit-media --expert sempre dalla shell )
-msec non rispetta i vari settaggi di tempo e parte a vanvera
-filtri per la famiglia non salva la lista sicura dopo il riavvio
quindi cercando un po nel MCC si scopre che quello che abbiamo suggerito noi come MIB , ovvero di essere riscritto
, e molto imperativo nonché importante .
Quindi invece di facilitare la distro mandriva costringe gli utenti a usare la shell , che non mi dispiace per niente ...ghghgh
meno gente coi neuroni piallati
-impossibilità di aggiungere repository in modalità grafica ( ad eccezione mdv e plf )
-impossibilità di abilitare/disabilitare alcune voci ( almeno che non si usi drakrpm-edit-media --expert sempre dalla shell )
-msec non rispetta i vari settaggi di tempo e parte a vanvera
-filtri per la famiglia non salva la lista sicura dopo il riavvio
quindi cercando un po nel MCC si scopre che quello che abbiamo suggerito noi come MIB , ovvero di essere riscritto
, e molto imperativo nonché importante .
Quindi invece di facilitare la distro mandriva costringe gli utenti a usare la shell , che non mi dispiace per niente ...ghghgh
meno gente coi neuroni piallati
ciao ciao SymbianFlo
Linus Torvalds only has to enter a room, and every Windows computer in it segfaults instantly.
http://video.linuxfoundation.org/video/1057
Linus Torvalds only has to enter a room, and every Windows computer in it segfaults instantly.
http://video.linuxfoundation.org/video/1057