Bugzilla/Hibabejelentés útmutatója
Ez a cikk elmagyarázza, hogy miként jelentheti be a hibákat a Gentoo Bugzilla használatával, amely enyhén testre szabható azért, hogy az egyes Gentoo projektterületekhez specifikus részleteket gyűjthessen.
Tekintse meg a Bugzilla/Guide leírást, amely elmagyarázza a Gentoo hibajelentésnek a javasolt módszerét.
Legjobb gyakorlatok
- A hibajelentés beküldése előtt olvassa el újra a beküldendő szöveget. A szöveg utólag nem szerkeszthető. A hibajelentésbe beírt szövegeket általában azonnal e-mail segítségével továbbküldik sok embernek. Írjon pontos és tiszta nyelven, és kerülje a köznyelvi beszédet. Tipp: Képzelje el Ön, hogy az életben csak egyetlen lehetősége van megírni ezt a nagyon fontos hibajelentést. Legyen tisztában azzal, hogy a címzett valószínűleg tud angolul olvasni, de neki nem ez az anyanyelve.
- Keressen olyan hibajelentéseket amelyek már mások beküldtek ugyanazzal a hibával, még mielőtt Ön is beküldené a saját hibajelentését.
- Maradjon a témánál. - A technikai hibajelentésekhez hibajegyet szoktak használnak. Kérjük, ne használja a chat felületeket azért, hogy a hibát bejelentse. A vitákat a támogatási csatornákon (fórumok, IRC vagy levelezőlisták) szokták lefolytatni, de azok önmagukban nem a közvetlen hibabejelentésre valók.
- Egyszer erősítse csak meg a probléma létezését. - Nem segít a probléma megoldásában, az ha Ön, és egy másik személy is bejelenti ugyan azt a problémát. De ha az Ön rendszere és a másik személy rendszere nyilvánvalóan különbözik, és ezt a különbséget hasznos lenne tudni (az Ön véleménye szerint a hibafelderítők számára), akkor nyugodt szívvel adja hozzá ezt az Ön információját. Kétszer viszont ugyan azt a problémát abszolút felesleges lenne bejelenteni.
- Témakörönként csak egy hibajegyet nyisson meg - Általában ez a módszer csak egyetlen csomagot szokott érinteni, és egy hibát ír le hibajegyenként. Ha az Ön problémáját egyetlen hibajegy alatti megbeszélés se nem tárgyalja, akkor keressen egy, az Ön problémájához kapcsolódó/hasonló témakört, esetleg hozzon létre új témakört. Ne térítse el a konkrét hibatárgyalásokat.
- Nincs szó a TRACKER hibáiról. - Ezek a hibák metahibák. Ha hasznos információkat szeretne hozzáadni, adja hozzá őket egy kapcsolódó alhibához, vagy hozzon létre új hibajegyet.
- Opcionális: A Gentoo tanácsadók kereskedelmi támogatást is nyújtanak a hibákhoz és az ebuild-ekhez.
- Csatolja a naplófájlokat a hibajegyhez, ha a hibajegy futási vagy telepítési problémákról szól.
Programcsomagok/ebuild
Mindig hozzá kell adnia a rendszer konfigurációjával kapcsolatos információkat a hibabejelentéshez. Ehhez hozzon létre egy új mellékletet, és illessze be a következők tartalmát:
user $emerge --info > /tmp/emerge--info.txtProgramcsomag-létrehozás közben bekövetkező hiba (emerge közben fellépő hiba) bejelentése
- First write the exact version of the package in the title of the bug report e.g. sys-apps/package-2.3-r4
- Add a short description to the title.
- Attach the logs to the bug ticket
Egy futásidőben bekövetkező hiba jelentése
Fájlok és érdekes információk fontossági sorrend szerint rendezve:
- A csomag pontos verziója a hibajelentés címében pl. A system-apps/csomagneve-2.3-r4 hibával omlik össze: Nem lehet folytatni...
- A probléma leírása azért, hogy mások is ugyan azt a hibát reprodukálni tudják:
- Hogyan fut a program? (Konzolon? Parancssorban? Szolgáltatásonként? Milyen futási szinten fut?, stb.) .
- Van-e valamilyen hibakimenet.
- Mitől omlik össze a program? Mitől viselkedik rosszul? Mitől nem indul el?
- Talált-e Ön rá hibamegoldást?
- Pontosan melyik volt az utolsó, még jól működő programcsomag verziója? (Amennyiben létezett ilyen).
- Mi változott, hogy most nem működik?
- Csatolja a naplófájlokat a hibajegyhez
Verzió ütközés jelentése. Egy újabb upstream kiadás egy ideje elérhető
- Keressen a Bugzilla hibabejelentő oldalán, még mielőtt Ön is jelentené az verzióütközés hibát – Van már hibajelentés kinyitva? A helyi Portage fa szinkronizálva lett az utóbbi időben? A Portage csomagkezelőben van már?
- Kerülje a nulladik napi kéréseket. (Várjon legalább 48 órát a kiadás bejelentése után).
- Valóban kiadták az upstream források, vagy csupán a forrásfában e-képpen van csak megjelölve? Ugyanis egyes projektek megjelenését jóval a hivatalos megjelenési dátum előtt jelzik a fában.
- Mindenképpen említse meg, hogy lefordul-e és jól fut-e az Ön architektúráján. Minden egyéb hasznos információt szívesen fogadunk.
- Adjon hozzá egy hivatkozást ami az upstream webhelyére mutat.
- Adjon meg egy hivatkozást vagy egy listát a javított hibákról vagy új szolgáltatásokról. (Sokszor változási napló-nak (changelog-nak) nevezik).
- Írjon egy összefoglalót app-editors/vim-12.3.5 version bump űrlapra.
Opcionális
- Működik-e egy egyszerű másolat, vagy az ebuild-en kell változtatni? (Megváltozott függőségek, elavult javítási fájlok).
- tesztelje le az ebuild-et egy helyi átfedésen, még mielőtt beküldi a mellékletek.
- Hozzon létre Ön hibajavító foltozásokat a javasolt ebuild szerkesztésekhez, a változtatások opcionális magyarázatával. (A fájl nevének meg kell egyeznie az új verziószámmal, nem pedig a régivel).
- Adjon meg további fájlokat (initd, unit fájlok) külön mellékletként (ha erre szükség van).
- Ne illesszen be fájlokat közvetlenül a megjegyzések közé. Mellékleteket használjon.
Új csomag kérése. Ebuild kérés
Ha Ön új build-et kér egy szoftverhez, amit a Portage csomagkezelőhöz kell hozzáadni, akkor meg kell Önnek találnia a csomagot, vagy karbantartónak kell lennie.
Ha már létezik hibajelentés a csomaghoz, akkor a csomagra vonatkozó információk naprakészen tartásával segítheti a munkát. Ha hozzáadunk egy -VERSION komponenst a csomag atomjához, akkor ez idővel frissülhet új kiadásokkal, miközben a hibajelentés karbantartás nélkül fog maradni, jelezve, hogy folyamatos az érdeklődés a Portage csomagkezelő fába integrálva.
Ha nincs hibajelentés a csomaghoz, akkor hibajelentést készíthet a Gentoo Linux projekt és az New package (új csomag) komponens alatt.
A hibajelentés Összefoglaló (Summary) részében fel kell sorolni egy (előzetes) csomag atom kategóriát/csomagot, esetleg -VERSION utótaggal, majd a csomag kanonikus rövid leírását kell megadni (a DESCRIPTION változó az ebuild-ben). Fontos, hogy egyértelmű legyen az új csomag neve: Ha az upstream különböző neveket használ ugyanarra a szoftverre, esetleg egy rövidítést és a teljes nevet is használja, akkor mindkettőt meg kell említeni az Összefoglaló-ban, hogy mások megtalálhassák a hibajelentést ugyanarról a szoftverről. Ha több ember (csoportok) követi nyomon a különböző hibajelentéseket gyakorlatilag ugyanarról az ebuild kérelemről, az megkettőzi az ebuild kutatás-fejlesztési erőfeszítéseit, és megosztja a közös érdeklődésű embereket.
Az URL mezőbe Önnek az upstream webhelyét kellene írnia (az ebuild HOMEPAGE változója). Meg kell adnia a funkciók listáját a hibajelentés Description részében. Ez könnyen átvehető közvetlenül az upstream webhelyről vagy egy kézikönyvből vagy más dokumentációból, és később felhasználható a metadata.xml longdescription címkéjéhez.
Ön csatolhat egy ebuild-et és a kapcsolódó fájlokat, amelyeknek közvetlenül a portage fába kell kerülniük a hibajelentéshez, vagy használhatja a Lásd még (See also) mezőt egy git pull request-hez.
Segíthet a csomag fejlesztésében, ha létrehoz egy helyi átfedést az ebuildekkel, metaadatokkal, javításokkal és egyéb segédfájlokkal. Sokan szívesen segítenek, ha technikai támogatásra van szüksége az ebuild fejlesztéséhez.
Stabilizálás kérése
A fejlesztők számára a devmanual részletesebb információkat tartalmaz a stabil kérésekről.
Egy hibajegy használható a stabilizációs kérelem elküldésére is.
Mindenki kérhet stabilizálást. A felhasználóknak nem kell aggódniuk a hibajegy minden mezőjének vagy részletének kitöltése miatt. A karbantartó (vagy meghatalmazott karbantartó) másolatot készít az architektúrákról.
Egy csomag stabilizálásának kéréséhez adjon meg küldjön be egy új hibabejelentést a Stabilization résznél, ügyelve a két speciális hibamező kitöltésére:
Package list– Soronként egy teljesen minősített csomag, amelyet opcionálisan követ a megcélozandó architektúrák szóközzel tagolt listája. Ha nincs megadva architektúra lista, akkor a hibajelentő rendszer az összesCC-ben lévő architektúrát fogja feltételezni. Korábban ezt a mezőtAtoms to stabilize-nek hívták, és teljesen minősített atomokat tartalmazott, ami szintén támogatott.Runtime testing required- Jelzi, ha további futásidejű tesztelést kell végezni a felépítésen és a sikeres teszteken túl. Ha ez undefined, akkor az architektúra tesztelőnek a legjobb belátása szerint kell lennie.
Példák:
| Összefoglaló | A foo-libs/libbar-1.2.3 stabilizációjának a kérelme. |
|---|---|
| CC | amd64 x86 |
| Szükséges a futásidőben történő letesztelés | Nem |
| Csomaglista | foo-libs/libbar-1.2.3 .(A régi szintaxis továbbra is támogatott: =foo-libs/libbar-1.2.3 ). |
| Magyarázat |
|
| Összefoglaló | Az app-foo/bar-1.2.3 és az app-foo/baz-4.5.6 stabilizációinak a kérelme. |
|---|---|
| CC | amd64 arm x86 |
| Szükséges a futásidőben történő letesztelés | Igen |
| Csomaglista | app-foo/bar-1.2.3 |
| app-foo/baz-4.5.6 amd64 x86 | |
| Magyarázat |
|
Kernel
Fájlok és érdekes információk a kernel hibajelentéseihez prioritás szerint rendezve:
- Melyik kernelt és melyik verziót használjuk? Milyen architektúrán? Például: gentoo-sources-3.4.2-r2 és x86_64 architektúrán.
- A kernel konfigurációs fájlját (/usr/src/linux/.config) csatolni kell a hibajelentéshez.
- A rendszerünkben lévő összes eszköznek a listája az lspci -k paranccsal kérhető le.
- A kernel inicializálása során naplófájlokat kell csatolni. (/var/log/dmesg vagy /var/log/messages).
Kérésre egy kernel git-bisect is elvégezhető a rossz javítások azonosítására.
Kiegészítő információk a hibajelentésekhez
| Információ | Amikor szükséges | Hogyan kell gyűjteni? |
|---|---|---|
| SRC_URI reachable? | download failed | GENTOO_MIRRORS="" ebuild foo-1.2.ebuild fetch
|
| OpenGL version | Games with OpenGL | glxinfo -B
|
| linked libraries | Dependency is missing | Add missing dependency, compile, check with lddtree |
Hibakövetők
A hibakövetők (Tracker-Bugs) virtuális hibák az azonos témájú hibák csoportosítására.
További olvasnivaló a témában
- Attach the logs to the bug ticket — explains how to attach log files to a bug ticket
- Bugzilla/Guide — covers the recommended method of forensically reporting specific details of bugs within Gentoo.
- Contributing to Gentoo — explains how users can contribute to the development of Gentoo
- Support — provide support for technical issues encountered when installing or using Gentoo Linux
- Troubleshooting — felhasználók számára egy sor technikát és eszközt biztosítson a Gentoo beállításaikkal kapcsolatos hibaelhárításhoz és javításhoz.