Panduan Pembuatan Laporan Bug Gentoo

1.  Pendahuluan

Kata Pengantar

Salah satu faktor yang menghambat perbaikan bug adalah cara bug tersebut dilaporkan. Dengan panduan ini, kami berharap dapat meningkatkan komunikasi antara para pengembang dan pengguna dalam mengatasi bug. Perbaikan bug sangatlah penting untuk menjamin kualitas setiap proyek dan kami harap panduan ini dapat membantu meningkatkan kualitas proyek.

Bug!!!!

Anda sedang meng-emerge sebuah paket atau bekerja dengan sebuah program dan tiba-tiba terjadi hal yang tidak diinginkan -- anda menemukan bug. Bug dapat ditemukan dalam berbagai bentuk seperti kegagalan emerge atau segfault. Apapun sebabnya, bug tersebut harus segera diperbaiki. Berikut ini adalah contoh beberapa bug.

$ ./bad_code `perl -e 'print Ax100'`
Segmentation fault

/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include/g++-v3/backward/backward_warning.h:32:2:
warning: #warning This file includes at least one deprecated or antiquated
header. Please consider using one of the 32 headers found in section 17.4.1.2 of
the C++ standard. Examples include substituting the <X> header for the <X.h>
header for C++ includes, or <sstream> instead of the deprecated header
<strstream.h>. To disable this warning use -Wno-deprecated.
In file included from main.cc:40:
menudef.h:55: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:62: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:70: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:78: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
main.cc: In member function `void OXMain::DoOpen()':
main.cc:323: warning: unused variable `FILE*fp'
main.cc: In member function `void OXMain::DoSave(char*)':
main.cc:337: warning: unused variable `FILE*fp'
make[1]: *** [main.o] Error 1
make[1]: Leaving directory
`/var/tmp/portage/xclass-0.7.4/work/xclass-0.7.4/example-app'
make: *** [shared] Error 2

!!! ERROR: x11-libs/xclass-0.7.4 failed.
!!! Function src_compile, Line 29, Exitcode 2
!!! 'emake shared' failed

Error-error ini bisa jadi sangat memusingkan. Namun, ketika anda menemukannya, apa yang harus anda lakukan? Seksi-seksi berikut akan menjelaskan beberapa alat penting yang berguna untuk menangani error ketika program dijalankan (runtime error). Mari kita lihat alat pertama untuk men-debug error run time -- gdb.

2.  Debug dengan GDB

Pendahuluan

GDB, atau (G)NU (D)e(B)ugger, adalah sebuah program yang digunakan untuk menemukan error run time yang biasanya terkait dengan korupsi memori. Pertama, mari kita lihat apa saja yang diperlukan untuk melakukan debug. Satu hal penting yang harus anda lakukan untuk men-debug sebuah program adalah meng-emerge program tersebut dengan mengaktifkan FEATURES="nostrip". Ini akan mencegah penghapusan simbol-simbol debug. Mengapa simbol-simbol ini dihapus secara default? Alasannya sama dengan alasan mengapa halaman manual di-gzip -- untuk menghemat tempat. Berikut ini adalah contoh besarnya ukuran sebuah program dengan dan tanpa simbol debug.

(Simbol debug dihapus)
-rwxr-xr-x  1 chris users 3140  6/28 13:11 bad_code
(Simbol debug tidak dihapus)
-rwxr-xr-x  1 chris users 6374  6/28 13:10 bad_code

Sebagai keterangan, bad_code adalah program yang nanti akan kita debug dengan gdb. Seperti yang bisa anda lihat, program tanpa simbol-simbol debug berukuran 3140 byte, sedangkan dengan simbol-simbol debug, ukurannya menjadi 6374 byte. Hampir dua kali lipat! Dua hal lagi yang perlu dilakukan sebelum memulai debug. Yang pertama adalah menambahkan ggdb3 ke variabel CFLAGS dan CXXFLAGS. Flag ini menambahkan informasi debug yang lebih banyak daripada informasi yang biasa diberikan. Kita akan membahasnya nanti. Berikut ini adalah contoh isi /etc/make.conf setelah flag baru ditambahkan.

setelah flag baru ditambahkan
CFLAGS="-O1 -pipe -g -ggdb"
CXXFLAGS="${CFLAGS}"

Terakhir, anda juga perlu menambahkan debug ke flag USE paket dengan menggunakan file package.use.

# echo "category/package debug" >> /etc/portage/package.use

Selanjutnya emerge ulang paket tersebut agar perubahan diterapkan.

# FEATURES="nostrip" emerge package

Setelah simbol-simbol diikutsertakan pada program, kita dapat melanjutkan dengan men-debug program.

Menjalankan program dengan GDB

Katakanlah kita memiliki sebuah program dengan nama "bad_code". Beberapa orang mengatakan program ini crash dan mereka memberikan contoh. Pertama mari kita coba:

$ ./bad_code `perl -e 'print Ax100'`
Segmentation fault

Kelihatannya mereka memang benar. Karena program ini benar-benar rusak, kita memiliki bug. Sekarang, saatnya untuk menggunakan gdb untuk mengatasi masalah ini. Pertama kita jalankan gdb dengan opsi --args, lalu kita berikan program tadi dengan argumen seperti berikut:

$ gdb --args ./bad_code `perl -e 'print Ax100'`
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

Anda akan melihat prompt "(gdb)" dan menunggu input. Pertama, kita harus menjalankan program. Ketik run pada prompt dan anda akan mendapatkan respon seperti:

(gdb) run
Starting program: /home/chris/bad_code

Program received signal SIGSEGV, Segmentation fault.
0xb7ec6dc0 in strcpy () from /lib/libc.so.6

Di sini kita lihat program akan mulai dijalankan, juga pemberitahuan tentang SIGSEGV, atau segfault. Di sini GDB memberitahukan kita bahwa program kita telah crash. Namun info ini tidak terlalu berguna, karena akan ada banyak "strcpy" di dalam program yang mempersulit para pengembang untuk menemukan penyebab masalah. Untuk membantu mereka, kita akan melakukan apa yang disebut dengan backtrace. Backtrace berjalan mundur melewati semua fungsi yang ada ketika program diekseskusi, sampai ke fungsi yang rusak. Fungsi yang kembali (tanpa menyebabkan crash) tidak akan ditampilkan. Untuk mendapatkan backtrace, pada prompt (gdb), ketik bt. Anda akan mendapatkan hasil seperti ini:

(gdb) bt
#0  0xb7ec6dc0 in strcpy () from /lib/libc.so.6
#1  0x0804838c in run_it ()
#2  0x080483ba in main ()

Anda bisa lihat pola trace dengan jelas. main() dipanggil pertama kali, diikuti oleh run_it(), dan di dalam run_it() terdapat strcpy() yang rusak. informasi seperti ini dapat membantu para pengembang untuk mengatasi masalah. Ada beberapa pengecualian dari output. Pertama ialah lupa mengaktifkan simbol debug dengan FEATURES="nostrip". Tanpa simbol debug, output akan terlihat seperti berikut:

(gdb) bt
#0  0xb7e2cdc0 in strcpy () from /lib/libc.so.6
#1  0x0804838c in ?? ()
#2  0xbfd19510 in ?? ()
#3  0x00000000 in ?? ()
#4  0x00000000 in ?? ()
#5  0xb7eef148 in libgcc_s_personality () from /lib/libc.so.6
#6  0x080482ed in ?? ()
#7  0x080495b0 in ?? ()
#8  0xbfd19528 in ?? ()
#9  0xb7dd73b8 in __guard_setup () from /lib/libc.so.6
#10 0xb7dd742d in __guard_setup () from /lib/libc.so.6
#11 0x00000006 in ?? ()
#12 0xbfd19548 in ?? ()
#13 0x080483ba in ?? ()
#14 0x00000000 in ?? ()
#15 0x00000000 in ?? ()
#16 0xb7deebcc in __new_exitfn () from /lib/libc.so.6
#17 0x00000000 in ?? ()
#18 0xbfd19560 in ?? ()
#19 0xb7ef017c in nullserv () from /lib/libc.so.6
#20 0xb7dd6f37 in __libc_start_main () from /lib/libc.so.6
#21 0x00000001 in ?? ()
#22 0xbfd195d4 in ?? ()
#23 0xbfd195dc in ?? ()
#24 0x08048201 in ?? ()

Backtrace ini berisi banyak sekali tanda ??. Ini disebabkan oleh tidak adanya simbol debug, gdb tidak dapat mengetahui bagaimana program tersebut dijalankan. Jadi, sangat penting untuk tidak menghapus simbol debug. Sekarang mari kita lihat bagaimana output yang akan diberikan dengan flag -ggdb diaktifkan:

(gdb) bt
#0  0xb7e4bdc0 in strcpy () from /lib/libc.so.6
#1  0x0804838c in run_it (input=0x0) at bad_code.c:7
#2  0x080483ba in main (argc=1, argv=0xbfd3a434) at bad_code.c:12

Di sini kita bisa melihat informasi yang lebih banyak lagi. Tidak hanya informasi fungsi yang ditampilkan, tetapi juga nomor baris dari file source. Metode ini adalah metode yang paling dianjurkan jika anda memiliki ruang harddisk yang cukup besar. Berikut ini adalah perbandingan antara ukuran file sebuah program dengan debug, strip dan -ggdb diaktifkan.

(simbol debug dihapus)
-rwxr-xr-x  1 chris users 3140  6/28 13:11 bad_code
(simbol debug tidak dihapus)
-rwxr-xr-x  1 chris users 6374  6/28 13:10 bad_code
(flag -ggdb diaktifkan)
-rwxr-xr-x  1 chris users 19552  6/28 13:11 bad_code

Seperti yang bisa anda lihat, -ggdb menambahkan sekitar 13178 byte dari file yang memiliki simbol debug. Namun begitu, seperti yang telah kita ketahui di atas, pertambahan ukuran file ini sangat berguna untuk mendapatkan informasi debug tambahan bagi para pengembang. Backtrace dapat disimpan ke sebuah file dengan cara menyalinnya dari terminal (anda dapat menggunakan gpm pada terminal yang tidak berbasis X, bacalah panduan gpm untuk mengetahui caranya). Setelah kita selesai menggunakan gdb, sekarang kita boleh menutupnya.

(gdb) quit
The program is running. Exit anyway? (y or n) y
$

Dengan gdb, kami harap anda dapat membuat laporan bug yang lebih baik. Bagaimanapun juga, ada beberapa jenis error lain yang dapat menyebabkan program gagal ketika dijalankan. Salah satu sebabnya adalah melalui cara akses file yang tidak benar. Kita dapat menemukannya dengan sebuah program kecil yang bagus bernama strace.

3.  Menemukan kesalahan akses file dengan strace

Pendahuluan

Terkadang sebuah program menggunakan file untuk mendapatkan informasi pengaturan, akses ke hardware, atau menulis log. Namun tidak jarang program tersebut mengakses file dengan cara yang tidak benar. Sebuah tool bernama strace diciptakan untuk membantu kita mengatasi masalah ini. strace mencari jejak panggilan sistem termasuk penggilan yang menggunakan memori dan file. Sebagai contoh, kita akan menggunakan program "foobar2" yang merupakan update dari "foobar". Ketika anda berpindah ke foobar2, semua file konfigurasi anda hilang! Pada foobar versi 1, anda telah membuat file konfigurasinya yang diberi nama "foo", tetapi sekarang pada versi 2, program ini menggunakan file konfigurasi "bar".

$ ./foobar2
Configuration says: bar

File konfigurasi kita yang sebelumnya diatur ke foo, jadi mari kita gunakan strace untuk mengetahui apa yang terjadi.

Menggunakan strace untuk melacak masalah

Kita perintahkan strace untuk me-log hasil dari panggilan sistem dengan menjalankan strace dengan argumen -o[file]. Mari kita gunakan perintah ini pada foobar2.

# strace -ostrace.log ./foobar2

Perintah ini akan menciptakan sebuah file bernama strace.log pada direktori sekarang. Kita akan memeriksa file ini, berikut adalah bagian penting dari file tersebut.

open(".foobar2/config", O_RDONLY)       = 3
read(3, "bar", 3)                       = 3

Aha! Jadi ini dia masalahnya. Ada yang telah memindahkan direktori konfigurasi yang tadinya adalah .foobar ke .foobar2. Kita juga melihat bahwa program telah membaca "bar" seperti yang sudah seharusnya dilakukan. Pada kasus ini, kita perlu menganjurkan pengurus ebuild untuk memberikan peringatan tentang perubahan ini. Tetapi untuk sekarang, kita dapat menyalin file konfigurasi dari .foobar dan merubahnya untuk mendapatkan hasil yang benar.

Kesimpulan

Sekarang kita telah mengetahui cara menemukan bug run time. Bug-bug ini terbukti sangat menjengkelkan ketika anda mencoba untuk menjalankan program. Namun begitu, error run time tidak seberapa menjengkelkan dibandingkan dengan program yang tidak dapat dikompilasi sama sekali. Mari kita lihat cara menangani kegagalan emerge.

4.  Menangani kegagalan emerge

Pendahuluan

Kegagalan emerge, seperti pada contoh sebelumnya, bisa menjadi sumber frustasi kebanyakan pengguna. Melaporkan kegagalan ini sangat penting untuk menjaga kualitas Gentoo. Sekarang mari kita lihat contoh ebuild foobar2, yang berisi beberapa kegagalan ketika dikompilasi.

Evaluasi kegagalan emerge

Berikut ini adalah contoh kegagalan sederhana:

gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod   -c -o foobar2-7.o foobar2-7.c
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod   -c -o foobar2-8.o foobar2-8.c
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod   -c -o foobar2-9.o foobar2-9.c
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod   -c -o foobar2.o foobar2.c
foobar2.c:1:17: ogg.h: No such file or directory
make: *** [foobar2.o] Error 1

!!! ERROR: sys-apps/foobar2-1.0 failed.
!!! Function src_compile, Line 19, Exitcode 2
!!! Make failed!
!!! If you need support, post the topmost build error, NOT this status message

Program ini dikompilasi dengan mulus sampai tiba-tiba berhenti dan memberikan pesan error. Error seperti ini bisa dibagi menjadi tiga bagian, pesan kompilasi, error kompilasi, dan pesan error emerge seperti berikut:

(Pesan-pesan kompilasi)
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod   -c -o foobar2-7.o foobar2-7.c
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod   -c -o foobar2-8.o foobar2-8.c
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod   -c -o foobar2-9.o foobar2-9.c
gcc -D__TEST__ -D__GNU__ -D__LINUX__ -L/usr/lib -I/usr/include -L/usr/lib/nspr/ -I/usr/include/fmod   -c -o foobar2.o foobar2.c

(Eror kompilasi)
foobar2.c:1:17: ogg.h: No such file or directory
make: *** [foobar2.o] Error 1

(Pesan error emerge)
!!! ERROR: sys-apps/foobar2-1.0 failed.
!!! Function src_compile, Line 19, Exitcode 2
!!! Make failed!
!!! If you need support, post the topmost build error, NOT this status message

Pesan kompilasi adalah pesan yang membawa ke error. Biasanya, baik sekali untuk mengikutsertakan 10 baris terakhir dari informasi kompilasi agar para pengembang mengetahui di bagian mana kompilasi mengalami kegagalan.

Error "make" adalah error yang sebenarnya dan informasi inilah yang dibutuhkan oleh para pengembang. Ketika anda melihat "make: ***", di sinilah biasanya error terjadi. Pada keadaan normal, anda dapat menyalin 10 baris untuk dikirimkan kepada para pengembang. Namun, cara ini tidak selalu dapat digunakan dan kita akan melihat cara alternatifnya sebentar lagi.

Pesan error emerge adalah apa yang dimuntahkan oleh emerge sebagai error. Terkadang, pesan ini juga berisi informasi penting. Tetapi banyak pengguna yang melakukan kesalahan dengan hanya memberikan pesan error emerge. Pesan ini tidak berguna tanpa adanya pesan error "make" dan informasi kompilasi agar para pengembang dapat mengetahui aplikasi apa dan versi berapa yang gagal dikompilasi. Sebagai catatan, "make" umum digunakan untuk proses kompilasi program (tetapi tidak selalu). Jika anda tidak dapat menemukan error "make ***", maka salinlah 20 baris terakhir sebelum pesan error emerge. Sekarang anggaplah pesan errornya sangat banyak. 10 baris tidak cukup untuk mengetahui penyebabnya. Di sinilah manfaat dari PORT_LOGDIR.

emerge dan PORT_LOGDIR

PORT_LOGDIR adalah variabel portage yang menentukan direktori log untuk berbagai log emerge. Mari kita lihat apa saja yang diperlukan untuk ini. Pertama, jalankan emerge dengan sebelumnya telah mengatur PORT_LOGDIR ke lokasi yang anda sukai. Anggaplah kita memilih /var/log/portage. Kita akan menggunakannya sebagai direktori log:

# PORT_LOGDIR=/var/log/portage emerge foobar2

Sekarang emerge gagal lagi. Tetapi kali ini kita mendapatkan log yang dapat kita lampirkan ketika membuat laporan bug nantinya. Mari kita lihat isi direktori log kita.

# ls -la /var/log/portage
total 16
drwxrws---   2 root root 4096 Jun 30 10:08 .
drwxr-xr-x  15 root root 4096 Jun 30 10:08 ..
-rw-r--r--   1 root root 7390 Jun 30 10:09 2115-foobar2-1.0.log

File log berformat [counter]-[nama paket]-[version].log. Counter adalah variabel khusus yang berguna untuk menyatakan paket ini sebagai paket ke-n yang telah anda emerge. Hal ini untuk mencegah duplikasi log. Dengan melihat isi log, kita akan mengetahui seluruh proses emerge. Log ini dapat kita lampirkan nanti ketika kita melaporkan bug. Tetapi sebelumnya, kita perlu memastikan dulu bahwa belum ada pengguna lain yang telah melaporkan masalah ini. Berikut adalah cara mencari bug.

5.  Mencari bug di Bugzilla

Pendahuluan

Bugzilla adalah apa yang digunakan oleh Gentoo untuk menangani bug. Bugzilla Gentoo dapat dicapai melalui HTTPS dan HTTP. HTTPS tersedia untuk anda yang berada di jaringan yang tidak aman atau anda yang penakut :). Untuk konsistensi, kita akan menggunakan versi HTTPS pada contoh. Masuklah ke Bug Gentoo untuk mengetahui tampilannya.

Salah satu hal yang membuat para pengembang frustasi adalah adanya duplikasi bug. Ini dapat menyia-nyiakan waktu mereka yang sebenarnya dapat digunakan untuk memperbaiki bug lain yang lebih penting. Hal ini dapat kita hindari dengan menggunakan metode pencarian sederhana. Jadi sekarang kita akan mencari bug untuk mengetahui apakah bug yang ingin kita laporkan sudah ada. Untuk contoh ini, kita akan menggunakan error emerge xclass yang tadi kita gunakan.

/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include/g++-v3/backward/backward_warning.h:32:2:
warning: #warning This file includes at least one deprecated or antiquated
header. Please consider using one of the 32 headers found in section 17.4.1.2 of
the C++ standard. Examples include substituting the <X> header for the <X.h>
header for C++ includes, or <sstream> instead of the deprecated header
<strstream.h>. To disable this warning use -Wno-deprecated.
In file included from main.cc:40:
menudef.h:55: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:62: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:70: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
menudef.h:78: error: brace-enclosed initializer used to initialize `
OXPopupMenu*'
main.cc: In member function `void OXMain::DoOpen()':
main.cc:323: warning: unused variable `FILE*fp'
main.cc: In member function `void OXMain::DoSave(char*)':
main.cc:337: warning: unused variable `FILE*fp'
make[1]: *** [main.o] Error 1
make[1]: Leaving directory
`/var/tmp/portage/xclass-0.7.4/work/xclass-0.7.4/example-app'
make: *** [shared] Error 2

!!! ERROR: x11-libs/xclass-0.7.4 failed.
!!! Function src_compile, Line 29, Exitcode 2
!!! 'emake shared' failed

Untuk memulai pencarian, masuklah ke Website Bugzilla.

Gambar 5.1: Website Bugzilla

Klik "Query Existing bug reports". Kita melakukan ini karena biasanya, pencarian dasar memberikan hasil yang terlalu banyak dan menyebabkan calon pelapor malas untuk memeriksa semua hasil pencarian. Sekarang kita telah berada di halaman selanjutnya:

Gambar 5.2: Halaman Pencarian Bugzilla

Lanjutkan dengan meng-klik link "Advanced Search" untuk memasuki halaman "Advanced Search"

Gambar 5.3: Halaman Advanced Search

Beginilah tampilan halaman Advanced Search. Walaupun kelihatannya memusingkan, kita akan berfokus pada beberapa bagian penting untuk lebih memperkecil hasil pencarian bugzilla.

Gambar 5.4: Isi

Bagian pertama adalah ringkasan bug. Di sini kita akan mencantukan nama bug dari paket yang bermasalah. Jika bugzie tidak memberikan hasil apa-apa, coba hapus nama paket, kalau-kalau ada pelapor yang tidak mencantumkan nama paket (biasanya jarang sekali terjadi, tetapi kami pernah mendapatkan laporan bug yang aneh seperti ini).

Product, Component, dan Version harus selalu dibiarkan ke default. Ini agar pencarian kita tidak terlalu spesifik sehingga melewatkan semua bug.

Comment adalah bagian terpenting. Gunakan bagian ini untuk mencantumkan pesan error. Pada dasarnya, anda tidak perlu menggunakan kata-kata seperti pada permulaan error kompilasi, cari baris sebelumnya yang menyatakan error yang sebenarnya. Juga, anda mungkin perlu membuang tanda-tanda baca agar bugzie tidak menginterpretasikan komentar dengan cara yang salah. Contoh dari error emerge xclass:

menudef.h:78: error: brace-enclosed initializer used to initialize `OXPopupMenu'
(Hapus tanda kutip' ')
menudef.h 78 error brace-enclosed initializer used to initialize OXPopupMenu

Komentar di atas sudah cukup spesifik untuk menemukan bug yang mirip tanpa harus memeriksa semua bug yang berhubungan dengan kegagalan kompilasi xclass.

URI, Whiteboard, dan Keywords boleh dibiarkan kosong. Apa yang telah kita cantumkan sejauh ini sudah cukup untuk mencari bug. Mari kita lihat apa saja yang telah kita isi.

Gambar 5.5: Formulir Pencarian yang Telah Dilengkapi

Sekarang klik tombol "Search" dan inilah hasilnya....

Gambar 5.6: Hasil Pencarian

Hanya 2 Bug! Ini lebih enak untuk dibaca. Klik bug pertama untuk memeriksanya, dan hampir pasti bahwa ini adalah bug yang kita cari.

Gambar 5.7: Bug Ditemukan

Bukan saja bug ini adalah bug yang kita cari, tetapi bug ini telah diperbaiki. Dengan membaca komentar terakhir, kita dapat mengetahui solusinya dan bagaimana cara mengatasi permasalahan. Sekarang, mari kita lihat apa yang terjadi jika kita tidak menggunakan "Advanced Search".

Gambar 5.8: Hasil Pencarin Dasar

Lebih banyak 4 bug! Ini bisa lebih parah jika kita mencari paket lain yang lebih besar. Namun dengan tool sederhana ini, kita dapat dengan mudah memperuncing pencarian dan menemukan bug yang kita cari.

Kesimpulan

Katakanlah anda telah mencari dan terus mencari tetapi masih belum menemukannya. Ini berarti anda telah menemukan bug baru. Mari kita lihat proses pembuatan laporan bug.

6.  Melaporkan Bug

Pendahuluan

Pada bab ini, kita akan mempelajari cara menggunakan Bugzilla untuk melaporkan bug baru. Masuklah ke Bug Gentoo dan...

Gambar 6.1: Website Bugzilla

Klik "Report a Bug - Using the guided format".

Gambar 6.2: Pemilihan Produk

Seperti yang bisa anda lihat, kami telah membuat penekanan agar bug anda dimasukkan ke tempat yang benar. "Gentoo Linux" adalah tempat hampir semua bug dimasukkan.

Walaupun begitu, masih banyak yang memasukkan bug ke pengembangan portage (dengan beranggapan bahwa tim portage menangani bug dari isi pohon portage) atau infra (dengan anggapan infra memiliki akses ke mirror dan rsync sehingga dapat memperbaikinya dengan cepat). Bukan begitu yang benar.

Konsepsi salah yang lainnya terjadi pada bug Dokumentasi. Misalnya, ketika seorang pengguna menemukan bug di Dokumentasi Catalyst, ia menempatkan bug tersebut dalam kategori "Doc-user" yang nantinya akan diserahkan kepada GDP, padahal seharusnya diserahkan kepada tim Release Engineering. Aturannya, hanya dokumentasi yang berada di http://www.gentoo.org/doc/* yang merupakan bagian dari GDP. Dokumentasi lain yang berada di http://www.gentoo.org/proj/* merupakan bagian dari timnya masing-masing.

Bug kita akan dimasukkan ke dalam produk Gentoo Linux karena merupakan bug ebuild. Kita akan beranjak ke sana dan kita akan disambut dengan beberapa langkah dalam proses melaporkan bug. Mari kita lanjutkan dengan Langkah 1...

Gambar 6.3: Guided Format Langkah 1

Langkah pertama di sini sangatlah penting (sebagaimana yang dikatakan oleh tulisan merah). Di sinilah tempat anda mencari tahu apakah ada pengguna lain yang telah melaporkan bug yang sama atau belum. Jika anda melewatkan bug ini dan bug yang akan anda laporkan telah ada, bug anda akan ditandai DUPLICATE karena dapate membuang-buang waktu dengan percuma. Sekarang kita masuk ke langkah 2, tempat kita memberikan informasi.

Informasi yang Diperlukan

Gambar 6.4: Informasi Dasar

Mari kita lihat satu persatu dengan teliti.

• Pertama, "Product". Product akan mengkategorikan bug ke wilayah tertentu dari Gentoo seperti Bugzilla (untuk bug yang terkait dengan bugs.gentoo.org), Docs-user (untuk Dokumentasi Pengguna) atau Gentoo Linux (untuk ebuild dan yang sejenisnya).
• "Component" adalah lokasi terjadinya error, lebih spesifik lagi, bagian dari produk yang memiliki bug. Ini akan mempermudah klasifikasi.
• "Hardware platform" adalah arsitektur yang anda gunakan. Jika anda menggunakan SPARC, anda harus memilih SPARC.
• "Operating System" adalah sistem operasi yang anda gunakan. Karena Gentoo dianggap sebagai sebuah "Meta-distribution", Gentoo dapat digunakan pada sistem operasi selain Linux.

Jadi, untuk contoh bug ini, kita memiliki:

• Product - Gentoo Linux (Karena ini adalah masalah ebuild)
• Component - Application (Ini adalah kesalahan dari aplikasi, foobar2)
• Hardware Platform - All (Error ini terjadi pada semua arsitektur)
• Operation System - All (Bisa saja terjadi pada semua jenis sistem)

Gambar 6.5: Informasi Dasar yang Telah Dilengkapi

• "Build Identifier" pada dasarnya adalah "User Agent" dari browser yang dipakai untuk melaporkan bug (untuk tujuan pembuatan log). Anda boleh membiarkannya.
• "URL" merupakan opsional dan digunakan untuk menunjukkan informasi terkait yang berada di situs lain (bugzilla pusat, catatan rilis pada website pusat, dll.). Anda sebaiknya tidak menggunakan URL yang menunjuk ke pastebin untuk mencantumkan pesan error, log, output dari emerge --info, screenshot, atau informasi sejenisnya. Namun, lampirkan semua informasi tersebut (jika diperlukan) pada bug.
• Pada "Summary", anda harus mencantumkan kategori, nama, dan nomor versi paket.

Mencantumkan kategori pada kolom "Summary" tidaklah terlalu penting tetapi dianjurkan. Namun jika anda tidak mencantumkan nama paket, kami tidak akan dapat mengerti bug yang anda laporkan dan kami akan menanyakannya pada anda nanti. Nomor versi paket penting untuk pengguna lain yang melakukan pencarian bug. Jika ada 20 orang yang melaporkan bug tanpa mencantumkan nomor versi, bagaimana orang lain yang mencari bug dapat mengetahui jika bug yang ingin ia laporkan telah ada? Ia harus memeriksa setiap laporan bug yang ditemukan, yang sebenarnya tidak terlalu sulit. Tetapi bagaimana jika, katakanlah, ada 200 bug... tidak mudah kan? Setelah mengisi semua informasi paket, anda perlu memberikan penjelasan singkat tentang apa yang terjadi. Berikut ini adalah contohnya:

Gambar 6.6: Summary

Aturan-aturan yang sederhana ini dapat mempermudah penanganan bug. Berikutnya adalah "Details". Di sini kita berikan informasi tentang bug, seperti pada contoh:

Gambar 6.7: Details

Sekarang para pengembang mengerti mengapa anda melaporkan bug. Mereka kemudian dapat me-reproduce bug tersebut. Reproduksibilitas dapat memberitahukan kepada kita seberapa sering kita dapat menyebabkan masalah ini terjadi. Pada contoh berikut, kita dapat me-reproduce bug tersebut kapan saja dengan menjalankan foobar2. Mari kita berikan informasi ini.

Gambar 6.8: Reproduction

Kita telah menjelaskan bagaimana kita menemukan bug. Langkah selanjutnya adalah menjelaskan hasil yang kita dapatkan dan apa yang menurut kita seharusnya terjadi.

Gambar 6.9: Hasil

Selanjutnya kita dapat memberikan informasi tambahan. Ini bisa berupa jejak, bagian-bagian dari log (karena biasanya log sangat besar dan tidak diperlukan semuanya), dan yang lebih penting adalah output emerge --info anda. Berikut ini adalah contohnya.

Gambar 6.10: Informasi Tambahan

Terakhir kita pilih "severity"/tingkatan bug. Tolong perhatikan baik-baik. Pada kebanyakan kasus, anda boleh saja membiarkannya seperti apa adanya agar orang lain dapat menaikkan/menurunkannya. Namun, jika anda menaikkannya, tolong pastikan anda telah membacanya dengan seksama dan pastikan anda tidak membuat kesalahan. Berikut ini adalah beberapa tingkatan bug:

• "Blocker" - Program tidak dapat diinstal atau menjadi gangguan besar di sistem. Sebagai contoh, masalah baselayout yang mencegah sistem untuk boot.
• "Critical" - Program memiliki banyak kebocoran memori atau data ketika dijalankan. Lagi-lagi, sebuah program penting seperti net-tools yang gagal dikompilasi dapat diberikan label "critical". Masalah ini tidak akan mencegah sistem anda untuk boot tetapi sangat penting untuk pekerjaan sehari-hari.
• "Major" - Program crash, tetapi tidak menyebabkan kerusakan berarti pada sistem atau menghilangkan data.
• "Minor" - Program crash dan sudah ada cara untuk mencegahnya.
• "Normal" - Default. Jika anda tidak yakin, gunakanlah pilihan ini kecuali ada perubahan lain yang terjadi, untuk itu bacalah informasi di bawah ini.
• "Trivial" - Hal-hal seperti penulisan kata yang salah atau pembersihan spasi yang tidak perlu.
• "Enhancement" - Permintaan untuk pengaktifan fitur baru pada sebuah program, atau lebih spesifiknya, ebuild baru.

Gambar 6.11: Severity

Di sini, kita akan memilih "Normal".

Sekarang kita dapat mengirimkan laporan bug dengan menekan tombol "Submit Bug Report". Anda akan melihat sebuah bug baru ditampilkan. Lihatlah Bug 97561 untuk mengetahui hasilnya. Kita telah melaporkan bug! Sekarang mari kita lihat bagaimana bug ini ditangani.

Permintaan "Zero-day bump"

Sejauh ini, kami telah menunjukkan cara mengisi laporan bug. Sekarang mari kita lihat apa yang seharusnya tidak kita lakukan.

Dengan anggapan anda sedang semangat sekali mengikuti jadwal pada pusat sebuah proyek, dan ketika anda mengunjungi website mereka, anda mengetahui bahwa mereka baru saja merilis versi baru beberapa menit yang lalu! Kebanyakan pengguna akan buru-buru melaporkan hal ini di bugzie; "Tolong buatkan ebuild untuk versi baru dan masukkan ke Portage", dsb. Bagaimanapun juga, anda seharusnya tidak melakukan hal ini. Permintaan semacam ini disebut sebagai permintaan zero-day (atau 0-day) karena dibuat pada hari yang sama dengan dirilisnya versi baru.

Mengapa harus menunggu? Pertama, rasanya sangat tidak sopan untuk memaksa para pengembang Gentoo untuk menambahkan rilis baru yang baru saja keluar 15 menit yang lalu. Permintaan anda bisa saja ditandai INVALID atau LATER, karena para pengembang sedang sibuk membereskan urusan penting lainnya. Kedua, para pengembang biasanya sudah lebih dahulu mengetahui akan adanya rilis baru, karena mereka harus mengikuti perkembangan di pusat proyek. Mereka sudah tahu bahwa rilis baru telah ada. Pada kebanyakan kasus, mereka mungkin sudah membuka bug baru, atau bahkan telah menambahkannya ke Portage sebagai paket yang di-mask.

Bersikap bijaklah ketika anda menguji dan membuat permintaan untuk versi baru dari sebuah paket. Lakukan pencarian di bugzie sebelum anda membuat permintaan -- apakah sudah ada bug yang dibuka? Apakah anda sudah melakukan sync; apakah versi baru tersebut sudah ditambahkan di Portage? Apakah versi tersebut benar-benar telah dirilis oleh pusat? Jika memang versi tersebut telah dirilis beberapa hari yang lalu dan belum ada permintaan di bugzie (juga belum ada di Portage), maka anda boleh membuka bug baru. Pastikan untuk memberi informasi bahwa versi baru tersebut dapat dikompilasi dengan sukses dan dapat dijalankan tanpa masalah pada arsitektur anda. Informasi lain yang bisa membantu akan sangat diterima.

Ingin melihat versi terbaru dari program favorit anda di Portage? Buatlah laporan bug yang bagus.

7.  Bekerja Dengan Bug Anda

Dengan memperhatikan bug, kita dapat melihat informasi yang kita berikan tadi. Anda juga akan melihat bahwa bug tersebut telah diserahkan kepada bug-wranglers@gentoo.org. Ini adalah lokasi default untuk bug komponen Aplikasi.

Gambar 7.1: Informasi Dasar Bug Baru

Rincian tentang bug yang tadi kita berikan juga telah tercantum.

Gambar 7.2: Rincian Bug Baru

Bagaimanapun juga, bug-wranglers (biasanya) tidak akan memperbaiki bug kita, jadi kita akan menyerahkan bug tersebut ke pihak lain yang dapat memperbaikinya (anda boleh membiarkan bug-wrangler melakukannya). Untuk ini, kita akan menggunakan file metadata.xml dari paket tersebut. Biasanya anda dapat menemukannya di /usr/portage/kategori/paket/metadata.xml. Berikut ini adalah metadata dari foobar2.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
<pkgmetadata>
<herd>chriswhite</herd>
<maintainer>
<email>chriswhite@gentoo.org</email>
<name>Chris White</name>
</maintainer>
<longdescription lang="en">
Foobar2 is a package that uses a configuration file to display a word.
</longdescription>
</pkgmetadata>

Perhatikan bagian maintainer. Bagian ini berisi daftar para pengurus paket, yang pada contoh ini adalah penulis sendiri, Chris White. Email yang tercantum adalah chriswhite@gentoo.org. Kita akan menggunakannya untuk menyerahkan bug. Untuk melakukannya, klik balon di samping "Reassign bug to", lalu isi alamat email.

Gambar 7.3: Penyerahan Bug

Selanjutnya tekan tombol "Commit" agar perubahan diterapkan. Sekarang bug telah diserahkan kepada penulis. Setelah itu anda akan melihat bahwa penulis telah merespon bug anda (biasanya melalui email). Penulis telah mengatakan bahwa penulis ingin melihat log untuk mengetahui cara program membaca file konfigurasinya. Ikuti petunjuk yang tadi telah dijelaskan tentang penggunaan strace untuk mendapatkan log. Sekarang anda harus melampirkannya pada laporan bug. Untuk melakukannya, klik "Create A New Attachment".

Gambar 7.4: Lampiran Baru

Sekarang kita perlu melampirkan log. Mari kita bahas satu persatu.

• File - Ini adalah lokasi file di komputer anda. Pada contoh ini, lokasi strace.log. Anda dapat menggunakan tombol "Browse..." untuk memilih file, atau langsung memasukkan path ke kolom yang tersedia.
• Description - Penjelasan singkat tentang lampiran. Karena kita akan melampirkan strace.log, cantumkan saja nama file-nya.
• Content Type - Tipe dari file yang kita lampirkan.
• Obsoletes - Jika ada file yang telah dilampirkan ke bug sebelum file yang akan anda lampirkan, anda memiliki pilihan untuk menjadikan file lama usang dengan adanya file yang baru. Karena kita belum pernah melampirkan apapun, kita biarkan saja.
• Comment - Berikan komentar yang nantinya akan ditampilkan di bawah lampiran. Anda boleh memberikan penjelasan tentang lampiran anda di sini jika diperlukan.

Untuk "Content Type", berikut ini adalah sedikit penjelasannya. Anda dapat memberikan tanda cek pada kotak cek "patch" jika anda melampirkan tambalan/patch. Jika tidak, anda harus memerintahkan bugzie untuk meng-"auto-detect" tipe file (tidak dianjurkan). Pilihan lain adalah dengan menggunakan "select from list", yang paling sering digunakan. Gunakan teks biasa (text/plain) untuk hampir semua lampiran kecuali file binari seperti file gambar (yang boleh menggunakan image/gif, image/jpeg atau image/png, tergantung tipe) atau file terkompresi seperti .tar.bz2 yang harus menggunakan application/octet-stream sebagai "content type".

Gambar 7.5: Informasi Lampiran Baru Selesai Dilengkapi

Kita kirimkan strace.log dan sekarang telah terlampir pada laporan bug.

Gambar 7.6: Log strace Terlampir

Telah dijelaskan tadi bahwa terkadang ebuild akan meminta anda untuk melampirkan file yang disebutkan pada pesan error emerge. Berikut ini contohnya:

configure: error: PNG support requires ZLIB. Use --with-zlib-dir=<DIR>

!!! Please attach the config.log to your bug report:
!!! /var/tmp/portage/php-5.0.3-r1/work/php-5.0.3/config.log

!!! ERROR: dev-php/php-5.0.3-r1 failed.
!!! Function econf, Line 485, Exitcode 0
!!! econf failed
!!! If you need support, post the topmost build error, NOT this status message.

Tolong lampirkan file yang disebutkan seperti pesan di atas pada laporan bug anda.

Terkadang seorang pengembang akan meminta anda untuk melampirkan file "diff" atau file patch. File diff standar bisa didaptkan dengan:

$ cp file file.old
$ nano file
$ diff -u file.old file

Untuk file source C/C++, flag -p perlu ditambahkan untuk menunjukkan penggilan sistem apa yang diterapkan oleh diff.

$ cp file.c file.c.old
$ nano file.c
$ diff -up file.c.old file.c

Tim dokumentasi memerlukan kombinasi flag -Nt dan -u. Ini ada hubungannya dengan ekspansi tab. Anda dapat membuat diff seperti ini dengan:

$ cp file.xml file.xml.old
$ nano file.xml
$ diff -Nut file.xml.old file.xml

Diff anda sudah jadi. Ketika anda melakukannya, katakanlah ada orang lain yang menemukan bug anda dengan melakukan pencarian di bugzie dan ingin terus mengikuti perkembangan bug. Ia dapat melakukannya dengan menambahkan alamat email-nya di kolom "Add CC" bug seperti pada contoh berikut. Anda juga dapat mengikuti perkembangan bug yang dilaporkan oleh orang lain dengan melakukan hal yang sama.

Gambar 7.7: Menambahkan Email ke CC:

Setelah melalui semua proses ini, bug biasanya akan melalui berbagai proses pemberian status. Hal ini biasanya dilakukan oleh para pengembang Gentoo dan terkadang oleh sang pelapor. Berikut ini adalah berbagai status yang dapat diberikan kepada bug.

• UNCONFIRMED - Anda biasanya akan jarang melihat status ini. Ini artinya sang pelapor telah membuka bug baru menggunakan metode advanced dan tidak yakin apakah bug yang ia laporkan benar-benar bug.
• NEW - Bug yang baru dibuka dan dianggap masih baru.
• ASSIGNED - Ketika orang yang anda serahkan bug kepadanya telah menerima bug, bug akan mendapatkan status ASSIGNED selama masalahnya sedang diatasi. Dengan begini anda dapat mengetahui bahwa mereka telah menerima bug anda sebagai bug sungguhan.
• REOPENED - Seseorang sudah dapat mengatasi masalah pada bug tetapi anda merasa solusinya kurang bagus atau masalahnya masih ada. Di sini, anda boleh membuka kembali bug tersebut. Tolong jangan salah gunakan fungsi ini. Jika seorang pengembang telah menutup bug dua atau tiga kali, kemungkinan besar bug anda akan ditutup selamanya.
• RESOLVED - Keputusan yang telah diambil terhadap bug. Biasanya akan menjadi FIXED dalam waktu singkat untuk menandakan bahwa bug telah diperbaiki dan masalah sudah dapat diatasi dengan berbagai solusi. Kita akan membahas ini sebentar lagi.
• VERIFIED - Langkah yang diambil ketika bug dianggap benar. Ini biasanya dilakukan oleh QA.
• CLOSED - Pada dasarnya berarti RIP (salam perpisahan) untuk bug dan bug tersebut akan dikubur di antara bug lain yang tidak pernah ada habisnya.

Setelah itu, kami dapat menemukan error pada log strace dan memperbaiki bug serta memberikan status RESOLVED FIXED dan menyatakan bahwa ada perubahan pada lokasi file konfigurasi, dan penulis kemudian meng-update ebuild untuk mencantumkan peringatan tentang hal tersebut. Bug sekarang telah teratasi, anda anda akan melihat yang seperti ini:

Gambar 7.8: Bug yang Telah Diperbaiki

Di bawahnya, anda akan melihat:

Gambar 7.9: Pilihan-pilihan Bug

Ini akan memberikan anda pilihan untuk membuka kembali bug jika anda menginginkannya (misalnya jika menurut pengembang masalah sudah teratasi tetapi menurut anda solusinya kurang bagus). Sekarang bug kita telah diperbaiki! Namun masih ada beberapa resolusi yang bisa terjadi, berikut daftar singkatnya:

• FIXED - Bug telah diperbaiki, ikuti petunjuk yang ada untuk mengatasi masalah anda.
• INVALID - Anda tidak mengikuti petunjuk yang ada, sehingga menyebabkan bug.
• DUPLICATE - Anda tidak mengikuti petunjuk pada panduan ini sehingga melaporkan bug yang sudah ada.
• WORKSFORME - Pengembang/orang yang diserahkan bug tidak dapat me-reproduce bug anda.
• CANTFIX - Bug tidak dapat diperbaiki karena beberapa alasan. Alasan-alasan ini akan dicantumkan oleh orang yang menangani bug.
• WONTFIX - Ini biasanya terjadi pada ebuild baru atau permintaan fitur. Pada dasarnya pengembang tidak ingin menambahkan fitur tertentu karena tidak diperlukan, adanya alternatif lain yang lebih bagus, atau karena fitur tersebut rusak. Terkadang anda akan diberikan solusi untuk mengatasi masalahnya.
• UPSTREAM - Bug tidak dapat diperbaiki oleh tim pengembang Gentoo, dan telah meminta anda untuk melaporkannya kepada para pengembang pusat (orang-orang yang membuat program) untuk ditinjau. Pengembang pusat memiliki beberapa cara untuk menangani bug. Termasuk di antaranya adalah mislis, channel IRC, dan bahkan sistem pelaporan bug. Jika anda tidak tidak bagaimana melakukannya, cantumkan pertanyaan anda pada bug agar ada orang lain yang dapat memberikan petunjuk kepada anda.

Terkadang, sebelum bug dapat diatasi, seorang pengembang mungkin akan meminta anda untuk menguji sebuah ebuild yang telah diperbarui. Pada bab selanjutnya kita akan melihat cara menguji ebuild.

8.  Menguji Ebuild

Mendapatkan File Ebuild

Katakanlah anda telah melaporkan bug tentang error pada kompilasi foobar2. Sekarang seorang pengembang telah menemukan penyebab masalahnya dan meminta anda untuk menguji ebuild baru untuk memastikan apakah ebuild tersebut berfungsi dengan baik pada sistem anda.

Gambar 8.1: Permintaan Pengujian Ebuild

Beberapa kosakata yang membingungkan digunakan di sini. Pertama, mari kita ketahui apa itu overlay. Overlay adalah sebuah direktori khusus seperti /usr/portage. Bedanya, ketika anda melakukan emerge --sync, file yang ada di dalamnya tidak akan dihapus. Beruntung sebuah direktori khusus /usr/local/portage telah diciptakan untuk tujuan tersebut. Mari kita lanjutkan dengan mengatur overlay portage kita di /etc/make.conf. Bukalah make.conf dengan editor dan tambahkan baris ini di bawahnya.

PORTDIR_OVERLAY="/usr/local/portage"

Sekarang kita akan menciptakan sebuah direktori untuk menempatkan file ebuild percobaan. Pada contoh ini, kita akan menempatkannya di sys-apps/foobar2. Anda tadi telah melihat bahwa komentar kedua mengatakan bahwa anda harus menciptakan direktori files untuk meletakkan patch. Direktori ini digunakan untuk menyimpan file-file lain yang diperlukan tetapi tidak diikutsertakan pada file source paket (tambalan, skrip init.d, dll). Direktori ini adalah subdirektori pada direktori paket dengan nama files. Sekarang ciptakanlah direktori tersebut.

# mkdir -p /usr/local/portage/sys-apps/foobar2/files

Baiklah, sekarang kita dapat mendownload file. Pertama, download ebuild dan file-file lain yang diperlukan. Download ebuild ke /usr/local/portage/sys-apps/foobar2, kemudian download patch ke /usr/local/portage/sys-apps/foobar2/files. Setelah itu, kita dapat menguji ebuild.

Menguji ebuild

Proses pembuatan ebuild yang dapat digunakan oleh emerge sangatlah mudah. Anda harus menciptakan file Manifest untuk ebuild. Ciptakan keduanya dengan perintah ebuild. Jalankan seperti pada contoh berikut:

# ebuild foobar2-1.0.ebuild digest
>>> Creating Manifest for /usr/local/portage/sys-apps/foobar2

Sekarang mari kita lihat apakah ebuild dapat digunakan.

# emerge -pv foobar2

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild  N    ] sys-apps/foobar2-1.0  0 kB [1]

Total size of downloads: 0 kB
Portage overlays:
 [1] /usr/local/portage

Kelihatannya berhasil! Anda akan melihat [1] di samping baris [ebuild]. Tanda tersebut menunjuk ke /usr/local/portage, yakni overlay yang baru saja kita ciptakan. Sekarang kita lanjutkan dengan meng-emerge paket.

# emerge foobar2
 Calculating dependencies ...done!
(info kompilasi dipotong)
>>> Unpacking foobar2-1.0.tar.bz2 to /var/tmp/portage/foobar2-1.0/work
 * Applying foobar2-1.0-Makefile.patch ...                                    [ ok ]
(info kompilasi dipotong)
>>> Merging sys-apps/foobar2-1.0 to /
>>> chris +sandbox(preinst)
--- /usr/
--- /usr/bin/
>>> /usr/bin/foobar2

Pada bagian pertama bisa kita lihat bahwa emerge dimulai dengan baik. Bagian kedua menunjukkan bahwa patch kita berhasil diterapkan dengan pesan status "[ok]" di sebelah kanannya. Bagian terakhir menyatakan bahwa program telah berhasil dikompilasi. Patch berhasil! Sekarang kita dapat memberitahukan pengembang bahwa patch mereka bagus, dan mereka dapat menerapkan perubahan ke portage.

Penutup

Bagian tadi menutup panduan bugzie. Penulis berharap anda dapat memanfaatkan panduan ini. Jika anda memiliki pertanyaan, komentar, atau ide untuk memperbagus panduan ini, kirimkan ke Chris White. Terima kasih kepada moreon yang telah mengingatkan penulis tentang flag -g dan error kompilasi, teman-teman di #gentoo-bugs atas bantuannya dalam penanganan bug, Griffon26 yang telah mengingatkan penulis tentang maintainer-needed, robbat2 atas saran-sarannya dan fox2mike atas perbaikan dokumen dan penambahan hal-hal yang diperlukan.

Isi dokumen ini dilisensikan dengan lisensi Creative Commons - Attribution / Share Alike.