=== ompaul changed the topic of #ubuntu-classroom to: Ubuntu Open Week | Information and Logs: https://wiki.ubuntu.com/UbuntuOpenWeek | How to ask questions: https://wiki.ubuntu.com/UbuntuOpenWeek/Rules | Ask questions in #ubuntu-classroom-chat, prefaced with "QUESTION:" |See https://wiki.ubuntu.com/UbuntuOpenWeek/JoiningIn to filter out channel noise | Next up: Unwinding Stacktraces - Emmet Hikory (15:00, UTC) [16:00] Ok, let's get started [16:00] welcome back everyone to the last day of OpenWeek [16:00] thanks for coming out on a Saturday! :) [16:00] The last set of sessions are listed here: [16:00] https://wiki.ubuntu.com/UbuntuOpenWeek/ [16:00] First up we have Emmet Hikory with "Unwinding Stacktraces" [16:00] persia: take it away! [16:01] Welcome to Unwinding Stacktraces. [16:01] The intent of this discussion is to describe a stacktrace, explain how to find bugs with stacktraces, and walk through the process of investigation to be able to find (and fix) the bug. [16:01] Feel free to interrupt with specific questions or requests for clarification at any time, and there will be a more general question period at the end. [16:02] As a program executes, it typically involved calling some sequence of functions, each of which will call further functions, and so on. [16:03] The current state of the running program is stored in the stack, and a stack trace is simply a dump of all the information in the stack at the time the trace is taken. [16:03] For the interesting stacktraces, this is usually the point at which the program crashes, but it can be any point. [16:04] s an example, at the point where we print the second 'l' in the following simple program: int main() { printf("Hello World\n"); } the stack consists of three interesting frames (and some initialisation) [16:04] At the top (#0), we have the actual character display, with a local variable holding 'l'. [16:04] The next frame (#1) is printf(), with the local variable "Hello World". [16:04] The third (#2) is main(), with no local variables, reprenting our program. [16:05] A more complex example may be found from http://launchpadlibrarian.net/9409147/Stacktrace.txt, which is a crash in w3m: a text-mode browser. [16:06] As you can see, this stack is a little longer, as w3m is a bit more complicated than the previous example. [16:06] Also, this stacktrace represents a real crash, so instead of knowing we are at 'l', we have to discover our location. [16:07] < wolfger> QUESTION: for us noobs, how is a stack trace taken? [16:07] I find it easiest to read these from the bottom, as this goes from the general environment (starting the program), and becomes more specific. [16:07] wolfger: The common way to take a stacktrace is within GDB, although in Ubuntu the apport tool helps generate them for bug reports. [16:08] I'll talk a little about apport later, but https://wiki.ubuntu.com/Backtrace provides a quick guide to doing it manually. [16:09] < BonesolTeraDyne> QUESTION: Is a stacktrace the same as the backtrace that the KDE crash handler gives? [16:09] BonesolTeraDyne: I'm not actually familiar with the KDE crash handler, but I expect that if it's not the same, it's very close. [16:10] So, looking at the w3m example, from the bottom, we can find out what is happening. I've not looked closely at the w3m code, but the following would be my guess: [16:10] At frame 15, the program is trying to start [16:10] At frame 14 glibc is processing the start request [16:11] At frame 13, the main() function starts, and we're in the code [16:11] At frame 12, it calls a function to load a file, so I'm guessing this is opening a local file on the machine [16:11] At frame 11 is calls "loadSomething", which is probably a generic helper function for the file load [16:12] At frame 10, it appears to have discovered this was an HTML file, and so is loading HTML [16:12] At frame 9, it is processing the HTML data as a data stream [16:12] At frame 8 it is processing a single line of the data [16:13] At frame 7, it seems to be processing a table [16:13] (At this point, we can say "Aha!", as while it's obvious a browser would be reading HTML, it being a table tells us more specifically where the problem is happening) [16:14] Frames 6, 5, 4, and 3 appear to be more table calls. Maybe it's nested tables, or maybe the code is just highly recursive. Determining which usually means reading the code or the data. [16:14] Frame 2 appears to be rendering an image within the table [16:14] Frame 1 appears to be handling the description of the image [16:15] And frame 0 crashes with the call to Strnew_size with the passed argument of (n=256). [16:15] From this, we can safely say that w3m has crashed while processing an image nested in a table, which is a lot more information then we had before. [16:17] < wolfger> QUESTION: how did we determine that about Frame #1? That step lost me [16:18] wolfger: I guessed it based on the local variables. I could be completely mistaken: to check for sure, one should check the code of w3m around line 2917 of file.c. [16:19] The part that makes me think it is related to handing the various attributes of the image is all the local variables (anchor, img, bold, etc.). [16:21] if one is using a stacktrace to debug something, one will likely pass back and forth over two or three frames, most commonly #0 - #2, but sometimes as high as #50 (if the program is compiled against a library with extensive internal signal handling, such as GTK+2) [16:22] From the point of view of getting an idea of what is happening, the specifics right near the problem aren't as important, as one will want to look at the code: it's mostly a matter of seeing how far one can get towards #0 before getting lost to save time in reviewing it. [16:23] So, in Ubuntu, the majority of stacktraces available for analysis are provided in launchpad by Apport. The apport tool captures the results of every program crash on every user's workstation, and offers the opportunity for the user to report the crash back to Ubuntu. [16:24] This is paired with the apport retracing service which processes these crash reports, and generates the nice stacktraces with the symbol names, and the line numbers of the corresponding code. [16:24] At some point in the apport process, the apport-crash tag is typically added to the bug, so that looking through all the bugs with the apport-crash tag is often a good way to find stacktraces. [16:25] This list is most easily accessible from the Tags list on https://launchpad.net/ubuntu/+bugs [16:25] When reviewing this myself, I tend to skip down until I find a package a use a fair bit, as it's a lot easier to understand a problem with a program that one uses than with a program one has to learn at the same time one is debugging. [16:26] The reports will have several different attachments that may be useful in understanding the problem, but the "Stacktrace.txt (retraced)" is typically the right one to review. [16:27] In cases where there are multiple threads and may be timing issues or interthread communication issues, the "ThreadStacktrace.txt (retraced)" may also be useful, but most of the time even when one reviews this, the problem is actually in Stacktrace.txt. [16:29] That about covers the definition, reading, and availability of stacktraces. Are there any questions about these before we look at a debugging example? [16:30] Great then! [16:31] So, I've picked one I did before to look at, specifically that the hydrogen frun machine crashed when a certain (broken) drumkit was used. This was bug #147476, and the Stacktrace is available from http://launchpadlibrarian.net/9612459/Stacktrace.txt [16:31] < bran_damage> QUESTION: Are the stacktraces similar no matter what language the code was written in ? [16:32] bran_damage: Typically, although they may look a little different. [16:33] In an interpreted language like python, the symbols are typically available at runtime, and so the trace can be presented to the user directly. In a compiled language like C, the symbols are typically opimised out, so the stacktrace has to be retraced to make sense. [16:33] An unretraced stacktrace looks like http://launchpadlibrarian.net/9032770/Stacktrace.txt [16:34] While the codes are meaningful with the debug symbols, without them, the function names are unknown, and the locals are hidden. [16:36] Going back to hydrogen, and the process of looking at a stacktrace for debugging. [16:37] I usually start around frame #3 or #4, unless it's a lot of signal handlers, in which case, I'll keep going back until I get to some function that looks like it was written for the program that crashed. [16:38] For this stacktrace, the mouse movement handling around frames 7&8 provide a nice boundary: anything earlier than this is the user doing something else, not likely related to the crash. [16:39] Also, a stacktrace doesn't actually keep a history of what was done, but only the nesting of function calls, so there's not enough information about what else the user did with the mouse before clicking on the button at 0x107bd40 at frame 7. [16:41] Frames 5 & 6 look like the callbacks to handle the mouse click, and frames 3&4 look like some QT function to call the actual handler for the button click (and here, I'm just guessing based on the name: if you're unsure, it's always safe to check the code) [16:42] This takes us to Frame #2 which is pretty clearly the loader that handles the loadDrumkitBtn click. [16:45] When debugging, you'll want to get an idea of the context for the local variables. In this case, we're looking around line 168 of DrumkitManager.cpp (available from http://paste.ubuntu.com/9766/ for those without source handy) [16:46] Now since frame #1 is in the Hydrogen::loadDrumkit function, it's actually line 167 of the pastebin. [16:46] Looking at what happens previously in this function, we can see that some name gets set (line 160) [16:46] It does a loop over the list of drumkits [16:47] Compares the selected name to each of the names [16:47] When it matches, it sets a cursor to tell the user to wait, and calls loadDrumkit, passing the information about he drumkit from the drumkit list. [16:49] Going back to the stacktrace, the intersting parts are drumkitInfo and sselectedDrumkitName, which are the defined local variables. Since this matches what we see in the code, and nothing is obviously wrong, we go to the next frame. [16:49] (code for this is available from http://paste.ubuntu.com/9756/ ) [16:50] Here, we're looking at the function starting at line 2469 [16:51] Going down, it crashes at an assignment, which ttrial and error showed to be line 2494. [16:51] Now, any questions about comparing the code and the stacktrace to debug a problem? [16:52] no questions so far [16:54] Well then, a few random notes, before we're out of time (but please interrupt if you have a question). [16:54] I find it typically takes an hour or two to go through a stacktrace carefully, and figure out the problem in the code. The first few can take longer. [16:56] Also, sometimes the code is in a language that you might not know well. Don't worry about this: it's better to get a rough idea of what is happening. Even if you can't figure out how to fix it, being able to pinpoint the problem (it crashes at this point, and I think it's because this variable didn't get set the way we wanted), can help someone who does know that language to fix it, [16:57] Most of all, be confident, and make a lot of guesses. As the stacktrace shows each line of code, and each function called, it's hard to get lost, even if you guess wrong, but there's usually more detail than you need. [16:58] Anyway, thanks for attending. Enjoy the other sessions today, and I'll hope to see you in #ubuntu-bugs or #ubuntu-motu looking at stacktraces and fixes for crashes. [16:58] thanks persia! === jcastro changed the topic of #ubuntu-classroom to: Ubuntu Open Week | Information and Logs: https://wiki.ubuntu.com/UbuntuOpenWeek | How to ask questions: https://wiki.ubuntu.com/UbuntuOpenWeek/Rules | Ask questions in #ubuntu-classroom-chat, prefaced with "QUESTION:" |See https://wiki.ubuntu.com/UbuntuOpenWeek/JoiningIn to filter out channel noise | "Virtualization" Soren Hansen [16:59] Next up will be a hot topic lately, Virtualization with Soren Hansen! [17:00] In about 1 minute. :D [17:01] soren: take it away! [17:02] hmm, let's give him a few minutes [17:07] Ok, we're texting soren, thanks for being patient! [17:10] Ok, soren is on his way! [17:11] o/ [17:11] Sorry, guys! [17:11] I was sure it wasn't for another two hours. [17:11] No worries! [17:11] Ok... Hi, everyone. [17:11] I'm Soren Hansen, and I work for Canonical as virtualisation specialist. [17:12] Er.. [17:12] This caught me a bit off guard :) [17:12] Are there any questions already or should I just talk about stuff? [17:13] I guess not. [17:13] Well, I can tell you what Ubuntu is focusing on and has focused on for Hardy. [17:14] I think we're the first major distro to put out a major release with a virtualisation solution based on kvm. [17:14] KVM is a modular hypervisor that runs in the linux kernel. [17:15] It's in the official kernel tree, and is very well-maintained. [17:15] Real quick soren, can you explain virtualization, hypervisor, and KVM? [17:15] KVM relies on the presence of the virtualisation extensions that are found in recent processors from both AMD and Intel. [17:16] jcastro: Ah.. Right :) [17:16] Virtualisation is not as well-defined as one would have hoped. [17:16] The easiest way to think of it is "some method for running many operating systems on just one machine at the same time". [17:17] That's a rather broad definition, though. [17:17] You can divide virtualisation into various categories.. [17:17] There's containers, such as openvz and linux vserver. [17:18] They basically allow you to have process running in a completely separate namespaces, thus separating the completely from one another. [17:18] Then you have paravirtualisation. [17:18] This is stuff like Xen. [17:19] The idea is that instead of exposing what looks like a regular PC as we all know it, it exposes a different interface, on top of which you can run e.g. a specialised linux kernel. [17:20] The there's full virtualisation. [17:20] This is stuff like KVM and QEmu. [17:20] The idea here is that run unmodified operating systems inside of it. [17:21] To accomplish this, the virtualisation technology must make it looks exactly as though it's a regular PC. [17:21] ...just like the one you've got under your desk. [17:22] There are variour variations of these things, but that's basically the gist of it. [17:22] A hypervisor is the bit of magic that makes this all possible. [17:23] It's the "thing" that takes care of assigning resources to guest operating systems and such. [17:24] I say "thing" because it's can be implemented in different ways. Xen works by booting a completely different system from the start and then you run Linux on top of it. (sort of) [17:24] KVM works by loading a module in your regular system, which makes userspace processes able to use the virtualisation extensions in the CPU. [17:24] So in this case, the hypervisor is the kernel module and the kvm userspace process. [17:25] < highvoltage> QUESTION: Does that mean that KVM won't run on any of the older CPUs, like Qemu did? [17:25] Short version: Yes. [17:26] One thing to remember is that the percentage of machines that can't use kvm is constantly dropping. [17:26] ..and due to this hardware requirement, KVM's design is very simple compared to most alternatives. [17:27] < Toadinator> QUESTION: could you explain the benefits of virtualization to someone who doesn't run a virtual machine? [17:27] Sure. [17:27] Hardware is cheap these days. [17:27] Most of the time, you fill up your data centers with the monstrous machines. [17:28] If you run some form of virtualisation on top of that, you can have many separate operating systems running. [17:29] If, some day, these virtual machines start to max out the server, all you need to do is migrate the virtual machine off to another physical machine. [17:29] The virtual machine still sees the same hardware, so there's no reconfiguration to be done in the guest. [17:30] The process of moving it is a simple matter of either copying a few disk images (regular files) ove rto another machine, or if you have some form of shared storage, you can just move the virtual ram over to another box and it can keep running there. [17:30] I've heard people suggest it used as a power saving mechanism. [17:31] Your servers are much busier during the day than they are at night, so at day, your virtual machines can be running on 200 servers, but at night you move them onto perhaps 25, and shut the other 175 down and save loads of power. [17:31] ..and the rain forest. [17:31] :) [17:31] The possibilities are endless. [17:32] On your desktop, you can use virtualisation to run other operating system for testing or for that last application under Windows you just can't live without. [17:32] < chell> QUESTION: what exactly does he mean by running a process in a different namespace? what kind of namespaces are we talking about here? [17:32] Containers are sort of an extended version of a chroot jail. [17:33] If you're in a chroot jail, device nodes, memory usage, processes are still the same as it is outside the chroot. [17:33] Inside a container, you can't see processes from other containers, you can't access their device nodes, etc., etc. [17:34] < chell> Question: so KVM is a program like vmware or virtual box? [17:34] Yes, kvm is very much like those. The differences are that it's completely free and maintained in the mainline linux kernel. [17:35] < smeg0l> QUESTION i find qemy very heavy what other alternatives do i have that wil run on hardy heron ? [17:35] QEmu is very heavy indeed. [17:35] Emulating a CPU is a very heavy process. [17:35] KVM uses parts of QEmu, but not the cpu emulation parts. [17:36] We also have virtualbox and Xen in universe and vmware server runs, too, so there are plenty of options. [17:36] We've just chosed to focus mostly on Xen. [17:36] Er.. [17:36] Damn, I did not just say that. [17:36] I meant, of course, that we've chosed to focus mostly on kvm. [17:37] QUESTION: does virtualization let the guest OS see your BIOS? I ask because I have a vista Express upgrade DVD which will only install in a virtual machine on THIS machine (the one it was distributed for)[D [17:37] No, that's the entire point of virtualisation. The virtual machines don't see your hardware. [17:37] < smeg0l> QUESTION what vitual maniger would cause the least trouble ? [17:37] I don't understand the questin. [17:38] < Salumu> QUESTION: How does hypervisors manage to run system calls from the applications in the virtual guest OS? [17:38] This is where Xen and kvm differ very much. [17:38] Well, one of the places, anyway. [17:38] System calls in Xen are translated to hypercalls to the hypervisor. [17:39] In Kvm guests, you're running a regular linux kernel. It turns into CPU instructions which the hypervisor execetes on the host CPU (expect for privileged instructions, which are trapped and handled differently). [17:40] < DoruHush> QUESTION: What other requirements have to be mentioned beside the processor? [17:40] Nothing, really. [17:40] If your processor has the magic stuff and your bios doesn't block them, then you're set. [17:41] Flyser> QUESTION: Can we expect a stable KVM release some day? (if yes, when? ^^) [17:41] I'm not sure what you mean by a stable KVM release. [17:42] The KVM in Hardy is rather stable. It's been working for a quite a few people with different use cases. [17:42] highvoltage> QUESTION: How stable is KVM compared to VMWare and Xen, and how does it compare performance wise? [17:43] KVM as achieved massive results in a very short time. It's already very stable for a lot of different work loads and I'd say it's a strong competitor to Xen. [17:43] I can't speak much of VMWare. I've not used it in any serious settings (only for small case testing on my desktop). [17:44] < smeg0l> QUESTION what vitual manager would cause the least trouble ? [17:44] I don't understand the question. [17:45] tzeentch_> QUESTION: Why the focus on KVM? What advantages does it have over VirtualBoxOSS or Xen? Do you think Xen couldn't be wrapped up to provide easy to use virtualization solution? [17:45] KVM as much, much simpler than Xen. [17:45] It's actually something that we can reasonable maintain and support. [17:45] Xen has famously been rejected by the linux kernel developers on several occasions. [17:46] One of the primary reasons we didn't choose virtualbox is the lack of headless support in the free version. [17:47] The non-free version offers an RDP server, so it's actually usable in server settings (which was our focus). [17:47] Also, virtualbox is not in mainstream Linux. That really, *Really* means a lot. [17:47] QUESTION: Do you know of any large uses of virtualisation, running on Ubuntu? [17:48] Well, Hardy is the first release where it's a major feature, and Hardy's still quite young. [17:48] Nevertheless, I do know of a rather large installation, but I'm not sure if I'm at liberty to tell you about it :/ [17:49] < bran_damage> QUESTION: Soren .. so I have hardy, I have AMD64 with VM extensions ... now what ? What do I do to get KVM running [17:49] The easy way: [17:49] sudo apt-get install kvm virt-manager libvirt-bin [17:49] sudo adduser $USER libvirtd [17:49] (log out, and log back in) [17:49] virt-manager -c qemu:///system [17:50] That'll give you a nice, graphical interface for managing your virtual machines. [17:50] highvoltage> QUESTION: how scriptable is KVM? can I suspend it on host shutdown and start it again when the host starts? [17:50] Yes, you can do that rather easily. [17:51] It's recommended to use libvirt to manage your virtual machines, and if you do so, it's a simple matter of "virsh save name-of-domain saved.img" and then "virsh load saved.img", when you're back up. [17:51] < smeg0l> QUESTION which virtual manager is the most userfriendly ? [17:51] What do you mean by virtual manager? [17:51] Do you mean hypervisor? [17:52] If so, it's a matter of taste, I think. [17:52] tip: screenshots of virtual manager: http://www.phoronix.com/scan.php?page=article&item=983&num=1 [17:52] VMWare server is still a bit ahead of virt-manager in many respects. [17:52] VirtualBox, too. [17:52] ...but the libvirt/virt-manager combination is really starting to shine, and it offers excellent scriptability, which is a major userfriendliness factor for me. [17:53] Oh, I forgot part of this question: [17:53] < ~tzeentch_> QUESTION: Why the focus on KVM? What advantages does it have over VirtualBoxOSS or Xen? Do you think Xen couldn't be wrapped up to provide easy to use virtualization solution? [17:54] Anything's possible, but I'm very happy indeed that I don't need to support and maintain a Xen kernel for 5 years. [17:54] We're starting to run out of time, can you tell everyone about ubuntu-vm-builder after this question? [17:54] livirt can manage Xen instances, too, so the userfriendliness can be about the same (from the user's POV). [17:55] jcastro: Oh, sure. [17:55] ubuntu-vm-builder started out as a bit of a pet project for me. In short, it's a script that creates an Ubuntu based virtual machine. [17:56] It doesn't go through the regular installer, it doesn't even use any virtualisation technology. [17:56] ..so it's really fast. [17:56] I've built ubuntu virtual machines in less than 45 seconds. [17:56] More info here: https://help.ubuntu.com/8.04/serverguide/C/ubuntu-vm-builder.html [17:57] If you have further questions, #ubuntu-virt is the channel for virtualisation in Ubuntu. Feel free to stop by any time. [17:57] thanks Soren! [17:58] Thanks for stopping by, everyone! [17:58] And sorry again for being late :( === jcastro changed the topic of #ubuntu-classroom to: Ubuntu Open Week | Information and Logs: https://wiki.ubuntu.com/UbuntuOpenWeek | How to ask questions: https://wiki.ubuntu.com/UbuntuOpenWeek/Rules | Ask questions in #ubuntu-classroom-chat, prefaced with "QUESTION:" |See https://wiki.ubuntu.com/UbuntuOpenWeek/JoiningIn to filter out channel noise | "Reporting Bugs" - Brian Murray [17:58] ok, next up is Reporting Bugs with Brian Murray [17:59] this session was done on Monday but we scheduled one today to get maximum participation! [17:59] Hi, I'm Brian Murray and I'm Ubuntu's bug master. [18:00] I'm here to talk today about how to report bugs about Ubuntu as there are various ways you can do it. [18:00] Additionally, I'll cover how to make your bug report more complete and therefore more likely to get fixed! [18:00] Perhaps you are wondering what exactly is a bug? [18:01] In computer software it is an error or a flaw that makes it behave in ways for which it wasn't designed. [18:01] Some of these can result in crashes, others may have a subtle effect on functionality, others can be spelling errors. [18:01] By reporting these issues you can help to make Ubuntu even better than it already is. [18:02] Reported bugs are kept in Launchpad, the bug tracking system used by Ubuntu. [18:02] Let's look at a sample bug report - http://launchpad.net/bugs/222278. [18:03] There are 4 things there that I want to point out. [18:03] 1) The bug's title or summary is 'upgrade hanges in checkViewDepends()' [18:04] 2) In the affects table, below the title, you'll see that this bug report affects 'update-manager (Ubuntu)' [18:04] This is the package / application which the bug is about [18:04] 3) Below that is the bug's description, labelled "Bug description" ;), which is filled out when you are reporting a bug [18:05] 4) You'll also notice that there are 5 comments, 4 of which contain attachments with supporting information about the bug. [18:05] So, that's what a bug report looks like. Are there any questions about the format of a bug report or what a bug is? [18:07] < wolfger> QUESTION: if something is behaving as designed, but we don't like it, is it bug report material? [18:08] Yes, that is a valid bug however it is ultimately up to the developers of that particular piece of software whether or not they will fix it. [18:09] < smeg0l> QUESTION when do determine if it's a hardware faily or a bug ? [18:10] Determining whether or not a bug report is due to faulty hardware can be quite tricky. [18:11] Most of those bug reports would be about the kernel and by looking at kernel log files we can help you determine whether or not it is a hardware or software issue. [18:11] Moving on - How can bugs be reported to Launchpad? [18:12] They can be reported via the web interface at https://bugs.launchpad.net/ubuntu/+filebug where you start by filling out the summary which becomes the bug's tile. [18:12] After which you are asked for the package affected and for 'Futher information' which becomes the bug's description. [18:12] The description should contain at a minimum the following: [18:13] 1) The release of Ubuntu that you found the bug in. [18:13] This is important as there is more than 1 supported release of Ubuntu out there right now. [18:13] 2) The version of the package you found the bug in. [18:14] 3) The behaviou that you expected to happen [18:14] and 4) What happened instead [18:14] You also have the opportunity to add an attachment to your bug when you are reporting it via the web interface. [18:15] Another way to report a bug is using apport an automated problem report application included with Ubuntu. [18:15] The advantage to using apport is that it automatically collects information about the release of Ubuntu you are using and the version of the package / application that you are reporting the bug about. [18:15] Let's say that you have encountered a bug with Firefox. [18:15] You can use apport to report the bug by going to Firefox's "Help" menu and choosing "Report a Problem". [18:16] Apport will start collecing information about your bug and then open a new window where you enter the bug's summary / title and then enter the bug's description. [18:17] Let's look at a bug reported using the "Report a Problem" menu item [18:17] http://launchpad.net/bugs/223455 [18:17] At the bottom of the description you'll see information regarding the DistroRelease, the package and version, and kernel version among other things. [18:18] All of this information is gathered for you automatically. [18:18] The "Report a Problem" functionality has been integrated into lots of applications and is the preferred way to report a bug. [18:19] Additionally, apport has a command line interface, called apport-cli, where you can report a bug about a specific package via 'apport-cli -f -p PACKAGE' which is useful for non GUI applications. [18:19] Additionally, you can also specify a process id number via 'apport-cli -f -P PID'. [18:19] Further information about reporting bugs can be found at https://help.ubuntu.com/community/ReportingBugs [18:20] Are there any questions about how you can report a bug? [18:21] < lyzium> Question: can apport initialise outside given example. If firefox crashes on start you are unable to launch the "report a problem" option [18:21] In that case you could use apport-cli -f -p firefox-3.0 for example [18:22] Also when you are running a development release of Ubuntu apport will watch for application crashes and report those [18:23] < Lardarse> QUESTION: Do you find that the differences between the developer's definition of a bug (to quote you: "an error or a flaw that makes it behave in ways for which it wasn't designed") and the end-users definition (to word it in the same way, it's usually something along the lines of "an error or a flaw that makes it behave in ways that don't make [18:23] sense") cases problems for you and for lthe other people inv [18:24] Ubuntu is designed for "human beings" and if an application behaves in a way that doesn't make sense then their is something wrong. [18:25] Possibly there is a bug in the documentation or the software's description. [18:26] That bug report won't have as a high of priority as a crash report or other bugs but it still is a valid bug. [18:26] So how can we make our bug reports more useful for developers? [18:26] Choosing the name of the package or application the bug is about is critical. [18:27] If a bug does not have a package assigned to it is much less likely to get looked at by anyone let alone the developer of that application. [18:27] Some helpful hints for finding the proper package are at https://wiki.ubuntu.com/Bugs/FindRightPackage [18:27] This page also contains the names of packages that might be hard to discover. [18:27] For example, bugs about the kernel in Hardy Heron should be reported about the 'linux' package. [18:28] Additionally, members of the Ubuntu bug squad are available in the #ubuntu-bugs cahnnel if you need help identifying the proper package. [18:29] After the bug is reported in Launchpad an important part of its life cycle is it entering the Confirmed status. [18:29] Pedro will talk about this more in the next class, but when a bug is Confirmed it means that someone has been able to recreate the bug or believes sufficient information has been included in the bug report for a developer to start working on it. [18:29] Any Launchpad user can confirm a bug report, but please don't confirm your own! [18:30] This will make the Confirmed status less useful. [18:30] What this means is that you should include extremely detailed steps to recreate the bug in it's description so anyone, not just a developer, could confirm it. [18:31] Let's take OpenOffice for example, there are phenomenal amount of things you can do in the Word Processor or the Spreadsheet parts of it. [18:31] And not every bug triager may now all the intricacies of that application. [18:32] So by putting extremely detailed steps in your bug report you are increasing the chances of it being confirmed. [18:32] It is far better to have too much detail than not enough! [18:33] Some fairly simple things you can do to make your report easier for someone to confirm are including a screenshot. [18:33] Or you can create a screencast, a movie of your desktop, using an application like istanbul. [18:34] Let's take a look at http://launchpad.net/bugs/212425 [18:34] This bug has a screencast attached to it [18:35] Their description of how to reproduce the bug is pretty good but is a little hard to understand [18:36] By watching the screencast though, bug triagers are able to clearly see what steps we should take to recreate the bug. [18:37] Are there any more questions at this point in time? [18:38] < BonesolTeraDyne> QUESTION: Are there any plans to make a KDE version of Apport, or to at least give the KDE crash handler some sort of LP integration? [18:40] There are some crash reports about KDE applications reported by apport. [18:41] In regards to integration with the KDE crash handler, I'm not certain but will look into it. [18:42] One of the best ways to make your bug report more likely to be fixed is to follow the debugging procedures for the package or subsystem your bug is about. [18:44] Bug triagers and software developers have written up a variety of these debugging procedures. [18:44] A list of them can be found at https://wiki.ubuntu.com/DebuggingProcedures [18:46] If you look at the debugging update-manager page - https://wiki.ubuntu.com/DebuggingUpdateManager [18:47] You'll see there is a how to file section, there we have instructions about which log files we need if your bug is about upgrading from one release to another [18:47] Providing information like that makes your bug report much more complete [18:49] And a bug report with more relevant information is more likely to get fixed! [18:49] QUESTION: If you wanted to report a bug, but are unsure what the bug is for (ex: it could belong to one of many programs) how would you know what package to file it under? [18:50] Toadinator: early I mentioned the wiki page https://wiki.ubuntu.com/Bugs/FindRightPackage [18:51] This contains some high level information about when an application is running [18:51] For example when your system boots and you see the "Ubuntu" logo that is the usplash package [18:52] Also printing bugs should generally be reported about cupsys and then they will be moved to the proper package if necessary [18:53] Additionally, there is information about how to find out what application an open window belongs to [18:53] < gscholz> QUESTION: Coming back to apport, how do you include the functionality into an applications menu (report a problem)? Do you write a patch against the source code? I guess these are no upstream features, or is this a kind of generic GNOME functionality? How do you select the applications worth this feature? [18:55] The functionality of apport is integrated into an application via the package 'liblaunchpad-integration1' [18:56] And I'm fairly certain this is a patch that Ubuntu carries for the package with that integration [18:56] Any more questions? [18:58] Okay, then thanks for coming to the class on How to Report bugs [18:58] If you need any help reporting a bug please come to the #ubuntu-bugs channel on freenode [18:58] Thanks! === jcastro changed the topic of #ubuntu-classroom to: Ubuntu Open Week | Information and Logs: https://wiki.ubuntu.com/UbuntuOpenWeek | How to ask questions: https://wiki.ubuntu.com/UbuntuOpenWeek/Rules | Ask questions in #ubuntu-classroom-chat, prefaced with "QUESTION:" |See https://wiki.ubuntu.com/UbuntuOpenWeek/JoiningIn to filter out channel noise | "Ubuntu Bugsquad and Triaging Bugs" - Pedro Villavicencio [18:59] ok guys, next up is pedro_ and Iulian - talking about the Ubuntu bugsquad! [18:59] take it away guys! [18:59] thanks jcastro! [19:00] Thank you, jcastro. [19:00] Hello folks my name is Pedro Villavicencio and I'm the guy behind the Ubuntu Desktop Bugs, i'm here to day with the great bugsquader Iulian to talk about our Bugsquad and how to Triage Bugs [19:02] the awesome Brian Murray already talked to you on how to report good quality bugs [19:02] so we're going to talk to you about the rest of the process [19:02] Bugsquad first: [19:02] The Ubuntu BugSquad is the first point of contact for the bugs filed about Ubuntu [19:03] we keep track of them and try to make sure that major bugs do not go unnoticed by developers [19:03] we do this with a process called "Triage" will talk to you about it in a minutes [19:03] Working with the Bug Squad it's an excellent way to start helping out and learn a lot about Ubuntu and it's infrastructure [19:03] You do not need any programming knowledge to join the team in fact it is a great way to return something to our lovely Ubuntu project if you cannot program at all [19:04] we have a few points of contact [19:04] a team on LP https://edge.launchpad.net/~bugsquad it's an open team, so everybody can join us [19:04] so if you're interested on bugs feel free to join now ;-) [19:05] we also have a mailing list https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad [19:05] and a couple of IRC channels [19:05] where the bugs are discussed: #ubuntu-bugs [19:06] and another one where the bugs are announced: #ubuntu-bugs-announce [19:06] also, if you have questions over a specific project you can look https://wiki.ubuntu.com/BugSquad/Contacts to see to who you can ask about it later [19:07] Ok so, Bug triage is an essential part of Ubuntu's development and consists in a list of things: [19:07] - Responding to new bugs as they are filed [19:07] - Ensuring that new bugs have all the necessary information [19:08] - Assigning bugs to the proper package [19:08] Brian already talked to you about this things so we hope you'll be filing good quality reports ;-) [19:09] most of the bugs we have to deal with are not assigned to the right package [19:09] and moreover not assigned to anything [19:09] if you look to this list http://tinyurl.com/32l4gd [19:09] there's ~3500 reports without a package assigned to it [19:10] lets keep going with the list of parts [19:10] - Confirming bug reports by trying to reproduce them [19:10] - Setting the priority of bugs reports [19:10] - Searching for and marking duplicates in the bug tracking system [19:10] - Sending bugs to their upstream authors, when applicable [19:11] for this one you might want to look to https://wiki.ubuntu.com/Bugs/Upstream for instructions on how to do it [19:11] - Cross-referencing bugs from other distributions. [19:11] - Expiring old bugs. [19:11] All of these activities help the bug get fixed and subsequently making Ubuntu even better [19:11] As soon as you have done enough good triage work, you can apply to the ubuntu-bugcontrol team which is the one with more rights over the reports [19:12] so basically you can see the Private reports, change the Importance of the bugs and set a couple of bug status (Triaged, Won't Fix) we will talk about both in a min [19:12] the requirements for join the team are available here: https://wiki.ubuntu.com/UbuntuBugControl [19:13] and the lp url is : https://edge.launchpad.net/~ubuntu-bugcontrol [19:14] Bug status: [19:15] We currently have 9 status, they are: New, Incomplete, Invalid, Confirmed, Triaged, In Progress, Fix Committed, Fix Released and Won't Fix [19:15] New status means that no one has triaged or confirmed the report [19:16] The Incomplete status means that the bug is missing some information, for example, the steps for trigger that behavior [19:17] A Confirmed is almost self explanatory, someone else than the reporter is having the same bug [19:17] I guess that Brian told you this, but in case of: Please do not confirm your own reports [19:18] The Triaged state is set by a member of the Ubuntu Bug Control team [19:19] when they think that the bug has enough information for a developer to start working on fixing the issue [19:19] If a bug was marked as Triaged and a Developer is working on fixing the bug [19:19] that report needs to be marked as "In Progress" [19:20] please use "In Progress" just for that, I've encounter some bugs marked as In Progress because the reporter is collecting more info because a triager asked they to do so [19:20] that's wrong, so please don't do it [19:21] If that developer committed the fix to a bzr branch or to another repository [19:21] the reports now needs to be marked as "Fix Committed" [19:21] and when the fix is released, released meaning available on a Official Ubuntu repository [19:22] the status of that report needs to be changed to "Fix Released" [19:22] if you have any doubt or want to know more about status, you can read about them here: https://wiki.ubuntu.com/Bugs/Status [19:24] does anybody has a question regarding bug status? [19:24] It seems that you missed the 'Invalid' status. [19:24] ok so the bad guy the "Invalid" status [19:24] go ahead Iulian [19:25] This status should be used when the bug report does not contain adequate information to determine whether or not it is a bug even if it is resolved for the reporter. [19:26] Be careful when you set this status, when a bug has the invalid status it will no longer show up in default searches. [19:27] We have one question. [19:27] ok [19:27] QUESTION: how long does it takes to be able to join the ubuntu-bugcontrol team? [19:28] sourcercito: it depends on how much work you been doing, the whole process can take a few weeks [19:29] for the whole process i mean, for a new triager to start doing a good triage work [19:29] apply for the team and then get the membership [19:30] ok so Bug Importance [19:30]