[16:00] <jcastro> Ok, let's get started
[16:00] <jcastro> welcome back everyone to the last day of OpenWeek
[16:00] <jcastro> thanks for coming out on a Saturday! :)
[16:00] <jcastro> The last set of sessions are listed here:
[16:00] <jcastro> https://wiki.ubuntu.com/UbuntuOpenWeek/
[16:00] <jcastro> First up we have Emmet Hikory with "Unwinding Stacktraces"
[16:00] <jcastro> persia: take it away!
[16:01] <persia> Welcome to Unwinding Stacktraces.
[16:01] <persia> 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] <persia> 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] <persia> As a program executes, it typically involved calling some sequence of functions, each of which will call further functions, and so on.
[16:03] <persia> 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] <persia> For the interesting stacktraces, this is usually the point at which the program crashes, but it can be any point.
[16:04] <persia> 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] <persia> At the top (#0), we have the actual character display, with a local variable holding 'l'.
[16:04] <persia> The next frame (#1) is printf(), with the local variable "Hello World".
[16:04] <persia> The third (#2) is main(), with no local variables, reprenting our program.
[16:05] <persia> 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] <persia> As you can see, this stack is a little longer, as w3m is a bit more complicated than the previous example.
[16:06] <persia> Also, this stacktrace represents a real crash, so instead of knowing we are at 'l', we have to discover our location.
[16:07] <jcastro> < wolfger> QUESTION: for us noobs, how is a stack trace taken?
[16:07] <persia> 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] <persia> 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] <persia> I'll talk a little about apport later, but https://wiki.ubuntu.com/Backtrace provides a quick guide to doing it manually.
[16:09] <jcastro> < BonesolTeraDyne> QUESTION: Is a stacktrace the same as the backtrace that the KDE crash handler gives?
[16:09] <persia> 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] <persia> 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] <persia> At frame 15, the program is trying to start
[16:10] <persia> At frame 14 glibc is processing the start request
[16:11] <persia> At frame 13, the main() function starts, and we're in the code
[16:11] <persia> 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] <persia> At frame 11 is calls "loadSomething", which is probably a generic helper function for the file load
[16:12] <persia> At frame 10, it appears to have discovered this was an HTML file, and so is loading HTML
[16:12] <persia> At frame 9, it is processing the HTML data as a data stream
[16:12] <persia> At frame 8 it is processing a single line of the data
[16:13] <persia> At frame 7, it seems to be processing a table
[16:13] <persia> (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] <persia> 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] <persia> Frame 2 appears to be rendering an image within the table
[16:14] <persia> Frame 1 appears to be handling the description of the image
[16:15] <persia> And frame 0 crashes with the call to Strnew_size with the passed argument of (n=256).
[16:15] <persia> 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] <jcastro> < wolfger> QUESTION: how did we determine that about Frame #1? That step lost me
[16:18] <persia> 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] <persia> 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] <persia> 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] <persia> 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] <persia> 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] <persia> 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] <persia> 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] <persia> This list is most easily accessible from the Tags list on https://launchpad.net/ubuntu/+bugs
[16:25] <persia> 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] <persia> 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] <persia> 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] <persia> 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] <persia> Great then!
[16:31] <persia> 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] <jcastro> < bran_damage> QUESTION: Are the stacktraces similar no matter what language the code was written in ?
[16:32] <persia> bran_damage: Typically, although they may look a little different.
[16:33] <persia> 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] <persia> An unretraced stacktrace looks like http://launchpadlibrarian.net/9032770/Stacktrace.txt
[16:34] <persia> While the codes are meaningful with the debug symbols, without them, the function names are unknown, and the locals are hidden.
[16:36] <persia> Going back to hydrogen, and the process of looking at a stacktrace for debugging.
[16:37] <persia> 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] <persia> 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] <persia> 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] <persia> 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] <persia> This takes us to Frame #2 which is pretty clearly the loader that handles the loadDrumkitBtn click.
[16:45] <persia> 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] <persia> Now since frame #1 is in the Hydrogen::loadDrumkit function, it's actually line 167 of the pastebin.
[16:46] <persia> Looking at what happens previously in this function, we can see that some name gets set (line 160)
[16:46] <persia> It does a loop over the list of drumkits
[16:47] <persia> Compares the selected name to each of the names
[16:47] <persia> 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] <persia> 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] <persia> (code for this is available from http://paste.ubuntu.com/9756/ )
[16:50] <persia> Here, we're looking at the function starting at line 2469
[16:51] <persia> Going down, it crashes at an assignment, which ttrial and error showed to be line 2494.
[16:51] <persia> Now, any questions about comparing the code and the stacktrace to debug a problem?
[16:52] <jcastro> no questions so far
[16:54] <persia> Well then, a few random notes, before we're out of time (but please interrupt if you have a question).
[16:54] <persia> 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] <persia> 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] <persia> 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] <persia> 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] <jcastro> thanks persia!
[16:59] <jcastro> Next up will be a hot topic lately, Virtualization with Soren Hansen!
[17:00] <jcastro> In about 1 minute. :D
[17:01] <jcastro> soren: take it away!
[17:02] <jcastro> hmm, let's give him a few minutes
[17:07] <jcastro> Ok, we're texting soren, thanks for being patient!
[17:10] <jcastro> Ok, soren is on his way!
[17:11] <soren> o/
[17:11] <soren> Sorry, guys!
[17:11] <soren> I was sure it wasn't for another two hours.
[17:11] <jcastro> No worries!
[17:11] <soren> Ok... Hi, everyone.
[17:11] <soren> I'm Soren Hansen, and I work for Canonical as virtualisation specialist.
[17:12] <soren> Er..
[17:12] <soren> This caught me a bit off guard :)
[17:12] <soren> Are there any questions already or should I just talk about stuff?
[17:13] <soren> I guess not.
[17:13] <soren> Well, I can tell you what Ubuntu is focusing on and has focused on for Hardy.
[17:14] <soren> I think we're the first major distro to put out a major release with a virtualisation solution based on kvm.
[17:14] <soren> KVM is a modular hypervisor that runs in the linux kernel.
[17:15] <soren> It's in the official kernel tree, and is very well-maintained.
[17:15] <jcastro> Real quick soren, can you explain virtualization, hypervisor, and KVM?
[17:15] <soren> KVM relies on the presence of the virtualisation extensions that are found in recent processors from both AMD and Intel.
[17:16] <soren> jcastro: Ah.. Right :)
[17:16] <soren> Virtualisation is not as well-defined as one would have hoped.
[17:16] <soren> 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] <soren> That's a rather broad definition, though.
[17:17] <soren> You can divide virtualisation into various categories..
[17:17] <soren> There's containers, such as openvz and linux vserver.
[17:18] <soren> They basically allow you to have process running in a completely separate namespaces, thus separating the completely from one another.
[17:18] <soren> Then you have paravirtualisation.
[17:18] <soren> This is stuff like Xen.
[17:19] <soren> 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] <soren> The there's full virtualisation.
[17:20] <soren> This is stuff like KVM and QEmu.
[17:20] <soren> The idea here is that run unmodified operating systems inside  of it.
[17:21] <soren> To accomplish this, the virtualisation technology must make it looks exactly as though it's a regular PC.
[17:21] <soren> ...just like the one you've got under your desk.
[17:22] <soren> There are variour variations of these things, but that's basically the gist of it.
[17:22] <soren> A hypervisor is the bit of magic that makes this all possible.
[17:23] <soren> It's the "thing" that takes care of assigning resources to guest operating systems and such.
[17:24] <soren> 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] <soren> 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] <soren> So in this case, the hypervisor is the kernel module and the kvm userspace process.
[17:25] <soren> < highvoltage> QUESTION: Does that mean that KVM won't run on any of the older CPUs, like Qemu did?
[17:25] <soren> Short version: Yes.
[17:26] <soren> One thing to remember is that the percentage of machines that can't use kvm is constantly dropping.
[17:26] <soren> ..and due to this hardware requirement, KVM's design is very simple compared to most alternatives.
[17:27] <soren> < Toadinator> QUESTION: could you explain the benefits of virtualization to someone who doesn't run a virtual machine?
[17:27] <soren> Sure.
[17:27] <soren> Hardware is cheap these days.
[17:27] <soren> Most of the time, you fill up your data centers with the monstrous machines.
[17:28] <soren> If you run some form of virtualisation on top of that, you can have many separate operating systems running.
[17:29] <soren> 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] <soren> The virtual machine still sees the same hardware, so there's no reconfiguration to be done in the guest.
[17:30] <soren> 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] <soren> I've heard people suggest it used as a power saving mechanism.
[17:31] <soren> 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] <soren> ..and the rain forest.
[17:31] <soren> :)
[17:31] <soren> The possibilities are endless.
[17:32] <soren> 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] <soren> < 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] <soren> Containers are sort of an extended version of a chroot jail.
[17:33] <soren> If you're in a chroot jail, device nodes, memory usage, processes are still the same as it is outside the chroot.
[17:33] <soren> Inside a container, you can't see processes from other containers, you can't access their device nodes, etc., etc.
[17:34] <soren>  < chell> Question: so KVM is a program like vmware or virtual box?
[17:34] <soren> Yes, kvm is very much like those. The differences are that it's completely free and maintained in the mainline linux kernel.
[17:35] <soren> < smeg0l> QUESTION i find qemy very heavy what other alternatives do i have that wil run on hardy heron ?
[17:35] <soren> QEmu is very heavy indeed.
[17:35] <soren> Emulating a CPU is a very heavy process.
[17:35] <soren> KVM uses parts of QEmu, but not the cpu emulation parts.
[17:36] <soren> We also have virtualbox and Xen in universe and vmware server runs, too, so there are plenty of options.
[17:36] <soren> We've just chosed to focus mostly on Xen.
[17:36] <soren> Er..
[17:36] <soren> Damn, I did not just say that.
[17:36] <soren> I meant, of course, that we've chosed to focus mostly on kvm.
[17:37] <soren> 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] <soren> No, that's the entire point of virtualisation. The virtual machines don't see your hardware.
[17:37] <soren>  < smeg0l> QUESTION what vitual maniger would cause the least trouble ?
[17:37] <soren> I don't understand the questin.
[17:38] <soren>  < Salumu> QUESTION: How does hypervisors manage to run system calls from the applications in the virtual guest OS?
[17:38] <soren> This is where Xen and kvm differ very much.
[17:38] <soren> Well, one of the places, anyway.
[17:38] <soren> System calls in Xen are translated to hypercalls to the hypervisor.
[17:39] <soren> 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] <soren> < DoruHush> QUESTION: What other requirements have to be mentioned beside the processor?
[17:40] <soren> Nothing, really.
[17:40] <soren> If your processor has the magic stuff and your bios doesn't block them, then you're set.
[17:41] <soren> Flyser> QUESTION: Can we expect a stable KVM release some day?  (if yes, when? ^^)
[17:41] <soren> I'm not sure what you mean by a stable KVM release.
[17:42] <soren> The KVM in Hardy is rather stable. It's been working for a quite a few people with different use cases.
[17:42] <soren>  highvoltage> QUESTION: How stable is KVM compared to VMWare and Xen, and how does it compare performance wise?
[17:43] <soren> 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] <soren> 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] <soren> < smeg0l> QUESTION what vitual manager would cause the least trouble ?
[17:44] <soren> I don't understand the question.
[17:45] <soren> 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] <soren> KVM as much, much simpler than Xen.
[17:45] <soren> It's actually something that we can reasonable maintain and support.
[17:45] <soren> Xen has famously been rejected by the linux kernel developers on several occasions.
[17:46] <soren> One of the primary reasons we didn't choose virtualbox is the lack of headless support in the free version.
[17:47] <soren> The non-free version offers an RDP server, so it's actually usable in server settings (which was our focus).
[17:47] <soren> Also, virtualbox is not in mainstream Linux. That really, *Really* means a lot.
[17:47] <soren> QUESTION: Do you know of any large uses of virtualisation, running on Ubuntu?
[17:48] <soren> Well, Hardy is the first release where it's a major feature, and Hardy's still quite young.
[17:48] <soren> 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] <soren> < 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] <soren> The easy way:
[17:49] <soren> sudo apt-get install kvm virt-manager libvirt-bin
[17:49] <soren> sudo adduser $USER libvirtd
[17:49] <soren> (log out, and log back in)
[17:49] <soren> virt-manager -c qemu:///system
[17:50] <soren> That'll give you a nice, graphical interface for managing your virtual machines.
[17:50] <soren> highvoltage> QUESTION: how scriptable is KVM? can I suspend it on host shutdown and start it again when the host starts?
[17:50] <soren> Yes, you can do that rather easily.
[17:51] <soren> 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] <soren> < smeg0l> QUESTION which virtual manager is the most userfriendly ?
[17:51] <soren> What do you mean by virtual manager?
[17:51] <soren> Do you mean hypervisor?
[17:52] <soren> If so, it's a matter of taste, I think.
[17:52] <jcastro> tip: screenshots of virtual manager: http://www.phoronix.com/scan.php?page=article&item=983&num=1
[17:52] <soren> VMWare server is still a bit ahead of virt-manager in many respects.
[17:52] <soren> VirtualBox, too.
[17:52] <soren> ...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] <soren> Oh, I forgot part of this question:
[17:53] <soren> < ~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] <soren> 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] <jcastro> We're starting to run out of time, can you tell everyone about ubuntu-vm-builder after this question?
[17:54] <soren> livirt can manage Xen instances, too, so the userfriendliness can be about the same (from the user's POV).
[17:55] <soren> jcastro: Oh, sure.
[17:55] <soren> 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] <soren> It doesn't go through the regular installer, it doesn't even use any virtualisation technology.
[17:56] <soren> ..so it's really fast.
[17:56] <soren> I've built ubuntu virtual machines in less than 45 seconds.
[17:56] <jcastro> More info here: https://help.ubuntu.com/8.04/serverguide/C/ubuntu-vm-builder.html
[17:57] <soren> If you have further questions, #ubuntu-virt is the channel for virtualisation in Ubuntu. Feel free to stop by any time.
[17:57] <jcastro> thanks Soren!
[17:58] <soren> Thanks for stopping by, everyone!
[17:58] <soren> And sorry again for being late :(
[17:58] <jcastro> ok, next up is Reporting Bugs with Brian Murray
[17:59] <jcastro> this session was done on Monday but we scheduled one today to get maximum participation!
[17:59] <bdmurray> Hi, I'm Brian Murray and I'm Ubuntu's bug master.
[18:00] <bdmurray> I'm here to talk today about how to report bugs about Ubuntu as there are various ways you can do it.
[18:00] <bdmurray> Additionally, I'll cover how to make your bug report more complete and therefore more likely to get fixed!
[18:00] <bdmurray> Perhaps you are wondering what exactly is a bug?
[18:01] <bdmurray> In computer software it is an error or a flaw that makes it behave in ways for which it wasn't designed.
[18:01] <bdmurray> Some of these can result in crashes, others may have a subtle effect on functionality, others can be spelling errors.
[18:01] <bdmurray>  By reporting these issues you can help to make Ubuntu even better than it already is.
[18:02] <bdmurray> Reported bugs are kept in Launchpad, the bug tracking system used by Ubuntu.
[18:02] <bdmurray> Let's look at a sample bug report - http://launchpad.net/bugs/222278.
[18:03] <bdmurray> There are 4 things there that I want to point out.
[18:03] <bdmurray> 1) The bug's title or summary is 'upgrade hanges in checkViewDepends()'
[18:04] <bdmurray> 2) In the affects table, below the title, you'll see that this bug report affects 'update-manager (Ubuntu)'
[18:04] <bdmurray> This is the package / application which the bug is about
[18:04] <bdmurray> 3) Below that is the bug's description, labelled "Bug description" ;), which is filled out when you are reporting a bug
[18:05] <bdmurray> 4) You'll also notice that there are 5 comments, 4 of which contain attachments with supporting information about the bug.
[18:05] <bdmurray> 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] <bdmurray> < wolfger> QUESTION: if something is behaving as designed, but we don't  like it, is it bug report material?
[18:08] <bdmurray> 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] <bdmurray> < smeg0l> QUESTION when do determine if it's a hardware faily or a bug ?
[18:10] <bdmurray> Determining whether or not a bug report is due to faulty hardware can be quite tricky.
[18:11] <bdmurray> 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] <bdmurray> Moving on - How can bugs be reported to Launchpad?
[18:12] <bdmurray> 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] <bdmurray> After which you are asked for the package affected and for 'Futher information' which becomes the bug's description.
[18:12] <bdmurray> The description should contain at a minimum the following:
[18:13] <bdmurray> 1) The release of Ubuntu that you found the bug in.
[18:13] <bdmurray> This is important as there is more than 1 supported release of Ubuntu out there right now.
[18:13] <bdmurray> 2) The version of the package you found the bug in.
[18:14] <bdmurray> 3) The behaviou that you expected to happen
[18:14] <bdmurray> and 4) What happened instead
[18:14] <bdmurray> You also have the opportunity to add an attachment to your bug when you are reporting it via the web interface.
[18:15] <bdmurray> Another way to report a bug is using apport an automated problem report application included with Ubuntu.
[18:15] <bdmurray> 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] <bdmurray> Let's say that you have encountered a bug with Firefox.
[18:15] <bdmurray> You can use apport to report the bug by going to Firefox's "Help" menu and choosing "Report a Problem".
[18:16] <bdmurray> 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] <bdmurray> Let's look at a bug reported using the "Report a Problem" menu item
[18:17] <bdmurray> http://launchpad.net/bugs/223455
[18:17] <bdmurray> 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] <bdmurray> All of this information is gathered for you automatically.
[18:18] <bdmurray> The "Report a Problem" functionality has been integrated into lots of applications and is the preferred way to report a bug.
[18:19] <bdmurray> 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] <bdmurray> Additionally, you can also specify a process id number via 'apport-cli -f -P PID'.
[18:19] <bdmurray> Further information about reporting bugs can be found at https://help.ubuntu.com/community/ReportingBugs
[18:20] <bdmurray> Are there any questions about how you can report a bug?
[18:21] <bdmurray> < 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] <bdmurray> In that case you could use apport-cli -f -p firefox-3.0 for example
[18:22] <bdmurray> Also when you are running a development release of Ubuntu apport will watch for application crashes and report those
[18:23] <bdmurray> < 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] <bdmurray>  sense") cases problems for you and for lthe other people inv
[18:24] <bdmurray> 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] <bdmurray> Possibly there is a bug in the documentation or the software's description.
[18:26] <bdmurray> 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] <bdmurray> So how can we make our bug reports more useful for developers?
[18:26] <bdmurray> Choosing the name of the package or application the bug is about is critical.
[18:27] <bdmurray> 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] <bdmurray> Some helpful hints for finding the proper package are at https://wiki.ubuntu.com/Bugs/FindRightPackage
[18:27] <bdmurray> This page also contains the names of packages that might be hard to discover.
[18:27] <bdmurray> For example, bugs about the kernel in Hardy Heron should be reported about the 'linux' package.
[18:28] <bdmurray> Additionally, members of the Ubuntu bug squad are available in the #ubuntu-bugs cahnnel if you need help identifying the proper package.
[18:29] <bdmurray> After the bug is reported in Launchpad an important part of its life cycle is it entering the Confirmed status.
[18:29] <bdmurray> 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] <bdmurray> Any Launchpad user can confirm a bug report, but please don't confirm your own!
[18:30] <bdmurray> This will make the Confirmed status less useful.
[18:30] <bdmurray> 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] <bdmurray> 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] <bdmurray> And not every bug triager may now all the intricacies of that application.
[18:32] <bdmurray> So by putting extremely detailed steps in your bug report you are increasing the chances of it being confirmed.
[18:32] <bdmurray> It is far better to have too much detail than not enough!
[18:33] <bdmurray> Some fairly simple things you can do to make your report easier for someone to confirm are including a screenshot.
[18:33] <bdmurray> Or you can create a screencast, a movie of your desktop, using an application like istanbul.
[18:34] <bdmurray> Let's take a look at http://launchpad.net/bugs/212425
[18:34] <bdmurray> This bug has a screencast attached to it
[18:35] <bdmurray> Their description of how to reproduce the bug is pretty good but is a little hard to understand
[18:36] <bdmurray> By watching the screencast though, bug triagers are able to clearly see what steps we should take to recreate the bug.
[18:37] <bdmurray> Are there any more questions at this point in time?
[18:38] <bdmurray> < 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] <bdmurray> There are some crash reports about KDE applications reported by apport.
[18:41] <bdmurray> In regards to integration with the KDE crash handler, I'm not certain but will look into it.
[18:42] <bdmurray> 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] <bdmurray> Bug triagers and software developers have written up a variety of these debugging procedures.
[18:44] <bdmurray> A list of them can be found at https://wiki.ubuntu.com/DebuggingProcedures
[18:46] <bdmurray> If you look at the debugging update-manager page - https://wiki.ubuntu.com/DebuggingUpdateManager
[18:47] <bdmurray> 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] <bdmurray> Providing information like that makes your bug report much more complete
[18:49] <bdmurray> And a bug report with more relevant information is more likely to get fixed!
[18:49] <bdmurray> 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] <bdmurray> Toadinator: early I mentioned the wiki page https://wiki.ubuntu.com/Bugs/FindRightPackage
[18:51] <bdmurray> This contains some high level information about when an application is running
[18:51] <bdmurray> For example when your system boots and you see the "Ubuntu" logo that is the usplash package
[18:52] <bdmurray> Also printing bugs should generally be reported about cupsys and then they will be moved to the proper package if necessary
[18:53] <bdmurray> Additionally, there is information about how to find out what application an open window belongs to
[18:53] <bdmurray> < 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] <bdmurray> The functionality of apport is integrated into an application via the package 'liblaunchpad-integration1'
[18:56] <bdmurray> And I'm fairly certain this is a patch that Ubuntu carries for the package with that integration
[18:56] <bdmurray> Any more questions?
[18:58] <bdmurray> Okay, then thanks for coming to the class on How to Report bugs
[18:58] <bdmurray> If you need any help reporting a bug please come to the #ubuntu-bugs channel on freenode
[18:58] <bdmurray> Thanks!
[18:59] <jcastro> ok guys, next up is pedro_ and Iulian - talking about the Ubuntu bugsquad!
[18:59] <jcastro> take it away guys!
[18:59] <pedro_> thanks jcastro!
[19:00] <Iulian> Thank you, jcastro.
[19:00] <pedro_> 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] <pedro_> the awesome Brian Murray already talked to you on how to report good quality bugs
[19:02] <pedro_> so we're going to talk to you about the rest of the process
[19:02] <pedro_> Bugsquad first:
[19:02] <pedro_> The Ubuntu BugSquad is the first point of contact for the bugs filed about Ubuntu
[19:03] <pedro_> we keep track of them and try to make sure that major bugs do not go unnoticed by developers
[19:03] <pedro_> we do this with a process called "Triage" will talk to you about it in a minutes
[19:03] <pedro_> 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] <pedro_> 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] <pedro_> we have a few points of contact
[19:04] <pedro_> a team on LP https://edge.launchpad.net/~bugsquad it's an open team, so everybody can join us
[19:04] <pedro_> so if you're interested on bugs feel free to join now ;-)
[19:05] <pedro_> we also have a mailing list https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad
[19:05] <pedro_> and a couple of IRC channels
[19:05] <pedro_> where the bugs are discussed: #ubuntu-bugs
[19:06] <pedro_> and another one where the bugs are announced: #ubuntu-bugs-announce
[19:06] <pedro_> 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] <pedro_> Ok so, Bug triage is an essential part of Ubuntu's development and consists in a list of things:
[19:07] <pedro_> - Responding to new bugs as they are filed
[19:07] <pedro_> - Ensuring that new bugs have all the necessary information
[19:08] <pedro_> - Assigning bugs to the proper package
[19:08] <pedro_> Brian already talked to you about this things so we hope you'll be filing good quality reports ;-)
[19:09] <pedro_> most of the bugs we have to deal with are not assigned to the right package
[19:09] <pedro_> and moreover not assigned to anything
[19:09] <pedro_> if you look to this list  http://tinyurl.com/32l4gd
[19:09] <pedro_> there's ~3500 reports without a package assigned to it
[19:10] <pedro_> lets keep going with the list of parts
[19:10] <pedro_> - Confirming bug reports by trying to reproduce them
[19:10] <pedro_> - Setting the priority of bugs reports
[19:10] <pedro_> - Searching for and marking duplicates in the bug tracking system
[19:10] <pedro_> - Sending bugs to their upstream authors, when applicable
[19:11] <pedro_> for this one you might want to look to https://wiki.ubuntu.com/Bugs/Upstream for instructions on how to do it
[19:11] <pedro_> - Cross-referencing bugs from other distributions.
[19:11] <pedro_> - Expiring old bugs.
[19:11] <pedro_> All of these activities help the bug get fixed and subsequently making Ubuntu even better
[19:11] <pedro_> 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] <pedro_> 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] <pedro_> the requirements for join the team are available here: https://wiki.ubuntu.com/UbuntuBugControl
[19:13] <pedro_> and the lp url is : https://edge.launchpad.net/~ubuntu-bugcontrol
[19:14] <pedro_> Bug status:
[19:15] <pedro_> We currently have 9 status, they are: New, Incomplete, Invalid, Confirmed, Triaged, In Progress, Fix Committed, Fix Released and Won't Fix
[19:15] <pedro_> New status means that no one has triaged or confirmed the report
[19:16] <pedro_> The Incomplete status means that the bug is missing some information, for example, the steps for trigger that behavior
[19:17] <pedro_> A Confirmed is almost self explanatory, someone else than the reporter is having the same bug
[19:17] <pedro_> I guess that Brian told you this, but in case of: Please do not confirm your own reports
[19:18] <pedro_> The Triaged state is set by a member of the Ubuntu Bug Control team
[19:19] <pedro_> when they think that the bug has enough information for a developer to start working on fixing the issue
[19:19] <pedro_> If a bug was marked as Triaged and a Developer is working on fixing the bug
[19:19] <pedro_> that report needs to be marked as "In Progress"
[19:20] <pedro_> 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] <pedro_> that's wrong, so please don't do it
[19:21] <pedro_> If that developer committed the fix to a bzr branch or to another repository
[19:21] <pedro_> the reports now needs to be marked as "Fix Committed"
[19:21] <pedro_> and when the fix is released, released meaning available on a Official Ubuntu repository
[19:22] <pedro_> the status of that report needs to be changed to "Fix Released"
[19:22] <pedro_> 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] <pedro_> does anybody has a question regarding bug status?
[19:24] <Iulian> It seems that you missed the 'Invalid' status.
[19:24] <pedro_> ok so the bad guy the "Invalid" status
[19:24] <pedro_> go ahead Iulian
[19:25] <Iulian> 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] <Iulian> 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] <Iulian> We have one question.
[19:27] <pedro_> ok
 QUESTION: how long does it takes to be able to join the ubuntu-bugcontrol team?
[19:28] <pedro_> sourcercito: it depends on how much work you been doing, the whole process can take a few weeks
[19:29] <pedro_> for the whole process i mean, for a new triager to start doing a good triage work
[19:29] <pedro_> apply for the team and then get the membership
[19:30] <pedro_> ok so Bug Importance
[19:30] <pedro_> as i said one of the nice privileges you're going to have if you join to the bugcontrol team is set importances
[19:31] <pedro_> we currently have 6 importances
[19:31] <pedro_> Undecided
[19:31] <pedro_> Wishlist
[19:31] <pedro_> Low
[19:32] <pedro_> Medium
[19:32] <pedro_> High and Critical
[19:32] <pedro_> during your first steps into the Ubuntu Bugsquad you're probaby not going to use them
[19:32] <pedro_> but you can always ask on #ubuntu-bugs for someone to set an importance for you
[19:34] <pedro_> the Undecided one is the default for new bugs
[19:35] <pedro_> and it means that there's no sufficient information to determine the importance
[19:37] <pedro_> A Wishlist is a request to add a new feature to the programs available on Ubuntu
[19:38] <pedro_> rodolfo> QUESTION: Sometimes it's hard to describe a bug in English, specially when it's about the system behavior. In these cases, there would be better to upload a video, demonstrating the bug and how it happens. Is there any idea to make this possible?
[19:38] <pedro_> rodolfo: yes, you can do it, the more information you can provide us the better
[19:38] <pedro_> there's a program called istanbul that allow you to record things happening on your desktop
[19:39] <pedro_> and if you don't know how to explain what's happening , a video it's always a good thing
[19:40] <pedro_> ok when a wishlist request it's too complex
[19:40] <pedro_> it should rather be written as a feature specification
[19:40] <pedro_> you can read about how to write them here  https://wiki.ubuntu.com/FeatureSpecifications
[19:41] <pedro_> and also if you have some ideas that you'd like to see included on Ubuntu
[19:41] <pedro_> you can use the Ubuntu Brainstorm website
[19:41] <pedro_> http://brainstorm.ubuntu.com/
[19:42] <pedro_> where you can vote for ideas and the ubuntu developers will probably going to discuss the better ones at the Ubuntu Developer Summit
[19:42] <pedro_> so *now* is the right time to do it
[19:42] <Iulian> We currently have ~8000 ideas reported on the brainstorm website.
[19:43] <pedro_> yep so feel free to add yours or vote for one that you'd like to have on our next version
[19:43] <Iulian> Every day we get 5-10 ideas.
[19:43] <Iulian> Even more sometimes.
[19:44] <Iulian> Ok, so let's get back to the Importance of a bug.
[19:45] <Iulian> The Low importance are the bugs which affect functionality.
[19:46] <Iulian> They can be easily worked around, are the bugs that affect unusual configurations or uncommon hardware.
[19:47] <Iulian> It is a bug that has a moderate inpact on a non-core application.
[19:47] <Iulian> Medium importance:
[19:48] <Iulian> Most bugs are of medium importance. For example: it has a moderate impact on a core application.
[19:49] <Iulian> It's a bug that has a severe impact on a non-core application. You can set this importance if you have a problem with a non-essential hardware component (network card, webcam, sound card, printer, etc)
[19:51] <Iulian> High importance: This is a bug that has a severe impact on a small portion of Ubuntu users. It makes a default Ubuntu installation generally unusable.
[19:51] <Iulian> e.g: system fails to boot or X fails to start on a certain make and model of computer.
 QUESTION: Can all of the status only be set by the Bug Team or can some status be set by other people, too, and only some are reserved to the Bug Team?
[19:52] <Iulian> All statuses can be set by everyone, except Triage and Won't Fix.
[19:53] <Iulian> You have to be a member of the Ubuntu Bug Control to set those two statuses.
[19:54] <Iulian> Ok, so, the High importance should be set only if it has a moderate impact on a large portion of Ubuntu users.
[19:55] <Iulian> The Critical importance is pretty much self-explanatory.
[19:55] <Iulian> Only set this importance if a bug has a SEVERE impact on a large portion of Ubuntu users.
[19:56] <pedro_> yes, ok if you want to work with the bugsquad we organize the Bug Days
[19:56] <pedro_> also known as Hug Days (triage a bug and get a hug)
[19:57] <pedro_> well the idea of a hug day is to work together with the bugsquad and project maintainers on a specific task, weekly we organize two hug days, Tuesdays and Thursdays
 QUESTION: what about the bug status "wishlist"?
[19:58] <pedro_> first one are more general hug days, focused for example of the bugs without a package and the Thursday ones are focused on desktop related task like compiz, firefox and GNOME applications
[19:59] <pedro_> If you want to join us at Hug Days just come to #ubuntu-bugs the days I've mentioned and join the fun
[19:59] <Iulian> nosrednaekim: There is no such status, that is an importance. You set that importance if it's a feature request. Pedro just talked several minutes ago about it.
[19:59] <pedro_> yes ;-)
[20:00] <pedro_> ok so we're running out of time
[20:00] <pedro_> everyday is perfect day for triaging so don't wait till hug day!
[20:00] <jcastro> yep, you're out of time, thanks guys!
[20:00] <Iulian> Yup, thanks everyone!
[20:00] <pedro_> thanks you all ;-)
[20:00] <jcastro> ok boredandblogging, take it away!
[20:01] <boredandblogging> Hi folks, welcome to the Ubuntu Open Week LoCo Teams session
[20:01] <boredandblogging> I'm Nick Ali, part of the Ubuntu Georgia US team.
[20:01] <boredandblogging> So lets get started.
[20:02] <boredandblogging> First, what is a LoCo?
[20:02] <boredandblogging> LoCo stands for Local Community.
[20:02] <boredandblogging> LoCos are run by the community, not Canonical. However Canonical does support LoCo in various ways that we will cover later.
[20:03] <boredandblogging> Its purpose is to help advocate, develop, and support Ubuntu in your local region.
[20:03] <boredandblogging> Advocacy is the most important job of a LoCo. LoCos should promote Ubuntu to schools, organizations, companies, and media outlets.
[20:04] <boredandblogging> Usually, there is one LoCo per country. But depending on size and population, there may be several per region. For example, the United States has one LoCo per state.
[20:04] <boredandblogging> The list of LoCos is available at https://wiki.ubuntu.com/LoCoTeamList.
[20:05] <boredandblogging> If you find a LoCo in your area, join its mailing list and Launchpad team. Introduce yourself on the mailing list and IRC channel.
[20:05] <boredandblogging> All teams welcome new members. You can help out with advocacy, supporting new members, helping organize events, translation, and many other arenas.
[20:06] <boredandblogging> LoCos have online meetings, usually in IRC, and meet in person.
[20:06] <boredandblogging> They organize or participate in events promoting Ubuntu.
[20:06] <boredandblogging> This can be holding install fests after the release of new version of Ubuntu or running stalls and booths at conferences or expos.
[20:06] <boredandblogging> What if there is no LoCo in your area?
[20:07] <boredandblogging> See https://wiki.ubuntu.com/LoCoTeamHowto on directions on how to set up your online presence. Instructions are provided on how to request mailing lists and forums, setting up wiki pages and IRC channels.
[20:07] <boredandblogging> If you are interested in starting a LoCo, remember that being a leader is more than just setting up your mailing list, IRC channels, etc.
[20:08] <boredandblogging> You will have to motivate all the volunteers in your team to participate and get things done.
[20:08] <boredandblogging> Everyone should be involved in some way, and you will need to encourage everyone to participate however they feel comfortable and to their talents.
[20:08] <boredandblogging> * Communication is key! *
[20:08] <boredandblogging> So, how are LoCos different from existing Linux user groups (LUG)?
[20:09] <boredandblogging> The main difference is that LoCos are specifically promoting Ubuntu. LoCos are not interested in replacing existing LUGs.
[20:09] <boredandblogging> Instead you should work with LUGs to promote Ubuntu. LUGs can be helpful, like getting a place for LoCos to hold meetings.
[20:10] <boredandblogging> LUGs also provide a good starting point for promoting Ubuntu. There may be existing LUG Ubuntu users who might be interested in advocating Ubuntu.
[20:10] <boredandblogging> Some of you have seen references to approved LoCos. What are they?
[20:11] <boredandblogging> Approved LoCos are officials teams that have been recognized for their ongoing contributions and their plans for promoting Ubuntu in the future.
[20:11] <boredandblogging> Approved LoCos get CDs after every release, hosting for their websites (by Canonical), and materials for booths at conferences.
[20:12] <boredandblogging> LoCos wanting to be approved should provide evidence of their experience in advocacy, support, exhibitions, translations, etc.
[20:12] <boredandblogging> To find out how to get approved, see https://wiki.ubuntu.com/LoCoGettingApproved.
[20:12] <boredandblogging> Currently, there are some ongoing changes in how LoCos will be approved
[20:12] <boredandblogging> The Community Council was responsible for evaluating LoCos and approving them.
[20:13] <boredandblogging> A LoCo Council has been created that will be in charge of approvals from now on.
[20:13] <boredandblogging> Can non-approved LoCos get CDs?
[20:14] <boredandblogging> The best way for non-approved LoCos to get CDs is to have each LoCo member order a few from shipit, then collect them together and distribute them as necessary.
[20:14] <boredandblogging> A common question that is often asked: Having a website would help LoCos grow. Why can't non-approved teams have websites?
[20:15] <boredandblogging> Usually LoCos spend too much time trying to figure out what tools to use on their websites, how it should look, etc. The time is better spent contacting local resources and offering to do presentations or interacting face to face.
[20:15] <boredandblogging> Hopefully most teams will work hard and get approved quickly, so this should not be a problem :-)
[20:16] <boredandblogging> Another common question: I can't motivate anyone. Everyone just idles on IRC!
[20:16] <boredandblogging> This is tough. Many people don't like to take initiative, but like to do things. Try giving them a small specific task to do. They might feel more involved at that point.
[20:17] <boredandblogging> Just for reference, a good starting point for LoCos is https://wiki.ubuntu.com/LoCoTeamKnowledgeBase.
[20:17] <boredandblogging> How do run install fests or other real life events?
[20:17] <boredandblogging> The wiki has a wealth of information.
[20:18] <boredandblogging> See https://wiki.ubuntu.com/LoCoRunningInstallfests
[20:18] <boredandblogging> and
[20:18] <boredandblogging> https://wiki.ubuntu.com/UbuntuAtConferences
[20:18] <boredandblogging> questions?
[20:20] <boredandblogging> face to face meetings can be a good way to get started
[20:21] <boredandblogging> they may be small at first
[20:21] <boredandblogging> but getting to know fellow ubunteros can help people bring together
[20:21] <boredandblogging> and easier to start holding events to promote Ubuntu
[20:22] <boredandblogging> it also allows for better opportunities to find out where your local region needs help
[20:22] <boredandblogging> and can take advantage of the LoCo
[20:23] <boredandblogging> join the loco-contacts mailing list to discuss ideas with other LoCos or just to bounce ideas off of other LoCos
[20:24] <boredandblogging> to see what has worked for other teams
[20:25] <boredandblogging> Leadership in LoCos can be structured in different ways
[20:25] <boredandblogging> some teams have an individual that runs the team
[20:26] <boredandblogging> some have a small group responsible for the direction of the team
[20:26] <boredandblogging> there is no best way, but you should see what works for you LoCo
[20:30] <boredandblogging> Synutx asked if the LoCo can provide commercial support to companies
[20:31] <boredandblogging> specifically if the business opportunity can be done under the LoCo team
[20:32] <boredandblogging> while that really isn't the point of the LoCo team, I would probably encourage creating some kind of legal entity
[20:33] <boredandblogging> while probably partnering with Canonical to provide partner services
 QUESTION i like ti get involved on the danish loCo team What steps do i need to tke ?
[20:34] <boredandblogging> smeg0l: take a look at https://wiki.ubuntu.com/DanishTeam
[20:35] <boredandblogging> i would suggest joining the mailing list, irc channel, and forums
[20:35] <boredandblogging> introduce yourself
[20:35] <boredandblogging> see what they need help with
[20:35] <boredandblogging> and ask for what you can help with
[20:35] <boredandblogging> remember, every LoCo needs help
[20:35] <boredandblogging> every time wants to do lots of different projects
[20:36] <boredandblogging> but there is usually a shortage of people
[20:36] <boredandblogging> smeg0l: I'm sure the Danish Team would love to have you
[20:37] <boredandblogging> next?
 QUESTION: Which locos are setting a good example for others to look at?
[20:38] <boredandblogging> nealmcb: take a look at the approved teams in https://wiki.ubuntu.com/LoCoTeamList
[20:38] <boredandblogging> most of them should be pretty active
[20:39] <boredandblogging> australia and brazil are very active
[20:39] <boredandblogging> also lots of teams in central america
[20:40] <boredandblogging> they are very active in organizing events and holding expos promoting Ubuntu
[20:41] <boredandblogging> for example, the nicaragua team just did the FLISOL 2008 event
[20:41] <boredandblogging> next?
 QUESTION: I'm going to host a program at my local library with another LoCo member (Indiana) to get people to try Ubuntu for one week risk free (thank God for Wubi). What are some things I could do to get people interested and come?
[20:42] <boredandblogging> progfou: prepare instructions on how to install Wubi and hand them out with CDs
[20:42] <boredandblogging> provide URLs for help
[20:42] <progfou> the question was from Toadinator, not mine :-)
[20:42] <boredandblogging> make sure they understand that you are willing to help them out
[20:43] <boredandblogging> you might also want to demonstrate the wubi installtion at the library
[20:43] <boredandblogging> just so they know what to expect
[20:43] <boredandblogging> if you walk them through it in person, they will be more comfortable
[20:44] <boredandblogging> also make sure they have links to the indiana team
[20:44] <boredandblogging> forums, mailing lists, or a contact person
[20:44] <boredandblogging> next?
 QUESTION: What if a LoCo team decided to release a Localized distro based on ubuntu, or localization-package to make it more local ie, more Jordanian in my case; would that hurt if we call it Jordan/Ubuntu ?
[20:46] <boredandblogging> Syntux: that should be fine...
[20:46] <boredandblogging> lots of LoCos localize for their region
[20:46] <boredandblogging> i'm not sure the name is an issue
[20:46] <boredandblogging> next?
 QUESTION: What if a LoCo team decided to release a Localized distro based on ubuntu, or localization-package to make it more local ie, more Jordanian in my case; would that hurt if we call it Jordan/Ubuntu ?
[20:47] <progfou> ooops...
 QUESTION (mine this time): do you know if canonical would sponsorize such localisation?
[20:48] <boredandblogging> what do you mean sponsorize? Like doing official translations through Rosetta?
[20:48] <boredandblogging> I would check Launchpad to see if someone has already started working with your language
[20:49] <boredandblogging> you can find some marketing material on https://wiki.ubuntu.com/MarketingTeam
 QUESTION: Would this be a good time to make a plug for the https://wiki.ubuntu.com/MarketingTeam (since there isn't a session this week for them)?
[20:50] <boredandblogging> if your LoCos does create some new material, I encourage LoCos to put their material on it
[20:50] <boredandblogging> so other LoCos can benefit from it as well
[20:50] <boredandblogging> next
 QUESTION: Any idea when the new Loco Council will first meet to approve new teams?
[20:51] <boredandblogging> the next meeting will be during UDS week actually...
[20:52] <boredandblogging> I'm not sure if it will be taking approval requests then
 what's UDS week
[20:52] <boredandblogging> but it will be widely announced when the LoCo Council is ready
[20:52] <boredandblogging> UDS-Intrepid will be Monday 19th May to Friday 23rd May 2008
[20:53] <boredandblogging> the LoCo Council is working on logistics, so the approval process can be smooth
[20:54] <boredandblogging> and easy for LoCos
[20:54] <boredandblogging> next
[20:54] <progfou> (no other question for now)
 QUESTION: When a Kubuntu team has active members, a forum, a wiki, active IRC, a planet, its own packaging archive, a translation team, participates in many local and national Linux conventions and related events with boots and talks ... why can it not be a Loco team?
[20:55] <boredandblogging> Monika|K: there is nothing wrong with it being a sub-team of a general loco
[20:56] <boredandblogging> but having a separate loco for kubuntu seems too much
[20:56] <jcastro> ~5 more minutes boredandblogging
[20:56] <boredandblogging> too much overlap in resources
[20:57] <boredandblogging> a LoCo can promote Ubuntu, Kubuntu, Xubuntu, etc
[20:57] <boredandblogging> a LoCo doesn't just have to do just gnome Ubuntu
[20:58] <boredandblogging> next?
[20:58] <progfou> (no other question so far)
[20:59] <jcastro> ok that's it for time, thanks Nick!
[20:59] <boredandblogging> thanks everyone
[21:00] <nosrednaekim> hello everyone
[21:01] <nosrednaekim> My name is Michael Anderson, aka, nosrednaekim (extra points to those who can figure out what that stands for)
[21:02] <nosrednaekim> I have been doing community support in #kubuntu (and now #kubuntu-kde4) ever since the release of edgy, so about 2 years.
[21:02] <nosrednaekim> While I do work on the occasional app or bug for Kubuntu, I normally do just user support.
[21:03] <nosrednaekim> At least half of the probems in user support deal with getting hardware functioning (its not called "hard" for nothing).
[21:03] <nosrednaekim> In this session, we will deal with some simple command line applications to:
[21:03] <nosrednaekim> *determine hardware configurations and associated drivers
[21:03] <nosrednaekim> manipulating common hardware components
[21:03] <nosrednaekim>  such as wireless cards, sound chips, and storage devices.
[21:04] <nosrednaekim> Why not graphical applications to do these tasks you may ask?
[21:04] <nosrednaekim> 1) the output of graphical applications is hard to communicate via any text means (forums, IRC)
[21:04] <nosrednaekim> 2) command line output is usually far more informative and easily searchable with grep as well (more on that later)
[21:05] <nosrednaekim> 3) a graphical tool is mot much use when you are trying to fix your video card drivers
[21:05] <nosrednaekim> This information should be invaluable to you if you are either thinking of doing user support, or commonly do installs
[21:05] <nosrednaekim> on different hardware configurations.
[21:06] <nosrednaekim> So first, some commands to determine what your hardware devices are:
[21:06] <nosrednaekim> (if I'm going to fast... someone yell at me in chat)
[21:06] <nosrednaekim> There are three very useful command for this purpose -- lshw, lspci and lsusb.
[21:07] <nosrednaekim> Everyone run lspci in a terminal/console. your output should look something like this:
[21:07] <nosrednaekim> ....
[21:07] <nosrednaekim> 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
[21:07] <nosrednaekim> 01:05.0 VGA compatible controller: ATI Technologies Inc RS485 [Radeon Xpress 1100 IGP]
[21:07] <nosrednaekim> 08:01.0 CardBus bridge: ENE Technology Inc CB-712/4 Cardbus Controller (rev 10))
[21:07] <nosrednaekim> 08:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
[21:07] <nosrednaekim> 08:04.0 Ethernet controller: Atheros Communications Inc. AR2413 802.11bg NIC (rev 01)
[21:08] <nosrednaekim> ...
[21:08] <nosrednaekim> As you can see, I have a not-so-nice ATI card on PCI bus 1:5.0
[21:08] <nosrednaekim> Why is this important? Well, the PCID is a
[21:08] <nosrednaekim> very crucial part of the "Device" section of the many xorg.conf configurations, allowing you to differentiate between multiple video cards in the same configuration file.
[21:09] <nosrednaekim> A host of other information can be gleaned from this output such as exact model numbers for hardware components to google with.
[21:09] <nosrednaekim> Next command is "lsusb". Everyone can run that too if you want. My output is:
[21:09] <nosrednaekim> Bus 002 Device 001: ID 0000:0000
[21:09] <nosrednaekim> Bus 001 Device 003: ID 05e1:0b02 Syntek Semiconductor Co., Ltd
[21:09] <nosrednaekim> Bus 001 Device 001: ID 0000:0000
[21:10] <nosrednaekim> ...
[21:10] <nosrednaekim> Not really exciting since this is a laptop and the only thing I have attached right now is a webcam i'm trying to fight to get working (yes, I have hardware troubles too)
[21:11] <nosrednaekim> Printers and fancy(USB) keybaords will show up here too.
[21:11] <nosrednaekim> ...
[21:11] <nosrednaekim> Onwards! to lshw, the most powerful command of them all.
[21:12] <nosrednaekim> lshw is best run with sudo, since that gives you alot more information.
[21:12] <nosrednaekim> Everyone can run "sudo lshw" if you want.
[21:12] <nosrednaekim> As you can tell, it takes a bit longer and generates quite a bit more information than lspci.
[21:13] <nosrednaekim> Here, you can find good information on everything from your BIOS version to what driver your wireless card is using.
[21:13] <nosrednaekim> Lets run through one of these sections and see what information is included.
[21:13] <nosrednaekim> ....
[21:13] <nosrednaekim> *-multimedia
[21:13] <nosrednaekim>              description: Audio device
[21:13] <nosrednaekim>              product: IXP SB4x0 High Definition Audio Controller
[21:13] <nosrednaekim>              vendor: ATI Technologies Inc
[21:13] <nosrednaekim>              physical id: 14.2
[21:13] <nosrednaekim>              bus info: pci@0000:00:14.2
[21:14] <nosrednaekim>              version: 01
[21:14] <nosrednaekim>              width: 64 bits
[21:14] <nosrednaekim>              clock: 33MHz
[21:14] <nosrednaekim>              capabilities: pm msi bus_master cap_list
[21:14] <nosrednaekim>              configuration: driver=HDA Intel latency=64 module=snd_hda_intel
[21:14] <nosrednaekim> ...
[21:14] <nosrednaekim> This tells us alot of information we already knew from lspci.
[21:14] <nosrednaekim> It also gives us another very crucial piece of information: the driver and kernel module for the device.
[21:14] <nosrednaekim> The module can be used along with rmmod to very effectively disable this piece of hardware or "free it up" for a new driver.
[21:15] <nosrednaekim> for instance, here I would run "sudo rmmod snd_hda_intel"
[21:15] <nosrednaekim> If you want to permanantly disable this module/device, you can place a reference to the module in /etc/modprobe.d/blacklist with
[21:15] <nosrednaekim> 'sudo echo "blacklist modulename" >> /etc/modprobe.d/blacklist '
[21:15] <nosrednaekim> or manually editing that file
[21:16] <nosrednaekim> Ok, lets have a +1 fromeveryone who is keeping up
[21:16] <nosrednaekim> in #ubuntu-classroo-chat of course
[21:16] <nosrednaekim> *classroom
[21:17] <nosrednaekim> ok, great!
[21:17] <nosrednaekim> Finally, a related command to this is "lsmod" which lists the loaded kernel modules.
[21:17] <nosrednaekim> In conclusion, you can "pipe" any of these commands though grep -i (-i makes the search case insensitive) to search for just what you want.
[21:18] <nosrednaekim> For example: "lspci | grep -i ethernet" will return:
[21:18] <nosrednaekim> ...
[21:18] <nosrednaekim> 08:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
[21:18] <nosrednaekim> 08:04.0 Ethernet controller: Atheros Communications Inc. AR2413 802.11bg NIC (rev 01)
[21:18] <nosrednaekim> ...
[21:19] <nosrednaekim> Thats on my computer of course.
[21:19] <nosrednaekim> This is especially useful for IRC support where a pastebin would waste time when you only need one line.
[21:20] <nosrednaekim> ...
[21:20] <nosrednaekim> The next command we are going to explore is "dmesg"
[21:20] <nosrednaekim> Dmesg prints out the errors and status messages from the kernel as stored in /var/log/messages.
[21:20] <nosrednaekim> Dmesg output is useful for seeing the /dev location of newly attached removeable disks, and for many other things such as module loading errors.
[21:21] <nosrednaekim> Normally, when you run dmesg, only the last 50 lines or so are useful for the purpose, so you may want to pipe the output through tail, or only paste that many lines.
[21:22] <nosrednaekim> Now, lets move onto some diagnostics for pieces of hardware that commonly have "issues" within Ubuntu: wireless and sound.
[21:22] <nosrednaekim> As many of you may know, Wireless is an especially finicky piece of hardware and the NetworkManager does not always work either.
[21:23] <nosrednaekim> Iwconfig is the most powerful command for wireless diagnostics. If you have wireless, go ahead and run that.
[21:23] <nosrednaekim> th0      IEEE 802.11g  ESSID:"OpenWRT"
[21:23] <nosrednaekim>           Mode:Managed  Frequency:2.437 GHz  Access Point: FE:ED:FA:CE:DB:EE:F
[21:23] <nosrednaekim>           Bit Rate=54 Mb/s
[21:23] <nosrednaekim>           Power Management:off
[21:23] <nosrednaekim>           Link Quality:48/100  Signal level:-65 dBm  Noise level:-96 dBm
[21:24] <nosrednaekim>           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
[21:24] <nosrednaekim>           Tx excessive retries:1330  Invalid misc:5687   Missed beacon:0
[21:24] <nosrednaekim> ....
[21:24] <nosrednaekim> thats my output
[21:24] <nosrednaekim> From this we can the following useful information:
[21:24] <nosrednaekim> *can gather
[21:24] <nosrednaekim> * the protocol of the card (IEEE 802.11x), if your card is in b mode, it could explain why you are getting slower speeds.
[21:25] <nosrednaekim> * the mode, this should almost always be Managed, unless you are doing somthing special
[21:25] <nosrednaekim> * Number of Errors for different reasons, these can tell you if your antennae is not on, or if you are
[21:25] <nosrednaekim>   not correctly connected to your wireless AP (the error numbers in ifconfig are equally useful for this)
[21:25] <nosrednaekim> You can also change any of these values (except the errors) with the iwconfig command (probably requiring sudo)
[21:26] <nosrednaekim> Run "man iwconfig" to see how each of these (and others) can be changed (but not now since its a fairly long document)
[21:26] <nosrednaekim> The next useful wireless command is "iwlist <devicename> scan"
 is the logical name of the device seen on iwconfig, ath0 for myself
[21:26] <nosrednaekim> This should give a list of AP's, their ESSID and any encryption they may have.
[21:26] <nosrednaekim> Again, this information may be in the NetworkManager, but the text is both more informative and ALWAYS available
[21:27] <nosrednaekim> ...
[21:27] <nosrednaekim> Ok! thats it for networking!
[21:27] <nosrednaekim> Next, lets do some hard drive diagnostics.
[21:27] <nosrednaekim> Here will will have a nice speed contest, so stop watching those movies and playing those games and let your hard drive be dedicated to this benchmark (and your eyes to my talk!!!!)
[21:28] <nosrednaekim> run "sudo hdparm -t /dev/hda" or whatever logical drive name you have, maybe /dev/sda
[21:29] <nosrednaekim> When its finished, paste the MB/sec measurement in -chat, and we'll see who has teh l33test computer :)
[21:31] <nosrednaekim> ok! thank you... as you can see, there is quite a range
[21:31] <nosrednaekim> and I would bet that gscholz has a 4200RPM drive with that number...
[21:32] <nosrednaekim> if you are getting numbers below 10, its not good, and could cause things to run very slowly
[21:33] <nosrednaekim> ok, so that will tell you if a computer might be possibly be performing poorly because of a slow, or under utilized disc
[21:33] <nosrednaekim> hdparm can tell you alot more stuff about your disc, as well as perform some --many potentially dangerous -- performance enhancments
[21:34] <nosrednaekim> I just heard all the ricers listening to this talk suddenly become very interested,So
[21:34] <nosrednaekim> if you are the ricer type, please do read the man page first :)
[21:35] <nosrednaekim> ...
[21:35] <nosrednaekim> Next, is the command "smartctl" for reading the SMART information for your hard drive.
[21:35] <nosrednaekim> you can install it with "sudo apt-get install smartmontools" and execute it with "sudo smartctl --all /dev/hda"
[21:35] <nosrednaekim> of course, changin /dev/hda for your device name
[21:36] <nosrednaekim> Note... if your load count is over 100,000 and you have had your computer for a year or less, you may have the
[21:36] <nosrednaekim> infamous power-management bug which could potentially drastically shorten the life of your drive.
[21:38] <nosrednaekim> Ok, everyone done with that?
[21:38] <nosrednaekim> ...
[21:39] <nosrednaekim> SOUND!
[21:39] <nosrednaekim> lets have a -1 from everyone who has had a problem with this essential function.
[21:40] <nosrednaekim> I'm not very good at sound since it has always Just Worked(tm) for me, and I mostly only have experiece with commands I personally use.
[21:41] <nosrednaekim> However, there is one command that is vital for sound debugging that I have been told about, and that is "alsa-info.sh."
[21:41] <nosrednaekim> you can get it with "wget  http://hg.alsa-project.org/alsa/raw-file/tip/alsa-info.sh"
[21:42] <nosrednaekim> (there is a wiki page for sound troubleshooting here as well where you can get this information https://wiki.ubuntu.com/DebuggingSoundProblems )
[21:42] <nosrednaekim> execute this command with "./alsa-info.sh --no-upload"
[21:43] <nosrednaekim> Include the output of this in your bug report/forum post for better reponses (I personally have no clue about what it all means, so don't talk ot me about it :P
[21:43] <nosrednaekim> crimsun, you about?
[21:44] <nosrednaekim> I guess not.... progfou I can take questions now
 QUESTION: What do the numbers in brackets mean ie [  320.656000] (dmesg output)?
[21:44] <nosrednaekim> gscholz: that is the "kernel time" in seconds since boot
[21:45] <nosrednaekim> next?
 QUESTION: how to get rid of the problem sr0 device?  i am don install new version ubuntu because of this problem
[21:45] <nosrednaekim> I am not aware of that issue or how to fix it, sorry :(
[21:46] <nosrednaekim> next
[21:46] <progfou> (no other question so far)
QUESTION: What does that tell me (load cycle)? How to repare?
[21:47] <nosrednaekim> gsholz, no, it simply tells you that you have an alot of on/off cycles, which depending on the age of the drive, can be very bad
[21:48] <nosrednaekim> A word about what you should include when you make a forum post about certain issues
[21:50] <nosrednaekim> VIDEO/X problems -- always include your /etc/X11/xorg.conf, the output of "lspci | grep -i Vesa" and the contents of "/var/log/Xorg.0.log"
 QUESTION: What if my HDD has a load cycle count over 100K? Is there a script/patch to get around this?
[21:51] <nosrednaekim> if you have a laptop, yes, there is a powermanagement patch to lessen this
 QUESTION: There are plans when (if ever) to include into the Ubuntu distro an application with human interface (GUI) to analyze and configure hardware problems regarding network devices drivers, sound drivers, tvtuner devices?
[21:52] <nosrednaekim> rodolfo: here https://launchpad.net/bug59695.html
[21:52] <nosrednaekim> DoruHush: I am not aware of what Ubuntu has in that regard, but I know Kubuntu(KDE) includes such a app by default
[21:54] <nosrednaekim> DoruHush: the ouput is akin to lshw, so you can't exactly fix things within it though
[21:54] <nosrednaekim> DoruHush: such a application would be very nice though, yes.
[21:55] <nosrednaekim> OK, I hope this session has helped you debug hardware problems better
[21:55] <nosrednaekim> many of the commands I listed have more options, so "man programname" will help you hone your detection skills even better
[21:56] <nosrednaekim> Thank you all for coming out today (and to OpenWeek in general since this is the last general session)!
[21:56] <jcastro> thanks Michael!
[21:56] <jcastro> ok, that was the last session, thanks everyone for coming!
[21:57] <jcastro> and especially to our speakers for giving up their saturday!
[21:57] <jcastro> I am now opening up this room for feedback and questions about openweek itself
[21:58] <nealmcb> jcastro: thanks for putting together a fascinating week!
[21:58] <jcastro> you're welcome, thanks for coming!
[21:58] <nealmcb> a session on marketing might make sense next time
[21:58] <Pusselgenerator> Awesome, learned alot!
[21:59] <bobbo> jcastro: great week :D
[21:59] <nealmcb> too bad we didn't get a training session
[21:59] <nosrednaekim> thanks jcastro :)
[21:59] <jcastro> nealmcb: yeah for sure I will schedule training next time
[21:59] <nosrednaekim> specially for including my last minute request!
[21:59] <Lardarse> jcastro: just before the open week started, i heard a comment about the timing of the open week sessions not being ideal for people who aren't in a timezone that's close to UTC. Are there any plans to look at ths for future open weeks?
[22:00] <jcastro> also the intro to mobile Q+A was interrupted by the presenters DSL messing up so we will reschedule that again as well
[22:00] <ted_> jcastro: Excellent open week, the speakers did a fantastic job.  Thank you.
[22:00] <progfou> yep, great week! even if I sadly miss almost half of it... hopefully we'll get logs online :)
[22:00] <nealmcb> I wonder if a regular schedule of session, like one a week at different times, would work, rather than a firehose of info for a week straight
[22:00] <jcastro> Lardarse: yes I have been knocking the idea of hemisphere-specific openweek, but it's difficult enough to get enough speakers for the one open week
[22:00] <nosrednaekim> progfou: they should all be up by now
[22:01] <progfou> nosrednaekim, ok I'll correct a sudo one right now then ;-)
[22:01] <jcastro> nealmcb: that's a good idea, I will put that down, thanks
[22:01] <nosrednaekim> progfou: ah! forgot about that! heh
[22:01] <nosrednaekim> progfou: thanks
[22:02] <jcastro> I noticed that attendance is down a bunch today (by 100 people), do you guys think it's worth having sessions on a saturday?
[22:02] <Heartsbane> jcastro: not a full day, weekends are for living
[22:02] <jcastro> I agree. :D
[22:03] <Heartsbane> just my .02
[22:03] <progfou> jcastro, I second for the training one! I'm interested in trying to do some in Vietnam and so I'll need to learn how to organize them
[22:03] <Monika|K> I thought weekends would be more attended
[22:03] <Monika|K> because there would not be so much time zone difficulties
[22:04] <jcastro> Monika|K: I was expecting that as well
[22:04] <progfou> (note: we'll do that in native language here, so we'll need some translation work, which means access to materiel first...)
[22:04] <nosrednaekim> monday and tuesday sessions were packed..
[22:04] <Monika|K> How was Thursday, as a holiday in most of the world?
[22:05] <Heartsbane> jcastro: maybe a way to solve the timezone difficulty would be a audio component, a podcast but then again I have suggested something like this when I met you
[22:05] <nosrednaekim> eh... what holiday was Thursday?
[22:05] <nosrednaekim> <_<
[22:05] <jcastro> nearly every session had around 300-350 people in the channel
[22:05] <Monika|K> there were two holidays on Thursday
[22:05] <jcastro> except today, where we hovered around 200-ish
[22:05] <nealmcb> publishing stats on attendance would be nice, to help us all figure out what might be worth changing
[22:05] <Monika|K> one: the first of May, worker's day
[22:05] <nosrednaekim> ah.... ok... that comes a month later here in the US
[22:05] <Monika|K> and the other is always a Thursday ... means something like Christ going back to heaven
[22:06] <Monika|K> no idea what it's in English
[22:06] <progfou> Monika|K, and the 30 of April in Vietnam ;-)
[22:06] <nosrednaekim> the day of Assencion?
[22:06] <Monika|K> could be
[22:07] <Monika|K> 1st of June is worker's day in the US?
[22:07] <Monika|K> that's children's day ... but it's not a holiday (not free)
[22:07] <Monika|K> Friday was weird at work, I was almost alone in my department <g>
[22:07] <nosrednaekim> erm... sorry, I was mixed up... too much coffee I guess :)
[22:08] <nosrednaekim> Memorial day is later this month
[22:08] <nosrednaekim> and Labor day is in Sept. :)
[22:08] <BonesolTeraDyne> I've got one major suggestion: Encourage the speakers to loosen up on their speeches. It seemed like the business-esqe talks didn't get as much in the way of attendance\interest.
[22:08] <jcastro> BonesolTeraDyne: example?
[22:09] <nosrednaekim> progfou: BTW... thanks for handling questions
[22:09] <BonesolTeraDyne> Nixternal's talk seemed to pull in the crowd, while... grr... I can't think of the one I wanted to use
[22:10] <nosrednaekim> haha... nixternal is awesome :)
[22:10] <Monika|K> he's cool
[22:10] <progfou> nosrednaekim, you're welcome :)
[22:10] <Heartsbane> nixternal was awesome
[22:10] <BonesolTeraDyne> nosrednaekim: he is our version of balmer, after all
[22:10] <nosrednaekim> !nixternal
[22:10] <BonesolTeraDyne> And no, I don't plan on letting him live it down
[22:10] <nosrednaekim> belh... no bot
[22:11] <jcastro> btw you can also send feedback to me via mail - jorge (at) ubuntu.com
[22:11] <nealmcb> nixternal: "ubottu: Oh no!  The pointy-clicky Vista lover has arrived!  He's rumoured to be giving out free money, too!"
[22:11] <BonesolTeraDyne> XD
[22:12] <Monika|K> We're thinking about doing something like Ubuntu Open Week for D-A-CH (German-speaking countries), but the planning is not very far yet, not sure if it will work out.
[22:12] <stdin> bit late, but the bots here now
[22:12] <BonesolTeraDyne> XD
[22:13] <nosrednaekim> !Riddell
[22:13] <Monika|K> certainly not 7 hours a day
[22:13] <jcastro> Monika|K: yeah I believe the dutch team islooking about doing a localized "openweek"
[22:13] <BonesolTeraDyne> Ah,I enjoyed Open Week. Well, what I could attend of it, anyway. Had to go to work on Mon, Wed, and Fri.
[22:13] <jcastro> if there is people-power to do localized openweeks then that would also handle the timezone problem as well
[22:14] <Monika|K> yes, that's the main thought behind it
[22:14] <Monika|K> and doing it in German, of course ;)
[22:14] <Monika|K> even though essentially all Germans speak English, chats are too fast for many
[22:15] <nealmcb> jcastro: does the doc team mine the transcripts for adding to the wiki and docs in any organized way?
[22:15] <jcastro> the scribes team have been doing that iirc
[22:16] <nealmcb> :-)
[22:16] <nealmcb> asking for questions ahead of time somehow might be handy also, to help with timezone stuff
[22:17] <nealmcb> e.g. on a wiki page
[22:18] <progfou> e.g. on the log wiki page
[22:18]  * nealmcb nods
[22:18] <progfou> since the links are ready as soon as the week is planned
[22:18] <nosrednaekim> that might work for the Ask Mark session, but I don't think it'd work for ones in which things are taught like "python packageing"
[22:18] <jcastro> yeah, plus the realtime aspect is what makes it interesting
[22:18] <jcastro> otherwise it'd be just like a forum thread
[22:18] <progfou> that's true...
[22:19] <tzeentch__> jcastro: you say someone from the scribes team might be creating docs based on the session logs?
[22:19]  * nealmcb notes the note at the top of https://wiki.ubuntu.com/MeetingLogs/openweekhardy/ReportBugs2
[22:19] <jcastro> tzeentch__: maybe for some things? usually sessions refer to existing docs
[22:19] <nealmcb> jcastro: yeah - I'd give preference to live questions.  but some sessions ended early for lack of questions, and some presenters didn't know what folks were most interested in
[22:19] <progfou> no, he said they « have been doing that » ;-)
[22:20] <jcastro> they have been posting the logs ups
[22:21] <tzeentch__> jcastro: any idea how to let them know to skip 'python packaging' one? just to avoid duplicated effort. i created a tutorial from it (on stani's request).
[22:21] <progfou> are the logs managed manually? (I'm currently waiting for this one: https://wiki.ubuntu.com/MeetingLogs/openweek/hardy/hardwareDB )
[22:21] <tzeentch__> ah, ok
[22:22] <jcastro> tzeentch__: you can add something to the top of the log as in "Check out the guide _here_, this info is now deprecated" or something like that
[22:22] <progfou> tzeentch__, thanks for this work! where will you put it?
[22:22] <jcastro> progfou: yeah someone has been doing them, but if you want and have logs feel free to add them
[22:22] <stdin> progfou: yes, someone has to manually enter them into the wiki after formatting them nicely
[22:22] <tzeentch__> jcastro: ok, it's on the wiki: https://wiki.ubuntu.com/PackagingGuide/Python
[22:23] <jcastro> tzeentch__: oh cool!
[22:23] <jcastro> tzeentch__: link to that page on top of the log but keep the original log intact for archival purposes
[22:23] <tzeentch__> jcastro: no probs
[22:24] <nealmcb> tzeentch__: yeah - pretty!
[22:24] <progfou> stdin, done (I've uploaded my log from XChat), but what's the meaning of "formatting them nicely" here?
[22:25] <nealmcb> tzeentch__: you might want to link the other way also, to help people find it and other openweek transcripts
[22:25] <jcastro> ok any more burning feedback? I need to get food soonish
[22:25] <tzeentch__> nealmcb: heh, thanks! ok, will do
[22:25] <nealmcb> :-)
[22:26] <stdin> progfou: just making sure it has not clutter like join/part messages
[22:26] <nealmcb> jcastro: you've earned a nice meal.....
[22:26] <jcastro> and a beer!
[22:26] <nealmcb> \o
[22:26] <stdin> progfou: where did you upload it?
[22:27] <Monika|K> free beer as in free beer ;)
[22:27] <progfou> jcastro: I would like to complain about last-moment changes... it really is a pain when you are in GMT+0700 ! but the quality of the sessions would let me forgive everything ;-)
[22:28] <nealmcb> Monika|K: Prost!
[22:28] <Monika|K> :-)
[22:28] <jcastro> progfou: yeah, that was unfortunate. :-/
[22:28] <jcastro> that is not a normal thing we do
[22:28] <Monika|K> what happened? people sick?
[22:29] <jcastro> mark's schedule got wonked for us at the last minute. :-/
[22:29] <jcastro> ok off to dinner, feel free to hang out!
[22:29] <progfou> stdin, on the wrong page... :-P I've just redone it
[22:29] <Monika|K> what's wonked
[22:29] <progfou> have a nice dinner! :)
[22:29] <nealmcb> Monika|K: abruptly changed
[22:29] <stdin> progfou: looks good to me
[22:30] <nealmcb> or fouled up
[22:31] <Monika|K> gute Nacht
[22:36] <progfou> stdin, should the log be kept exactly as the original or may I have the right to correct some errorneus command line? (acknowleged by the author)
[22:37] <sucitrams_> good night all
[22:38] <stdin> progfou: if the commands are dangerous then I would say it's a good idea, but if they aren't (and the author corrects them) then I don't see a reason to
[22:38] <stdin> I'd rather the log was as un-tampered with as possible, it is a log after all ;)
[22:39] <progfou> the command is not dangerous, but not useful too because of the mistake (so the reader may be misguided because of this error) ; the author forgot to correct it during the session, that's why I proposed him to correct it
[22:40] <stdin> if the correction isn't in the log, then go, correct it :)
[22:47] <progfou> done, and so I've finished with my DUD (Daily Ubuntu Duty) and I have the right to go to sleep and have nice dreams ;-)
[22:48] <progfou> see ya everyone!
[22:48]  * progfou is gone to sleep... ZZZzzz
[22:48] <stdin> good night
[22:48] <nosrednaekim> later