Introduzione

Questa pagina fornisce istruzioni su come segnalare bugs relativi ad Unity, fornire le necessarie informazioni di debugging ed eseguirne il triage.

Segnalare bugs

Problemi tecnici

Utilizzare lo strumento standard di Ubuntu per la raccolta di informazioni dettagliate inerenti la vostra configurazione di sistema. Da linea di comando:

ubuntu-bug unity

Quando nel vostro sistema avviene un crash, apparirà una finestra di dialogo che vi inviterà a segnalare il problema. Raccoglierà inoltre, automaticamente, informazioni necessarie al debugging. Ma è possibile rendersi ulteriormente utili aggiungendo informazioni alla segnalazione del bug che ne faciliteranno il lavoro di analisi:

• Fornire il risultato del comado glxinfo. Esso contiene importanti informazioni grafiche utili nell'identificazione del problema (glxinfo è fornito dal pacchetto mesa-utils ed è automaticamente in esecuzione in Natty)
• fornire una completa descrizione della vostra GPU e quanta RAM video ha. Per esempio, il nome commerciale della vostra scheda video potrebbe essere Radeon HD 4650 oppure NVidia Geforce GTX 280. Per le schede video integrate Intel non è necessario fornire alcuna informazione.
• La risoluzione del monitor e le modalità dello schermo (singolo, doppio monitor, triplo monitor)

Se la finestra di dialogo non dovesse apparire consultare la sezione "avanzata" descritta più avanti.

Anche se il problema è attualmente in Compiz, è ragionevole riportare il bug contro Unity, provvederemo noi comunque a gestire le cose in modo da coinvolgere anche Compiz. Lavoriamo a stretto contatto con il progetto Compiz. Se invece siete certi che il problema risieda realmente in Compiz allora leggete la relativa sezione DebuggingCompiz.

Problemi di design ed usabilità

Siccome Unity è un'interfaccia utente, qualsiasi bug relativo alla funzionalità deve essere segnalato all' Unity design team. Per riportare un bug nell'interfaccia utente:

• Segnalare il bug contro il progetto Ayatana Design (NON contro il progetto Unity)

• Impostare l'importanza come ti sembra corretto

• Se il bug è urgente pingare JohnLea nel canale IRC #ayatana su freenode.

Consigli utili

• La precedenza è data ai bugs che si verificano in una installazione standard, quindi se è stata forzata l'installazione del cubo od altri plugin disabilitati bisogna prima riprodurre il bug in una installazione standard, ricordando che se alcuni plugin sono stati disabilitati c'è un valido motivo.
• È utile riferire i passi da compiere per riprodurre il bug, è altresì utile sapere se avviene solamente con alcuni temi o in tutti.

• Eseguendo nel terminale unity --reset avverrà il reset delle impostazioni di Unity, può anche essere utile creare un nuovo utente e verificare se il bug è ancora riproducibile.

Procedure di debugging avanzate

Crashers bloccati

Se apport non si avvia automaticamente proponendovi di segnalare il bug potete verificare se una traccia del crasher è stata raccolta nella directory /var/crash. Controllate l'esistenza di un file il cui nome contenga 'compiz'.

ls -altr /var/crash per listarli in ordine cronologico.

Per segnalare un bug utilizzando un crashfile:

• Rimanere nella attuale sessione di X.

• Aggiungere un gestore finestre da una TTY se necessario, es. CTRL-ALT-F1, autenticarsi, DISPLAY=:0 metacity --replace

• Dalla vostra sessione X eseguire: apport-bug -c /var/crash/<compiz crash file> e seguire la procedura nella pagina web che si aprirà. Attenzione, problemi di focalizzazione potrebbero impedire la comparsa della pagina, controllare quindi sullo spazio di lavoro l'apertura di una nuova finestra del browser web.

Ottenere uno stack trace

Se per una qualsiasi ragione apport non sia abilitato sul vostro sistema oppure avete un problema riproducibile, vi chiediamo di investigare spiegandovi come ottenere uno stack trace in modo da ispezionare le variabili interne. Assicurasi di avere installato i debugging symbols per i pacchetti compiz, nux ed unity.

Altrimenti, da tty1 (Ctrl + Alt + F1)

$ unity --advanced-debug
GNU gdb (GDB) 7.2-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>

...

(gdb) set logging file unity.log
(gdb) set logging on
(gdb) b _exit
Function "_exit" not defined.
Make breakpoint pending on future shared library load? (y or [n])
[Rispondere yes (y)]

(gdb) run

[ e quando avviene il crash di compiz/unity eseguire...]

(gdb) bt full

[ quindi CTRL-D o riavviare compiz per continuare il lavoro ]

(gdb) run

È anche possibile ottenere una traccia con valgrind eseguendo valgrind compiz --replace & in un terminale. Questo sistema è un po' più lento poichè esegue compiz sotto emulazione ma consente di ottenere maggiori informazioni di quelle avute tramite gdb.

In circostanze estreme potrebbe esservi richiesto di utilizzare un plugin gestore di crash scaricabile da git ed abilitarlo in ccsm.

Se si è afflitti da un freeze, ma è possibile utilizzare Ctrl-Alt-F1 per ottenere TTY1, è possibile usare gdb per connettere il processo compiz in esecuzione ed ottenere una traccia. Questa informazione è utilissima per il debugging del problema. Per connettere il processo in esecuzione, andare su TTY1 e seguire le seguenti istruzioni:

$ sudo gdb compiz `pgrep compiz`

(gdb) set logging file unity.log
(gdb) set logging on
(gdb) bt full

[ quindi CTRL-D o riavviare compiz per continuare il lavoro ]

(gdb) run

È quindi possibile ritornare ad Unity premendo Ctrl-Alt-F7.

Istruzioni per il triage

Procedure operative standard

La mancata osservanza di queste semplici linee guida potrebbe causare seri danni alle mani di lamalex e didrocks.

Mantenenre gli stati Upstream e Downstream sincronizzati

Il flusso di lavoro upstream e downstream per un'esperienza desktop è leggermente differente dagli altri progetti. Siccome non esiste alcuna distro che produce patch per i progetti di esperienze desktop, i bugs sono una frazione estremamente piccola di quelli segnalati. Per questa ragione il flusso di lavoro è il seguente:

1. Assicurarsi che il bug sia segnalato sia upstream che downstream.
2. Mantenere i due status sincronizzati.
   • Upstream è il pricipale. Sincronizzare lo status downstream come quello upstream.
   • Quì l'eccezione è per i pacchetti che vengono fixati downstream. Occasionalmente un fix potrà essere preso da un codice di esperienza desktop non ancora rilasciato e pacchettizzato per fixare un problema con status critical. In questo caso non si deve sincronizzare lo status upstream a quello downstream.

Marcare i componenti afflitti

Spesso, durante il triage di un bug, capita che il problema risieda in un componente base. Se ciò dovesse verificarsi è imperativo aprire la segnalazione anche contro il componente base. Se ad esempio un bug in nux fa crashare unity dovremo segnalare, nello stesso report, che il bug affligge sia unity che nux, syncronizzando i due status riferendoci a nux come principale. Per fare ciò utilizzare la funzione 'Also afflict project Similmente, se un bug è riportato contro un progetto componente, una segnalazione dovrà essere aperta anche contro il super progetto, nella medesima pagina. Per esempio, se un reporter apre una segnalazione contro nux, bamf, dee, etc. una segnalazione deve essere aperta anche contro unity in modo da avere traccia di tutti i componenti affetti in un unica pagina.

Bugs inerenti il design

Alcuni bugs non sono difetti tecnici, bensì comportamentali o visuali. Questi spesso richiedono valutazioni da parte del design team prima di essere corretti. Quando si è stabilito che un bug è un bug di design deve essere segnalato anche contro Ayatana design e lo status relativo ad unity deve essere impostato ad incomplete con l'aggiunta del tag needs design. Dopo che il team design si sarà pronunciato in merito lo status di unity potrà essere cambiato in Triaged dato che contiene tutte le informazioni necessarie agli sviluppatoriche dovranno fixare il bug. Vedi anche la risposta precompilata Bloccato in atttesa di decisione del team design.

Un esempio concreto di bug nel design: https://bugs.launchpad.net/unity/+bug/649560

Risposte precompilate

Tags dei bug

Queste tags consentono di isolare i bugs in sottogruppi, fornendo un facile e veloce sistema per lavorare su uno specifico problema.

Testare un fix

Talvolta uno sviluppatore potrebbe richiedere di testare una veloce patch chiedendovi: check the Daily builds PPA per valutare se il problema è stato risolto in una versione aggiornata di Unity. Siate cauti nel fare ciò dato che questi sono rilasci giornalieri che potrebbero danneggiare altre parti del sistema e sono da considerarsi instabili. Meglio testare su macchine virtuali.

Bugs noti

Bugs noti o funzioni mancanti sono tracciati in Launchpad ed assegnati a milestones per indicare quando è pianificato il loro fixing o rilascio.

• Milestones di Unity: https://bugs.launchpad.net/unity/+milestones

  • https://launchpad.net/unity/+milestone/3.4 - milestones di ubuntu

    • https://launchpad.net/unity/+milestone/3.4.4 - milestones settimanali

    • https://launchpad.net/unity/+milestone/3.4.4

  • https://launchpad.net/unity/+milestone/3.6

  • https://launchpad.net/unity/+milestone/3.8

Documento originale

CategoryBugSquad CategoryDebugging