
Melaporkan bug adalah salah satu dari banyak cara Anda dapat membantu Linux berkembang. Semua distribusi perangkat lunak bebas, proyek memiliki sistem yang berbeda di mana bug dikumpulkan, dianalisis, diberi label, dan diperbaiki tergantung pada jumlah orang yang mengetahui kode sumbernya.
Karena saya menyukai Debian, saya akan menunjukkan cara membuat laporan bug di Debian.
Cara melaporkan bug di Debian Linux
Alat goto di Debian untuk melaporkan bug adalah Reportbug. Saya berharap saya mengetahuinya ketika saya mulai dengan pelaporan bug, akan menghindari sedikit mulas untuk diri saya sendiri dan juga pengelola.
Mari kita lihat bagaimana kita dapat menggunakan Reportbug untuk pelaporan bug di Debian Linux.
Langkah 1. Instalasi Reportbug
Gunakan perintah di bawah ini untuk menginstal Reportbug:
sudo aptitude install reportbug
Langkah 2. Reportbug:Jalankan pertama
Setelah Anda menginstal Reportbug, saat pertama kali dijalankan, Anda perlu mengonfigurasinya agar dapat digunakan untuk mengajukan laporan bug.
Gunakan perintah di bawah ini untuk menjalankannya.
reportbug
Dan kemudian banyak pertanyaan seperti yang dapat dilihat di bawah ini:
File ini berisi teks Unicode dua arah yang dapat ditafsirkan atau dikompilasi secara berbeda dari yang muncul di bawah. Untuk meninjau, buka file di editor yang menampilkan karakter Unicode tersembunyi. Pelajari lebih lanjut tentang karakter Unicode dua arah Tampilkan karakter tersembunyiCatatan tentang peluncuran pertama Reportbug:
sebuah. Karena saya telah menggunakan Debian selama beberapa waktu, saya dapat beralih antara 2 dan 3. Bagi orang yang sangat baru dalam pelaporan bug, mereka dapat tetap menggunakan [1] yang ditampilkan sebagai pemula dan default, cukup tekan Enter.
b. Antara UI teks dan antarmuka gtk2/3 , saya menemukan antarmuka gtk2/3 tidak menarik dan juga mengambil sedikit memori, maka saya memilih 1 sepanjang waktu. Jika Anda memilih editor gtk2/3, petunjuk di bawah ini tetap sama untuk Anda, hanya Anda yang akan melihat editor gtk menampilkan hal yang sama dengan cara yang sedikit lebih indah.
c. Bagian di mana Reportbug meminta akses bersih, saya selalu menolaknya untuk sudut pandang praktis dan keamanan. Sedikit penjelasan lebih lanjut tentang alasan saya melakukannya akan dibagikan di bawah ini.
d. Terakhir, ketika menanyakan nama, jika Anda menyukai nama yang sudah ada (diambil dari variabel [dilindungi email]) tekan Enter, jika Anda ingin nama yang lain, berikan nama yang Anda inginkan.
Langkah 3. Menangani kebiasaan Gmail
Pertama kali Reportbug dijalankan, ia akan meminta pengaturan email:
File ini berisi teks Unicode dua arah yang dapat ditafsirkan atau dikompilasi secara berbeda dari yang muncul di bawah. Untuk meninjau, buka file di editor yang menampilkan karakter Unicode tersembunyi. Pelajari lebih lanjut tentang karakter Unicode dua arah Tampilkan karakter tersembunyiApakah Anda memiliki "agen pengangkut surat" (MTA ) seperti Exim, Postfix atau SSMTP yang dikonfigurasi di komputer ini untuk mengirim email ke Internet? [y|T|q|?]?n | |
Silakan masukkan nama host SMTP Anda. Biasanya disebut sesuatu seperti "mail.example.org" atau "smtp.example.org". Jika Anda perlu menggunakan port yang berbeda dari port default, gunakan format alternatif :. Cukup tekan ENTER jika Anda tidak memilikinya atau tidak tahu, maka host SMTP Debian akan digunakan. | |
> | |
Silakan masukkan nama server proxy Anda. Seharusnya hanya menggunakan parameter ini jika Anda berada di belakang firewall. Argumen PROXY harus diformat sebagai URL HTTP yang valid, termasuk (jika perlu) nomor port; misalnya, http://192.168.1.1:3128/. Cukup tekan ENTER jika Anda tidak memilikinya atau tidak tahu. | |
> |
Pertanyaan pertama menanyakan apakah Anda memiliki beberapa perangkat lunak yang memungkinkannya mengirim email secara otomatis.
Jika Anda telah menyiapkan klien email desktop seperti Evolution atau Thunderbird, pilih ya. Jika tidak, pilih tidak.
Setelah file preferensi default ditulis, file tersebut disimpan di /home/shirish/.reportbugrc. Anda dapat mengubah konfigurasi nanti dengan mengedit file ini.
Di konsol, Anda dapat menggunakan CTRL+C untuk keluar dari Reportbug kapan saja.
Langkah 5. Mencari tahu nama paket aplikasi dari biner
Mari saya ambil contoh Aiselriot. Ini adalah salah satu permainan Kartu GTK yang sering dimainkan ibu saya. Sekarang jika ada masalah dengan game, bagaimana cara mengetahui paket apa yang harus saya laporkan bug?
Jadi hal pertama yang saya lakukan ketika mencoba memecahkan masalah aplikasi GUI adalah mengambil ikonnya dan meletakkannya di panel dan melihat propertinya seperti yang saya tunjukkan di sini –

Sekarang saya tahu itu nama aplikasinya. bukan Aiselriot tetapi sol dan jalur tempat aplikasi dipasang ada di /usr/games/sol
.
Sekarang mari kita coba cari apa nama paketnya –
dpkg -S /usr/games/sol
Outputnya adalah:
aisleriot: /usr/games/sol
Kami beruntung paket itu juga disebut aiselriot tetapi ini tidak selalu terjadi.
Selanjutnya, mari kita laporkan laporan bug pertama kita. Karena saya menggunakan pengujian Debian/stretch/soon agar stabil dalam beberapa bulan, akan ada laporan bug di sana.
Langkah 6. Menggunakan Reportbug untuk membuat laporan bug
Sekarang kita membutuhkan paket yang memiliki masalah/bug yang perlu kita laporkan ke komunitas Debian.
Saya memiliki paket piuparts yang menunjukkan gejala masalah yang saya alihkan ke Reportbug seperti yang ditunjukkan pada intinya:
File ini berisi teks Unicode dua arah yang dapat ditafsirkan atau dikompilasi secara berbeda dari yang muncul di bawah. Untuk meninjau, buka file di editor yang menampilkan karakter Unicode tersembunyi. Pelajari lebih lanjut tentang karakter Unicode dua arah Tampilkan karakter tersembunyiSekarang izinkan saya menjelaskan bagaimana segala sesuatunya bekerja. Saya menggunakan alat yang disebut memadai (yang merupakan alat pemeriksaan paket Debian) saat menginstal paket. Saya akan membicarakannya secara mendetail di beberapa posting blog mendatang.
Apa yang Reportbug lakukan adalah mendapatkan dan mengurai semua informasi yang dimilikinya tentang paket tersebut sehingga ia tahu apakah akan melanjutkan atau tidak.
Sekarang, alat yang memadai berjalan di latar belakang sepanjang waktu. Salah satu pekerjaan utamanya terjadi tepat di akhir instalasi paket, misalnya. untuk piuparts ia membagikan/menunjukkan ini kepada saya –
adequate found packaging bugs
-----------------------------
piuparts: obsolete-conffile /etc/piuparts/scripts/post_setup_experimental
yang memberi tahu saya bahwa paket piuparts memiliki conffile yang sudah usang. Conffile adalah singkatan dari File konfigurasi.
Jadi perintah pertama yang saya lakukan setiap kali saya menemukan bug yang layak dilaporkan adalah saya melakukan ini –
reportbug piuparts --severity=normal
Memberi/memberi tahu tentang paket yang bermasalah, dalam hal ini piuparts.
Menempatkan keparahan pada bug apa pun adalah bisnis yang rumit. Kecuali jika saya memiliki perasaan yang cukup kuat tentang sebuah paket dan yakin bahwa bug tersebut memang parah, saya tidak akan meningkatkan keparahannya. Ini adalah etika pribadi saya sendiri, juga sedikit kurang bekerja untuk seorang pengelola.
Dikatakan demikian, sebagian besar pengelola akan melihat bug terlepas dari tingkat keparahan apa pun yang Anda berikan. Saya memiliki pengelola yang menanggapi saya dengan cepat bahkan ketika saya telah mengajukan bug daftar keinginan dan pengelola tidak kembali. MIA (Missing-In-Action) bahkan setelah mengajukan bug parah. Mengarsipkan dan melakukan percakapan yang sehat dengan pengelola adalah aktivitas teknis dan sosial.
Setelah menanyakan subjek, reportbug bertanya/memberi berbagai pilihan jika salah satu syarat berlaku. Anda dapat menggunakan apa saja jika menurut Anda bug Anda terpengaruh atau memengaruhi salah satu hal di atas dalam daftar. Misalnya jika Anda akan membagikan tambalan untuk memperbaiki masalah, Anda akan memilih 6 atau salah satu dari yang lain. Jika tidak ada yang diperlukan, cukup Masuk dan lanjutkan.
Setelah hal di atas selesai, perlu beberapa saat dan kami mendapatkan sesuatu yang mirip dengan inti yang dibagikan ini:
File ini berisi teks Unicode dua arah yang dapat ditafsirkan atau dikompilasi secara berbeda dari yang muncul di bawah. Untuk meninjau, buka file di editor yang menampilkan karakter Unicode tersembunyi. Pelajari lebih lanjut tentang karakter Unicode dua arah Tampilkan karakter tersembunyiNow what this does is, it gives an idea to the maintainer of the state of your system. As you all know, almost all GNU/Linux distributions and the packages therein are based on a complex set of relationships with other packages. The maintainer needs to know what version of the package you were using, which other packages were there, what version were they at, apart from knowing that the integrity of the package hasn’t been tampered with in any way.
Now you need to fill in the banks –
I usually remove/delete cut the following, if you are a new user you could just answer the questions below and your bug report would be ready.
Step 7. The final changes made to spend the report
And in its place, I put the details as being shared right here:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters Show hidden charactersSubject:piuparts:adequate reports obsolete conffile for piuparts | |
Package:piuparts | |
Version:0.75 | |
Severity:normal | |
User:[email protected] | |
Usertags:obsolete-conffile adequate | |
Dear Maintainer, | |
Adequate reports broken obsolete-conffile – | |
[$] adequate piuparts | |
piuparts:obsolete-conffile /etc/piuparts/scripts/post_setup_experimental | |
Maybe you could use what pabs (Paul Wise) did in #815563, in that the | |
proper thing to do would be – | |
Use the dpkg-maintscript-helper support provided by dh_installdeb to remove such similar obsolete conffiles on upgrade | |
Also https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files | |
You can also see manpage of dh_installdeb via debhelper package which is the same thing. | |
I ran the same command as he did – | |
[$] pkg=piuparts; adequate $pkg; dpkg-query -W -f='${Conffiles}\n' $pkg | grep obsolete | |
piuparts:obsolete-conffile /etc/piuparts/scripts/post_setup_experimental | |
/etc/piuparts/scripts/pre_remove_40_find_obsolete_conffiles | |
dce83ee504ba336d8a2930fb6053635c | |
/etc/piuparts/scripts/post_setup_experimental | |
f7a1f3d45dc43106d1cd9b124b7c1ca8 obsolete | |
Please fix the above. | |
— System Information: | |
Debian Release:9.0 | |
APT prefers testing | |
APT policy:(600, 'testing'), (500, 'unstable-debug'), (500, | |
'testing-debug'), (1, 'experimental-debug'), (1, 'experimental'), (1, | |
'unstable') | |
Architecture:amd64 (x86_64) | |
Foreign Architectures:i386 | |
Kernel:Linux 4.9.0-1-amd64 (SMP w/2 CPU cores) | |
Locale:LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) | |
Shell:/bin/sh linked to /bin/dash | |
Init:systemd (via /run/systemd/system) | |
Versions of packages piuparts depends on: | |
ii debootstrap 1.0.87 | |
ii debsums 2.2 | |
ii dpkg 1.18.18 | |
ii lsb-release 9.20161125 | |
ii lsof 4.89+dfsg-0.1 | |
ii piuparts-common 0.75 | |
ii python-debian 0.1.30 | |
pn python:any | |
Versions of packages piuparts recommends: | |
ii adequate 0.15.1 | |
Versions of packages piuparts suggests: | |
ii schroot 1.6.10-3 | |
— no debconf information |
Some more info. now – These two tags signal/tell the maintainers few things –
User: [email protected]
The first tag is signaling that the bug being raised is part of debian-qa efforts.
Usertags: obsolete-conffile adequate
The second tag is telling the tool we have used and one of the common issues under which it has come -in this case obsolete-conffile.
There are few common and uncommon use-cases that adequate looks into. As shared before, will need another blog post to share about it in detail.
The other thing I’m telling/sharing the maintainer is s/he should be looking into debhelper (a toolkit for debian/rules) and to look for specific bits therein.
Tip – Paul Wise, better known as pabs in Debian community. He is a prolific contributor to Debian. As you can see from his wiki page and the secondary apps. He always has a never-ending list of applications, packages that would be interesting to package alongwith things that could be/need to be improved. I dunno if he has done any mentoring or not, do see signs of a good and goofy mentor in him. I sometimes ask, sometimes steal his ideas to help in Debian QA :)
Now, that the bug-report is complete, I have to send it via gmail.com . If you have enabled MTA (Mail Transfer Agent) and don’t have a gmail.com you can just send and it will be done. If on the other hand, you haven’t enabled MTA (like me) and like to do things yourself, log on to your gmail account, hit compose and then –
Step 8. The final step
To - [email protected]
Subject - piuparts: adequate reports obsolete conffile for piuparts
Body of your mail should start with Package
something like this –

You might have noticed some labels, they are just to help me be somewhat organized as after you have reported some bugs it can become chaotic to know what’s going on. Gmail’s labels and filters make things somewhat sanish with the amount of mail I receive.
At that point, make sure to recheck the mail once more before clicking the send mail button. I usually click on save draft, review it once or twice before sending it over.
If you are satisfied click send and your bug-report will be sent to Debian BTS .
Step 9. Getting acknowledgment from Debian BTS server saying the bug has reached them.
Usually, within minutes I get a short acknowledgment mail from the Debian BTS, like in the gist being shared
Look at the time-stamp given, just 3 minutes apart from when the mail was sent. I sent the bug mail on 05:03 and got the automated reply saying everything went fine on 05:06 itself.
What I look for into the acknowledgment mail is the bug number as that is how I come to know how things are going with the bug. #854317
Post bug-reporting cycle.
Coincidentally, as can be seen, the package maintainer somehow was around the time when I filed the bug. I do know the importance of piuparts in the debian ecosystem but I didn’t think Andreas will act so quickly, so now probably the next point release or even bug-fix release will have the fix. As can be seen though, Andreas seems to be a busy bee seeing the number of packages he’s maintaining/co-maintaining, besides uploading Non-Maintainer Uploads (NMU) and QA uploads.
I hope I have given enough insight so you know what to do as and when things go wrong.
Tip – Nowadays, I usually follow couple of rules before filing a bug. First check the bts for existing list of bugs, for e.g. piuparts bugs page (as also shared by Simon Tatham above). If the bug is not listed there, more often than not, it the package has not too many dependencies, and I know there aren’t any configuration files that I might have to recreate then I usually purge the package and install the package afresh. If adequate still finds a fault, I usually report it. I don’t do that though for obsolete conffiles as they usually happen when you are upgrading from version x.1 to x.2 or something like that.
Using such simple tips I save time and energy for myself as well as the maintainer of a package.
At first, it may take sometime, after a while, the whole thing may take 10-15 minutes or even less, depending on the package in which the bug is found, the bug itself, replication of the bug etc.
That’s about it to make a bug-report in Debian using Reportbug.
Hopefully, you have gotten some idea the steps to finding bugs and reporting them. Please post any queries you have in the comments below and I’ll try my best to answer/share whatever little I know.