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:
Riportare 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:To manually file a bug report using a crash file:
- 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 spigandovi come ottenere uno stack trece 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 è una utilissima informazione 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 esperieze desktop, i bugs sono una frazione estremamente piccola di quelli segnalati. Per questa ragione il flusso di lavoro è il seguente:
- Make sure the bug has both an upstream and downstream task.
- Keep statuses in sync.
- Upstream is the master. Sync downstream statuses to upstream.
- The exception here is for downstream packages that are fix released. Occasionally a fix will be cherry-picked from unreleased DX code, and released in a package to fix a critical issue. In this case do not sync the downstream status to the upstream.
Marking affected components
During triaging it is often the case that a bug reported will actually be a bug in a base component. When this occurs it is imperative to add a task on that component. For example, if a bug in nux is crashing unity, a task should be added against nux, and statuses should be sync'd with nux as the master.
Similarly, if a bug is reported against a component project a task should be added against the super project. For example if a reporter reports a bug in nux, bamf, dee, etc. a task should be filed against unity so that we can keep track of all of the components in one place.
Design Bugs
Some bugs are not technical defects, but behavioral, or visual ones. These often require input from the design team before they can be fixed. When a bug is determined to be a design bug, it should have an Ayatana design task added to it, and its Unity status should be set to incomplete with the tag needs-design. After a design decision has been reached the Unity status should be set to triaged as there is then enough information for the bug to be fixed. See also the Blocked waiting for design decision canned response.
An example (real world) design bug: https://bugs.launchpad.net/unity/+bug/649560
Canned Responses
Situation |
Response |
Note |
Patch needs author to sign Canonical Contributer agreement |
Looks good but before we merge it we need you to sign the Canonical contributer agreement. It's a quick, but necessary step to getting your code into the tree. Luckily you only need to sign it once and it will apply to all other Canonical project contributions you may make in the future. http://www.canonical.com/contributors Make sure to CC David Barth when you send it in. |
|
Blocked waiting for design decision |
This bug is awaiting design feedback before progress can be made. Confirming that there is a question to be answered. Will be marked triaged when design gives a suitable direction forward. |
Mark status as incomplete, and tag needs-design until design gives feedback. |
Bug reported from clutter based Unity |
This bug was reported against an old version of Unity. The new version of Unity is almost an entire rewrite based on very different technologies. Could you please check if this issue is present in the current version, and if it is reopen the bug to a NEW status. |
Set the bug to WONTFIX, and let the user reopen it |
Bugs that don't appear to be Unity related at all |
The issue you're describing doesn't sound related to Unity. Could you log into a classic gnome session and see if this issue persists? |
|
Crashers for which you'd like the user to get a stack trace |
Could you please follow the instructions on https://wiki.ubuntu.com/Unity/FilingBugs#Getting%20a%20stack%20trace and attach unity.log to this bug report? |
|
Bug Tags
These tags allow isolation of bugs into smaller groups, providing an easier and faster way to work on specific issues.
Tag |
Use case |
Compiz bugs which are affecting Unity |
|
Bugs reported by people who are running Unity |
|
Smaller bugs that would be ideal for new contributors. |
|
A bug that needs UI design done first. |
|
... |
... |
Testing a fix
Sometimes a developer might ask you to test a quick patch he came up with: check the Daily builds PPA to see if an updated version of Unity fixes the bugs you are experiencing. Be careful though, as those are daily builds that may break other things, and are to be considered unstable.
Known bugs
Known bugs, or missing features, are tracked in Launchpad and assigned to milestones to indicate when it is planned to be fixed and/or released.
Unity milestones: https://bugs.launchpad.net/unity/+milestones
Also see:
