[00:07] <DieSetter> is there anyway to install 9.10 but use the network driver from the 9.04 live cd
[00:08] <Doorman352> If you can let me know, Iḿ having issues with my laptop and have to use 9.04 ......
[00:08] <DieSetter> the one that ships with 9.10 restricts my network speeds to 45kps
[00:09] <Doorman352> Was it something I said?
[00:22] <IdleOne> Doorman352: and DieSetter please join #ubuntu for support.
[00:40] <rockstar1> Hello! Does anybody knows some tutorial to install Ubuntu on Intel-based Macbook?
[00:40] <IdleOne> !install
[00:40] <ubot2> Ubuntu can be installed in lots of ways. Please see https://help.ubuntu.com/community/Installation for documentation. Problems during install? See https://wiki.ubuntu.com/CommonProblemsInstall and https://wiki.ubuntu.com/DapperReleaseNotes/UbiquityKnownIssues - Don't want to use a CD? Try http://tinyurl.com/3exghs - See also !automate
[00:41] <IdleOne> rockstar: please join #ubuntu for further support
[00:50] <rockstar> IdleOne, I think you're talking to the wrong one of us.  :)
[00:51] <IdleOne> lol rockstar sorry
[00:51] <rockstar> :)
[00:51] <IdleOne> but  now you know :P
[05:09] <ccm> 1/3
[05:09] <ccm> ups
[06:55] <amonch> hello everyone
[06:56] <jmarsden> amonch: This is #ubuntu-classroom.  There is no class right now.  If you are seeking help about Ubuntu, try in #ubuntu
[06:56] <amonch> been looking for someone who can teach me to set-up a server in a classroom laboratory
[07:19] <roots> Hello
[07:19] <roots> Im I welcome to this class?
[07:20] <roots> Im a newbie to linux. May you assist me with all the necessary documentation to be able to setup a mailserver in ubuntu
[07:21] <roots> exit
[07:22] <jmarsden> roots: This is #ubuntu-classroom.  There is no class right now.  If you are seeking help about Ubuntu, try in #ubuntu or for servers try #ubuntu-server
[10:59] <jj3502> No screensaver when running on battery
[10:59] <jj3502> ?
[11:01] <Forlon> jj3502: try in #ubuntu, this is no supportchannel here :-)
[13:11] <Animagladius> Huhu.
[14:14] <Sertse> xubuntu is first when it starts right?
[14:14] <charlie-tca> yes
[14:15] <Sertse> Thanks.I see you're helping presenting it :) Gotta be a good day for me, xubuntu, +1 and ofc..sabfl.
[14:15] <charlie-tca> Gotta be!
[14:30] <yadudoc> jvc007 ?
[14:59] <jcastro> Gooooood morning everyone
[14:59] <jcastro> we'll start in one minute
[14:59] <jcastro> with Xubuntu - Lot's kittens and mice
[14:59] <jcastro> charlie-tca, you may begin whenever you're ready!
[15:00] <charlie-tca> Thanks,
[15:00] <charlie-tca> jcastro
[15:00] <charlie-tca> I'm Charlie Kravetz, known as charlie-tca on irc and the mailing lists. I am Xubuntu Quality Assurance Lead.
[15:01] <charlie-tca> We are going to talk a bit about my favorite flavor this morning, Xubuntu.
[15:01] <charlie-tca> We will take your questions in #ubuntu-classroom-chat, and
[15:02] <charlie-tca> will have a few minutes at the end to answer questions you hold on to. Feel free to ask questions at any time,
[15:02] <charlie-tca> but please start them with QUESTION: so they easy to spot. For example,
[15:02] <charlie-tca> QUESTION: What is Xubuntu?
[15:03] <charlie-tca> The answer would then be
[15:03] <charlie-tca> Xubuntu is Ubuntu with the Xfce desktop. Xfce emphasizes conservation of system resources, which makes Xubuntu an excellent choice for any system, new or old.
[15:04] <charlie-tca> Notice, that does not say "old only"
[15:04] <charlie-tca> I do run an Athlon amd64 to use daily
[15:04] <charlie-tca> As a ubuntu derivative, Xubuntu maintains the same high standards and quality that Ubuntu has. We still have bugs to track down and resolve, and we do help with the bugs in Ubuntu also. Testing is a combined effort, since the releases are on the same schedule.
[15:05] <charlie-tca> Xubuntu is an ideal candidate for older hardware or low-end machines, thin-client networks, or those who would like to get more performance out of their hardware.
 QUESTION: With LXDE coming in as the new low-resource desktop, is XFCE going to shift to become more of a full-power desktop like Gnome and KDE, or will it try and lower it's resource requirements to compete with LXDE?
[15:06] <charlie-tca> I don't see a need to shift at this time. Of course, Xubuntu does not drive Xfce, either. We incorporate it, just as Ubuntu uses Gnome.
[15:07] <charlie-tca> As for lowering the resource requirements, there are many other distributions out there with lower requirements already.
[15:08] <charlie-tca> As a ubuntu derivative, Xubuntu maintains the same high standards and quality that Ubuntu has. We still have bugs to track down and resolve, and we do help with the bugs in Ubuntu also. Testing is a combined effort, since the releases are on the same schedule.
[15:09] <charlie-tca> Also, Xubuntu is the Xfce-based distribution with a native 64-bit architecture. We produce both a 32-bit and 64-bit versions, and ports for the Mac PowerPC and Sony PlayStation 3.
 QUESTION: Are the PPC ports fully supported?
[15:10] <charlie-tca> Great question!
[15:11] <charlie-tca> Unfortunately, we can not fully support the ports. There are, however, two freenode channels where our developers with macs hang out
[15:12] <charlie-tca> Both #ubuntu-powerpc and #ubuntu-ps3 are available
 Question: GNOME and KDE are already fast, especially when compare some other OS's (not going to say which, we all know), is there really any need XFCE? how much of a performance boost is one likely to get?
[15:14] <charlie-tca> Again, let's not confuse desktop environments with distributions. I agree, Ubuntu and Kubuntu are fast. Can I run them on a PII with a 400MHz CPU?
[15:14] <charlie-tca> It has 256MB ram. I haven't been able to. I can run Xubuntu on it, though
 QUESTION: How does Xubuntu respond to claims that it is rather fat for an xfce distro, and thus misrepresents xfce? Many people draw conclusions on xfce from xubuntu. Xfce itself is rather light.
[15:16] <charlie-tca> Thanks for asking that. We agree with it.
[15:17] <charlie-tca> As a dirivative of Ubuntu, we rely on a number of applications from Ubuntu. This does cause some bloating for Xubuntu. We attempt to keep as many lightweight
[15:18] <charlie-tca> applications as possible, though. In 9.10, installed from the desktop cd, you pull in OpenOffice.org. You can remove it, and in Lucid, it will not pull it in.
[15:18] <charlie-tca> The bloat is a price we pay for staying a part of Ubuntu
 QUESTION: The Acer Aspire One and early Moblin demo's were based on XFCE, but recently UNR/Gnome, plasma-netbook/KDE and Clutter/Moblin have taken the limelight. Are there plans for an XFCE/Xubuntu netbook variant?
[15:20] <charlie-tca> I don't have an answer to this at this time.
[15:22] <charlie-tca> I have a question about why the gnome desktop ran after Xubuntu was installed along side of Ubuntu.
[15:23] <charlie-tca> You can install Ubuntu or Kubuntu or both, then install Xubuntu. This allows you to switch between the desktops and applications as you wish.
[15:24] <charlie-tca> Sometimes, when you do this, as you log in, you must tell gdm what session you want to run. At the bottom of the login screen, there is a selector for xfce, gnome, kde
[15:24] <charlie-tca> This normally is invisible until you tell gdm who is logging in.
[15:25] <charlie-tca> There is also a setting to tell the system if you want gnome, kde, or xfce to be the default environment
 QUESTION: I am a new to Gnu/Linux, if Kernel, File system and Desktop is being developed by an independent communities. What exactly is ubuntu, Kubuntu or Xubuntu community is doing? Are they just combining all these components and giving it a new name?
[15:27] <charlie-tca> Great question from a new Gnu/Linux user! In Windows, everything came from one place, basically, Microsoft.
[15:28] <charlie-tca> In Linux, a desktop environment is built of many small applications. A distribution is built of many more applications, which may or may not include the desktop environment.
[15:29] <charlie-tca> So, yes, Ubuntu, Kubuntu, and Xubuntu are combining many applications to make something easy to use.
[15:29] <charlie-tca> without them, it could take you two or three or four weeks of running programs without a graphic environment to get what we give you.
 QUESTION: Xubuntu seems to be trying to look the same as the default Gnome setup in Ubuntu, why not do your own style like Kubuntu does?
[15:30] <charlie-tca> Glad you asked!
[15:31] <charlie-tca> I could not tell you what the desktop in Gnome looks like in Ubuntu 9.10
[15:31] <charlie-tca> I have not actually seen it. If it does look like Xubuntu, that was an accident on our part.
 QUESTION: Does Xubuntu have any contacts with upstream? I remember there used to be an liason at one point.
[15:34] <charlie-tca> Yes, we do maintain contacts with upstream. While we no longer have a liason in Xfce, we do talk to developers in Xfce daily, also with developers in Gnumeric, Exaile, and other upstream projects.
[15:35] <charlie-tca> Well, that looks like enough questions for now. Hopefully, I answered all of them. If I missed yours, please ask it again.
[15:38] <charlie-tca> As a dirivative of Ubuntu, we are not officially sponsored by Canonical as Ubuntu and Kubuntu are. Xubuntu receives no funding from Canonical.
[15:38] <charlie-tca> All of the developers and team members are volunteers.
[15:38] <charlie-tca> We report bugs found through launchpad. Brian Murray gave a great session on "Reporting Bugs" on Monday. If you missed that session, there are full logs of all the sessions maintained on the wiki.
[15:39] <charlie-tca> Just go to the schedule, https://wiki.ubuntu.com/UbuntuOpenWeek/ , and click on the session you wish to review. I do much of the bug triage for Xubuntu, and most of our bugs in Xfce are forwarded upstream.
[15:39] <charlie-tca> We do verify a number of the bugs reported to Xfce from other sources.
[15:40] <charlie-tca> We work very close with upstream xfce, abiword and gnumeric bug teams to help resolve the bugs found. Once you report a bug, it goes through a process called bug triage.
[15:40] <charlie-tca> You will find that I often triage the Xfce, Abiword, and Gnumeric bugs for this reason. I am also the bugsquad contact for these bugs.
[15:41] <charlie-tca> We will work very closely to the Ubuntu bugsquad when triaging, and follow the guidelines set in https://wiki.ubuntu.com/Bugs/HowToTriage. A very important idea in triaging for Xubuntu is that just because only one person had a failure, that does not make it invalid.
[15:42] <charlie-tca> At this time, I would like to hit on some of the key points in Xubuntu 9.10, otherwise known as Karmic Koala.
[15:42] <charlie-tca> Xubuntu now has Xfce 4.6.1, which included many bug fixes.
[15:43] <charlie-tca> In work at Xfce is 4.8, which will have the menu editor. It is scheduled for final release April 18, which may be too late for Lucid, but could make the .1 upgrade
[15:44] <charlie-tca> Xubuntu 9.10 includes the Exaile 0.3.0.x music player to make enjoying podcasts, streaming radio, audio books, and music library easier than ever before.
 QUESTION: why was OpenOffice.org included now in 9.10, but going to be removed again in 10.04?
[15:45] <charlie-tca> Good question! OpenOffice.org slipped passed the testers. It is not normally included in Xubuntu, due to the size.
[15:45] <charlie-tca> It will be removed in future releases because it does not meet Xubuntu's requirements for lightweight applications.
 QUESTIONS: Why does Xubuntu use  GDM,  rather than it's own Display Manager?  Also isn't really XFCE just a window manager, instead of being a desktop environment such as Gnome or KDE?  As for xubuntu-desktop it's just XFCE with some choosen apps right? If so that's probably why there isn't a XFCEDM, or whatever it would be called, because XDM already exists.
[15:46] <charlie-tca> Thanks for asking, sebsebseb
[15:47] <charlie-tca> Xubuntu uses GDM because it is included in Ubuntu. We are a small team, and if Ubuntu has an application that works for us, we can have our developers work on other, more important tasks.
 QUESTION: What's going on with XFCE's settings backend?  Is it going to use the same as Gnome?
[15:50] <charlie-tca> Before I answer this, let me step back a minute
[15:51] <charlie-tca> I want to touch on the names we use for a minute. Xubuntu uses many applications to maintain lightweight, usable environment.
[15:51] <charlie-tca> Whether that application contains the name KDE, Gnome, Xfce, Lxde, etc, does not really come into the decision making process.
[15:52] <charlie-tca> We are looking for applications that work the best for Xubuntu. If the name mattered, most applications won't work. If the name doesn't matter, many applications will work.
[15:53] <charlie-tca> GDM is Gnome Display Manager. We use it for a log-in screen. It works for that.
[15:54] <charlie-tca> Now back to mhall119|work question. We aren't using Gnome's backend. We do use the parts that work for us.
[15:57] <charlie-tca> Does anyone know why was the name "Xubuntu - Lots of Kittens and Mice" given for this session? it does't seems to be related.
[15:57] <charlie-tca> Let's tackle this one, even though it is not actually being asked.
[15:58] <charlie-tca> Xfce's logo is a mouse. Xubuntu uses that mouse inside the "human circle of friendship" of Ubuntu. And, what good are mice without kittens?
[15:59] <charlie-tca> The kittens chase the mice round and round
[15:59] <charlie-tca> I want to thank all of you for being here.
[15:59] <charlie-tca> If you want to join the *developer* team, there is #xubuntu-devel and there is also the developer mailing list, https://lists.ubuntu.com/mailman/listinfo/xubuntu-devel
[16:00] <jcastro> thanks a bunch charlie-tca!
[16:00] <charlie-tca> As part of one of the best, fastest growing distributions available, we welcome anyone who would like to assist in development, testing, and bug triage!
[16:00] <jcastro> ok we'll give it a minute and then I will start the next session, how to run Ubuntu+1 "aka the development release"
[16:01] <jcastro> ok
[16:01] <jcastro> thanks for coming to my session, let's begin!
[16:01] <jcastro> First off, I'd like to introduce myself. My name is Jorge Castro and I work on the Ubuntu Community team doing upstream developer relations. I've been using Ubuntu since 4.10 (the Warty Warthog) and Debian for many years before that.
[16:01] <jcastro> I've spent a great deal of time running developmental releases and things that generally break your computer, so I thought I would share this information with people, since I've been in the situation many times where I have turned my computer until a pile of molten slag.
[16:01] <jcastro> I've written up some parts, we'll get through that - then we'll open up it up for some questions.
[16:02] <jcastro> Recently I've noticed more and testers using the Ubuntu developmental release, what lot's of people call "Ubuntu+1". Currently Ubuntu+1 is the lucid "lucid lynx".
[16:02] <jcastro> This is really good
[16:02] <jcastro> because more testing is always needed
[16:02] <jcastro> However just because you are testing doesn't mean you want your OS to stab you in the face.
[16:02] <jcastro> Running +1 back in the old days was relatively easy because most of the users were already experienced with The Debian System(tm) and how it worked. However as more and more people started using Ubuntu and the promise of new bling crept around the corner more and more people started using it, and breaking it, so I thought I'd have a session on how to not blow up your computer.
[16:03] <jcastro> First off
[16:03] <jcastro> there are some guides out there already!
[16:03] <jcastro> https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases
[16:03] <jcastro> and more recently http://ubuntuforums.org/showthread.php?t=1286309
[16:04] <jcastro> however I find that the best method is what you learn by sometimes painful experience!
[16:04] <jcastro> Now, there are many ways Ubuntu developers run their development release. Some prefer apt-get, some do aptitude. I will be discussing the way I do it because I've managed to stay out of trouble for three releases in a row! Also, even if you use different tools the concepts I talk about will apply.
[16:04] <jcastro> (some use synaptic, etc.)
[16:05] <jcastro> So first off, let's talk about why you WOULDN'T want to run a a dev release like lucid
[16:05] <jcastro> a) You need to get work done
[16:05] <jcastro> and b) Computer downtime or dataloss isn't an option
[16:05] <jcastro> so, for example I know many ubuntu developers stick to a stable release
[16:05] <jcastro> and use pbuilder or a VM to test their packages
[16:05] <jcastro> some people have multiple machines
[16:06] <jcastro> I personally always keep my laptop on a stable release until beta-ish
[16:06] <jcastro> but on my desktop I let it rip with the brokeness.
[16:06] <jcastro> either way, you should ensure that your data is backed up and safe
[16:06] <jcastro> Of course, if you use your computers for work I recommend using VMs or spare hardware
[16:07] <jcastro> however
[16:07] <jcastro> if you're a sysadmin or deploy ubuntu
[16:07] <jcastro> setting aside spare hardware to help us test ubuntu would  be most appreciated!
[16:08] <jcastro> for most people, Virtual Machines will do the trick
[16:08] <jcastro> unless you want to test hardware
[16:08] <jcastro> so for example, if you have an infamous broadcom wireless card that doesn't work well, you might have problems
[16:09] <jcastro> ok
[16:09] <jcastro> so I am going to go through the steps that I take to run the release
[16:09] <jcastro> the first step is to actually run it. :D
[16:10] <jcastro> this is accomplished by downloading one of the alpha CDs, a daily CD, or upgradiing in place
[16:10] <jcastro> If you download a new CD, you want to use something like a mirror or zsync to save bandwidth
[16:11] <jcastro> if you upgrade in place I recommend "update-manager -d"
[16:11] <jcastro> (old school fans, replacing "karmic" with "lucid" in your sources.list still works)
[16:12] <jcastro> there are three major things you need to check before you upgrade
[16:12] <jcastro> (and that goes for the subsequent daily upgrades)
[16:12] <jcastro> here are the sources I check: http://people.canonical.com/~ubuntu-archive/testing/lucid_probs.html
[16:12] <jcastro> this one is handy
[16:12] <jcastro> it tells you what's broken in the archive right now
[16:13] <jcastro> so if you see important-looking things in here, you might want to wait
[16:13] <jcastro> since it's the beginning of lucid it's not surprising to see kernel packages and stuff in there
[16:13] <jcastro> the second thing to check is the -changes mailing list
[16:13] <jcastro> https://lists.ubuntu.com/mailman/listinfo/lucid-changes
[16:14] <jcastro> which has the upload changelogs
[16:14] <jcastro> here's an example
[16:14] <jcastro> https://lists.ubuntu.com/archives/lucid-changes/2009-November/000177.html
[16:14] <jcastro> (protip, the RSS feeds for these packages are here: http://feeds.ubuntu-nl.org/UbuntuChanges )
[16:14] <jcastro> as you run the dev release you'll start to learn how to read changelogs
[16:14] <jcastro> and why that's important
[16:14] <jcastro> usually if you see a package you'll start to learn how things work
[16:15] <jcastro> so for example if you see "New upstream release" in a small gnome game or something, it'll be safe
[16:15] <jcastro> but if it's a bunch of kernel packages and a changelog miles long, that might be worrisome
[16:15] <jcastro> after a while you'll learn about how packages interact with each other
[16:16] <jcastro> and then the third thing I check is the dev forum: http://ubuntuforums.org/forumdisplay.php?f=377here
[16:16] <jcastro> By now if someone has a problem and can't figure it out
[16:16] <jcastro> it might be posted here
[16:17] <jcastro> With all three of those sources you should have a good idea how +1 is for the moment
[16:17] <jcastro> remember that uploads happen all the time
[16:17] <jcastro> so at any given point the archive is in a different state
[16:17] <jcastro> I personally upgrade twice a day
[16:17] <jcastro> once in the morning, and in the afternoon
[16:17] <jcastro> and before each of those I check all three of those, just to be sure
[16:17] <jcastro> ok, after that you decide "ok this looks safe enough"
[16:18] <jcastro> or "no way, that's crazy"
[16:18] <jcastro> that's when I do the update step: sudo apt-get update
[16:18] <jcastro> a quick thing here
[16:18] <jcastro> a bunch of people just think they can run +1 and have update manager just fire off daily and they can click a button and be happy
[16:19] <jcastro> this probably will lead to tears
[16:19] <jcastro> in fact, if you're not comfortable with apt-get (or aptitude if you use that) and dpkg itself you can easily paint yourself into a corner
[16:19] <jcastro> so ensure that you read the man pages and documentation on those tools
[16:19] <jcastro> ok
[16:19] <jcastro> after the update you want to go ahead and do the upgrade
[16:20] <jcastro> which is: sudo apt-get upgrade
[16:20] <jcastro> now, here is where everyone gets confused
[16:20] <jcastro> (if you've been ignoring the whole session this is the important part)
[16:20] <jcastro> you always need to remember in the back of your head that the  archive is always changing in a dev release
[16:20] <jcastro> and things are connected in all sorts of ways
[16:21] <jcastro> so for example, when calc uploads openoffice.org, it's a TON of packages
[16:21] <jcastro> and sometimes it takes a while for things to build
[16:21] <jcastro> so for large packages sometimes chunks land right away
[16:21] <jcastro> sometimes not
[16:21] <jcastro> plus you have to wait for the mirrors to propagate, etc.
[16:21] <jcastro> so, in order to protect you
[16:22] <jcastro> apt says "well, he's missing some parts, let me hold back these packages so it doesn't break"
[16:22] <jcastro> when this happens apt tells you "the following packages have been held back:" and then a list of stuff
[16:22] <jcastro> when this happens to me I let it hold those packages back
[16:22] <jcastro> and let the upgrade continue
[16:23] <jcastro> if I see a package held back over the course of a few days then I try to seperately apt-get installing them
[16:23] <jcastro> so, let's say openoffice.org-awesomeness is held back
[16:23] <jcastro> because the rest of OOo is building
[16:24] <jcastro> in a few days I do "sudo apt-get install openoffice.org-awesomness"
[16:24] <jcastro> now I get more detail
[16:24] <jcastro> usually if it hasn't worked itself out it's because something significant has changed
[16:25] <jcastro> sometimes it looks scary
[16:25] <jcastro> it might say "library3 will be REMOVED, library4 will be installed" or something like that
[16:25] <jcastro> so this means that someone has updated the libraries
[16:25] <jcastro> so this is fine
[16:25] <jcastro> and I just let it finish and it does the upgrade
[16:25] <jcastro> sometimes a package is going through what we call a transition
[16:26] <jcastro> so let's say program A used to use library A, but now wants to use library B.
[16:26] <jcastro> this will cause it to be held back
[16:26] <jcastro> so you'll have to go back and work it  out
[16:26] <jcastro> however, since you've read the changelogs I mentioned above
[16:26] <jcastro> usually there should be no surprise
[16:26] <jcastro> the maintainer will put in the log something like "transitioning this to libfoo" or something
[16:27] <jcastro> there will also be announcements for major things on the development list
[16:27] <jcastro> particularly with sensitive things like boot stuff
[16:27] <jcastro> and since you also check the forums before you upgrade (right?) you'll see the scattered bodies of people who have not read the changelogs. :D
[16:27] <jcastro> one thing I do NOT recommend
[16:28] <jcastro> is just do sudo apt-get dist-upgrade
[16:28] <jcastro> this is the cause of many problems
[16:28] <jcastro> in fact, you'll see people posting this all over the internet
[16:28] <jcastro> the "problem" with dist-upgrading blindly is that it does what it's designed to do
[16:28] <jcastro> it reads the package lists of things that are supposed to be installed
[16:28] <jcastro> and it doesn't really account for the archive changing
[16:30] <jcastro> so it thinks "well, he said he wanted openoffice.org upgraded, but it's missing openoffice.org-awesome, however, I can't stand the package system being in an unknown state, so let's be safe an remove openoffice.org entirely"
[16:30] <jcastro> this is how people end up removing half their GUI or weird things like that
[16:30] <jcastro> so, remember dist-upgrade is for moving from stable release to stable release
[16:31] <jcastro> if the archive is being uploaded to and dependencies are changing, this will doom you
[16:31] <jcastro> so remember, just do a normal "upgrade"
[16:31] <jcastro> and if something is held back, let it sit there a bit
[16:31] <jcastro> and it will usually work itself out over the next few hours or days
[16:31] <jcastro> any questions on this so far?
[16:31] <jcastro> I want to make sure everyone is clear about the dist-upgrade
[16:32] <jcastro> (ask questions in #ubuntu-classroom-chat)
[16:32] <jcastro> wow, no questions, awesome
[16:32] <jcastro> ok
[16:32] <jcastro> so, after you've done the upgrade, you're not done!
[16:32] <jcastro> depending on what you upgraded you might need to do things
[16:33] <jcastro> so for example if you have firefox open and firefox upgrades we tell you to restart firefox (just in case)
[16:33] <jcastro> also, if you get a new kernel you'll need to reboot
[16:33] <jcastro> if you get a new GNOME or KDE you'll want to log out and back in
[16:34] <jcastro> while stable releases run great for days and days
[16:34] <jcastro> during the devel release you'll want to make sure you're running the latest thing and given the program a chance to run
[16:34] <jcastro> otherwise your bugs will be worthless
[16:34] <jcastro> Question: where can we get the Lucid ISO? or do we have to install Karmic and go from there?
[16:35] <jcastro> there are no ISOs at this point, you'll have to upgrade from karmic
[16:35] <jcastro> ok, some other pointers
[16:35] <jcastro> you can get a feel for what's going on depending on what week it is
[16:35] <jcastro> https://wiki.ubuntu.com/LucidReleaseSchedule
[16:35] <jcastro> so for example
[16:36] <jcastro> right now we're syncing with debian
[16:36] <jcastro> and UDS hasn't happened yet
[16:36] <jcastro> so there will be a bunch of syncs
[16:36] <jcastro> also, if you look at all the freezes on the schedule you can also figure out how safe the archive will be
[16:37] <jcastro> so, the week before feature freeze it's likely to be very busy
[16:37] <jcastro> and during UDS week it's likely slowed down
[16:37] <jcastro> I know some people who wait for a certain point
[16:37] <jcastro> that's up to you
[16:37] <jcastro> remember once you are running lucid when you update you're up to date
[16:37] <jcastro> so if you get a Beta, and you do your updates
[16:38] <jcastro> you won't need to download and reinstall RC
[16:38] <jcastro> Question: We are syncing from testing for lucid, I think? How do you feel this would affect development, and those running it?
[16:38] <jcastro> I think this will mean Lucid will have less bugs overall
[16:38] <jcastro> and be a less bumpy ride
[16:38] <jcastro> (but not right now, bunch of syncs happening)
[16:39] <jcastro> unless you seriously want the crack, I don't recommend using lucid until at least alpha 1
[16:39] <jcastro> right now the toolchain and the lower bits are settling
[16:39] <jcastro> and we haven't had UDS yet so it's just syncing
[16:39] <jcastro> ok
[16:39] <jcastro> let's talk about some other common problems
[16:39] <jcastro> one you'll see a bunch is when you use a slow mirror
[16:40] <jcastro> and apt spits out 404 errors
[16:40] <jcastro> usually if you're using an official mirror trying again will round robin to another one and you'll get the packages
[16:40] <jcastro> also, sometimes mirrors sync with others wrong
[16:40] <jcastro> so it will rsync the Packages files and it just so happens that you want to upgrade and the mirror hasn't gotten the actual packages yet
[16:41] <jcastro> this happens with large packages like OOO or eclipse or something
[16:41] <jcastro> one thing I don't recommend (but people do) is to hammer the official archive mirrors over and over
[16:41] <jcastro> also, if you have a bunch of machines, consider using squid or something to save bandwidth and load on the mirrors
[16:42] <jcastro> because the archive updates ALOT
[16:42] <jcastro> hundreds of megs a day sometimes
[16:43] <jcastro> Any more questions?
[16:43] <jcastro> Ok
[16:43] <jcastro> so, remember that the reason to use +1 is to get testing
[16:43] <jcastro> so it's important to make sure you report good bugs
[16:43] <jcastro> Sometimes you don't know if something is a real bug
[16:44] <jcastro> or if someone just broke something and is fixing it
[16:44] <jcastro> when people get lost they post on the lucid forum
[16:44] <jcastro> this is totally /fine/ and encouraged!
[16:44] <jcastro> in fact some people flesh out bugs before they report them
[16:44] <jcastro> "Is anyone else seeing this or is it just me?"  :D
[16:50] <jcastro> Question: When does the development of the next release of Ubuntu start? Right after one is released
[16:50] <jcastro> usually
[16:50] <jcastro> right now we're scheduling sessions for UDS
[16:51] <jcastro> https://wiki.ubuntu.com/UDS-L
[16:51] <jcastro> all the information you need is linked from there
[16:51] <jcastro> http://summit.ubuntu.com/uds-l/ has the schedule
[16:51] <jcastro> there will be icecast streams so you can follow along
[16:51] <jcastro> and all the blueprints and documents are all available
[16:51] <jcastro> I also plan to post many videos this time around!
[16:52] <jcastro> Question: what are the development goals for Lucid?
[16:52] <jcastro> that's what we do at UDS, figure those out
[16:52] <jcastro> however Lucid is LTS so we already know certain things
[16:52] <jcastro> like we'll be more conservative on things
[16:52] <jcastro> and we'll concentrate on bug fixes all cycle
[16:52] <jcastro> some people might call that boring
[16:52] <jcastro> but rock solid is never boring. :D
[16:53] <jcastro> Question: How does one join the development of Ubuntu? Beta testing is, of course, there; but what about main development?
[16:53] <jcastro> Oh man, that session was yesterday!
[16:53] <jcastro> but don't worry
[16:53] <jcastro> https://wiki.ubuntu.com/MeetingLogs/openweekKarmic/IntroDeveloper
[16:53] <jcastro> start here
[16:53] <jcastro> that should have everything you need to get started
[16:53] <jcastro>  QUESTION: Can I upgrade in place by editing /etc/apt/sources.list changing karmic to lucid?
[16:53] <jcastro> Yep
[16:53] <jcastro> that's how I used to do it
[16:54] <jcastro> lately I get lazy and just do update-manager -d
[16:54] <jcastro> also, this reminds me
[16:54] <jcastro> if you have a bunch of PPAs or something in your sources.list you'll want to comment them out before an upgrade
[16:54] <jcastro> also, if you're running a "mongrel" system with a bunch of PPAs, self made debs
[16:54] <jcastro> and general crack
[16:54] <jcastro> consider a clean install
[16:55] <jcastro> instead of reporting bugs with all sorts of brokeness
[16:55] <jcastro> ok that's all I have time for
[16:55] <jcastro> I hope you guys are ready for Mark Shuttleworth!
[16:58] <jcastro> Ok I've been informed that mark is having power supply problems
[16:58] <jcastro> but it's getting sorted, please bear with us
[16:59] <jcastro> While mark sorts out his PC
[17:00] <jcastro> remember to put your questions in #ubuntu-classroom-chat
[17:00] <jcastro> and akgraner and myself will paste them in
[17:00] <jcastro> please try to have a good question, if it's easily googleable we'll likely skip it
[17:02] <jcastro> welcome mark!
[17:02] <sabdfl> hello all
[17:02] <jcastro> sabdfl, akgraner and I will paste questions
[17:02] <sabdfl> thanks jorge - happy to be here! hi amber
[17:02] <jcastro> so just say "next" when you are ready!
[17:03] <sabdfl> fire away
[17:03] <jcastro> feel free to kick it off!
[17:03] <jcastro> QUESTION: What's your opinion of ChromeOS?
[17:03] <sabdfl> there's a lot of concern in the desktop environment groups (Gnome, KDE) that Chrome will be bad for desktop linux, but i think it will be very good
[17:04] <sabdfl> one of the toughest challenges for us in desktop linux is hardware compatibility
[17:04] <sabdfl> and ChromeOS gives PC manufacturers *another* good reason to invest in Linux compatibility for their peripherals
[17:04] <sabdfl> same goes for Intel's Moblin
[17:05] <sabdfl> i'm sure there are PC manufacturers now trying to figure out how to deliver Chrome. Since they don't know which peripherals and devices they will use, they are telling their suppliers "make sure it does linux" for *all* devices
[17:05] <sabdfl> that's got to be good for us too
[17:05] <sabdfl> next
 QUESTION: We, at least in the US, have seen Apple's "I'm a Mac and I'm a PC" ads. We've seen Microsoft's "Windows 7 was my idea" ads.  When will we see Canonical's Ubuntu ads?
[17:06] <sabdfl> we do advertise, but mostly to the corporate market
[17:06] <sabdfl> i can picture our equivalent, though
[17:06] <sabdfl> it would feature a poodle for the mac
[17:06] <sabdfl> next
[17:06] <jcastro> QUESTION: Hi from Saint Petersburg, Mark. Ubuntu is one of the first distributions to adopt 2.6.31 kernel, but many users discovered a lot of troubles with it - sound issues, disk issues, filesystem issues, usb issues.  How could this happen?
[17:07] <sabdfl> i don't think there are substantially more issues with 2.6.31 than with .28
[17:07] <sabdfl> but there are likely *different* issues
[17:07] <sabdfl> you don't notice the new things that work (especially if you don't have those devices)
[17:07] <sabdfl> but you definitely do notice regressions
[17:07] <sabdfl> i hope people tested the milestones, and reported bugs
[17:08] <sabdfl> for Lucid, we'll freeze the kernel earlier and call for more testing
[17:08] <sabdfl> and have more time to address issues
[17:08] <sabdfl> i believe .32 has a bunch of new stuff but .33 is supposed to be quite stable
[17:08] <sabdfl> next
 Question: Ubuntu has come along way, it's great and I'm pretty sure it's only going to get better, but no matter how great it becomes, if people don't know about it, we have a great grassroots effort but what about marketing?
[17:08] <sabdfl> our marketing depends mostly on passionate technologists - you!
[17:09] <sabdfl> that's why the LoCo teams, and personal advocacy from our users, are so important
[17:09] <sabdfl> it's why we ask people to share the CD they receive so as many people as possible can get it
[17:09] <sabdfl> it doesn't make economic sense to do mass marketing for us now
[17:09] <sabdfl> if it does in future, we'll do it
[17:09] <sabdfl> next
[17:09] <jcastro> Question: What's going to happen with compiz and gnome shell?
[17:09] <sabdfl> good question
[17:10] <sabdfl> the gnome shell work is very interesting
[17:10] <sabdfl> i think mutter has a long way to go before it supports everything that compiz does
[17:10] <sabdfl> but i'm confident that mutter will become a great window manager in due course
[17:10] <sabdfl> i saw today that gnome shell has been pushed back six months, so there is more time to get it right
[17:10] <sabdfl> next
 QUESTION: Hi Mark, so when will Asia have a taste of UDS? I'm pretty sure the region is a huge market for you at the moment, but it seems the collaborative development of Ubuntu is focusing solely on EU and the continental US. Lots of developers here too. Thanks.
[17:11] <sabdfl> i would love to do a UDS in asia
[17:11] <sabdfl> perhaps you could organise an online commitment roll, where developers can commit to coming if we have, say the 10.10 UDS there, or the 11.04 UDS there
[17:12] <sabdfl> i like how debconf is put to community competition between cities
[17:12] <sabdfl> if you want to make the case for UDS in asia, let us know which city and which developers would actually come
[17:12] <sabdfl> next
[17:12] <jcastro> QUESTION: What do you think can or should be done to encourage the spread of LoCo's throughout the world? Does the list of LoCo's look to you like it's representative of the size of the Ubuntu market, or user base?
[17:13] <sabdfl> (btw, the maestro 4k in Toulouse has proposed that city for the next UDS and it's being seriously considered because he has such a great track record in bringing the community together)
[17:13] <sabdfl> wow, good question
[17:13] <sabdfl> i haven't seen the LoCo list for a while so can't comment
[17:13] <sabdfl> Jono would be the best person to ask
[17:13] <sabdfl> i saw a comment on a bug today, suggesting ReCo's for Regional Community, and CiCo's for City Community
[17:14] <sabdfl> so, I think that network will grow in scale and complexity
[17:14] <sabdfl> if you care about this, please do dive in and help with the LoCo Council and general organisation
[17:14] <jono> indeed, feel free to email me
[17:14] <sabdfl> the most important thing is figuring out how to keep LoCo's healthy
[17:14] <jono> jono AT ubuntu dot com
[17:14] <sabdfl> they have no trouble starting
[17:14] <sabdfl> but we have trouble knowing if they are active, healthy, fun and positive
[17:14] <sabdfl> next
 QUESTION: Mark, do you have any specific advice on how to grow the market for Ubuntu? What's holding us back from grabbing 10% of the market in one year's time?
[17:15] <sabdfl> rrnwexec: hardware compatibility, software solutions, economics
[17:15] <sabdfl> but all three are changing for the better
[17:15] <sabdfl> hardware compat is improving because lots of PC manufacturers are starting to realise how much people love ubuntu
[17:15] <sabdfl> and it's low cost for them too
[17:16] <sabdfl> software solutions - more and more ISV's are starting to certify Ubuntu, but we are still a long way behind red hat and suse in that regard
[17:16] <sabdfl> we have to stay friendly to both free and proprietary software solutions providers, that's important
[17:16] <sabdfl> flash imrpved a lot recently, there's more to be done
[17:17] <sabdfl> and economics... win xp was a diving catch for microsoft
[17:17] <sabdfl> they had to keep it alive much longer than planned
[17:17] <sabdfl> cost them a fortune
[17:17] <sabdfl> but they left it out there as a cheap, familiar solution
[17:17] <sabdfl> now, with win7, i think the economics are back in our favour
[17:17] <sabdfl> next
[17:17] <jcastro> QUESTION: Will Canonical ever start branding hardware as "Ubuntu Compatible"?
[17:17] <sabdfl> definitely, if we ever start making hardware, which is not in the plan :-)
[17:18] <sabdfl> but we do see more and more manufacturers putting the ubuntu logo on their boxes
[17:18] <sabdfl> which is *great*
[17:18] <sabdfl> next
 QUESTION:  Have you already got any ideas for what Ubuntu 10.10  might be called, if so what?
[17:18] <jcastro> QUESTION: a lot of people still buy their computer software from a "brick and mortar" store, does Canonical have any plans to work with these stores to distribute Ubuntu, maybe for $5 ?
[17:18] <jcastro> Sorry!
[17:18] <sabdfl> sebsebseb: patience ;-)
[17:18] <sabdfl> on the distribution front, we see people doing that today
[17:18] <sabdfl> we don't have an active program
[17:19] <sabdfl> though we do sell CD's in bulk for like $1 per CD so people could do that
[17:19] <sabdfl> if you think it would work, see if you can get some brick and mortar stores to buy sets of 100 CD's and offer them
[17:19] <sabdfl> i would suggest you offer the CD together with an install service (for more than $5) to make it worth the store's time
[17:19] <sabdfl> next
 QUESTION: Do you have any specific plans to encourage non-technical and non developer types to contribute to the project? (Translations and documentation exempt from this question.)
[17:20] <sabdfl> we do have the marketing team
[17:20] <sabdfl> and locos and advocacy require organisational skill, more than technical skill
[17:20] <sabdfl> there's room for people of all talents, that's something we care a lot about in Ubuntu
[17:20] <sabdfl> this is NOT just for developers, and NOT for fundamentalists
[17:21] <sabdfl> this is for people who care about moving to a better technology world
[17:21] <sabdfl> whatever background, gender, or colour they have
[17:21] <sabdfl> next
[17:21] <jcastro> QUESTION: a lot of hardware-support issues (with regards to the linux kernel and as such with Ubuntu) is depending on the openess and cooperation from/with hardware vendors. How do you see hardware support in the future and what can we (in the broadest sense of the word) do to get more vendors to open up their specs and/or develop their own kernel drivers?
[17:21] <sabdfl> we have to demonstrate *business success* for them
[17:22] <sabdfl> initially, nost of them don't understand the open model
[17:22] <sabdfl> that doesn't mean they are stupid
[17:22] <sabdfl> it's just unfamiliar
[17:22] <sabdfl> it's better to engage with them on whatever terms they initially understand best
[17:22] <sabdfl> and then show how they win deals and ship *volume*
[17:22] <sabdfl> that industry only makes money in volume, their margins are too tight
[17:23] <sabdfl> the enthusiast market loves to tell hardware companies to do linux, but then it doesn't buy their stuff
[17:23] <sabdfl> "because they picked the wrong distro" or "that's an old version"
[17:23] <sabdfl> well, there's no incentive there for the hardware companies to stick around and figure it out
[17:23] <sabdfl> so, we have to engage with them, even if it starts with proprietary drivers, and show them money
[17:23] <sabdfl> then we can move them to free software
[17:23] <sabdfl> next
[17:23] <akgraner> rrnwexec> QUESTION: How is Ayatana coming along? Are you still energized by it? Is it still on the high priority list? (lots of Ayatana questions)
[17:24] <sabdfl> i love that part of the project and spend a few hours on it every day (a lot of time for me)
[17:24] <sabdfl> there's a great and growing team
[17:24] <sabdfl> they really care about the desktop experience, and they are not fundamentalist about GNOME or KDE, they want *both* to get better
[17:24] <sabdfl> i like how it's going, though it's taking longer than i would like to get a really effective machine running
[17:25] <sabdfl> if you liked the notifications bits, and the messaging menu, you will love lucid
[17:25] <sabdfl> we are going to make sure that all works perfectly across all of main and universe
[17:25] <sabdfl> we'll neaten the panel up a lot
[17:25] <sabdfl> and if you like the UNR, that's their design work too
[17:25] <sabdfl> next
[17:25] <jcastro> QUESTION: Why you don't use identi.ca and very-very seldom twittering? The same thing with blogging - some posts really very instresting. You, probably, have not enough time for such things, but please - it would be great to read your tweets/dents/posts as often as possible.
[17:26] <sabdfl> thanks for the kudos!
[17:26] <sabdfl> i should blog more often
[17:26] <sabdfl> my twitter account is only used by my evil identical twin for callous and coarse thoughts ;-)
[17:26] <sabdfl> next
 QUESTION: you can already buy desktops and laptops with Ubuntu installed from several vendor's online stores.  When do you think we will see them in brick and mortar stores, especially running as a demo?
[17:26] <sabdfl> getting Linux right at retail is a very serious challenge for us
[17:27] <sabdfl> we are working on it with a big manufacturer
[17:27] <sabdfl> but it's not easy and i can't promise it will happen soon
[17:27] <sabdfl> it failed at walmart and a few other large scale attempts
[17:27] <sabdfl> we don't want to screw it up
[17:27] <sabdfl> next
[17:27] <jcastro> QUESTION: You stated at the last UbuntuOpenWeek that the economic problems might create good opportunities for GNU/Linux and Ubuntu. Since then, have you already found concrete evidence to support this prediction?
[17:28] <sabdfl> yes - i was at an event for open source company CEO's last month
[17:28] <sabdfl> everyone agreed this had been their best year ever
[17:28] <sabdfl> people got a fright and had to look hard at how they do IT
[17:28] <sabdfl> and open source was a common answer
[17:28] <sabdfl> next
 QUESTION: Would you consider a short tour of the most active LoCo's to get some buzz and energy in the far outposts, or at least the ones that offer to take you out for beers ;)
[17:28] <sabdfl> i generally do hang out with LoCo's in the places i go
[17:29] <sabdfl> but it hasn't been such a creative list of late
[17:29] <sabdfl> next year i expect to move on from London
[17:29] <sabdfl> so perhaps i'll travel to more interesting places then
[17:29] <sabdfl> and would love to hang out with LoCo's
[17:29] <sabdfl> next
[17:29] <jcastro> QUESTION: when and how do you see Canonical making a profit?
[17:29] <sabdfl> from services, and in due course.
[17:30] <sabdfl> to a certain extent, we choose to expand faster than our revenue base
[17:30] <sabdfl> because we want to deliver a great solution across desktop, netbook *and* server
[17:30] <sabdfl> so we are starting three businesses in one
[17:30] <sabdfl> which is harder than three times one :-)
[17:30] <sabdfl> if we wanted to, we could scale back our goals and break even sooner
[17:31] <sabdfl> but i worry that we are the main hope of genuinely free free software
[17:31] <sabdfl> and i want to deliver that everywhere
[17:31] <sabdfl> next
 QUESTION how important is having a diverse group of contributors (women & minority folks) to solving Bug #1?
[17:31] <sabdfl> not especially, but it makes the project more interesting
[17:31] <sabdfl> next
[17:31] <jcastro> QUESTION: Is there anything that the community isn't doing well enough that you like it to see people do better?
[17:32] <sabdfl> wow
[17:32] <sabdfl> the community is so amazing it's hard to know what else one could ask for
[17:32] <sabdfl> i'd like to see more engagement in bug triage and qa
[17:32] <sabdfl> on the bug front, passing bugs upstream is really important
[17:33] <sabdfl> a lot of upstreams don't see bug reports unless we pass them upstream
[17:33] <sabdfl> because most people file bugs against the distro, not the upstream
[17:33] <sabdfl> that would help
[17:33] <sabdfl> next
[17:33] <jcastro> (talk to me later about upstreaming bugs folks  -ed.)
 QUESTION: do you foresee Canonical becoming a publicly traded company?
[17:33] <sabdfl> if that's the right thing for us, sure
[17:33] <sabdfl> next
[17:33] <jcastro> QUESTION: Have you ever considered a large Ubuntu conference for the public? Would you consider doing it in the interest of getting the word out to a broader audience? (I'm thinking about something that has the reach and buzz of MacWorld San Francisco).
[17:34] <sabdfl> we did Ubuntu Live a few years back with O'Reilly
[17:34] <sabdfl> it was too soon, we didn't have enough people coming
[17:34] <sabdfl> sooner or later, someone will do an event, and we'll support it
[17:34] <sabdfl> next
 QUESTION: I see that Ubuntu is being loaded with to-be moneymaker such as One, SwCenter. Why not "Ubuntu Enterprise" like Redhat & SUSE did?
[17:35] <sabdfl> well, there are two elements to the Enterprise Edition strategy as pursued by Red Hat and SUSE that I don't like
[17:35] <sabdfl> first, you have to tell people they can't use the Enterprise Edition unless they pay for it
[17:35] <sabdfl> efectively, you *have* to pay to use RHEL and SLES
[17:35] <sabdfl> i want to make sure that Ubuntu can be used in rich and poor environments
[17:36] <sabdfl> it costs me nothing if a guy in Bangladesh gives his copy of Ubuntu to someone else to install
[17:36] <sabdfl> so i don't expect to be paid for it
[17:36] <sabdfl> but we offer services to companies that want them, and can afford them, to fund the platform
[17:36] <sabdfl> so, Ubuntu *is* enterprise quality
[17:36] <sabdfl> but we don't make people "pay for the Enterprise version"
[17:37] <sabdfl> the second thing is about quality
[17:37] <sabdfl> the "Enterprise Version" strategy usually involves having a Community Version which is described as low quality, and and Enterprise Version (paid) that is not
[17:37] <sabdfl> if you meet Red Hat folks at an exhibition and ask about using Fedora, you'll know what I mean
[17:38] <sabdfl> i want to do high quality releases
[17:38] <sabdfl> so our non-LTS releases get high quality maintenance and updates
[17:38] <sabdfl> and LTS get those, but for longer
[17:38] <sabdfl> there are some other differences
[17:38] <sabdfl> but you can, and people do, deploy non-LTS releases in serious production environments
[17:38] <sabdfl> and that's wonderful
[17:38] <sabdfl> so, we won't go down that route
[17:38] <sabdfl> next question
[17:38] <jcastro> QUESTION: What are your thoughts on "Linux" as a brand? Is the term still meaningful, compelling? Do you think it's necessary to co-brand Ubuntu to always include the term "Linux"?
[17:39] <sabdfl> no, i don't think so
[17:39] <sabdfl> of course, the Linux kernel is an essential ingredient
[17:39] <sabdfl> but it;'s just one part of a huge and complex system
[17:39] <sabdfl> and you may be right if you think that emphasising Linux gives too much credit and causes confusion
[17:39] <sabdfl> next
 Question: What's your average day like?
[17:39] <sabdfl> long
[17:40] <sabdfl> i try to be up and exercising by 7, email at 8, office at 9 till 7, then home
[17:40] <sabdfl> calls in the evening, lots of email
[17:40] <sabdfl> not exactly james bond
[17:40] <sabdfl> that whole billionaire cosmonaut bachelor thing is overrated
[17:40] <sabdfl> next
[17:40] <jcastro> QUESTION: Do you have a linux phone (such as android or openmoko)? :)
[17:41] <sabdfl> nope. symbian
[17:41] <sabdfl> next
 QUESTION: to what extent do you see Lucid as a critical release, especially for the home user who may be used to a longer upgrade cycle?
[17:41] <sabdfl> lucid is critical for us, yes
[17:41] <sabdfl> we're working harder than ever on the details of the plan
[17:41] <sabdfl> we will need a lot of support from the community and from upstreams to make it *amazing*
[17:42] <sabdfl> next
 QUESTION: Did you attend (or hear about) any great release parties this time around? And, do you feel that Release Parties are a good marketing tool?
[17:42] <sabdfl> release parties are for us to celebrate our work together, i don't think of them as marketing
[17:42] <sabdfl> i go to the London one, usually that's where I am at release time
[17:42] <sabdfl> this one was great, in the west end
[17:42] <sabdfl> next
[17:42] <jcastro> QUESTION: What is your next world-changing idea, now that the Ubuntu project is well on its way to fixing Bug #1?
[17:43] <sabdfl> if we get Ubuntu to the point of self-funding growth, i will stay involved and use it to explore lots of interesting ideas
[17:43] <sabdfl> an OS is an amazing basis for interests in just about any part of technology
[17:43] <sabdfl> robotics? we got it. servers and cloud? we got it. consumer electronics? we got it
[17:44] <sabdfl> i picked this project because *if* it works, it should keep me out of trouble for a long time
[17:44] <sabdfl> by trouble, i mean space ;-)
[17:44] <sabdfl> next
[17:44] <jcastro> QUESTION: Don't you think that Ubuntu releases too often? Linus Torvalds talked about a yearly release as a good compromise.
[17:44] <sabdfl> i didn't think linus did compromise ;-)
[17:44] <sabdfl> next
 Question: You say you have marketing in the corporate sector,  and Ubuntu is starting to do great things with cloud computing and servers, but what about "Linux or Human Beings"? I thought the focus of Ubuntu was the average, person, the desktop user, I think it's great you provide a server set up as well, but will Ubuntu live up to it's promise of empowering people,  using technology to create a brighter future?
[17:45] <sabdfl> that was about marketing, which is expensive
[17:45] <sabdfl> we do focus on the desktop case, for the home user, but we don't run big marketing campaigns
[17:46] <sabdfl> as i said there, our marketing for consumers is entirely advocacy and word of mouth
[17:46] <sabdfl> it depends on YOU to get the word out
[17:46] <sabdfl> if you think it needs marketing, start talking and helping people learn about it
[17:46] <sabdfl> next
 QUESTION:  If you don't mind answering,  what kind of  things do you spend your money on,  other than funding Canonical and the space visits (which people like mentioning in Ubuntu articles)
 QUESTION: Since Ubuntu is becoming popular do you find more and more people thinking that Ubuntu IS linux?
[17:46] <akgraner> sorry
[17:46] <sabdfl> np
[17:46] <sabdfl> i don't spend a lot on myself, relatively speaking
[17:47] <sabdfl> i have a plane, which is a big luxury
[17:47] <sabdfl> but i don't live a particularly lavish lifestyle
[17:47] <sabdfl> yet
[17:47] <sabdfl> a lot of people think Google IS the Internet :-)
[17:47] <sabdfl> i don't worry about that. people figure stuff out over time, as needed
[17:48] <sabdfl> if people think their first distro *is* linux, that's OK till they need to know more
[17:48] <sabdfl> at which point someone will certainly, helpfully, point it out to them
[17:48] <sabdfl> next
[17:48] <jcastro> QUESTION: Have you considered tracking Bug #1 with more numeric precision, and publishing the results? I would personally like to see the uptick of Ubuntu user stats displayed very prominently. I was close enough to Redmond WA a few years back to see/feel the fear that erupted when Firefox began doing that.
[17:48] <sabdfl> it's so hard to quantify
[17:48] <sabdfl> i don't want to get worked up about bad statistics, either way
[17:49] <sabdfl> we just focus on making ubuntu wonderful, and let nature do the rest
[17:49] <sabdfl> next
 QUESTION: How do you envision Ubuntu on the netbook market for the coming years? Do you have a strategy?
[17:49] <sabdfl> nope. nossir. no strategy at all.
[17:49] <sabdfl> we are working on both Moblin and UNR versions
[17:49] <sabdfl> Dell just launched the Moblin Developer netbook, which is cool
[17:49] <sabdfl> next
[17:50] <jcastro> QUESTION:  Where is Ubuntu actually heading?  It seems at the moment that it is on the verge of becoming a lot more Windows user friendly. For example plans for the Ubuntu Software Centre: https://wiki.ubuntu.com/SoftwareCenter
[17:50] <sabdfl> we have to be friendly to established platforms
[17:50] <sabdfl> the software centre is going to rock! making it easier for people to find the goodness that's already there
[17:50] <sabdfl> as for the long term... it's a work in progress
[17:51] <sabdfl> i have good plans for lucid, and rough plans for lucid+1, but it's tough to be detailed beyond that
[17:51] <sabdfl> next
 QUESTION: New artwork for Lucid?
[17:51] <sabdfl> new window decorations
[17:51] <sabdfl> some new icons for the panel indicators
[17:51] <sabdfl> some new styling on boot and login
[17:51] <sabdfl> no new gtk theme
[17:51] <sabdfl> next
[17:51] <jcastro> QUESTION: I worked quite hard to write a patch fixing a11y issues in NotifyOsd - that were mentioned in ayatana's ML and, i must say, ignored, and a few months later, still no news. Whats the point of open source if there is no way to contribute outside of canonical?
[17:52] <sabdfl> post again to the ayatana list and i'll ask the team to follow up
[17:52] <sabdfl> if you changed the experience, then it might not have been considered because those changes were too extreme
[17:53] <sabdfl> next
 QUESTION: What is your favorite app?
[17:53] <sabdfl> firefox
[17:53] <sabdfl> next
[17:53] <jcastro> Question: How do you see touchscreen and multitouch being integrated into the Ubuntu OS, and what tricks might be part of it that will do something that the competition won't do?
[17:53] <sabdfl> we don't have good enough plans on that front, i haven't thought about it, and i should have. sorry!
[17:53] <sabdfl> next
[17:53] <jcastro> QUESTION: Is Canonical going to try and get Ubuntu (and Edubuntu) into schools, the way Microsoft and Apple did to gain their mindshare?
[17:54] <jcastro> (need more questions in #ubuntu-classroom-chat please)
[17:54] <sabdfl> Ubuntu is already hugely popular in schools
[17:54] <sabdfl> Spain, Macedonia, Greece and others all have active deployments
[17:54] <sabdfl> i don't know more
[17:54] <sabdfl> we don't have a business model for Ubuntu in schools, which limits what we can invest there
[17:55] <sabdfl> but i'm delighted that it's a great base for the work of others in that sector
[17:55] <sabdfl> next
 Question Mark > With the trend of cross-platform hacking attacks against systems connected to the Internet, what do you think the biggest challenge your security team will see in the next three years, and do you think that maybe a united front from all software vendors is needed.  Like recently with the null prefix attack against SSL/TLS which was cross platform, and how the different vendors took varying times to fix it
[17:55] <sabdfl> boy, i wish I could see the future. ubuntu would have *amazing* security if i could :-)
[17:56] <sabdfl> i hope we'll never see another flaw like the OpenSSH one that hit Debian and Ubuntu.
[17:56] <sabdfl> ever
[17:56] <sabdfl> EVAR
[17:56] <sabdfl> but for the rest we have to be responsive, clear, effective and deliver the updates cleanly
[17:56] <sabdfl> i think we have a great track record
[17:56] <sabdfl> better than any other free distro, and better than at least one of the commercial ones
[17:56] <sabdfl> next
 QUESTION: Do you plan to support more mobile devices like tablets and smartphones
 QUESTION: when you have a problem with your laptop, do you fix it or just someone in Canonical? :-)
[17:56] <sabdfl> yes
[17:57] <sabdfl> i try, then i ask around :-)
[17:57] <sabdfl> next
 FOLLOW-UP QUESTION - did you just say that primarily white dudes are able to address the solving of Bug #1? Women & minorities just make it more interesting? Please clarify.
[17:58] <sabdfl> MarkDude, if you think i can't see a baited trap from this close, you're mistaken
[17:59] <sabdfl> i said that having diversity in the project is a wonderful goal. but it's no more a requirement to fix bug #1 than it is a requirement to do most other things. fundamentalism is something i despise, and that goes for overdone activism too.
[17:59] <jcastro> (that was the last question)
[17:59] <sabdfl> thanks all!
[17:59] <jcastro> Thanks everyone for participating!
[18:00] <jcastro> we'll take a minute break and then Leann will begin with Kernel QA!
[18:00] <jcastro> thanks sabdfl!
[18:00] <sabdfl> you all rock. thanks for a great 9.10 and here's to a fantastic 10.04 LTS
[18:00] <akgraner> thanks sabdfl !!!
[18:00] <ogasawara> man, sabdfl is such a tough act to follow
[18:01] <jcastro> take it away ogasawara!
[18:01] <ogasawara> Hi Everyone!
[18:01] <ogasawara> Welcome to the Kernel QA session - A Kernel Bug's Life Cycle.
[18:01] <ogasawara> My name is Leann Ogasawara and I help manage the Ubuntu Kernel Team's incoming and existing bugs against the kernel.
[18:01] <ogasawara> Having to deal with such a large volume of bugs is an on going challenge for us.
[18:02] <ogasawara> I thought this session would be a good opportunity to discuss the life cycle of a kernel bug and what bug reporters and triagers should expect.
[18:02] <ogasawara> The life cycle of a kernel bug is pretty straight forward.
[18:02] <ogasawara> 1: Report the Bug
[18:02] <ogasawara> 2: Triage the Bug
[18:02] <ogasawara> 3: Fix the Bug
[18:02] <ogasawara> Let's get started and begin with Part 1: Report the Bug
[18:02] <ogasawara> Ubuntu kernel bugs should be filed against the "linux" kernel package.
[18:02] <ogasawara> It's important to make sure the bug is filed against the linux package to help ensure it gets looked at by the Ubuntu kernel team.
[18:03] <ogasawara> Reporting a kernel bug can be done by running the following command from a Terminal (Applications->Accessories->Terminal):
[18:03] <ogasawara> ubuntu-bug linux
[18:03] <ogasawara> Running the command will automatically gather general kernel debug information and attach it to the bug being filed.
[18:03] <ogasawara> This includes information such as dmesg output, lspci, kernel version, etc.
[18:03] <ogasawara> dmesg output provides a log of kernel messages that often contains helpful debug information.
[18:04] <ogasawara> lspci output lets us know about hardware a system has.
[18:04] <ogasawara> And the kernel version lets us know the exact kernel version the bug is being reported against.
[18:04] <ogasawara> Part of the bug reporting process also involves writing a title for the bug.
[18:04] <ogasawara> Please make sure the title of the bug report is descriptive.
[18:04] <ogasawara> Don't use something like "Suspend Fails" or "Wireless is broken".
[18:04] <ogasawara> It's better to use for example "Suspend fails to resume on my Dell Inspiron 1420".
[18:05] <ogasawara> Always include hardware or driver information in a kernel bug's title when applicable.
[18:05] <ogasawara> The reason I say this is because kernel bugs are often hardware specific.
[18:05] <ogasawara> Even though someone may be experiencing the same symptom of a bug, they should really open a new report if they have different hardware than the original bug reporter.
[18:05] <ogasawara> Different hardware uses different drivers which likely require different fixes, hence the reason for opening separate bug reports.
[18:06] <ogasawara> Remember, hijacking someone else's bug report is bad.
[18:06] <ogasawara> We can always mark a bug as a duplicate of another bug later on if necessary.
[18:06] <ogasawara> When something like "Suspend Fails" is used as the title, everyone with suspend/resume issues ends up subscribing and commenting to the bug.
[18:06] <ogasawara> This invites others to post completely unrelated information to the bug.
[18:06] <ogasawara> Even worse, the bug will often get a flurry of "me too" comments posted.
[18:07] <ogasawara> "Me too" comments serve no useful purpose in helping fix a bug and only bloat a bug report.
[18:07] <ogasawara> This results in impossible to follow bug reports which are not likely to get much attention from the kernel team.
[18:07] <ogasawara> If you are affected by the same issue, Launchpad now has an +affectsmetoo functionality.  Just click on the "Does this bug affect you?" link in the bug report.
[18:07] <ogasawara> If you are the original bug reporter and feel someone commenting on your bug has a separate issue, don't be afraid to kindly tell them they have a separate issue and to open a new report.
[18:08] <ogasawara> These are the many reasons why I stress the importance of a descriptive bug title.
[18:08] <ogasawara> Along with providing a descriptive title for the bug report, it's also just as important to provide a well written bug description.
[18:08] <ogasawara> For the bug's description, it's always great to include steps to reproduce the issue if possible.
[18:08] <ogasawara> This helps others to confirm they do indeed have the same bug.
[18:08] <ogasawara> Additionally, it will help the developers debug the situation by either being able to reproduce the issue or get an idea what might be the root cause of the issue.
[18:09] <ogasawara> Also, the bug description is a great place to mention if this is a regression or not.
[18:09] <ogasawara> If the bug is a regression, it's important to also tag the bug as a regression.
[18:09] <ogasawara> At the bottom or each bug report's description there should be a "Tags" line and a yellow pencil edit icon to add, remove, or update a bug's tag(s).
[18:10] <ogasawara> There are usually 4 different regression tags that kernel bugs will use:
[18:10] <ogasawara> 1) regression-potential - A bug discovered in the development release that was not present in the stable release.
[18:10] <ogasawara> For example, right now Lucid is known as the development release and Karmic is the previous stable release.
[18:10] <ogasawara> If someone finds a regression while testing Lucid while we are still in the development phase, this would be tagged "regression-potential".
[18:11] <ogasawara> 2) regression-release - A regression in a new stable release.
[18:11] <ogasawara> For example, Karmic just had it's official release.  If a regression is found in Karmic, this would be tagged "regression-release".
[18:11] <ogasawara> regression-potential bugs could very well become regression-release bugs.
[18:11] <ogasawara> 3) regression-update - A regression introduced by an updated package in the stable release.
[18:11] <ogasawara> For example, if Jaunty released a new kernel update and if a regression were discovered due to the update, this would be tagged "regression-update"
[18:12] <ogasawara> 4) regression-proposed - A regression introduced by a package in -proposed
[18:12] <ogasawara> Prior to any updates being released, packages sit in what's called -proposed.  See https://wiki.ubuntu.com/Testing/EnableProposed .  If a regression is found in -proposed, this would be tagged "regression-proposed"
[18:12] <ogasawara> For more information, refer to https://wiki.ubuntu.com/QATeam/RegressionTracking
[18:12] <ogasawara> If the bug is a regression, making sure to also specifically note the most recent version of the kernel where the bug did not occur and the version where the bug was first introduced is most helpful.
[18:12] <ogasawara> This can help isolate the set of kernel patches which should be examined.
[18:13] <ogasawara> With this version information a git bisect could also be used to determine the specific patch which introduced the regression.
[18:13] <ogasawara> For those of you who don't know, git is the revision control system which is used by the upstream kernel as well as the Ubuntu kernel.  For more information on git refer to:
[18:13] <ogasawara> http://www.kernel.org/pub/software/scm/git/docs/
[18:13] <ogasawara> Regarding the git bisect, it's basically a multi-step process to systematically narrow down a specific commit which introduced a regression.
[18:13] <ogasawara> It involves a series of steps of marking a known "good" and "bad" kernel version and proceeding to build and test kernels.
[18:14] <ogasawara> It usually only takes a few iterations to narrow down a specific patch which is causing issues.
[18:14] <ogasawara> For more information please refer to:
[18:14] <ogasawara> http://www.kernel.org/doc/local/git-quick.html#bisect
[18:14] <ogasawara> Lastly, it's also good to comment on the frequency the bug is occurring.
[18:14] <ogasawara> Can the bug be triggered at will or does it happen randomly?  If it happens randomly, how often does it happen?
[18:14] <ogasawara> Once a bug has been reported, I have some additional tips to keep in mind that will help the kernel team work with the bug.
[18:15] <ogasawara> First, make sure bug reports are kept up to date.  Even a small comment that the issue still exists against the latest 2.6.xx-yy.zz kernel is useful.
[18:15] <ogasawara> Also, when asked to test the latest development kernel, please don't be difficult and reply with "I can't believe you want me to test a newer kernel!  This bug is against Hardy, which is an LTS release so it should be fixed there!"
[18:15] <ogasawara> We understand where the frustration is coming from, but the hostile remark does not help solve the bug.
[18:15] <ogasawara> Rants in general do not help resolve a bug, they rather have the opposite affect of annoying the developers trying to fix the issue.
[18:16] <ogasawara> The fact of the matter is that before any kernel bug can qualify for a Stable Release Update, the bug should be confirmed as fixed in the actively developed kernel.
[18:16] <ogasawara> Refer to http://wiki.ubuntu.com/StableReleaseUpdates for the Stable Release Update bug criteria and procedures.
[18:16] <ogasawara> Also, if a bug has been resolved, don't be afraid to close the bug report.
[18:16] <ogasawara> Marking the bug "Fix Released" helps make the kernel team's (and bug control team's) triaging efforts one step easier.
[18:16] <ogasawara> We can always use additional help triaging kernel bugs which brings us to Part 2 of a kernel bug's life cycle, triaging the bug.
[18:17] <ogasawara> But before we move on, I'm going to take a moment to field questions (if there are nay).  Remember to post them in #ubuntu-classroom-chat , I'll copy and reply to them here.
[18:18] <ogasawara> aight, lets move on
[18:18] <ogasawara> Part 2: Triage the Bug
[18:19] <ogasawara> Remember, as a triager we are often the first point of contact for a bug reporter.
[18:19] <ogasawara> It's important that we help move a bug into a good working state as well as help educate the bug reporter to submit better bug reports in the future.
[18:19] <ogasawara> So how does that happen?
[18:19] <ogasawara> First, make sure Ubuntu kernel bugs are assigned to the Ubuntu linux kernel package.
[18:19] <ogasawara> http://bugs.launchpad.net/ubuntu/+source/linux
[18:19] <ogasawara> If a bug reporter did not correctly file the bug against the linux kernel package, help reassign the bug and kindly remind them to report future kernel bugs against the linux kernel package.
[18:20] <ogasawara> Failing to do so may result in the bug getting overlooked.
[18:20] <ogasawara> It may be helpful to also point them at https://wiki.ubuntu.com/Bugs/FindRightPackage .
[18:20] <ogasawara> Next, we want to make sure a bug is really not a duplicate of another bug.
[18:20] <ogasawara> openweek7_> QUESTION: Does 'ubuntu-bug linux' allow to significantly automate identifying duplicate errors?
[18:21] <ogasawara> openweek7_: yes, during the bug filing process launchpad will present you a list of bugs this might be a duplicate of
[18:21] <ogasawara> When marking bugs as duplicates, this is where we as kernel triagers need to be careful.
[18:22] <ogasawara> Kernel bugs are usually hardware specific.
[18:22] <ogasawara> Just because someone may be experiencing the same symptom of another bug, it doesn't necessarily mean they have the same bug.
[18:22] <ogasawara> When in doubt, don't mark it as a duplicate and ask for a second opinion.
[18:22] <ogasawara> Additionally, if you see someone comment on a bug and they don't have the same hardware, ask them to open a new bug report and explain why.
[18:22] <ogasawara> This really helps prevent bugs from becoming wildly out of control with unrelated comments and impossible for a developer to follow, let alone fix.
[18:23] <ogasawara> Next, help make sure the title of the bug as well as the bug description is informative.
[18:23] <ogasawara> Like I mentioned earlier when reporting a bug, a title of "Sounds is broken" or "Suspend fails" is not informative.
[18:23] <ogasawara> As a triager, if a bug doesn't have an informative title, help fix the title by making it more descriptive.
[18:23] <ogasawara> One way to help improve the title is to mention the affected hardware or driver in the title.
[18:24] <ogasawara> Another role of your job as a triager is to help improve the bug's description.
[18:24] <ogasawara> One common improvement to a bug description would be to copy any relevant bits of debug information from the attached log files and paste them into the description of the bug.
[18:24] <ogasawara> This could include items such as error messages found in a reporter's dmesg output or hardware information found in the lspci output.
[18:24] <ogasawara> You may also want to post a comment as to why you're fixing the title or description of a bug to help remind the bug reporter to choose a better title/description in the next bug they report.
[18:24] <ogasawara> when triaging, it's also helpful to tag the bug when applicable.
[18:25] <ogasawara> Because the volume of kernel bugs is so high, tags are a useful way for triagers and developers to group and search for a category of bugs.
[18:25] <ogasawara> One example of tags we talked about earlier were for regressions - https://wiki.ubuntu.com/QATeam/RegressionTracking
[18:25] <ogasawara> If you see a bug is a regression and it has not been tagged, please feel free to add the appropriate tag.
[18:25] <ogasawara> A list of common bug tags used by the kernel can be found at https://wiki.ubuntu.com/Bugs/Tags under the "Kernel Specific" section.
[18:25] <ogasawara> Next, if you find you have the same hardware as a bug being reported, try to reproduce the bug yourself.
[18:26] <ogasawara> It's not unheard of for hardware to become faulty.  Being able to help confirm this is or is not the result of hardware going bad is important.
[18:26] <ogasawara> Now I know the next part is sometimes a bit controversial, but it's also best if the issue has been confirmed against the latest kernel available.
[18:26] <ogasawara> I realize this is a touchy subject for some individuals and some reporters often object to always being asked to "test the latest".
[18:27] <ogasawara> However, when you are dealing with the kernel, keep in mind there are literally thousands of commits between each release.
[18:27] <ogasawara> Then consider that each commit touches more than just one line of code and you've now hit insanity trying to isolate one fix (if it even exists) for a single bug.
[18:27] <ogasawara> It's much easier if someone triaging the bug could kindly ask if the issue remains with the actively developed kernel.
[18:28] <ogasawara> Finally, one of the most important aspects of triaging kernel bugs is making sure the appropriate debug information is attached.
[18:28] <ogasawara> For the kernel this means dmesg output, lspci, kernel version info, etc.
[18:28] <ogasawara> If a bug has been reported without this information, I recommend that instead of asking bug reporters to attach these files individually, have them run apport-collect.
[18:28] <ogasawara> apport-collect will automatically gather and attach package specific debug information for a bug.
[18:29] <ogasawara> For example, if we wanted kernel debug info attached to pretend bug 987654, the apport-collect command would look like:
[18:29] <ogasawara> heh
[18:29] <ogasawara> apport-collect -p linux 987654
[18:29] <ogasawara> There's less room for error having a bug reporter run one command versus having a bug reporter run multiple commands to capture multiple log files.
[18:29] <ogasawara> But as I mentioned earlier, it's best to just use ubuntu-bug to report the bug in the first place.
[18:29] <ogasawara> fagan> Question: when dealing with a hardware specific bug how are you able to confirm it?
[18:30] <ogasawara> fagan: if you happen to have the same hardware, hopefully the reporter has steps to reproduce for you to test and confirm the issue
[18:30] <ogasawara> fagan: unfortunately if you do not have the same hardware, the best you can do it make sure appropriate debug info is attached for the developers to dig in to
[18:31] <ogasawara> In the process of attempting to triage a bug, if you've asked a bug reporter to provide more information, be sure to set the bug's status to Incomplete.
[18:31] <ogasawara> Also be sure to subscribe yourself to a bug so that you are automatically notified when they have responded with the requested information.
[18:31] <ogasawara> Once the bug looks ready for a developer to begin working on it, set the status of the bug to Triaged and make sure the Importance is set.
[18:31] <ogasawara> Note that being able to set a bug to Triaged and also to set the Importance requires that you be a member of the Ubuntu Bug Control team in Launchpad.
[18:32] <ogasawara> To learn how to join the ubuntu-bugcontrol team, refer to https://launchpad.net/~ubuntu-bugcontrol
[18:32] <ogasawara> I'd also like to bring up one last thing to keep in mind when triaging kernel bugs . . . and that's forwarding the bug upstream.
[18:32] <ogasawara> Before a bug can be forwarded upstream, it should be confirmed to exist when running the latest upstream kernel.
[18:32] <ogasawara> The Ubuntu kernel team has started building vanilla mainline kernel builds for users to test with.
[18:33] <ogasawara> See https://wiki.ubuntu.com/KernelTeam/MainlineBuilds
[18:33] <ogasawara> If a bug exists with the upstream kernel, the bug should be forwarded upstream so that the upstream kernel developers are also aware of the issue.
[18:33] <ogasawara> Additionally, it may be discovered that the bug is fixed upstream and we should pull the fix back into the Ubuntu kernel.
[18:33] <ogasawara> If a bug has already been reported to the upstream kernel bugzilla, http://bugzilla.kernel.org/ , we should make sure we set up an upstream bug watch from the Launchpad bug report to the upstream bug report.
[18:33] <ogasawara> See https://wiki.ubuntu.com/Bugs/Watches for more information on how to set an upstream bug watch.
[18:34] <ogasawara> And since I think we have time, I'd also like to take a moment here to point out some extra specific triaging/debugging tips and tricks that people may find useful.
[18:34] <ogasawara> but I'll field two questions really quick
[18:34] <ogasawara> nameiner> QUESTION: When is the time to set a bug's status to confirmed or is this for the devs?
[18:34] <ogasawara> nameiner: anyone can set a bug's status to Confirmed . . .
[18:35] <ogasawara> nameiner: the time to do so is when you have been able to confirm the bug yourself
[18:35] <ogasawara> nameiner: otherwise if you think enough debug information it attached to confirm the issue, feel free to set it to confirmed then as well
[18:36] <ogasawara> nameiner: if you can then get a hold of someone in ubuntu-bugcontrol (usuall in #ubuntu-bugs), they can review and set it to Triaged
[18:36] <ogasawara> openweek1____> Question:  Why the Edubuntu 9.10 does not have LTSP module on it?
[18:36] <ogasawara> openweek1____: unfortunately I don't know the answer to that one, best to file a bug so it can be investigated :)
[18:37] <ogasawara> ok, moving on to helpful triaging/debugging tips and tricks
[18:37] <ogasawara> First, triaging update/install bugs . . .
[18:37] <ogasawara> Having dealt with a good number of these types of bugs myself, I took the liberty to document some of the more common types of update/install issues I saw while triaging.
[18:37] <ogasawara> See https://wiki.ubuntu.com/KernelTeam/DebuggingUpdateErrors
[18:38] <ogasawara> That wiki outlines what some of the common error messages look like and the master bug the issue is likely a duplicate of.
[18:38] <ogasawara> There are also examples of bugs being reported that really are not valid bugs.
[18:38] <ogasawara> For example, an update/install failing due to the fact the user ran out of disk space is not a bug.  We have no control over how much disk space someone has.
[18:38] <ogasawara> The next tip is for triaging wifi issues. . .
[18:38] <ogasawara> Some may or may not know that for the past few releases we've been packaging an updated compat-wireless stack from upstream via the linux-backports-modules package.
[18:39] <ogasawara> This allows users to run a newer compat-wireless stack which may in fact contain a fix for an issue they are seeing.
[18:39] <ogasawara> Most recently for karmic we've actually been packaging the upstream stable compat-wireless release.
[18:39] <ogasawara> If somone is experiencing wifi issues and uses a driver supported via the compat-wireless stack, they should try installing and testing the linux-backports-modules-wireless-karmic-generic package.
[18:40] <ogasawara> A list of supported drivers which would be eligible for testing using the linux-backports-modules package can be seen at http://wireless.kernel.org/en/users/Drivers .
[18:40] <ogasawara> Similarly, the next tip for triaging sound issues follows the same philosophy. . .
[18:40] <ogasawara> For the Karmic release, we also packaged an updated alsa-driver snapshot for testing.
[18:40] <ogasawara> If someone is experiencing sound issues, it might not hurt to try installing and testing the linux-backports-modules-alsa-karmic-generic package.
[18:41] <ogasawara> And lastly, a tip for triaging kernel panics. . .
[18:41] <ogasawara> One of the recent additions to Karmic is the linux-crashdump utility.
[18:41] <ogasawara> In the event you have a kernel panic and the system is unrecoverable, linux-crashdump can help at least capture the contents of the panic and the events leading up to the panic to help provide some post event diagnosis and analysis.
[18:41] <ogasawara> For more information, refer to https://wiki.ubuntu.com/KernelTeam/CrashdumpRecipe
[18:42] <ogasawara> In general, another good source for common debugging/triaging tips can be found at https://wiki.ubuntu.com/KernelTeam/KnowledgeBase#Debugging
[18:42] <ogasawara> As always, feel free to also take a look at https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies for more triaging information.
[18:42] <ogasawara> The volume of kernel bugs can be daunting, especially considering the limited number of resources the kernel team has.
[18:42] <ogasawara> If anyone has the desire to want to start helping out with Triaging kernel bugs, please let me know!  I'd be more than happy to help you get started.
[18:43] <ogasawara> So before we move on to Part 3, Fixing the Bug, I'd like to field any additional questions if there are any . . .
[18:44] <ogasawara> Ok, lets move on . . .
[18:44] <ogasawara> Part 3: Fix the bug
[18:44] <ogasawara> Once a bug has been reported and moved into a Triaged state, this implies the bug has enough information and is ready for a developer to hopefully begin debugging the issue and working on a fix.
[18:44] <ogasawara> When a developer begins working on a bug, they should assign the bug to their self and also set the Status of the bug to In Progress.
[18:45] <ogasawara> Please do not assign someone else to a bug unless you have their permission.
[18:45] <ogasawara> Likewise, do not mark a bug as In Progress unless you are actively working on fixing the bug.
[18:45] <ogasawara> Ignoring these requests will result in the bug likely getting overlooked as others will think someone else is already addressing the issue.
[18:46] <ogasawara> When a developer has a possible patch to test, they will typically build a test kernel for the bug reporter to try.
[18:46] <ogasawara> As a bug reporter, please be responsive with testing and feedback.
[18:46] <ogasawara> Ideally, the patch being tested will have originated from upstream or will have already been submitted upstream.
[18:46] <ogasawara> If a patch has not been pushed upstream, it needs to go upstream first.
[18:46] <ogasawara> It's preferable for a patch to first be accepted upstream and then be pulled back down into the Ubuntu kernel.
[18:47] <ogasawara> Once a patch has been committed to the Ubuntu kernel git repository, the status of the bug should be changed to Fix Committed.
[18:47] <ogasawara> This is usually done by the developer.
[18:47] <ogasawara> Only when a package containing the fix has been released to the archive should the status of the bug change to Fix Released.
[18:47] <ogasawara> Assuming the developer made a note of the bug # in the changelog, the launchpad janitor should automatically update the status of the bug to Fix Released when a package containing the fix has been released.
[18:47] <ogasawara> Once a bug has been marked Fix Released please refrain from re-opening the bug unless you are the original bug reporter and the issue remains unresolved.
[18:48] <ogasawara> If someone is still experiencing issues after a fix has been released, it's likely they are experiencing a different issue which warrants opening a new and separate bug report.
[18:48] <ogasawara> Likewise, if a bug has been marked Won't Fix or Invalid, please do not re-open the bug.
[18:48] <ogasawara> There should have been a reason explaining why the bug is being marked Won't Fix or Invalid.
[18:49] <ogasawara> Just because the status changes back to New, it doesn't change the reason the bug was originally closed.
[18:49] <ogasawara> So that should cover the general life cycle of an Ubuntu Kernel Bug.
[18:49] <ogasawara> Are there any other questions?
[18:49] <ogasawara> Otherwise we can end 10min early for people to stretch before the amazing bethlynn takes over.
[18:50] <ogasawara> Ok, I think we'll end a few mins early.  Thanks everyone!
[18:50] <ogasawara> And feel free to ping me if you have any other questions or want to get involved.
[18:58] <bethlynn> I am Beth Lynn Eicher of the Ohio LinuxFest. For the past 10 years I have been involved in user group activities
[18:58] <bethlynn> I am distro agostic
[18:58] <bethlynn> I use Ubuntu, SUSE, RHEL, Fedora
[19:02] <akgraner> bethlynn will be right back
[19:02] <akgraner> chat client issues I believe...
[19:06] <bethlynn1> Sorry... I'm back
[19:06] <akgraner> welcome back  hands back over to bethlynn1
[19:06] <bethlynn1> I am a professional system adminstrator who does not code
[19:06] <bethlynn1> so
[19:06] <bethlynn1> hacking on a bug is something that is unfamilar to me
[19:06] <bethlynn1> however,
[19:07] <bethlynn1> I am working on the biggest, most challenging bug, bug one
[19:07] <bethlynn1> Microsoft has majority market share
[19:07] <bethlynn1> When I first saw this bug file a few years ago, I was acutally a little ubset by it
[19:08] <bethlynn1> because I was in an environment where bug one actually was resolved
[19:08] <bethlynn1> I was working for Carnegie Mellon School of Computer Science which has deployed Linux on the desktop for almost 15 years
[19:09] <bethlynn1> The truth of the matter is that Microsoft is relatively new to the market place in the span of computuing history.
[19:09] <bethlynn1> The year is 2009. Unix is 40 years old.
[19:10] <bethlynn1> And in the beginning, it was assumed that you would share your source code
[19:11] <bethlynn1> This is why Richard Stallman was so annoyed in 1981 when he was told that he could have access to a printer driver code due to an non-disclosure agreement
[19:12] <bethlynn1> it is due to Marketing that the Microsoft operating systems are seen as the way things have always been
[19:12] <bethlynn1> and how they will always be
[19:12] <bethlynn1> Apple computer has done their own marketing to rebut this
[19:13] <bethlynn1> but what have we, as Linux users, especially Ubuntu users, done to tell the true story of how Linux is a useable operating system?
[19:15] <bethlynn1> At Southern California Linux Expo, Zonker, the Open SUSE community manager
[19:15] <bethlynn1> proposed an answer
[19:15] <bethlynn1> The Linux Dairy council
[19:15] <bethlynn1> The idea, is based on how American dairy farmers have formed a collective
[19:16] <bethlynn1> to make a marketing campagin that is very successful. Everyone in the Unitied States knows the phrase "Got Milk?"
[19:16] <bethlynn1> and that the Dairy council recommends 3 servings a day
[19:17] <bethlynn1> without this campaign
[19:17] <bethlynn1> if small farmers would have to market their own farm
[19:17] <bethlynn1> and their own brand of milk, cheese, yougurt, etc....
[19:18] <bethlynn1> instead of competing against eachother, they have come together to say one unitifed message that gets out there
[19:19] <bethlynn1> If you want to get involved in the distro neutral marketing of Linux, I highly recommend you join the Linux Dairy Council
[19:19] <bethlynn1> It's a google group: http://groups.google.com/group/linux-dairy-council
[19:20] <bethlynn1> We need a diverse group of people to be invovled in the task of marketing
[19:20] <bethlynn1> People of different geographic locations
[19:20] <bethlynn1> People of different languages
[19:21] <bethlynn1> and especially
[19:21] <bethlynn1> different people who have non-geek friends
[19:21] <bethlynn1> There is still an elistism in the Linux communityk
[19:22] <bethlynn1> that the operating system we use is for geeks, by geeks
[19:22] <bethlynn1> and that deploying Linux for their family
[19:22] <bethlynn1> friends and neighbors
[19:22] <bethlynn1> will be damaging to the relationship
[19:23] <bethlynn1> There is a fear that you will get a call at any given time of the day about how much Linux sucks because they don't understand it
[19:23] <bethlynn1> or because they can't do X
[19:24] <bethlynn1> first let me discuss the calls about "how much Linux sucks"
[19:24] <bethlynn1> I have deployed Linux on the desktop to non-geeks several times
[19:24] <bethlynn1> these are people who have zero interest in the command line
[19:25] <bethlynn1> just by sitting down and interviewing the person to see what they want to do with their computer before hand
[19:25] <bethlynn1> then preparting the Linux software and testing it for them, goes a long way
[19:25] <bethlynn1> at deployment time, show them how to do these tasks
[19:26] <bethlynn1> this is relationship building
[19:26] <bethlynn1> not relationship damanging
[19:26] <bethlynn1> when done well
[19:26] <bethlynn1> how to do this welll
[19:26] <bethlynn1> don't take away the keyboard
[19:26] <bethlynn1> let them play
[19:27] <bethlynn1> and assure them that they can't break it
[19:27] <bethlynn1> which is true because they will not invoke root anyway
[19:27] <bethlynn1> with the Ubuntu distrobution
[19:28] <bethlynn1> admin commands with a graphical interface get a prompt that doubles well as a message for "are you sure you really want to do this"
[19:28] <bethlynn1> with a prompt for a password
[19:29] <bethlynn1> now on to the "it doesn't do X" issue
[19:29] <bethlynn1> interviewing the person first about their needs first also is key to avoiding this issue
[19:30] <bethlynn1> setup the software for them if a tool to do X exists
[19:30] <bethlynn1> Jono Bacon discussed in his book "The art of community"
[19:30] <bethlynn1> that the audio software that he needed did not exist in his early days of podcasting
[19:31] <bethlynn1> it is possible, but increasingly unlikely that the Ubuntu Mulitverse lacks a package to do at least something close to X
[19:32] <bethlynn1> sometimes you need to conceed that their isn't a tool that does X
[19:32] <bethlynn1> examine if it works in Wine
[19:32] <bethlynn1> or if Crossover will support it
[19:33] <bethlynn1> if you can't find a package that does X, post the problem to a mailing list somewhere
[19:33] <bethlynn1> that gets into the internet search enginies
[19:34] <bethlynn1> that allows you tell the world that this bug is out there
[19:34] <bethlynn1> a question for the Ubuntu community
[19:34] <bethlynn1> please answer in -chat
[19:34] <bethlynn1> is there some way that people can file another bug and attach it as related to bug one
[19:34] <bethlynn1> thanks
[19:35] <bethlynn1> one more point about "It can't do X" before I more on
[19:35] <bethlynn1> Setting relistic expecations for those new to Linux before they see it is important
[19:36] <bethlynn1> Shawn Powers discussed this at his Ohio LinuxFest 2009 keynote
[19:36] <bethlynn1> People, at least Americans,
[19:36] <bethlynn1> have a negative idea of what "free" really gets you
[19:37] <bethlynn1> If you tell people the bad news up front then you make the experience of when the get to the keyboard up to the software to prove itself
[19:38] <bethlynn1> For example,
[19:38] <bethlynn1> if I was suggesting Linux for someone who does US Tax preparation
[19:39] <bethlynn1> I would tell that person that the shirkwrapped software that is bought in the electronic store is likely not to work
[19:39] <bethlynn1> then I would see if there is a webbased alternative
[19:40] <bethlynn1> and if alternatives would be acceptable to the user
[19:40] <bethlynn1> What I have seen,
[19:40] <bethlynn1> when I give a person a Linux computer, they are actually quite happy about the experience
[19:41] <bethlynn1> and it strengthens relationships
[19:41] <bethlynn1> because you start with the relationships of what you already have
[19:41] <bethlynn1> and what you already have in common
[19:41] <bethlynn1> if there are people who look like you
[19:41] <bethlynn1> and talk like you
[19:41] <bethlynn1> who are using a product
[19:42] <bethlynn1> it gives a great deal of ligitamacy
[19:42] <bethlynn1> this is why it is important for diversity
[19:42] <bethlynn1> I spend the majority of my time when I give a computer away to women
[19:42] <bethlynn1> because I am a woman
[19:43] <bethlynn1> I do tell men about how great Linux and free software is too
[19:44] <bethlynn1> but it is easier for me to speak the language for a woman to another woman
[19:44] <bethlynn1> than a man to a woman or vice versa
[19:44] <bethlynn1> there are other diversity groups
[19:44] <bethlynn1> that I can't discuss here, out of interest of time
[19:45] <bethlynn1> but the quick answer is to start in the neighborhoods you already work in
[19:45] <bethlynn1> and network with your friends there
[19:45] <bethlynn1> the Zareason folks use the phrase "Friends help Friends use Linux"
[19:45] <bethlynn1> good stuff
[19:45] <bethlynn1> Now
[19:46] <bethlynn1> since I only have 15 minutes left
[19:46] <bethlynn1> I will discuss where Microsoft has majority marketshare
[19:46] <bethlynn1> I have been blogging on whatwillweuse.com with maco since July 2009
[19:46] <bethlynn1> abut where Micorosoft has market share
[19:47] <bethlynn1> and it's status
[19:47] <bethlynn1> through this discussion, there are only three places where we have found that Microsoft can make the claim
[19:47] <bethlynn1> 1. Operating system
[19:47] <bethlynn1> 2. Browser
[19:47] <bethlynn1> 3. Office Suite
[19:48] <bethlynn1> Installing Ubuntu instead of Windows resolves the desktop operating system issue
[19:48] <bethlynn1> to be absolutely clear
[19:48] <bethlynn1> Microsoft only has majoroty market share in the desktop operating system area
[19:49] <bethlynn1> not in servers
[19:49] <bethlynn1> not in high performance computing
[19:49] <bethlynn1> not in embedded
[19:49] <bethlynn1> not in voip
[19:49] <bethlynn1> not in smart phones
[19:49] <bethlynn1> the only operating system space they have left is the desktop
[19:49] <bethlynn1> 2. Browser
[19:50] <bethlynn1> There are three versions that are still in use:
[19:50] <bethlynn1> IE 6, 7, 8
[19:50] <bethlynn1> Microsoft refuses to support IE6, in fact many web devs want IE6 to go away because it has not been patched for eons
[19:51] <bethlynn1> if you include IE6, Microsoft only has 52% market share
[19:51] <bethlynn1> if you exclude IE6, they don't have any where need significant market shere there
[19:52] <bethlynn1> Therefore, help your neighbor, especially if you see them using IE6 by installing firefox on their current operating system
[19:52] <bethlynn1> don't be so focused on getting them on to Linux
[19:52] <bethlynn1> becaue firefox is such a quick fix
[19:53] <bethlynn1> that will help us get some momentum in squashing this bug
[19:53] <bethlynn1> now Office Suites
[19:53] <bethlynn1> Microsoft Office 2007 is an unpopular product
[19:53] <bethlynn1> no one likes the ribbobn
[19:54] <bethlynn1> and it introduces the .docx extention
[19:54] <bethlynn1> which unpatched legacy versions of Microsoft Office can not  open
[19:54] <bethlynn1> moreover, there are US patent concerns specific to MS Word 2007
[19:55] <bethlynn1> Microsoft will not change way MS Word operates in MS Office 2010
[19:55] <bethlynn1> they aren't getting rid of the ribbon or the .docx
[19:56] <bethlynn1> this will make their users very frustrated
[19:56] <bethlynn1> therefore
[19:56] <bethlynn1> install Open Office
[19:56] <bethlynn1> on whatever opperating system they use right now
[19:56] <bethlynn1> it has a much more familar interface
[19:56] <bethlynn1> its free
[19:56] <bethlynn1> and people can stilll open and edit their .doc
[19:57] <bethlynn1> and there are great strides in .docx compability
[19:57] <bethlynn1> I see I must wrap this up
[19:57] <bethlynn1> If you are interested in Microsoft's market share
[19:57] <bethlynn1> come join us on the conversation on http://whatwillweuse.com
[19:58] <bethlynn1> I will be on #whatwillweuse on this server for about 2 hours after this talk too for questions
[19:59] <jcastro> wow thanks alot bethlynn1!
[19:59] <bethlynn1> There is a comparison to a Gandhi quote as to how we should work with Microsoft
[19:59] <jcastro> hard to believe this is your first session for openweek ever!
[19:59] <bethlynn1> 1. They mock you
[19:59] <akgraner> awesome... bethlynn1 !!
[19:59] <bethlynn1> oops
[19:59] <bethlynn1> 1. They mock you
[19:59] <bethlynn1> 2. They mock you
[19:59] <bethlynn1> 3. They fight you
[20:00] <bethlynn1> 4. You win
[20:01] <bethlynn1> but how do we get past 3? Use another Gandhi quote.... be the change in the world that you seek.... Thank you very much
[20:03] <akgraner> Next up is Matthew East with Ubuntu Documentation
[20:03] <akgraner> mdke, you ready to take the stage
[20:03] <mdke> yep
[20:03] <mdke> thanks akgraner
[20:03] <akgraner> take it away...
[20:03] <mdke> right let's get cracking!
[20:03] <mdke> I'm here to talk about the Ubuntu Documentation Project
[20:04] <mdke> It's an excellent way for newcomers to the community to get involved in Ubuntu
[20:04] <mdke> because it doesn't require substantial technical skills - just the ability to write reasonable English and a willingness to help
[20:05] <mdke> what I'm going to do today is a whistestop tour through the documentation team, just as an introduction
[20:05] <mdke> then, we'll run some more detailed sessions for people interested in contributing next week
[20:06] <mdke> stay tuned here for the details of that, I'll announce them at the end
[20:06] <mdke> right, an intro to the team
[20:06] <mdke> The documentation team is completely made up of volunteers. The core team is https://launchpad.net/people/ubuntu-doc but many others contribute to documentation all the time. To find out how to communicate with us, see https://wiki.ubuntu.com/DocumentationTeam/Contact
[20:06] <mdke> We have a mailing list and hang out on irc at #ubuntu-doc
[20:07] <mdke> There are essentially two types of documentation that the team produces. The ultimate reference page for any information is https://wiki.ubuntu.com/DocumentationTeam
[20:07] <mdke>    1. System documentation - this is written in a markup language called Docbook XML, and is hosted in our repository.
[20:07] <mdke> (That's the documentation that you see when you click on System->Help and Support on your Ubuntu system
[20:08] <mdke> or click the question mark button on the panel)
[20:08] <mdke>    2. Online documentation - composed of an html version of 1., and a community driven wiki (https://help.ubuntu.com/community)
[20:08] <mdke> I’ll discuss each in turn. I'm going to start with the community driven wiki first, because that is the easiest place for new contributors to get started with documentation.
[20:08] <mdke> = Wiki Documentation =
[20:09] <mdke> The wiki is found at https://help.ubuntu.com/community. As with wikipedia, it is a collaborative resource which is free to anyone to edit.
[20:09] <mdke> This provides a resource for users to search for help when they come across those unusual problems that baffle us all occasionally
[20:09] <mdke> The most basic way to contribute is simply to correct errors that you find in any particular document.
[20:10] <mdke> There are plenty! It's a huge resource, and not all of the pages are perfect by any means
[20:10] <mdke> This is really easy to do: the first step is to log into the wiki (using your launchpad account)
[20:10] <mdke> You do this by visiting https://help.ubuntu.com/community/ and then clicking on the "Login to Edit" link in the top right hand corner. Wait a few moments and you are taken to a Launchpad login page. Just click, "Sign In", and you're logged into the wiki.
[20:10] <mdke> Feel free to try it now!
[20:11] <mdke> Next, you visit the page you want to edit, say for example https://help.ubuntu.com/community/Installation/SystemRequirements. You then bring up the edit box, by clicking "Show Editing Options" in the bottom right hand corner. That gives you the various options that you have, including to edit the page.
[20:11] <mdke> The wiki is written in a simple markup language, which allows us to create basic formatting such as section titles and links.
[20:12] <mdke> Wikipedia has the same, but the markup used is slightly different
[20:12] <mdke> The wiki markup is very simple. It's easy to get to understand how it works. You can either read the markup of existing pages (by clicking "More Actions" -> "Raw Text" in the edit bar) or you can read through our guides to the wiki.
[20:13] <mdke> The most important guide to read for anyone working on the wiki is the WikiGuide, found here: https://help.ubuntu.com/community/WikiGuide.
[20:14] <mdke> The WikiGuide is the basic reference point whenever you want to find out how to do something as a wiki editor. It also gives you guidance about our standard practices
[20:15] <mdke> I hope that it's easy to understand - but if anything isn't clear feel free to let us know by posting to our mailing list
[20:15] <mdke> We're always eager to improve our own documentation :)
[20:15] <mdke> Once you are familiar with the wiki, the next step is to figure out how you can help. Obviously, you can review existing pages that you are interested in or happen to come across, but you may want some guidance about specific tasks.
[20:16] <mdke> Our basic task list is at https://wiki.ubuntu.com/DocumentationTeam/Wiki/Tasks. The Ubuntu Beginners Team also has a task list for their "Wiki Focus Group", which works closely with the Documentation Team, here: https://help.ubuntu.com/community/Beginners/Development
[20:17] <mdke> A great way to find pages that need work is by using the tag system. We have a number of different tags that we apply to pages that need different types of attention.
[20:17] <mdke> You can read about the different tags and how to use them here: https://help.ubuntu.com/community/Tag.
[20:18] <mdke> The different tags are: Unsupported Version, Content cleanup required, Style cleanup required, Needs Expansion, Page too long, Candidate for moving, Candidate for deletion, Duplicate article.
[20:18] <mdke> Great tags for finding pages that need work are the first five of those. These are pages that are outdated, unclear, too short, or too long.
[20:19] <mdke> You can find the list of pages with a particular tag by visiting https://help.ubuntu.com/community/Tag, going to the relevant tag, and clicking on "List of pages with this tag".
[20:20] <mdke> Then, you just pick a page, and start working on improving it! Feel free to get in touch with the team on the mailing list to let them know the work that you are doing on any particular page, and to seek advice if you need it.
[20:20] <mdke> If you come across a page that you think needs improving, and it doesn't have a tag, you can add one using the instructions on the "Tag" page
[20:21] <mdke> Right now we have a *lot* of tagged pages, so there is plenty of work to do!
[20:21] <mdke> Ok, that in a nutshell is the community help wiki. I'd encourage anyone interested in helping out with documentation to check it out, and in particular to start with this page: https://help.ubuntu.com/community/WikiGuide
[20:22] <mdke> This might be a good moment to take a break for questions
[20:22] <mdke> If anyone has any questions about the wiki, feel free to ask them now in #ubuntu-classroom-chat
[20:24] <mdke> 20:24:01 < saji> Hey What is the difference between https://help.ubuntu.com/community and wiki.ubuntu.com?
[20:24] <mdke> excellent question!
[20:24] <mdke> Both of these sites are wikis, so they are collaborative resources which are free for anyone to edit
[20:24] <mdke> the key distinction is that https://help.ubuntu.com/community is only for documentation
[20:25] <mdke> and wiki.ubuntu.com is only for team organisation and planning
[20:25] <mdke> so you can see help.ubuntu.com as a site for users, and wiki.ubuntu.com as a site for contributors to Ubuntu
 QUESTION: mdke, now that you are here, me and Phil were talking about this: how do we go about getting a survey of people
[20:26] <mdke> just a followup on the previous question
[20:26] <mdke> saji has pointed out that there are some help documents on wiki.ubuntu.com
[20:27] <mdke> The simple answer is that these are there by mistake, and should be moved
[20:27] <mdke> If you see a document for users on wiki.ubuntu.com, it can be reported by adding the word "CategoryDocumentation" at the bottom of the page
[20:27] <mdke> that will add it to the list to be moved
[20:28] <mdke> ok, to address dhillon-v10's question
[20:28] <mdke> at the moment we don't have much feedback from users about how helpful our website or help pages are
[20:29] <mdke> I personally think that there should be a way for a user to report easily possible errors or complaints about wiki pages, without having to file a bug report, just by clicking on a button on the page
[20:29] <mdke> it could even be a short survey embedded into the page
[20:29] <mdke> but we haven't discussed this as a team properly, and I'd encourage dhillon-v10 to post to the mailing list about it for a full discussion and brainstorming session
[20:30] <mdke> QUESTION: 20:30:21 < saji> mdke, where will the pages relating to troubleshooting come under?
[20:31] <mdke> A page which involves troubleshooting a piece of software to help a user will generally be for help.ubuntu.com
[20:32] <mdke> sometimes there are borderline cases, we don't always get the distinction right, but we try!
[20:33] <mdke> Right, I'm going to move on to discussing the second type of documentation that we have now
[20:33] <mdke> = System Documentation =
[20:34] <mdke> The System documentation is the documentation that is included by default with every Ubuntu system
[20:34] <mdke> It appears in the menu at System->Help and Support, or by clicking on the blue question mark in the top panel
[20:34] <mdke> Because this documentation is included with every Ubuntu system, we run a stricter system of quality control
[20:35] <mdke> it's not open to everyone to edit like the wiki is
[20:35] <mdke> But, it's still easy to contribute!
[20:35] <mdke> As usual, the starting place to learn how to contribute is our team wiki page, at https://wiki.ubuntu.com/DocumentationTeam
[20:35] <mdke> In particular: https://wiki.ubuntu.com/DocumentationTeam/SystemDocumentation
[20:36] <mdke> To prove that it's easy to learn how to contribute to system documentation, take myself as an example
[20:36] <mdke> I don't have any technical computing training, I'm not a computer scientist. However, I got interested in ubuntu documentation, and found that I'd pretty quickly learned the ropes to make basic contributions
[20:37] <mdke> Gradually, you get more experienced, and eventually you are completely comfortable contributing, and may be granted full access to edit the documentation
[20:37] <mdke> So let's take a closer look at how the system documentation works
[20:38] <mdke> Again, it's written in a markup language. But the markup is more complicated. It's called Docbook XML
[20:38] <mdke> It's a markup language quite similar to HTML, which webpages are written in, so some of you may be familiar with that
[20:39] <mdke> As before, the best way to get to know it is to read some existing documents and to read our guides
[20:39] <mdke> Our guides on Docbook XML start here: https://wiki.ubuntu.com/DocumentationTeam/SystemDocumentation/Editing
[20:39] <mdke> As for reading some existing documents, first we need to download the repository of the documents
[20:40] <mdke> The documents are stored in a version control repository which anyone can download. the version control system used is BZR
[20:40] <mdke> Most of the Ubuntu community uses BZR to store its code
[20:41] <mdke> bzr is pretty easy to learn
[20:41] <mdke> I don't have time to go into it in too much detail in the time we have, unfortunately
[20:41] <mdke> Essentially there are a few commands which we use to do just about everything we need
[20:41] <mdke> "bzr branch" is the command to download the documents.
[20:42] <mdke> A detailed guide to getting the documents and using bzr can be found here: https://wiki.ubuntu.com/DocumentationTeam/SystemDocumentation/Repository
[20:42] <mdke> One of the key things to notice is that we have quite a lot of different bzr "branches" that can be downloaded
[20:42] <mdke> it's important to get the right one
[20:43] <mdke> The list of all of our branches is here: https://code.launchpad.net/ubuntu-doc-project
[20:43] <mdke> The main ones for ubuntu-docs, kubuntu-docs, xubuntu-docs and edubuntu-docs have a star by them
[20:43] <mdke> so to get the ubuntu-docs branch, you would run "bzr branch lp:ubuntu-docs"
[20:44] <mdke> If you run into any problems having read the guide at https://wiki.ubuntu.com/DocumentationTeam/SystemDocumentation/Repository, feel free to ask the team for help
[20:45] <mdke> Again, finding tasks can be one of the thing that newcomers find difficult
[20:45] <mdke> We keep a list of tasks here: https://wiki.ubuntu.com/DocumentationTeam/SystemDocumentation/Tasks
[20:45] <mdke> the first thing you can do is simply to read the system documentation and point out errors (mistakes, typos, etc)
[20:45] <mdke> You can point them out by filing bug reports in Launchpad, just as you do with any Ubuntu project
[20:46] <mdke> Alternatively, you can try and submit a fix for them yourself
[20:46] <mdke> We have a "quick guide" to doing that - our playbook - https://wiki.ubuntu.com/DocumentationTeam/SystemDocumentation?action=AttachFile&do=view&target=BugsPlaybook.pdf
[20:46] <mdke> That explains how to fix a bug in a few quick and easy steps
[20:47] <mdke> Once you are familiar with our processes, you can find some more chunky tasks by visiting the https://wiki.ubuntu.com/DocumentationTeam/SystemDocumentation/Tasks page
[20:47] <mdke> That has links to existing bug reports for our projects, and suggestions for new documents
[20:48] <mdke> If you aren't comfortable with our markup yet, you can submit material as plain text, and we will convert it into Docbook XML - any contribution is valued
[20:48] <mdke> That is a (very fast) overview of System Documentation - I know that there will be plenty of things to develop further, and that's part of the point in having some further sessions next week
[20:49] <mdke> The sessions are going to be as follows:
[20:49] <mdke> Good Preparation when Writing Documentation - AugustinaBlair
[20:49] <mdke> Augustina is a new contributor to the team who wrote the help document for USB Startup Disk Creator
[20:50] <mdke> She did a great job with that and the secret was planning it very well - so she's going to share some thoughts on planning documentation with us
[20:50] <mdke> The second session is:
[20:50] <mdke> Project Mallard - Writing Documentation in XML - PhilBull
[20:50] <mdke> Phil is a longterm contributor to the team, and he will explain in much more detail how to understand the XML markup
[20:50] <mdke> He'll introduce a different type of XML markup which is being developed at the moment by the Gnome documentation team - Project Mallard
[20:51] <mdke> the sessions will be run on:
[20:51] <mdke> 11 November 2009 at 5pm UTC - in #ubuntu-doc
[20:51] <mdke> If there is a bit of demand, perhaps we can persuade Augustina and Phil to run the sessions again in the future :)
[20:51] <mdke> Before taking a couple of questions, I'd just like to mention translation as a great way of contributing to Ubuntu Documentation
[20:52] <mdke> Our documentation is translated into tens and tens of languages by the faithful ubuntu translation teams
[20:52] <mdke> they do an awesome job, but can always do with help!
[20:52] <mdke> Have a look at https://wiki.ubuntu.com/DocumentationTeam/Translation if you are interested in translating documentation
[20:53] <mdke> ok, time for a couple of questions
[20:53] <mdke> 20:35:57 < airurando> QUESTION: What, if any, are the collaborative links between Ubuntu Documentation and Ubuntu Learning?
[20:54] <mdke> airurando: At the moment, I'm not too familiar with what the ubuntu Learning project is doing in terms of user teaching. I know that they have developed a project in that area, and we have discussed collaboration at length, but it's still in early stages
[20:55] <mdke> I haven't been in touch with the learning team recently about this so I am a little out of touch
[20:55] <mdke> Sorry that I can't answer your question more fully but I'd be happy to followup by email with the learning team about collaborating
[20:55] <mdke> 20:38:24 < duanedesign> QUESTION: Are there any tools you recommend for working with DocBook XML, like XML Mind?
[20:56] <mdke> I have personally tried bluefish, and it was quite good
[20:56] <mdke> but I didn't try it very extensively, because I found it easy to use a simple text editor for working with docbook XML
[20:56] <mdke> For example gedit (the default Gnome text editor) is quite good because it hilights the relevant tags that are used
[20:57] <mdke> Again, I know that's not a great answer :) Other Documentation Team members might have better suggestions
[20:57] <mdke> Feel free to post to the mailing list about that!
[20:57] <mdke> 20:49:06 < saji> Question:How can plaintext contributions be made?
[20:57] <mdke> Plain text contributions can be attached or pasted into bug reports, or sent to the mailing list
[20:58] <mdke> We probably prefer bug reports, as they can't get lost
[20:58] <mdke> But either is fine
[20:59] <mdke> I think we're just about finished on timing, so I'll call a close and thank everyone for their attention
[20:59] <mdke> Thanks and look forward to seeing you on the ubuntu-doc mailing list and #ubuntu-doc
[20:59] <mdke> akgraner: over to you!
[20:59] <akgraner> mdke, Thank you so much...
[20:59] <akgraner> AWESOME session!!
[21:00] <akgraner> Up next is Ken VanDine..
[21:00] <kenvandine> hello everyone
[21:00] <akgraner> take it away...
[21:00] <kenvandine> ok, lets kick it off
[21:01] <kenvandine> We're here to talk about Telepathy, a real-time communications framework
[21:01] <kenvandine> Let me start out by saying this session is planned to be about the Telepathy real-time communications framework, not about instant messenger preferences.
[21:01] <kenvandine> Let me address that before we really get started.
[21:02] <kenvandine> Empathy vs. Pidgin, Pidgin is a fine IM client and I don't think anyone has anything against it.
[21:02] <kenvandine> A number of people have complained about the change of default IM client in Karmic, let me address that quickly.
[21:03] <kenvandine> The choice wasn't exactly "Which IM client do we want in Karmic?"  It was more about the Telepathy framework and the possibilities it brings to the desktop.
[21:03] <kenvandine> We have been watching telepathy for quite some time, and we feel it has matured enough that it is time to start to leverage it on the desktop.
[21:04] <kenvandine> Of course we aren't doing anything to prevent people from using Pidgin if they choose, but Ubuntu's default is Empathy which utilizes the telepathy framework.
[21:04] <kenvandine> Now lets talk about telepathy, what it is and why it rocks!
[21:05] <kenvandine> For a little background I will paste a few links along the way for you to skim over now or read later.
[21:05] <kenvandine> Telepathy - http://telepathy.freedesktop.org/wiki/
[21:06] <kenvandine> real-time communications framework
[21:06] <kenvandine>  for example instant messaging, voice and video chats, collaborative editing, etc
[21:06] <kenvandine> modular design, for example adding protocol support is really just installing another backend (like a plugin).
[21:07] <kenvandine> each of these backends run independently, if one crashes it doesn't crash everything else and it should just restart automatically
[21:07] <kenvandine> making it rather robust
[21:07] <kenvandine> Easily integratable, we'll talk more about that later
[21:09] <kenvandine> for the rationale behind Telepathy, http://telepathy.freedesktop.org/wiki/Rationale
[21:10] <kenvandine> also for a system overview, explaining all the components and how they work together
[21:10] <kenvandine> http://telepathy.freedesktop.org/wiki/System%20Overview
[21:10] <kenvandine> is a good read
[21:10] <kenvandine> basically there is mission-control which acts as a dispatcher between clients and backends
[21:11] <kenvandine> backends advertise their capabilities, etc and mission-control handles hooking everyone up
[21:12] <kenvandine> so empathy as a client, wants to create a video chat with a jabber contact, mission-control creates that channel to the telepathy-gabble (jabber) backend and begins creating the streaming channels
[21:12] <kenvandine> etc
[21:12] <kenvandine> next up is my favorite part, Tubes
[21:13] <kenvandine> Telepathy Tubes is a mechanism for supporting arbitrary data transfer and remote IPC
[21:14] <kenvandine> this allows telepathy to send data
[21:14] <kenvandine> and other methods of communication with an application on the other end (remote)
[21:14] <kenvandine> Tubes support both in band (stream through a jabber server) and out of band which talks directly to the remote contact.
[21:15] <kenvandine> some examples of how these are used, or will be used today
[21:15] <kenvandine> Vino and Vinagre - VNC server and client which supports streaming over telepathy tubes
[21:15] <kenvandine> you can use this today in Karmic
[21:15] <kenvandine> Screencast showing offering side http://people.collabora.co.uk/~cassidy/blog/vnc-tube-offer.ogv
[21:15] <kenvandine> Screencast showing accepting side http://people.collabora.co.uk/~cassidy/blog/vnc-tube-accept.ogv
[21:16] <kenvandine> those screencasts show both ends of a VNC session
[21:16] <kenvandine> basically in your empathy buddy list, you can select a friend and "Share your desktop" with them
[21:16] <kenvandine> telepathy negotiates the transport to do that
[21:17] <kenvandine> which makes it operate well behind a NAT, home router, etc
[21:17] <kenvandine> which has always been a limitation
[21:17] <kenvandine> QUESTION: is that protocol dependent?
[21:17] <kenvandine> yes it is
[21:17] <kenvandine> it requires xmpp (jabber)
[21:18] <kenvandine> i am not sure if it can work over other protocols, but xmpp is much more extensible
[21:18] <kenvandine> so that is a great example of tubes that you can use today in Karmic
[21:18] <kenvandine> some other works in progress
[21:18] <kenvandine> Banshee
[21:18] <kenvandine> Browse your friends music and music metadata
[21:19] <kenvandine> Download, stream and see what your friends are playing (if they allow it)
[21:19] <kenvandine> http://nlokos.blogspot.com/2009/08/crossing-finish-line.html
[21:19] <kenvandine> it was a google summer of code project
[21:19] <kenvandine> very impressive stuff, not really ready for everyday use but it will get there soon
[21:19] <kenvandine> Rhythmbox
[21:20] <kenvandine> there is work to enable sharing music with IM contacts
[21:20] <kenvandine> i don't have a link for that, it seems splintered at the moment between a couple git repositories
[21:20] <kenvandine> Gtetrinet
[21:20] <kenvandine> there is a patch for Gtetrinet to play tetris with your friends via tubes
[21:20] <kenvandine> http://cass.no-ip.com/~cassidy/blog/index.php/post/2007/10/21/GTetrinet-through-tubes
[21:21] <kenvandine> the site appears to be down, perhaps the link will work again at some point :)
[21:21] <kenvandine> i think it was up earlier this week, so hopefully only temporary
[21:21] <kenvandine> GNOME Games, sudoku
[21:21] <kenvandine> also a google summer of code project
[21:21] <kenvandine> collaborate or compete with friends
[21:21] <kenvandine> http://blog.zhangsen.org/2009/08/gsoc-final.html
[21:22] <kenvandine> i think that work is proposed for merging into gnome for 2.30
[21:22] <kenvandine> and there is talk about replacing ggz (gnome game zone i think) with telepathy based services
[21:22] <kenvandine> i don't think ggz has ever been used much
[21:23] <kenvandine> Tic Tac Toe (work in progress)
[21:23] <kenvandine> simple tic tac toe game with your friends
[21:23] <kenvandine> https://edge.launchpad.net/tictactoe
[21:23] <kenvandine> those are some samples i found to give everyone a basic idea
[21:24] <kenvandine> i would love to see a f-spot extension that lets you share/view your friends photos
[21:25] <kenvandine> there are many possibilities
[21:25] <kenvandine> QUESTION:  Is the VNC with Empathy secure.  VNC  needs to be tunneled over SSH for example to make it secure when using over The Internet.
[21:26] <kenvandine> I don't know what kind of encryption is used, if any
[21:26] <kenvandine> it is really piping vino/vinagre connection over jabber
[21:26] <kenvandine> which is likely using ssl
[21:26] <kenvandine> depending on your configuration
[21:26] <kenvandine> i can't answer if there is anything more done than that
[21:27] <kenvandine> that last question was from sebsebseb
 QUESTION: While talking about games. Have you considered Telepathy integration with the Volity framework?
[21:28] <kenvandine> I haven't heard about Volity, might be something nice to consider
[21:29] <kenvandine> next
 Question: are there any reasons why you might have to use another means to have a remote desktop session (at least with Linux/Ubuntu) or do you see Telepathy replacing older methods?
[21:29] <kenvandine> not sure about replacing other methods
[21:29] <kenvandine> but it definately adds convenience
[21:30] <kenvandine> for example, i used to have my mother's computer login to my openvpn server at home so i could have a connection out to her machine behind her router
[21:30] <kenvandine> so i could ssh in if needed
[21:30] <kenvandine> now i can just ask her to share her desktop with me if she has any problems (fortunately that never happens) :)
[21:30] <kenvandine> it greatly simplifies the networking situation if it is needed
[21:31] <kenvandine> and a good proof point for what telepathy can do
[21:31] <kenvandine> next
[21:31] <akgraner> none right now
[21:31] <kenvandine> ah... no more questions yet
[21:31] <kenvandine> anyone else?
[21:31] <kenvandine> or ideas for more applications to utilize telepathy?
[21:32] <kenvandine> we will be discussing it quite a bit at UDS for Lucid
 QUESTION: facebook chat???
[21:32] <kenvandine> I would love to have lots of ideas going into some discussions
[21:32] <kenvandine> ah... that is easy :)
[21:32] <kenvandine> facebook chat will be xmpp soon
[21:32] <kenvandine> it works today with the pidgin-facebookchat plugin
[21:33] <kenvandine> one of the backends for telepathy is called haze
[21:33] <kenvandine> which is an interface to the protocols supported by libpurple (pidgin)
[21:33] <kenvandine> so if you install telepathy-haze and pidgin-facebookchat it will almost work
[21:33] <kenvandine> you need to actually delete a file :)
[21:34] <kenvandine> but none of that will be needed when facebook opens up the jabber service
[21:34] <kenvandine> next
[21:34] <akgraner> gQuigs1> QUESTION - it would be possible to use pidgin as a frontend to telepathy (and then going through telepathy) to libpurple?  (yes I miss my pidgin plugins)
[21:35] <kenvandine> sure, if someone hacked pidgin to be a telepathy client
[21:35] <kenvandine> next
 QUESTION: Telepathy audio/video still seems a bit unstable. What's being done to address that for Lucid (or later)?
[21:35] <kenvandine> we are doing what we can there
[21:36] <kenvandine> it seems pretty stable if both ends have UPnP enabled, and UPnP is fairly reliable on the routers
[21:36] <kenvandine> most of the voice/video problems are failures to negotiate UPnP with the router
[21:36] <kenvandine> although, it will work without upnp
[21:36] <kenvandine> but for video, it opens two streams
[21:37] <kenvandine> and that seems to be a little more problematic
[21:37] <kenvandine> although i haven't seen a single voice only call failure in weeks
[21:37] <kenvandine> which has been great :)
[21:37] <kenvandine> some stuff we want to address in Lucid is the workflow used for answering calls
[21:37] <kenvandine> make that simpler and more discoverable
[21:38] <kenvandine> also we have talked to the upstream telepathy developers about working with them to create a diagnostics type of interface
[21:38] <kenvandine> so embedded into the call window there might be a button that lets you check for common problems and help guide you toward fixing them
[21:38] <kenvandine> for example checking to see if you have UPnP enabled
[21:38] <kenvandine> etc
[21:39] <kenvandine> perhaps sound configuration, things like that
[21:39] <kenvandine> next
 Question: Is there work on providing Telepathy support for Windows? I know this is not a windows discussion, but it would be great to use Telepathy for remote desktop and music browsing of my friends not using Linux, and I wouldn't always have to go to their house to fix their computer
[21:39] <kenvandine> hehe
[21:40] <kenvandine> there are instructions on the telepathy website for compiling telepathy on windows
[21:40] <kenvandine> i don't know how well it works
[21:40] <kenvandine> but
[21:40] <kenvandine> even if you had it running on windows, the applications would need to be there too
[21:40] <kenvandine> for example, banshee expects the other end to be banshee
[21:40] <kenvandine> because the client and remote end are actually talking to each other
[21:40] <kenvandine> next
 QUESTION: Meta-contacts in Empathy (or maybe better Telepathy) would be nice. Would they be available in Lucid? Having multiple buddies for the same person is a little annoying.
[21:41] <kenvandine> short answer is yes
[21:41] <kenvandine> it is on the roadmap for gnome 2.30 (i think)
[21:41] <kenvandine> even if it isn't on their roadmap, i think they have other features that depend on it
[21:41] <kenvandine> so i am pretty confident in saying we will have that for Lucid
[21:42] <kenvandine> next
[21:43] <akgraner> not one yet but I have one to ask typing it now
[21:43] <akgraner> akgraner> Question: I was using empathy to see someones computer today but if I moved my mouse it all to check on things not in that widow it messed up what the other person was doing.  How can I use it but still work on the other stuff on my desktop with messing up the other screen?  make sense
[21:44] <kenvandine> ah
[21:44] <kenvandine> that is remote control, which is usually what you want
[21:44] <kenvandine> for example there is only one mouse pointer and one keyboard cursor
[21:44] <kenvandine> but two people are controlling it
[21:44] <kenvandine> it isn't the same as multiple users logged in
[21:45] <kenvandine> anymore questions?
[21:46] <akgraner> maybe getting clarification
 I'd like to know when there will be LCS (Microsoft Network Communicator) support on Empathy, now it is provided by pidgin-sipe plugin but it doesn't work through telepathy-haze.
[21:47] <kenvandine> sorry, i can't really answer that
[21:47] <kenvandine> i would think it should work through haze
[21:47] <kenvandine> is there a bug filed against telepathy-haze?
[21:47] <kenvandine> if not, please do
[21:47] <kenvandine> next
 Question: it should be possible to use Telepathy to sync the calender on multiple machines..... as well as say your Evolution or Thunderbird mailbox, correct? or would something else like U1 be better?
[21:48] <kenvandine> humm..
[21:48] <kenvandine> well telepathy is designed for real-time communications
[21:48] <kenvandine> things like calendar sync are pretty well defined already