[00:03] <Nijabo> Is there some IRC I should turn to with questions regarding getting into "Getting started"
[00:03] <Nijabo> I have one regarding TestDrive
[00:05] <Nijabo> Wrong room sorry
[04:20] <kaydsoft> hi
[05:21] <xiaog> anybody home?
[05:22] <JackyAlcine> Hey
[05:22] <xiaog> Im from china
[05:23] <JackyAlcine> Cool, I'm in the US. :D
[05:23] <xiaog> it's not the time to discuss?
[05:23] <xiaog> I'm pool in english
[05:24] <chalcedony> i just got here
[05:24] <xiaog> me too
[05:26] <JackyAlcine> Well, it's a bit early, I don't think that the next class starts any time soon.
[05:29] <xiaog> yeh, difference of time
[05:30] <xiaog> let's have a look the class list.
[05:38] <chalcedony>  while waiting Full Circle Magazine: http://fullcirclemagazine.org/issue-46/
[05:38] <chalcedony>  Direct: http://dl.fullcirclemagazine.org/issue46_en.pdf
[07:43] <dholbach> good morning
[08:09] <xiaog> It's time to say "good night" in our country ~ hehe
[09:11] <sriram> Any Discussions?
[09:19] <tdelv> sriram, if you mean the classes they do not start for another 7 hours
[09:20] <sriram> tdelv, schedule please?
[09:22] <head_victim> !schedule
[09:22] <ubot2> To view the upcoming Ubuntu Classroom schedule, visit the Learning Events Calendar at http://people.ubuntu.com/~nhandler/classroom.html
[14:39] <ranjan> hey what time the today session is starting ? I am from India...
[14:40] <nigelb> ranjan: 2130 IST
[14:40] <ranjan> nigelb, thanks :P)
[14:43] <ranjan> can anybody give me the link of yesterdays' session log ?
[14:43] <ranjan> zeitgeist's log
[14:43] <dholbach> all on https://wiki.ubuntu.com/UbuntuDeveloperWeek
[14:44] <ranjan> dholbach, thanks :)
[14:45] <kajal> i am new to IRC
[14:45] <kajal> can say ubuntu participation on GSOC?
[15:32] <ElMago29> hey guys .. can you tell me why i cannot install with "sudo apt-get install openssh-server" in ubunto 10.04 Lucid?
[15:33] <fisch246> !support
[15:33] <ubot2> For general questions or support, please use our support channel, #ubuntu
[15:33] <nigelb> You should probably ask in #ubuntu which is the support channel
[15:33] <ElMago29> ok thanks!
[15:53] <techbreak> what is this sesion like ? "test drive " ??
[15:53] <techbreak> are we going to learn testing ?
[15:54] <acarpine> techbreak, yes
[15:54] <techbreak> acarpine, testing of what ?
[15:54] <acarpine> I think we are going to learn testdrive tool
[15:54] <techbreak> acarpine, what is that tool for  ? tool like ?
[15:54] <nigelb> hey folks, keep chat to #ubuntu-classroom-chat, sessions will be happening here :)
[15:55] <acarpine> ops right...
[15:58] <dholbach> HELLO MY FRIENDS! IT'S DAY 3 of UBUNTU DEVELOPER WEEK! WELCOME! :)
[15:58] <dholbach> if you need any information about the event at all, check out https://wiki.ubuntu.com/UbuntuDeveloperWeek
[15:58] <fisch246> !caps | dholbach
[15:58] <ubot2> dholbach: PLEASE DON'T SHOUT! We can read lowercase too.
[15:58] <fisch246> :P
[15:58] <dholbach> also, please make sure you join #ubuntu-classroom-chat
[15:58] <dholbach> because that's where all the chatter goes
[15:59] <dholbach> and questions too - please make sure you prefix your questions with QUESTION:
[15:59] <dholbach> ie: QUESTION: RoAkSoAx: was Pisco invented in Peru or in Chile?
[15:59] <RoAkSoAx> dholbach, Peru of course!
[15:59] <RoAkSoAx> :)
[16:00] <dholbach> today we'll start of the day with RoAkSoAx aka. Andres Rodriguez who will introduce you to TestDrive and how to run virtual machines (including the Ubuntu development release) in a sane manner
[16:00] <dholbach> RoAkSoAx, the stage is yours
[16:00] <dholbach> enjoy!
[16:00] <RoAkSoAx> thanks dholbach
[16:00] <RoAkSoAx> Good Morning Everybody! My name is Andres Rodriguez (as dholbach already saud) and I'm the upstream developer of TestDrive.
[16:01] <RoAkSoAx> So Who is here for the TestDrive Session?
[16:01] <RoAkSoAx> raise your hands in #u-c-chat
[16:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/03/02/%23ubuntu-classroom.html following the conclusion of the session.
[16:01] <RoAkSoAx> Perfect then.
[16:01] <RoAkSoAx> This session is divided as follows:
[16:01] <RoAkSoAx>  1. Introduction
[16:01] <RoAkSoAx>  2. How to use TestDrive (its different uses)!
[16:01] <RoAkSoAx>  3. Do you want to help TestDrive become better? - Development Opportunities!
[16:01] <RoAkSoAx>  4. Questions/Comments/Suggestions?
[16:02] <RoAkSoAx> == Introduction ==
[16:02] <RoAkSoAx> TestDrive was originally created by Dustin Kirkland to test the Ubuntu Daily ISO's of the development release. It was originally a command line application, a shell script, that was later rewritten to python. At this point, it was only a command line application. Nowdadays we have a GTK UI as well. The GTK was my Google Summer of Project with the objective of not only be able to test the Daily ISO Image of the Development release, but to be
[16:02] <RoAkSoAx>  able to test other ISO's in a simple way. I believe that the original objectives were achieved and there's also the opportunity to do more cool stuff.
[16:04] <RoAkSoAx> So the initial sole purpose of TestDrive was to be able to test Ubuntu Daily ISO's, to help with the Testing when new Ubuntu pre-releases were available and others, such as start a VM in a quick manner with no configuration based in any Ubuntu Daily ISO Available. These daily ISOs were only the Ubuntu development release
[16:05] <RoAkSoAx> So now you may wonder... what else can I do with TestDrive?
[16:06] <RoAkSoAx> TestDrive can be used for the following:
[16:06] <RoAkSoAx>  * Test Ubuntu Development Releases - Daily ISO's
[16:06] <RoAkSoAx>  * Test Older Ubuntu Releases
[16:06] <RoAkSoAx>  * Test flavors(Kubuntu/Xubuntu/Edubuntu/Mythbuntu/Ubuntu Studio)
[16:06] <RoAkSoAx>  * Test any *other* ISO from any Other Distribution
[16:06] <RoAkSoAx>  * Test Ubuntu Cloud Daily Images
[16:06] <RoAkSoAx>  * Test qcow2 disk images.
[16:06] <RoAkSoAx>  * Ubuntu ISO Download Manager :)
[16:06] <RoAkSoAx>  * And of course, test if any of our packages is fixed in any release.
[16:07] <RoAkSoAx> So at this point I'm assuming everybody is running TestDrive (and for those who are running natty, you'll notice a notification a few seconds right after you start TestDrive and I'll get to that in a bit)
[16:07] <RoAkSoAx> If you are not running it yet, please go ahead
[16:08] <RoAkSoAx> let me know when you all have TestDrive ready :)
[16:09] <RoAkSoAx> !question
[16:09] <RoAkSoAx> !q
[16:09] <RoAkSoAx> !y
[16:09] <ClassBot> techbreak asked: how to get testdrive ready ?
[16:10] <ClassBot> monish001 asked: how to start testdrive?
[16:10] <RoAkSoAx> sorry my bad
[16:10] <RoAkSoAx> From the command line: sudo apt-get install testdrive
[16:10] <RoAkSoAx> that comman will install both, TestDrive GTK and the command line application
[16:10] <RoAkSoAx> Or you guys can go to Software Center and search for TestDrive and Install it
[16:11] <RoAkSoAx> Then (for those running gnome Maverick + Applications > System Tools > TestDrive an Ubuntu ISO
[16:12] <ClassBot> monish001 asked: terminal says - You will have to enable the component called 'universe'
[16:13] <RoAkSoAx> monish001, yes you need to enable though by default it should be.You can also do it from Gnome but I can't seem to recall what to launch :)
[16:13] <RoAkSoAx> If you are running Maverick I believe it is in System > Preferences > Software Sources
[16:14] <RoAkSoAx> If you are running Ubuntu Software Center > Edit > Software Sources
[16:14] <RoAkSoAx> monish001, ^^
[16:15] <RoAkSoAx> (sorry I don't really use much Ubuntu Software Center)
[16:16] <RoAkSoAx> So anyways, let's move on otherwise time might run out
[16:16] <RoAkSoAx> So how can we Test Ubuntu Development Releases? It is easy. When you launch TestDrive, by default it will provide all the available ISO's of the current development release. In this case, Natty. The testing procedure is even easier. Simply 1. Select, 2. Sync, 3. Launch. So we can select either 1 or more ISO's. Sync means that It will download the ISO's form the repository automatically. And once an ISO is synced completely we can Launch it.
[16:16] <RoAkSoAx>  dholbach has setup a nice wikipage that show's this behavior: https://wiki.ubuntu.com/UsingDevelopmentReleases/
[16:17] <RoAkSoAx> techbreak_, Please do so :)
[16:18] <RoAkSoAx> Now, I understand not everybody has the same hardware as I do, and not everybody has the same virtualization techonlogy
[16:18] <RoAkSoAx> TestDrive Fully supports 2 virtualization technologies (In the latest release included in Natty, or in Maverick PPA)
[16:19] <RoAkSoAx> So for those who are running maverick do this in the command line:
[16:19] <RoAkSoAx> sudo apt-get install python-software-properties
[16:19] <RoAkSoAx> sudo add-apt-repository ppa:testdrive/ppa
[16:19] <RoAkSoAx> sudo apt-get update
[16:19] <RoAkSoAx> sudo apt-get install testdrive
[16:19] <RoAkSoAx> with that all in maverick/natty should have the latest release
[16:20] <RoAkSoAx> now, if you are using KVM as your virtualization technology or your CPU supports KVM, when you installed TestDrive everything should be ready to launch
[16:21] <RoAkSoAx> if you use virtualbox , you'll first have to install it: sudo apt-get install virtualbox-ose
[16:21] <RoAkSoAx> so anyways, how can I choose what virtualization technology to use: Simple TestDrive > Edit > Preferences > Virtualization > Hypervisor (and select the hypervisor of your preference and click SAVE)
[16:22] <RoAkSoAx> So by now I'm assuming you guys are downloading the ISO. Now we know how to change the Hypervisor. Please all take a look to https://wiki.ubuntu.com/UsingDevelopmentReleases/
[16:22] <RoAkSoAx> you'll see the nice screenshots
[16:23] <RoAkSoAx> so while the ISO downloads, I;ll continue to explain what other things we can do with TestDrive, so let's just leave TestDrive to do the work for a while
[16:24] <RoAkSoAx> So, what else can I do with TestDrive besides testing the Ubuntu Development releases.... We can test *Older* Ubuntu releases. So, how can we do it?  It is also simple. Edit > Preferences > Ubuntu Releases. If you notice, there's two things to consider. The Repository and the Release itself. The repository can either be http://cdimage.ubuntu.com or http://releases.ubuntu.com and the releases would be the available releases for each reposito
[16:24] <RoAkSoAx> ry. You just select the desired Repository and the desired release in the repository, and click save.
[16:24] <ClassBot> darkdevil75 asked: if i have already downloaded the iso, how do i point to the location?
[16:25] <RoAkSoAx> darkdevil75, I'll get to that in a bit
[16:26] <RoAkSoAx> So how we select older Development Releases in the command line? Somthing like this: testdrive -p cdimage -r maverick
[16:26] <RoAkSoAx> we specify the desired repository and the desired release
[16:26] <RoAkSoAx> if you only run "testdrive" in the command line, it will default to "cdimage" and "ubuntu development release (in this case, natty)"
[16:28] <RoAkSoAx> So, another thing we can do with TestDrive, is to also test different Ubuntu flavors, from both a previous release or the current development release. So now, how can we test different them? By default Ubuntu/Kubuntu/Xubuntu/Other are the flavors enabled. We can also test Edubuntu/Mythbuntu/UbuntuStudio. For that we go to  Edit > Preferences > Distributions > (Select the desired ones). Then we save and the available flavors in the selected
[16:28] <RoAkSoAx> repository/release will be appear.
[16:29] <RoAkSoAx> from the command line we do something like: "testdrive -p releases -r maverick -l kubuntu"
[16:29] <RoAkSoAx> or "testdrive -l kubuntu" -> For Kubuntu Natty
[16:30] <ClassBot> stefwal54 asked: is there a way to solve the problem that the virtual machine crashed
[16:30] <RoAkSoAx> Steap, not with testdrive :(
[16:31] <RoAkSoAx> stefwal54, not with testdrive :(
[16:31] <RoAkSoAx> testdrive in the case of KVM only uses kvm command to launch the ISO's
[16:31] <ClassBot> chilicuil asked: what if I pause downloading an iso, testdrive will continue downloading where I leave it?, what if I want to test the ubuntu dev version iso everyday, will it download all the iso again, or it will do a diff between the 2 isos?
[16:31] <RoAkSoAx> chilicuil, TestDrive will only download the diff and not the whole iso. However the progress will always go from 0 to 100
[16:32] <RoAkSoAx> Fpor all of those concerned, TestDrive to download all Ubuntu ISO's will use rsync
[16:34] <RoAkSoAx> Now, TestDrive Also allows us to to download and launch ISO's that might not be Ubuntu ISOs or are located in other repositories/servers/or Even the local machine. So how can we do this? Simple. In the GTK main interface you'll notice that there's the"Other". Once the "Other" tab is selected, the "Add ISO" button will become enabled. Then we enter a simple description, the URL where the ISO is located, and the protocol to use, which is eith
[16:34] <RoAkSoAx> er rzync, or zsync. If you notice there's also a file procotol. This can be used when the ISO is in our machine, and to be able to add it, we need to provide the absolute path of the ISO as URL.
[16:35] <RoAkSoAx> So, "Add Other ISO" will launch another dialog to be able to add the ISO
[16:37] <RoAkSoAx> In this case, we could use the URL of any ISO there, let's say a Fedora ISO, select zsync or rsync (if the server of the URL supports it), then click on "Add" and then "Save"
[16:37] <RoAkSoAx> this will make available the ISO under the "Other" tab, and we can select it, click Sync, and once it finished download, we can just click Launch
[16:37] <RoAkSoAx> easy huh?
[16:38] <RoAkSoAx> but wait, did you just mention we can also add ISO's already downloaded??? Yes you can ( darkdevil75 ). There's a few ways to do this
[16:39] <ClassBot> fisch246 asked: "Unable to validate Virtualization Method [virtualbox]" i have virtualbox installed... anyway i can fix this?
[16:39] <RoAkSoAx> fisch246, We'll hold that question for the end :)
[16:40] <RoAkSoAx> So anyways, how can be run with TestDrive ISO's that I already downloaded
[16:40] <RoAkSoAx> simple: With the GTK we can use TestDrive > File > Open
[16:40] <RoAkSoAx> TestDrive > File > New
[16:40] <RoAkSoAx> and notice that TestDrive > File >  New is the same as "Add Other ISO"
[16:41] <RoAkSoAx> so as URL we just give the full path of the ISO
[16:41] <RoAkSoAx> however, we can also do this from the command line
[16:41] <RoAkSoAx> testdrive -u rzync://www.youriso.com/download.iso
[16:42] <RoAkSoAx> or testdrive -u /path/to/iso/ubuntu.iso
[16:42] <ClassBot> chadadavis asked: 3D driver support?
[16:42] <RoAkSoAx> chadadavis, that's hypervisor side of things, not TestDrive's :(
[16:43] <RoAkSoAx> so anyways, what else can we do with TestDrive?
[16:44] <RoAkSoAx> we can also Test Ubuntu Cloud Images
[16:44] <RoAkSoAx> wait what? Cloud Images?? Yes, cloud images that run in the cloud can be tested in the local machine
[16:44] <RoAkSoAx> unfortunately for now it will just work for daily images and it only works in testdrive command line
[16:45] <ClassBot> techbreak asked: what is cloud image ? image of cloud ubuntu OS ?
[16:46] <RoAkSoAx> techbreak_, the Cloud Image is the Ubuntu Image used in cloud computing for either Eucalyptus Cloud or Amazon EC2. In other words, whenever you launch Ubuntu in the Cloud it uses a cloud image (i.e. a disk file with some other components that have Ubuntu pre-loaded)
[16:46] <RoAkSoAx> Now, to be able to test Ubuntu Cloud Daily Images we will need to use the command line application. So, we can open a command line and just do the following to obtain the latest Daily UEC/Cloud Images available:
[16:46] <RoAkSoAx> testdrive -p uec-daily -l uec-server
[16:46] <RoAkSoAx> We can also specify the release (i.e. Maverick)
[16:46] <RoAkSoAx> testdrive -p uec-daily -l uec-server -r maverick
[16:47] <RoAkSoAx> Now, a cool feature that was added lately is to be able to launch the Cloud Image in the local terminal/console. But what does this mean? Instead of launching the image in a separate KVM window it will display it in the terminal from where you are launching testdrive. The command is as follows:
[16:47] <RoAkSoAx> testdrive -p uec-daily -l uec-server --curses
[16:47] <RoAkSoAx> NOTE: Running cloud images only work with KVM
[16:48]  * RoAkSoAx running out of time
[16:48] <RoAkSoAx> as I mentioned before we can also run images located in the machine
[16:48] <RoAkSoAx> Now we can also launch images that are located in the machine. With TestDrive GTK you can do it by using the "Other" tab - "Add ISO" (Equivalent to File > New) or simply  File > Open. The local images that can be launched can be either ISO Images, Disk Images (QCOW2) and Cloud Images. We can also do this from the command line as follows:
[16:48] <RoAkSoAx> testdrive -u /local/path/to/image.iso
[16:48] <RoAkSoAx> testdrive -u /local/path/to/image.img
[16:48] <RoAkSoAx> testdrive -u /local/path/to/uec-image.tar.gz
[16:48] <RoAkSoAx> testdrive -u /local/path/to/uec-image.tar.gz --curses
[16:49] <RoAkSoAx> last but not least, for those running Natty, we have recently added an Indicator Applet (if you notice) that will appear and notify the user whenever there are available pre-release candidate ISO's available for testing. These ISOs are the ISOs that are being tested towards the next Ubuntu release. (i.e. ISO's for Tomorrow's Alpha3).
[16:49] <RoAkSoAx> the idea behind that was to make aware people who were using TestDrive that there's an Ubuntu pre-release available for testing
[16:49] <RoAkSoAx> == How to Contribute ==
[16:49] <RoAkSoAx> Now, we've given an overview of the things we can do with TestDrive. What about if you want to contribute to TestDrive and make it better. Well it is simple, you can either contribute with ideas, fixing bugs or implementing new features. Though if you have an idea and can submit a patch, that's more desirable :). Some of the new reported feature requests are:
[16:49] <RoAkSoAx> "Re-run this program with TestDrive" https://bugs.launchpad.net/testdrive/+bug/704675
[16:49] <RoAkSoAx> "Quicklist and progressbar support" https://bugs.launchpad.net/testdrive/+bug/711915
[16:49] <RoAkSoAx> "GUI Option for zsync" https://bugs.launchpad.net/testdrive/+bug/701818
[16:49] <RoAkSoAx> "Support VMWare" https://bugs.launchpad.net/testdrive/+bug/527161
[16:50] <RoAkSoAx> == Questions/Comments/Suggestions? ==
[16:50] <RoAkSoAx> Since I only have 10 mins left
[16:51] <RoAkSoAx> lets do questions/comments/suggestions and try to get up a machine up and running
[16:51] <ClassBot> There are 10 minutes remaining in the current session.
[16:51] <ClassBot> techbreak asked: ok if I am not funny what is this kvm ?
[16:51] <RoAkSoAx> techbreak, indeed KVM is one of the varios methods to create Virtual Machines
[16:51] <RoAkSoAx> and the one pre-ferred in Ubuntu
[16:52] <ClassBot> acarpine asked: why i should run a cloud image?
[16:53] <RoAkSoAx> acarpine, you don't have to, but if you would like to test it, you are more than welcome to do so!! :). Adding the support to TestDrive was a feature requested to be able to easily test Cloud Images by the Developer
[16:53] <ClassBot> stefwal asked: is there a difference between a second machine and testdrive? If some one has a second machine of course!
[16:54] <RoAkSoAx> stefwal: Of course, TestDrive uses a Vritualization Technology to run an ISO image (mainly) in a Virtual Machine
[16:54] <RoAkSoAx> you could also burn that ISO in a USB Stick and then test it in real HW
[16:54] <ClassBot> techbreak asked: what are we supposed do after testing ? what if we found some error or bug or something ? where to submit ? how ?
[16:54] <RoAkSoAx> techbreak_, if you found a error/bug with Ubuntu, just file the bug http://launchpad.net/ubuntu
[16:55] <RoAkSoAx> if you found a bug in TestDrive file a bug in launchpad.net/testdrive
[16:55] <ClassBot> Vikash asked: I have one que. I may be off the topic because i have just come to the session... Which OS is better Ubuntu or Ubuntu-derivative
[16:55] <RoAkSoAx> Vikash, you can test that yourself with TestDrive :)
[16:55] <RoAkSoAx> and use whichever you like better
[16:56] <ClassBot> There are 5 minutes remaining in the current session.
[16:56] <RoAkSoAx> So anyways, anyone has anything else for the last 5 minutes of the session?
[16:57] <ClassBot> stefwal asked: any good ways to test?
[16:57] <RoAkSoAx> stefwal, refer to https://wiki.ubuntu.com/UsingDevelopmentReleases/ for the steps on how to test techbreak_ shows how to run the download ISO
[16:58] <RoAkSoAx> stefwal, but that's the point, testing involves trying to do things
[16:58] <RoAkSoAx> you can always follow ISO testing if you would like to contribute
[16:58] <RoAkSoAx> and it will show step by step on how to do it and you can use TestDrive for that
[16:58] <RoAkSoAx> stefwal, refer to iso.qa.ubuntu.com
[16:59] <ClassBot> techbreak asked: what after i finish downloading ? any link if get stuck ?
[16:59] <ClassBot> techbreak asked: can I burn cd /dvd from the downloaded image from testrive ?
[17:00] <RoAkSoAx> techbreak_, yes: Slect the Image you'd like to burn and click on "Create USB disk"
[17:00] <RoAkSoAx> which will launch USB creator
[17:00] <RoAkSoAx> to finish please for more help you cn find me in channel #testdrive
[17:00] <RoAkSoAx> I believe my time is over. Thank you all for attending
[17:00] <RoAkSoAx> Project website: launchpad.net/testdrive IRC Channel: #testdrive
[17:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/03/02/%23ubuntu-classroom.html following the conclusion of the session.
[17:02] <mhall119> Hello everyone
[17:02] <mhall119> my name is Michael Hall, and I'm one of the developers of the Ubuntu LoCo Directory
[17:03] <mhall119> I hope you've all been to http://loco.ubuntu.com already, but does anybody not know what it is?
[17:04] <mhall119> alright, quick overview then
[17:05] <mhall119> the loco directory is a community-driven project, meaning decisions and implementation are determined by the community, not Canonical
[17:05] <ClassBot> techbreak asked: mhall119, idk what is this sessoin about ? loco directory ???
[17:05] <mhall119> techbreak_: http://loco.ubuntu.com
[17:05] <mhall119> this session is going to get you ready to start hacking and contributing to it
[17:06] <mhall119> the loco-directory is written in Python, and uses the Django web framework
[17:06] <mhall119> you will need at least working knowledge of python, and some basic understanding of Django to work on LD
[17:07] <mhall119> if you don't currently have Django knowledge, don't worry, it's very easy and I'll go over some of it this hour
[17:07] <mhall119> the main developers of LD are myself, cjohnston, dholbach, Ronnie and daker
[17:07] <mhall119> we all hang out in #ubuntu-locoteams, and that's usually where we discuss LD development
[17:08] <mhall119> since loco.ubuntu.com is hosted on one of Canonical's servers running Ubuntu 10.04, we're restricted to the versions software in those repositories
[17:09] <mhall119> specifically python 2.6, Django 1.1, jQuery 1.3 and jQuery-ui 1.7
[17:09] <mhall119> if you're running Lucid, you're all set
[17:09] <mhall119> if you're running Maverick or Natty, you'll need to grab those versions manually
[17:11] <mhall119> < YoBoY> QUESTION : we can't develop with earlier versions of python, django, ... or
[17:11] <mhall119>                it's just recomended ?
[17:12] <mhall119> since we develop on 2.6, and it'll be running 2.6 in production, it's generally a good idea for you to use 2.6
[17:12] <mhall119> I can't say for sure that it won't work with 2.4, but it's likely
[17:13] <mhall119> I'm assuming you have all been introduced to the basics of bzr by now, but if not just ask about it as I go
[17:13] <mhall119> alright, lets get the code!
[17:13] <mhall119> cd to where you want it to live
[17:13] <mhall119> then run: bzr branch lp:loco-directory
[17:13] <mhall119> that'll get you a copy of the latest trunk
[17:14] <mhall119> trunk is almost always stable
[17:14] <ClassBot> RawChid asked: IS there a manual or webpage which describes how to do this?
[17:14] <mhall119> not that I know if, but ask us in #ubuntu-locoteams (after this session) and we can help you with it
[17:15] <mhall119> okay, by now you should all have a local branch of loco-directory
[17:15] <mhall119> so cd loco-directory and let's take a look
[17:16] <mhall119> quick Django info:
[17:16] <mhall119> Django projects are divided between the root 'project' folder, and sub 'application' folders
[17:17] <mhall119> in the root of the branch, 'loco_directory' is the django project folder
[17:17] <mhall119> so cd loco_directory
[17:17] <mhall119> under there you'll see 'common', 'events', 'meetings', 'services', 'teams', 'userprofiles' and 'venues'
[17:18] <mhall119> those are all of the Django applications that make up LD
[17:18] <mhall119> 'common' is just what it sounds like, it's for things that don't fit elsewhere
[17:19] <mhall119> 'teams' contains all the code for LoCo Team records
[17:19] <mhall119> ls ./teams/
[17:19] <mhall119> a Django app typically has several standard files
[17:20] <mhall119> models.py is where you define your data models, Django will automatically turn these into SQL tables for you (you'll see that later)
[17:20] <mhall119> views.py is where you write the code that is responsible for responding to an HTTP request
[17:21] <mhall119> and urls.py maps a URL pattern to a view
[17:21] <mhall119> any questions so far?
[17:21] <mhall119> ok, moving on
[17:22] <mhall119> the 'events' and 'venues' are the apps that handle LD's event tracker, if you've used LD before you'll know what they do
[17:22] <mhall119> they have the same basic structure as 'teams', with models.py, views.py and urls.py
[17:23] <mhall119> same for 'meetings' and 'userprofiles'
[17:23] <mhall119> now, Django has a built-in templating system that we use.  Our views.py code will usually make use of one or more templates in rendering an HTTP response
[17:24] <mhall119> templates live under the 'templates' directory in the project folder
[17:24] <mhall119> if you ls ./templates/ you'll see that they're separated out by app as well
[17:24] <mhall119> so, to recap
[17:25] <mhall119> if you want to change data structures, it'll likely be in a models.py
[17:25] <mhall119> if you want to change the logic behind a display, it'll likely be in a views.py
[17:25] <mhall119> and if you want to change the interface (html), it'll likely be in the templates
[17:25] <mhall119> everybody with me so far?
[17:26] <mhall119> alright, let's get you guys setup with a working instance of LD
[17:27] <mhall119> first things first, lets look at settings.py in the project folder
[17:27] <mhall119> there's a lot of stuff in here, but the key piece is down around line 116: INSTALLED_APPS
[17:27] <mhall119> this is a list of apps that Django will use for this project
[17:28] <ClassBot> monish001 asked: does Django works on MVC (model view controller framework)?
[17:28] <mhall119> yes, though they call it Model-View-Template, and things are slighting shifted
[17:29] <mhall119> specifically, the typical 'controller' logic is in the view, and most of the display stuff is in the templates
[17:29] <mhall119> okay, lets loot at INSTALLED_APPS
[17:29] <mhall119> the first 4 are the standard Django apps, auth gives us User and Group models, plus permissions
[17:30] <mhall119> contenttypes is really internal stuff you won't likely ever need to worry about
[17:30] <mhall119> sessions gives us automatic session tracking, just like any good web framework should
[17:30] <mhall119> admin is the best of them all, it'll give you a fully functional interface to manage the data in your database for all your defined models
[17:31] <mhall119> if you look in most of the application folders, you'll see amdin.py, which tells the admin app how to present your models
[17:31] <mhall119> the next 6 items in INSTALLED_APPS are the LD apps we've already gone over
[17:32] <mhall119> django_openid_auth is what let's us tie our users and groups to the Ubuntu Single Signon
[17:32] <mhall119> south is a special Django app, by default Django will create DB tables based on your models, but it won't change existing tables, which means once you create them you have to make any future changes manually
[17:33] <mhall119> south lets you track your model structure, and will provide migration scripts whenever you make changes to them
[17:33] <mhall119> we make good use of south in the loco directory
[17:33] <mhall119> if you look under most of the application folders, you'll see a 'migrations' folder, these are the south scripts
[17:33] <mhall119> ok, that's all for settings.py
[17:34] <mhall119> next step, copy local_settings.py.sample to local_settings.py
[17:34] <mhall119> we use local_settings.py for settings that are specific to a running instance of LD, they aren't checked into bzr
[17:35] <mhall119> there's not really anything you need to do with it right now, except make the copy
[17:35] <mhall119> everyone with me still?  The next part is setting it all up
[17:36] <mhall119> alright, lets get our database
[17:36] <mhall119> from the project folder, run "./manage.py syncdb"
[17:36] <mhall119> it will ask you for a superuser, select yes and give it a username, email and password
[17:37] <mhall119> syncdb is the Django command that created your initial database tables
[17:37] <mhall119> by default, LD will use a local sqlite3 file for it's database
[17:37] <mhall119> in production, it runs against postgres
[17:38] <mhall119> you're also free to use MySQL
[17:38] <mhall119> when syncdb finishes, you'll see a message about some apps not being synced because they're under south's migration control
[17:38] <mhall119> so after syncdb, run: ./manage.py migrate
[17:39] <mhall119> this will cause South to run through all  of it's migration scripts
[17:39] <mhall119> which will leave you with the proper table structures
[17:39] <mhall119> if you're using sqlite, you'll see some warnings because it doesn't support some contraints, don't worry about those
[17:40] <mhall119> finally, we'll need to initialize your setup, so run: ./manage.py init-ld
[17:41] <mhall119> init-ld does several things, it'll setup a group in your database for the LoCo Council, it will create necessary symlinks for jquery, and finally it'll grab a copy of lp:ubuntu-website/light-django-theme
[17:41] <mhall119> that last bit is important
[17:41] <mhall119> light-django-theme provides the base templates and CSS for several Django powered Ubuntu sites
[17:42] <mhall119> loco.ubuntu.com (of course), but also summit.ubuntu.com and 10.cloud.ubuntu.com
[17:42] <mhall119> everybody run all of those steps okay?
[17:42]  * mhall119 looks at the clock
[17:44] <mhall119> okay, typically the next step is to either refresh your database with data from Launchpad,or refresh it with data from loco.ubuntu.com
[17:44] <mhall119> but, both of those take a while to run, so we're going to skip them and I'll just have you download a copy of loco_directory.db
[17:44] <mhall119> http://ubuntuone.com/p/fn1/
[17:44] <mhall119> put that into your project folder (over-writing the one you made with syncdb)
[17:45] <mhall119> for reference, "./manage.py lpupdate" will refresh teams and some users from Launchpad, but won't get events, venues or meetings
[17:45] <mhall119> "./manage.py import-live-data" will use LD's REST/Json services to download data from loco.ubuntu.com
[17:46] <mhall119> once you have the database file, run: ./manage.py runserver
[17:46] <mhall119> this will run django's built in webserver on localhost:8000
[17:47] <mhall119> which you can then visit in your browser to see your local instance running
[17:48] <mhall119> oh yes, Ronnie brings up a point that I missed
[17:48] <mhall119> INSTALL file in the root of the branch has instructions for getting things setup
[17:48] <mhall119> one of the lines is a long apt-get install, which will get you all the dependencies
[17:49] <mhall119> okay, hopefully I've gotten you guys a working (or mostly working) isntance of the LD code
[17:50] <mhall119> the next step is to find a bug at https://bugs.launchpad.net/loco-directory to work on
[17:50] <mhall119> if you need help figuring out what needs to be done, just ask us in #ubuntu-locoteams
[17:51] <ClassBot> There are 10 minutes remaining in the current session.
[17:51] <mhall119> but remember, data=models.py, logic=views.py, UI=templates
[17:51] <mhall119> that'll get you to the right place 90% of the time
[17:51] <mhall119> after you make the fix, test it locally first
[17:51] <mhall119> once you're happy with it, run: bzr commit -m "You message" --fixes lp:12345
[17:51] <mhall119> where 12345 is the bug number you're working on
[17:52] <mhall119> that'll help launchpad associate your code with that bug
[17:52] <mhall119> then: bzr push lp:~you/loco-directory/fixes-12345
[17:52] <mhall119> agian, I hope you've all been introduced to bzr and distributed development, so this should be familiar
[17:53] <mhall119> then go to https://code.launchpad.net/loco-directory, select your branch, and click the "Propose for merging" link
[17:54] <mhall119> then one of the main developers will review your code (when we have time, we all have actual jobs too)
[17:54] <mhall119> < chadadavis> QUESTION, doe the push statement make a new branch as well, or just
[17:54] <mhall119>                     upload the current branch?
[17:55] <mhall119> it will create a new branch in Launchpad, based off the lp:loco-directory branch
[17:55] <mhall119> these are very lightweight in launchpad, so don't hesitate to push stuff
[17:55] <mhall119> we typically have one branch per fix or feature
[17:56] <ClassBot> There are 5 minutes remaining in the current session.
[17:56] <mhall119> once your code bases a review, we will merge it into lp:loco-directory
[17:56] <mhall119> from there it will get translated and wait for the next release of LD
[17:56] <mhall119> anything that lands in trunk will be in the next release
[17:57] <mhall119> we don't have a fixed release schedule though, so it's hard to say if it'll take days or weeks to get it out
[17:57] <mhall119> < YoBoY> QUESTION : can you point us some easy bugs to start working on ?
[17:58] <mhall119> we try to mark small/easy fixes as 'bitesize' in launchpad, you can get a list of them from https://bugs.launchpad.net/loco-directory/+bugs?field.tag=bitesize
[17:58] <mhall119> if you get stuck or have other questions, come find one of us in #ubuntu-locoteams
[17:58] <mhall119> and happy hacking!
[18:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/03/02/%23ubuntu-classroom.html following the conclusion of the session.
[18:02] <ogra> hey hey
[18:03] <ogra> so i will give a short insight into Ubuntu ARM, the team and the images we care for, i dont expect this to take much time so there should be plenty of time for questions (if there are any)
[18:04] <ogra> the ubuntu arm team (as the name suggests) cares for the arm port in ubuntu
[18:04] <ogra> we build images for different types of arm hardware
[18:04] <ogra> target audience for these images are endusers
[18:05] <ogra> and we try to make them an identical experience to any other ubuntu architecture, so you can expect identical functionallity as in any other ubuntu install
[18:06] <ogra> initially the ubuntu arm team consisted of 8 developers that cared for the whole archive
[18:06] <ogra> all builds (and their failures) as well as all images had to be maintained by this small bunch of people
[18:07] <ogra> recently ARM recognized how important ubuntu was for them, so they started linaro ...
[18:07] <ogra> linaro is a consortium of companies taking care of improving arm and the arm experience
[18:08] <ogra> i.e. nowadays if you get an arm board you will need a linux kernel from the vendor, a so called BSP
[18:08] <ogra> usually that has tons of incompatible changes so the kernel couldnt be merged upstream in linus tree
[18:08] <ogra> and you will also not run a kernel for board A on board B
[18:09] <ogra> linaros mission is to fix such issues
[18:09] <ogra> so that at some point you have someting like the linux-generic package that runs on all arm hardware
[18:09] <ogra> they also care about the toolchain and compiler to get the best optimization out of them
[18:10] <ogra> and they help a lot with failures to build from source
[18:10] <ogra> so since linaro is around, the work of the ubuntu-arm team got a lot easier, we stand on their sholders now
[18:10] <ogra> ...
[18:11] <ogra> over the recent releases we built images for a variety of boards ... starting with freescales imx51 babbage board, marvells dove board (which is known from the press as armada board nowadays) and the very popular beagleboard from TI
[18:12] <ogra> with maverick we started to work closely with TI to make ubuntu the reference platform for their OMAP4 pandaboard
[18:12] <ogra> this was released in 10.10 and gets improved in 11.04 now
[18:12] <ogra> as architectures come and go the babbage and dove architectures vanished from our list of ports, omap 3 and 4 persist
[18:13] <ogra> if you want to help out with arm development i would highly suggest to take a look at the pandaboard on http://pandaboard.org
[18:13] <ogra> its is available for $175 and has all HW you can imagine
[18:14] <ogra> with the ubuntu install and the TI addons it is fully capable of playing 1080p video
[18:14] <ogra> so if you are intrested in arm development on ubuntu a beagleboard (see beagleboard.org) or a panda is the way to go
[18:15] <ogra> for people that cant afford hardware we also worked out cross ways of building and testing arm packages, the qemu-kvm-extras-static package brings all you need to run an arm chroot on your x86 boax
[18:15] <ogra> for testing and devevlopment thats a good start
[18:16] <ogra> for the highly embedded thinking people linaro offers a cross toolchain and the xdeb packages that makes it possible to cross build packages for arm on an x86 host
[18:17] <ogra> if you are intrested in tryinf out our images you can find install instructions and download links at https://wiki.ubuntu.com/ARM/OMAP it sill always list links to the different release centric instructions
[18:17] <ogra> ok, enough of me babbling i think :)
[18:18] <ogra> there are some questions
[18:18] <ClassBot> darkdevil75 asked: arm?
[18:19] <ogra> yes :)
[18:19] <ClassBot> monish001 asked: arm port means arm hardware architecture platform?
[18:19] <ogra> right, it means the CPU you carry in your mobile phone, tablet or (rarely) in your netbook
[18:19] <ClassBot> monish001 asked: why is arm hardware important?
[18:20] <ogra> heh, well, as you see above it runs very transparently in many devices ... you can find arm in your dishwasher as well as in your mobile phone or the ipad
[18:20] <ogra> even in TVs
[18:21] <ogra> ARM CPUs usually eat a tenth of the power of an x86 CPU while providing the same computing power
[18:21] <ogra> that means you usually dont need a fan for example
[18:22] <ogra> within the last years ARM CPUs turned from very low profile embedded things into powerful CPUs
[18:22] <ogra> i'm currently typing on a netbook (toshiba ac100) that is powered by an arm dual core cpu and can easily take it up with an atom
[18:22] <ogra> but it only weights 700garms and has no fans
[18:23] <ogra> in the next years you will very likely see arm approaching the server market
[18:23] <ogra> in a datacenter the most power is used to keep the air condition running ... wirth arm CPUs that cost will drop significantly
[18:23] <ogra> ...
[18:24] <ogra> thats why arm is an important arch
[18:24] <ogra> (and in my personal opinion the future)
[18:24] <ClassBot> beachbrake asked: Why are ARM development boards more expensive? (from the point of view of a student)
[18:25] <ogra> well, i dont think the beagle or pandaboards are much more expensive than and intel mainboard+cpu+graphics card+network card
[18:25] <ClassBot> chadadavis asked: are compiler developers (i.e. GNU) also involved, or is Linaro also taking that upon themselves?
[18:25] <ogra> linaro is working with gcc upstream and if you know a bit about arm you will know about codesourcery, they are part of linaro
[18:26] <ogra> so all work done on the compiler is done very closely with all entities that are involved in arm gcc nowadays
[18:26] <ClassBot> bullgard asked: "recently ARM recognized how important ubuntu was for them" <- Why is ARM important for Ubuntu end users?
[18:27] <ogra> well, once you can buy netbooks with arm cpu and have a battery life of 3days you will know ;)
[18:27] <ogra> honestly though, tablets, netbooks and mobile phones are the future
[18:28] <ogra> while ubuntu doesnt offer any UI options for the latter two, having the distro running on such platforms enables the developer community to work on them
[18:29] <ogra> so you can work on your concept of porting unity to a mobile phone if you are intrested for example ;)
[18:29] <ClassBot> fisch246 asked: when will Ubuntu Server support ARM?
[18:29] <ogra> well, theoretically it already does
[18:29] <ogra> you can turn a pandaboard into a server and i.e. use it as webserver etc
[18:30] <ogra> practically we might work on server images in future releases, server has always been on our list of devices to support, currently we only focus on netbook though
[18:30] <ClassBot> bullgard asked: What do you mean by "low profile" in "ARM CPUs turned from very low profile embedded things into powerful CPUs"? ("low profile" appears to have several meanings in English.)
[18:30] <ogra> well, i actually meant "underpowered"
[18:30] <ogra> :)
[18:31] <ogra> arm CPUs in the past were designed exactly for a low power task ... i.e. run your dishwasher or your TV settop box
[18:31] <ogra> there was no focus in running a desktop or full server on them
[18:32] <ogra> (though there were many embedded servers around ... your router might run an embedded arm with a webserver UI)
[18:33] <ogra> over the recent years arm simply "grew up" your smartphone is as powerful as your PC was 5 years ago nowadays and you can play games you wouldnt have imagined a few years ago
[18:33] <ogra> (or watch HD movies or ... or ...)
[18:33] <ClassBot> bullgard asked: Is a Ubuntu image enough software or does one need additional software to run Ubuntu from an ARM board?
[18:33] <ogra> depends what hardware you look at
[18:34] <ogra> the omap3 and 4 images we provide also offer you the missing bits and pieces (closed source drivers etc) in an easy way so you can get up and running within minutes
[18:35] <ogra> though the bare image is always good enough to start working right away
[18:35] <ogra> the install isnt harder than on x86 and it doesnt behave different in userspace
[18:35] <ClassBot> balau asked: Debian is working on ARM ports, too. Is Ubuntu (and Linaro) coordinated with Debian on this front?
[18:35] <ogra> INDEED !!!
[18:36] <ogra> i just returned from the emdebian sprint this weekend where debian, linaro, ubuntu and genesi met for working on improvements of the arm port
[18:36] <ogra> and as with x86 debian is our upstream for packages, even though ubuntu is optimized more
[18:37] <ogra> ubuntu builds focus only on the last two generations of arm cpus while debian tries to be backwards compatible for a lot more boards
[18:37] <ogra> but that goes at the cost of performance
[18:38] <ogra> the first arm port in ubuntu was a nearly unmodified rebuild of debian
[18:38] <ogra> optimizations and architecture specific improvements happened since though
[18:38] <ClassBot> jderose asked: what hardware do you recommend for uTouch + ARM?
[18:39] <ogra> oh, thats hard to say since i dont know what HW utouch supports yet, i would recommend talking to the utouch guys for this
[18:39] <ogra> theoretically all hardware that runs on x86 will also run on arm
[18:40] <ogra> i.e. a usb touchscreen you attach to x86 that is supported by utouch will definitely also work on an arm device
[18:40] <ClassBot> chadadavis asked: Are licenses required to distribute the necessary drivers?
[18:40] <ogra> yes
[18:41] <ogra> powervr (which you might know as poulsbo from the intel world) is the most sold 3D chip in the arm world
[18:41] <ogra> sadly the situation isnt much better than with nvidia drivers here
[18:41] <ogra> the drivers are freely usable but not distributable in images
[18:42] <ogra> so we have a set of PPAs for these and a process that automatically installs them after first boot if you chose so
[18:43] <ogra> in cases where you have to accept an EULA this is shown and you can approve or decline it
[18:43] <ClassBot> jderose asked: speaking of drivers, embedded graphics drivers are a big concern for me... looking at ARM website, I got the impression the Mali-T604 might have fully open-source drivers... do you know if this is true?
[18:43] <ogra> i know there are plans that all drivers should go opensource but i dont know if this is already the case
[18:44] <ogra> in fact there is only one board that just came out that uses the mali engine, the linaro guys might know more about this board
[18:44] <ClassBot> abhinav19 asked: so your work involves working at the kernel level or user space packages also need to be modified ? and also, how can new developers get started if they are interested in contributing or learning ?
[18:44] <ogra> our work involves everything that makes up ubuntu
[18:45] <ogra> from the kernel up to UI we make sure everything works on the platform
[18:46] <ogra> while i'm not particulary a kernel guy we gave persons in the team that cover that area and we have community developers that help out as well
[18:46] <ogra> if you want to get started i would suggest dropping by ion #ubuntu-arm, this is the channel where we all hang out
[18:47] <ogra> and there is also the #linaro channel if you are more intrested in the hardcore lowlevel stuff ... like assembler, hacking on toolchains or any other bit thats very close to the hardware
[18:48] <ogra> jederose said he was hoping i could give him a recommendation for a touchscreen regarding his question above
[18:48] <ogra> i cant really, what i know is that the liliput displays work quite well
[18:49] <ogra> they are mainly for car entertainment, but they are cheap and can do full HD
[18:49] <ogra> (and come with a USB touchscreen by default)
[18:49] <ogra> afaik there is no actual recommendation from TI for pandaboard touchscreens
[18:50] <ogra> you could ask in #pandaboard though :)
[18:50] <ogra> so there are 10min to go but no questions left
[18:51] <ogra> i hope i could give some insight in the ubuntu world of arm, linaro and the omap images, thanks for the questions :)
[18:51] <ClassBot> There are 10 minutes remaining in the current session.
[18:51] <ogra> tsimpson, i think i'm done, feel free to take the stage
[18:52] <tsimpson> give me a minute to get my notes :)
[18:53] <ogra> oh, there is another question ...
[18:53] <ogra> i can answer while tsimpson gets his notes
[18:53] <ClassBot> jderose asked: have the Linaro members (TI, Freescale, IBM, Samsung, etc)... been sympathetic to the importance of fully open-source drivers?  Are you optimistic about improvements on this front?
[18:53] <ogra> i think tehy see the need but after all they are all business people indeed
[18:54] <ogra> in fact though, the powervr situation changed a lot during the last year
[18:54] <ogra> part of that is because of TI pushing for more openess
[18:55] <ClassBot> abhinav19 asked: thanks. well I dont have the capacity to buy ARM hardware right now. So if one wants to do application level development, is there some thing like a simulator or emulator to run on PC ?
[18:55] <ogra> yes, as i noted above, there is the qemu-kvm-extras-static package that gives you a chroot ... and indeed you can run qemu VMs
[18:56] <ClassBot> There are 5 minutes remaining in the current session.
[18:57] <ogra> if there are remaining questions, feel free to come by in #ubuntu-arm at any time, the team is there and happily helps
[19:01] <tsimpson> Hello everyone \o
[19:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/03/02/%23ubuntu-classroom.html following the conclusion of the session.
[19:01] <tsimpson> my name is Terence Simpson, and I'm lead developer of the Ubuntu Bots project (that's the one that gives us ubottu and friends)
[19:01] <tsimpson> I'm also an IRC operator in several Ubuntu channels, and a councillor on the Ubuntu IRC Council
[19:01] <tsimpson> so I have come to know IRC quite well over the years
[19:01] <tsimpson> and contrary to some reports, I haven't been hacking on IRC bots since I was 5, I'm just not that 1337 ;)
[19:01] <tsimpson> this is the Launchpad project for Ubuntu Bots: https://launchpad.net/ubuntu-bots
[19:02] <tsimpson> today I'm going to talk to you a bit about the IRC protocol, and creating a simple plugin for the supybot IRC bot
[19:02] <tsimpson> so you may want to 'sudo apt-get install supybot' now if you want to play along
[19:02] <tsimpson> the IRC bot most of you will be familiar with is ubottu, or one of its ubot* and lubotu* clones
[19:03] <tsimpson> these bots are all standard supybot IRC bots with our custom plugins, which are developed in the launchpad project above
[19:03] <tsimpson> later, I'll go through creating a custom plugin, some python knowledge is required for that part
[19:03] <tsimpson> before that though, you should know a something abou the IRC protocol itself
[19:03] <tsimpson> some of what I'm going to discuss may not be necessary for developing a supybot plugin, but it's useful to understand what's actually going on
[19:04] <tsimpson> also, other IRC bots may require more/less knowledge than others, or you may be feeling particularly insane and want to write your own IRC bot/client
[19:04] <tsimpson> http://www.irchelp.org/irchelp/rfc/ contains lots useful information about the IRC protocol, as well as the RFC (the document describing the IRC protocol)
[19:04] <tsimpson> the general way IRC works is, you send a command to the IRC server, followed by carriage-return new-line, and it responds in some way
[19:04] <tsimpson> in this way we say IRC is an "event driven" protocol
[19:04] <tsimpson> the carriage-return and new-line characters are represented by "\r" and "\n" in character strings, new-line is also known as line-feed
[19:05] <tsimpson> and the server uses those two characters to determine when you're done sending your commands
[19:05] <tsimpson> the IRC command you'll care most about when developing an IRC bot, or plugins for IRC bots, is the "PRIVMSG" command
[19:05] <tsimpson> a PRIVMSG is how I'm talking to you now, it how clients send messages, and despite its name, it's not inherently a PRIVate MeSsaGe.
[19:05] <tsimpson> when you type a message into your IRC client, and hit enter, the client will send a PRIVMSG command to the server
[19:06] <tsimpson> command in IRC usually have some arguments/parameters that go along with them
[19:06] <tsimpson> for PRIVMSG, you'll want to tell the server where you want the message sent to
[19:06] <tsimpson> and what the message is
[19:06] <tsimpson> in IRC each argument is separated by a space
[19:06] <tsimpson> if you need to send an argument with a space in it, it has to be the last argument and it needs to be prefixed with a ':' character
[19:06] <tsimpson> our messages usually contain spaces, so that's an instance of where you need to do that
[19:06] <tsimpson> so here's an example
[19:07] <tsimpson> if I wanted to send the message "Hello World!" to the channel "#mychannel", this is what my client would send:
[19:07] <tsimpson> PRIVMSG #mychannel :Hello World!\r\n
[19:07] <tsimpson> the way the server responds to this is to forward that message to all of the other servers it's connected to and clients connected to it
[19:07] <tsimpson> however, when the server forwards these messages, it adds something called a "prefix" to the message
[19:07] <tsimpson> his prefix tells everyone who receives the message where it came from, it's made up of your nick name, user/ident, and host. then prefixed with a ':'
[19:07] <tsimpson> the format is ':nick!ident@host', so the prefix for me is ":tsimpson!~tsimpson@ubuntu/member/stdin"
[19:07] <tsimpson> when your client sees the "Hello World!" message from me, it would receive this:
[19:08] <tsimpson> :tsimpson!~tsimpson@ubuntu/member/stdin PRIVMSG #mychannel :Hello World!\r\n
[19:08] <tsimpson> the only difference between a public channel message and a private one-to-one message is the "target"
[19:08] <tsimpson> the target is either a channel, as #mychannel is above, or a nick of another user
[19:08] <tsimpson> there are lots of commands in the IRC protocol, like NICK, JOIN, PART, QUIT, PRIVMSG, NOTICE, MODE, and many numeric commands
[19:08] <tsimpson> all the numeric commands come from the server and are usually informational or indicate errors
[19:08] <tsimpson> all these messages have the same form when you receive them
[19:08] <tsimpson> :<prefix> <command> <arg0..argN> :<last>
[19:09] <tsimpson> where each item after the <command> is optional (depending on the command)
[19:09] <tsimpson> it's also worth noting that when you get a message from the server, rather than another person, the <prefix> is the server rather than a user mask
[19:09] <tsimpson> for instance, if you connect to someserver.freenode.net, that will be the prefix when you get a message from the server.
[19:09] <tsimpson> using the information in the IRC RFC you could create your own IRC client, and have that do whatever you wanted
[19:09] <tsimpson> and IRC bot is just an IRC client that reacts to the messages in some custom way
[19:09] <tsimpson> really, there is no difference between a "real" IRC client, and some script that connects to an IRC server
[19:10] <tsimpson> another thing to note about IRC, is that it has no character encoding. that is, it's not ASCII, or UTF-8, or anything
[19:10] <tsimpson> it is up to the client to figure out what each particular message is encoded in
[19:10] <tsimpson> but most clients are UTF-8 aware by default, and that's what you should use
[19:10] <tsimpson> IRC is also case insensitive, that is "PRIVMSG #MyChannel" and "privmsg #mychannel" are exactly the same command with exactly the same destination
[19:10] <tsimpson> the only exception to this is the characters '{', '}', and '|', which are considered the lower-case forms of '[', ']' and '\', respectively
[19:11] <tsimpson> the reason for that has to do with IRCs Scandinavian origin, and it's something you'll need to be aware of when comparing nick names etc
[19:11] <tsimpson> from that, you should have a good idea of how ubottu works when responding to factoid requests
[19:11] <tsimpson> it receives a PRIVMSG command from the server, looks at the message target (a channel or itself)
[19:11] <tsimpson> if the message is in a channel, it checks that it starts with the '!' character
[19:11] <tsimpson> then it goes looking in its database for that factoid reply, and sends that off to either the channel or the nick name
[19:11] <tsimpson> ubottu does more complicated things than that
[19:11] <tsimpson> like prefixing a nick in the "!factoid | nick" form, and sending the messages in private with the "!factoid > nick" form
[19:12] <tsimpson> that's a little more complicated, but it all starts with a PRIVMSG command.
[19:12] <tsimpson> there's lots more I could tell you about the IRC protocol
[19:12] <tsimpson> but I wanted to give you an example of how to write a plugin for supybot
[19:12] <tsimpson> some Python knowledge is required here on in, but you should get the general idea even if you don't know Python
[19:13] <tsimpson> if you've installed supybot, you can see its files in /usr/share/pyshared/supybot/
[19:13] <tsimpson> the first thing you need to do, after installing supybot, is to choose a directory where your bot is going to live in
[19:13] <tsimpson> this will be where all the config file and plugin will go
[19:13] <tsimpson> ~/bot is a good example, and that's what I'm going to use in this example
[19:13] <tsimpson> you need to have a terminal open for this, as supybot is set-up via the command-line
[19:14] <tsimpson> irst you create the directory; "mkdir ~/bot", then change to that directory; "cd ~/bot"
[19:14] <tsimpson> then you run though the supybot set-up with the "supybot-wizard" command from ~/bot
[19:14] <tsimpson> you can just hit enter for the first question about bolding, and then 'y' if it works
[19:14] <tsimpson> choose 'n' for the question "Are you an advanced supybot user?"
[19:14] <tsimpson> you can look through that later if you want, but it's not necessary right now
[19:14] <tsimpson> then hit enter to create the directories in the current (~/bot) directory
[19:14] <tsimpson> for the "IRC network", enter: freenode
[19:15] <tsimpson> for the server: irc.freenode.net
[19:15] <tsimpson> then hit enter (or choose 'n') for "Does this connection require connection to a non-standard port?"
[19:15] <tsimpson> then you need to choose a nick name for your bot, remember that it needs to be unique on the network (so don't choose ubottu ;)
[19:15] <tsimpson> for this example, I'll refer to the nick "mybot", but you should choose something different
[19:15] <tsimpson> press enter, or choose 'n', for the question about setting a server password
[19:15] <tsimpson> next it'll ask if you want the bot to join some channels when it connects, you'll want to choose 'y' here
[19:15] <tsimpson> you should now get yourself a temporary channel, this is easy enough, you just join an empty channel
[19:15] <tsimpson> a good idea is to create one based on your nick, so if you are "someone", you'd /join ##someone
[19:16] <tsimpson> the double-# on freenode indicates it's an "about" or unaffiliated channel, anyone is free to create that kind of channel on freenode
[19:16] <tsimpson> so, once you're in your new channel, type the name into the supybot wizard and press enter
[19:16] <tsimpson> supybot comes with many plugins pre-installed, you can look at them later
[19:16] <tsimpson> for now just answer 'n' when it asks if you want to look at them individually
[19:16] <tsimpson> next, it will ask if you want to add an owner for the bot, you do
[19:17] <tsimpson> supybot will only accept certain commands from an owner or an admin
[19:17] <tsimpson> commands that make it join/part channels or change nicks or quit for example
[19:17] <tsimpson> type in your IRC nick for the user-name and then pick a password you'll use
[19:17] <tsimpson> it'll ask twice for the password to make sure you don't mistype
[19:17] <tsimpson> the next question is about the "prefix char", this is a character that the bot will use to recognise when you are giving it a command
[19:17] <tsimpson> press 'y', then enter, then you can choose a character. a good choice is the '@' character
[19:17] <tsimpson> and that's it, a basic set-up for a working supybot IRC bot
[19:18] <tsimpson> to start the IRC bot and get it connected to IRC, you run the command "supybot mybot.conf" (where "mybot" is the nick you chose for your bot)
[19:18] <tsimpson> you'll see it connecting from the console, it'll print lots of information there so you can monitor it
[19:18] <tsimpson> as a note, you can run a supybot instance in "daemon" mode by adding '-d' to the command
[19:18] <tsimpson> that will make the supybot instance run in the background and log messages to ~/bot/log/messages.log
[19:18] <tsimpson> for now though, we will want to see the messages in case there are any errors when we start developing a plugin
[19:19] <tsimpson> which is quite common
[19:19] <tsimpson> you should see something like "Join to ##someone on freenode synced in 1.15 seconds.", that means the bot has successfully joined the channel you gave it
[19:19] <tsimpson> and you should see it sitting there in your channel
[19:19] <tsimpson> the first thing you need to do is let the bot know you are the owner, you do this in /msg as it requires you sending a password
[19:19] <tsimpson> so you do /msg mybot identify someone my_password
[19:19] <tsimpson> (changing "someone" and "my_password" for the name of the owner and the password you gave to supybot-wizard)
[19:20] <tsimpson> you should get a message back with "<mybot> The operation succeeded."
[19:20] <tsimpson> the bot knows you are the owner now
[19:20] <tsimpson> next you should type this in the channel where the bot is: @config supybot.reply.whenNotCommand False
[19:20] <tsimpson> (replacing '@' with the prefix character you choose)
[19:20] <tsimpson> I'll come back to why you did that that later
[19:20] <tsimpson> with its default set-up, the bot won't do very much
[19:20] <tsimpson> so we are going to make a plugin for the bot to do something :)
[19:21] <tsimpson> you'll want to open another terminal window/tab and navigate to ~/bot/plugins (cd ~/bot/plugins)
[19:21] <ClassBot> abhinav19 asked: are there any additional dependencies or requirements for running supybot-wizard as I got some errors ?
[19:21] <tsimpson> there shouldn't be
[19:21] <tsimpson> it just requires the basic python stuff
[19:22] <tsimpson> which should be pre-installed
[19:22] <tsimpson> ok, so we're in ~/bot/plugins
[19:22] <tsimpson> hat is where the bot will look for plugins you create for it
[19:22] <tsimpson> *that
[19:22] <tsimpson> we are going to create a plugin, called Say, that will make the bot say something when we tell it to
[19:22] <tsimpson> it will have one command in it, "say", which will repeat everything after the command
[19:23] <tsimpson> so when we do "@say Hello, World!", our bot will reply with "Hello, World!"
[19:23] <tsimpson> how exciting :)
[19:23] <tsimpson> to start we run the command "supybot-plugin-create"
[19:23] <tsimpson> it'll ask what the name of the plugin should be
[19:23] <tsimpson> et's choose "Say"
[19:23] <tsimpson> (plugin names should usually start with an upper-case character)
[19:23] <tsimpson> the question about if it should be threaded is for more advanced plugins, that may be doing many things at the same time. we don't need that so we choose 'n'
[19:23] <tsimpson> it'll then ask for your real name, so it can add a copyright and licensing information, go ahead and enter that
[19:24] <tsimpson> and choose 'y' to use the Supybot license
[19:24] <tsimpson> you can choose another license for your plugins if you wish, but the supybot license is an open-source license
[19:24] <tsimpson> the template for the plugin should now be in the "Say" sub-directory at ~/bot/plugins/Say, so navigate there
[19:24] <tsimpson> you'll see 5 files and one directory, "config.py", "__init__.py", "plugin.py", "README.txt", and "test.py" are the files
[19:24] <tsimpson> the directory is there in case you want to create custom python modules
[19:24] <tsimpson> we won't be using it in this example, but it does no harm being there
[19:24] <tsimpson> "config.py" is where all the configuration for the plugin will go, we don't need any configuration for this plugin, so we won't modify that
[19:25] <tsimpson> "__init__.py" is there to make that directory a python module, you can put some things in there if you wanted, but we don't need to do anything special here
[19:25] <tsimpson> "plugin.py" is where our actual plugin code will be, we'll come back to that in a second
[19:25] <tsimpson> "README.txt" is pretty self-explanatory, it's where you'll put some information about your plugin, like a description and any set-up information
[19:25] <tsimpson> "test.py" is for testing, for complex plugins you can use that with the supybot-test script to run tests on the plugin
[19:25] <tsimpson> now go ahead and open plugin.py in your favourite editor or python IDE
[19:26] <tsimpson> the comment block at the top is the your copyright and the supybot license
[19:26] <tsimpson> then it has some default imports followed by our plugin class "class Say(callbacks.Plugin):"
[19:26] <tsimpson> all supybot plugin classes need to derive from supybot.callbacks.Plugin in some way, and there are a few special sub-classes too
[19:26] <tsimpson> then is the line "Class = Say"
[19:26] <tsimpson> when supybot imports a plugin module, it looks for "Class" in that module to identify the plugin
[19:26] <tsimpson> and in __init__.py it imports "plugin", and sets Class = plugin.Class
[19:27] <tsimpson> now we should change the doc-string to something meaningful
[19:27] <tsimpson> supybot uses the doc-strings of classes and methods to provide the "@help" command
[19:27] <tsimpson> so it's good practice to always document as you go
[19:27] <tsimpson> something like """A plugin to say something when told to""" is good enough for this plugin
[19:27] <tsimpson> when supybot receives a command from the IRC server, it looks for a corresponding method in the plugins it has loaded
[19:27] <tsimpson> the command is lower-cased and capitalized, so "PRIVMSG" becomes "Privmsg"
[19:28] <tsimpson> the method supybot looks for is "do" followed by the command
[19:28] <tsimpson> so, if we want to listen for channel/private message, we need to create an "doPrivmsg" method
[19:28] <tsimpson> for all of these kinds of method, supybot passes 2 arguments
[19:28] <tsimpson> an instance of the supybot.irclib.Irc class (or a wrapper class), which represents the IRC client/bot, remember there's really no difference
[19:28] <tsimpson> and an instance of the supybot.ircmsgs.IrcMsg class, which represents and IRC message
[19:28] <tsimpson> in our method the Irc class we get will be a 'supybot.callbacks.ReplyIrcProxy'
[19:29] <tsimpson> it just adds some convenience methods for replying to messages
[19:29] <tsimpson> the Irc instance will contain information such as the network connected to
[19:29] <tsimpson> nick name of the bot on that network
[19:29] <tsimpson> and state information, like what channels are joined and what users are in those channels etc
[19:29] <tsimpson> as I mentioned earlier, when you want to compare channels or nicks in IRC, there are some special characters to consider
[19:29] <tsimpson> supybot has some utility function that help us, they are located in the supybot.ircutils module, which is already imported as "ircutils"
[19:30] <tsimpson> back to the plugin
[19:30] <tsimpson> in you plugin class (Say), remove the line "pass"
[19:30] <tsimpson> then create a method called "doPrivmsg" taking 3 arguments, "self", "irc", and "msg"
[19:30] <tsimpson> you should now have something similar to http://people.ubuntu.com/~tsimpson/botdev/plugin.1.py
[19:30] <tsimpson> still nothing useful there, but we're about to change that
[19:30] <tsimpson> this doPrivmsg method of our plugin class will be called when ever the bot sees a message
[19:31] <tsimpson> now, we need some way to tell if the message was addressed to the bot or not
[19:31] <tsimpson> we don't want our bot to respond to random messages after all
[19:31] <tsimpson> our bot is addressed for example, if the message starts with the bots nick or command character you set
[19:31] <tsimpson> now we could write some code to do all that
[19:31] <tsimpson> but I'm lazy ;)
[19:32] <tsimpson> and besides, we don't need to
[19:32] <tsimpson> there is a "addressed" function in the 'supybot.callbacks' module which will do all that for us
[19:32] <tsimpson> and supybot.callbacks is already imported as 'callbacks' for us
[19:32] <tsimpson> we give it the bots nick, and the IRC message ('msg' parameter)
[19:32] <tsimpson> it will either return an empty string, in which case the bot wasn't addressed
[19:32] <tsimpson> or it will return the message without the part of the message used to address the bot
[19:32] <tsimpson> for example, if the message way "mybot: this is a message", and we executed this code:
[19:32] <tsimpson> message = callbacks.addressed(irc.nick, msg)
[19:32] <tsimpson> the result in 'message' would be "this is a message"
[19:33] <tsimpson> f the message was just "this is a message", then 'message' would be an empty string ''
[19:33] <tsimpson> by the way, as I mentioned above the 'irc' parameter contains information, such as the bots nick. that's what 'irc.nick' gives us
[19:33] <tsimpson> in the 'msg' parameter there is the property 'args'
[19:33] <tsimpson> that holds a tuple with all the arguments of the message
[19:33] <tsimpson> remember that PRIVMSG has 2 arguments
[19:33] <tsimpson> the "target" (a channel or nick), and the message
[19:33] <tsimpson> the target is in 'msg.args[0]' and the message is in 'msg.args[1]'
[19:33] <tsimpson> when we call 'callbacks.addressed', it looks at both msg.args[0] and msg.args[1]
[19:34] <tsimpson> it will check if msg.args[0] (the target of the message) is the bots nick, in which case it is a private message
[19:34] <tsimpson> so, the first thing we do in our doPrivmsg method, is this:
[19:34] <tsimpson> message = callbacks.addressed(irc.nick, msg)
[19:34] <tsimpson> then we can check if 'message' is empty and, in that case, just return
[19:34] <tsimpson> this is the code:
[19:34] <tsimpson> if not message:
[19:34] <tsimpson>     return
[19:34] <tsimpson> that way our plugin will just ignore all the messages which are not addressed to it
[19:34] <tsimpson> next we will need to check that the message is our "say" command
[19:35] <tsimpson> we can do this by splitting off the first word of 'message' and checking that it equals 'say'
[19:35] <tsimpson> we'll also want to remove it from the 'message' string, as it's not part of what we are supposed to repeat
[19:35] <tsimpson> this is the code:
[19:35] <tsimpson> bot_cmd = message.split(None, 1)[0]
[19:35] <tsimpson> message = message[len(bot_cmd):].strip()
[19:35] <tsimpson> here we're also slicing the 'message' to remove the command, and calling strip on that
[19:35] <tsimpson> the command could well just be one word, so we can't just split it and assign to two variables
[19:35] <tsimpson> we need to use strip() so that we don't have any leading space if/when we reply
[19:35] <tsimpson> now we check if the command in 'bot_cmd' is the one we are looking for
[19:36] <tsimpson> this is the code:
[19:36] <tsimpson> if bot_cmd.lower() != 'say':
[19:36] <tsimpson>     return
[19:36] <tsimpson> we lower-case the command and check if it's "say", if not we just return as we aren't interested in other commands
[19:36] <tsimpson> the next thing we need to do is check if we were actually given a message to repeat
[19:36] <tsimpson> there's not much point calling a command that repeats a message without a message to repeat!
[19:36] <tsimpson> if we weren't give a message, then we need to respond with an error message indicating that we need more arguments
[19:36] <tsimpson> remember that 'message' is now whatever was left after we removed the command
[19:36] <tsimpson> this is the code:
[19:36] <tsimpson> if not message:
[19:36] <tsimpson>     irc.error("I need something to say")
[19:36] <tsimpson>     return
[19:37] <tsimpson> 'error' is a method on the 'irc' object that lets us respond with an error message
[19:37] <tsimpson> it will prefix "Error: " to whatever message you pass to it
[19:37] <tsimpson> if we get past that part of the code, then we know three things
[19:37] <tsimpson> 1) we know the bot was addressed in some way
[19:37] <tsimpson> 2) we know the command is "say"
[19:37] <tsimpson> 3) we know we have the message to repeat
[19:37] <tsimpson> the only thing left to do, is actually repeat the message!
[19:37] <tsimpson> this is the code:
[19:37] <tsimpson> irc.reply(message)
[19:37] <tsimpson> that's it, the 'reply' method does exactly what you think it does, replies to the message we got
[19:38] <tsimpson> now our plugin is ready to be used, it should look something like this: http://people.ubuntu.com/~tsimpson/botdev/plugin.2.py
[19:38] <tsimpson> that's around 12 lines of python we've added, and it does exactly what we want :)
[19:38] <tsimpson> to tell you bot to load that plugin, you issue the command "@load Say" in the channel it's in, or in a /msg
[19:38] <tsimpson> you should see a "The operation succeeded." message from the bot
[19:38] <tsimpson> if you get an error message, you probably have some typo in the code
[19:38] <tsimpson> now you can test the plugin out
[19:39] <tsimpson> I'll have nubotu join here to show you how it should work
[19:39] <tsimpson> nubotu is my general testing/development bot
[19:39] <tsimpson> @load Say
[19:39] <nubotu> tsimpson: The operation succeeded.
[19:39] <tsimpson> @say Hello, World!
[19:39] <nubotu> tsimpson: Hello, World!
[19:39] <tsimpson> the bot won't respond to this message, callbacks.addressed() will return an empty string
[19:39] <tsimpson> @the bot won't respond to this either, as "the" is not the "say" command we want
[19:39] <tsimpson> nubotu: and it won't respond here, as "and" isn't the "say" command either
[19:40] <tsimpson> this will cause nubotu to respond with an error, as I'm leaving out the message
[19:40] <tsimpson> @say
[19:40] <nubotu> tsimpson: Error: I need something to say
[19:40] <tsimpson> nifty ey?
[19:40] <tsimpson> now, even though that's only around 12 lines of code
[19:40] <tsimpson> it's still an awful lot of code for a simple repeater command
[19:40] <tsimpson> fortunately supybot can help us some more here
[19:40] <tsimpson> in the above example, we didn't really create a command
[19:40] <tsimpson> at least not in the sense supybot cares about
[19:40] <tsimpson> remember we did "@config supybot.reply.whenNotCommand False"?
[19:41] <tsimpson> if we set that back to True, you'll see what I mean
[19:41] <tsimpson> @config supybot.reply.whenNotCommand True
[19:41] <nubotu> tsimpson: The operation succeeded.
[19:41] <tsimpson> @say
[19:41] <nubotu> tsimpson: Error: "say" is not a valid command.
[19:41] <nubotu> tsimpson: Error: I need something to say
[19:41] <tsimpson> @say Hello, World!
[19:41] <nubotu> tsimpson: Error: The "Say" plugin is loaded, but there is no command named "Hello," in it.  Try "list Say" to see the commands in the "Say" plugin.
[19:41] <nubotu> tsimpson: Hello, World!
[19:41] <tsimpson> that's not so good :(
[19:41] <tsimpson> in supybot, we create command by defining a method of the same name, and then "wrapping" it
[19:41] <tsimpson> I'll talk more about wrap in a second
[19:41] <tsimpson> so now go ahead and delete the entire "doPrivmsg" method from your plugin.py
[19:42] <tsimpson> the whole thing
[19:42] <tsimpson> we don't need it
[19:42] <tsimpson> and replace it with this:
[19:42] <tsimpson> def say(self, irc, msg, args, message):
[19:42] <tsimpson>     """<message>
[19:42] <tsimpson>     Repeats <message>
[19:42] <tsimpson>     """
[19:42] <tsimpson>     irc.reply(message)
[19:42] <tsimpson> and that's our 'say' command
[19:42] <tsimpson> the doc-string describes how to use the command, we take only one argument '<message>', so that goes on the first line
[19:42] <tsimpson> then we have a blank line, followed by a description of the command.
[19:42] <tsimpson> this will be shown when we do @help say
[19:42] <tsimpson> the irc and msg parameters are pretty much the same as in our previous doPrivmsg method
[19:43] <tsimpson> except that 'irc' will usually be a supybot.callbacks.NestedCommandsIrcProxy, that' not something you really need to care about though
[19:43] <tsimpson> you don't need to worry about the 'args' parameter for now, it's for more advanced commands
[19:43] <tsimpson> the 'message' parameter is what is going to hold the message we are supposed to say, we don't need to do anything special like with doPrivmsg
[19:43] <tsimpson> when our command method is called, we *will* have a message to repeat, 'wrap' will make sure for us
[19:43] <tsimpson> next we need to tell supybot that that method is a command, we do this using the 'wrap' function, which is imported from supybot.commands
[19:43] <tsimpson> put this under you method:
[19:43] <tsimpson> at the same indentation as "def"
[19:44] <tsimpson> say = wrap(say, ['text'])
[19:44] <tsimpson> the 'wrap' function takes a method, and then a list of so-called "converters"
[19:44] <tsimpson> in this case, we only want some text, we don't care what it is as long as it's there
[19:44] <tsimpson> by the way, if you are creating a command that doesn't take any parameters, you can use wrap as a method decorator by putting '@wrap' before the definition
[19:44] <tsimpson> but you'll usually want to have some parameters for your commands
[19:44] <tsimpson> now your plugin.py should look like this: http://people.ubuntu.com/~tsimpson/botdev/plugin.3.py
[19:44] <tsimpson> without all the comments and doc-strings, it's just 3 lines. nice :)
[19:45] <tsimpson> let's reload the plugin so the changes take effect
[19:45] <tsimpson> @reload Say
[19:45] <nubotu> tsimpson: The operation succeeded.
[19:45] <tsimpson> now we test
[19:45] <tsimpson> @help say
[19:45] <nubotu> tsimpson: (say <message>) -- Repeats <message>
[19:45] <tsimpson> @say Hello, World!
[19:45] <nubotu> tsimpson: Hello, World!
[19:45] <tsimpson> @say
[19:45] <nubotu> tsimpson: (say <message>) -- Repeats <message>
[19:45] <tsimpson> nubotu: say hello to all the people
[19:45] <nubotu> tsimpson: hello to all the people
[19:45] <tsimpson> it works!
[19:45] <tsimpson> by the way, if you do '@config supybot.reply.withNickPrefix False', it won't prefix your nick to the response
[19:46] <tsimpson> @config supybot.reply.withNickPrefix False
[19:46] <nubotu> tsimpson: The operation succeeded.
[19:46] <tsimpson> nubotu: say hello to all the nice people
[19:46] <nubotu> hello to all the nice people
[19:46] <tsimpson> and that's the _basics_ of building plugins for supybot
[19:46] <tsimpson> things can get a lot more complicated very quickly, have a look at our plugins at: http://bazaar.launchpad.net/~ubuntu-bots/ubuntu-bots/devel/files
[19:46] <tsimpson> that's basically ubottu right there
[19:46] <tsimpson> there's also some useful documentation for using supybot at http://supybook.fealdia.org/latest/ and http://ubottu.com/supydocs/
[19:46] <tsimpson> and the documentation that comes with supybot in /usr/share/doc/supybot/, especially the USING_WRAP.gz document
[19:47] <tsimpson> oh, and come join us in #ubuntu-bots-devel if you want to help make ubottu even better :)
[19:47] <tsimpson> I'll answer any questions you may have now
[19:47] <tsimpson> (but please don't expect me to know the details of other IRC bot programs, I'll do my best though ;)
[19:47] <tsimpson> nubotu: part
[19:48] <tsimpson> hey, I just zoomed through the IRC protocol and bot plugin development in 47 minutes
[19:49] <tsimpson> no one has questions?
[19:51] <ClassBot> There are 10 minutes remaining in the current session.
[19:52] <ClassBot> Mkaysi asked: Doesn't Supybot require pysqlite ?
[19:52] <tsimpson> no
[19:52] <tsimpson> not the basic supybot
[19:52] <tsimpson> but as the plugins are just python modules
[19:53] <tsimpson> they can, and do, have their own dependencies
[19:53] <tsimpson> Encyclopedia (the factoid plugin for ubottu), does use it, for example
[19:54] <tsimpson> we plan to change that though :)
[19:55] <tsimpson> I should probably end by saying that supybot isn't the only IRC bot out there
[19:55] <tsimpson> there are many others
[19:55] <tsimpson> in different languages
[19:55] <tsimpson> and with different capabilities
[19:56] <ClassBot> There are 5 minutes remaining in the current session.
[19:56] <tsimpson> we use supybot mostly because it's the easiest to develop in, as Ubuntu comes with python anyway
[19:56] <tsimpson> but other bots can be, and are, just as good or better for you
[19:56] <ClassBot> Mkaysi asked: What things I should tell supybot to forget from Encyclopedia? In example op ops calltheops owner.
[19:57] <tsimpson> there is detailed use info on the bot wiki
[19:57] <tsimpson> http://ubottu.com/devel/wiki
[19:57] <tsimpson> and we can help in #ubuntu-bots too
[19:57] <ClassBot> chadadavis asked: Can a I configure a plugin to load on start (myplugin.conf)?
[19:58] <tsimpson> by default supybot loads all the plugins that were running when the bot shut down
[19:58] <tsimpson> so unless you @unload a plugin, it will auto-load
[19:59] <tsimpson> if you have any more question, the bots team hangs out in #ubuntu-bots and #ubuntu-bots-devel
[19:59] <tsimpson> we'll help you there :)
[20:00] <tsimpson> thanks for listening, and I hope you'll all come help us make ubottu rock! :D
[20:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/03/02/%23ubuntu-classroom.html following the conclusion of the session.
[20:02] <kamstrup> Hi all, so I guess I'm next one up...
[20:02] <kamstrup> And thanks to Terence Simpson for the cool talk
[20:02] <kamstrup> I am Mikkel Kamstrup Erlandsen
[20:02] <kamstrup> and I work on the DX team for Canonical
[20:03] <kamstrup> I am working on the backend side of all things unity
[20:03] <kamstrup> My work is primarily around the "places"
[20:03] <kamstrup> and in my spare time I hack on Zeitgeist
[20:04] <kamstrup> so its all searching and backend code for me :-)
[20:04] <kamstrup> So for today
[20:04] <kamstrup> It's about libunity
[20:04] <kamstrup> Here's what I plan to go over:
[20:04] <kamstrup>  - libunity background
[20:04] <kamstrup>  - libunity feature set
[20:04] <kamstrup>  - the unity launcher integration
[20:05] <kamstrup>  - the unity places integration
[20:05] <kamstrup>  - some working examples of ^^
[20:05] <kamstrup>  - and finally a bit about what you can expect for the future of libunity
[20:05] <kamstrup> Hopefully this should empower you all to go out and rock the world with awesome unity integration
[20:06] <kamstrup> So first item on the agenda: About libunity
[20:06] <kamstrup> It's a native library  written in Vala
[20:06] <kamstrup> We use Vala to generate GObject Introspection files so we can have automagic bings for Python and friends
[20:07] <kamstrup> It's important to underline that libunity is strictly a client side library
[20:07] <kamstrup> that is
[20:07] <kamstrup> Unity itself does *not* link to it
[20:07] <kamstrup> We focus on making the API simple and fun
[20:07] <kamstrup> So we've chosen to very "property based"
[20:08] <kamstrup> so you get access to a bunch of object on which you set properties
[20:08] <kamstrup> and that is automatically reflect on unity
[20:08] <kamstrup> all of the communication it does is pretty much DBus
[20:08] <kamstrup> and it leverages libdbusmenu and libdee
[20:08] <kamstrup> to perform some of the more complex dbus-stuff
[20:09] <kamstrup> Now let's move on to talk about the feature set of libunity
[20:09] <kamstrup> Right now there are 2 main things supportedd
[20:09] <kamstrup>  - the launcher inetgration
[20:10] <kamstrup>    - with progress, counter, emblems, and quicklist attached to application tiles in the launcher
[20:10] <kamstrup>  - and then place inetgration
[20:10] <kamstrup>     - which allows you to hook into the place framework and write you own places
[20:11] <kamstrup> Maybe some of you already saw the wiki page about the launccher API: https://wiki.ubuntu.com/Unity/LauncherAPI
[20:11] <kamstrup> let's slowly step through it
[20:11] <kamstrup> looking at the first screenshot
[20:12] <kamstrup> you'll see the progress bar and counter in action
[20:12] <kamstrup> and the screenie below is a quicklist
[20:12] <kamstrup> So if you scroll down to the Vala example
[20:12] <kamstrup> you can see it's all property based
[20:13] <kamstrup> all of the attributes has a _visible cousin
[20:13] <kamstrup> like emblem_visible
[20:13] <kamstrup> these allow you to keep the state of you variables around
[20:13] <kamstrup> by just hiding the overlay
[20:14] <kamstrup> there is one thing worth mentioning here
[20:14] <kamstrup> it is that the quicklists are not 100% wired up on the unity side yet
[20:14] <kamstrup> there are 2 ways to write quicklists
[20:14] <kamstrup> "static quicklists" are there even when your app is not running
[20:15] <kamstrup> these are defined inside the .desktop files for the apps
[20:15] <kamstrup> then there are "dyanmic quicklists"
[20:15] <kamstrup> dynamic
[20:15] <kamstrup> these are created at runtime by your app
[20:15] <kamstrup> and can be very funky
[20:15] <kamstrup> they use the Dbusmenu API which some of you may already know from the indicators
[20:16] <kamstrup> it's a powerful api that let's you create arbitrarily complex menus
[20:16] <kamstrup> if you want to compile the vala example you'll need the very latest libunity from the archives
[20:17] <kamstrup> that would be 3.4.6 i believe
[20:17] <kamstrup> if you run the example as is, you'll need to start evolution before you run the example
[20:18] <kamstrup> if you want to use the python example
[20:18] <kamstrup> make sure you have the packages:
[20:18] <kamstrup> gir1.2-unity-3.0
[20:18] <kamstrup> gir1.2-dee-0.5
[20:18] <kamstrup> so i hope you don't have trouble running that if you try
[20:19] <kamstrup> don't hesitate to ask if you have trouble
[20:19] <kamstrup> chances are that 50% of the other people here have the same problem
[20:19] <kamstrup> Ok, that was hopefully pretty light
[20:19] <kamstrup> The next thing we'll look at is the places
[20:20] <kamstrup> as you may expect that's more complex
[20:20] <kamstrup> There is a wiki page which gives a rought overview of the places architecture: https://wiki.ubuntu.com/Unity/Places
[20:20] <kamstrup> it probably can't stand for itself though
[20:21] <kamstrup> The first thing unity will look for when integrating with a place is a ".place file"
[20:21] <kamstrup> The .place files define the basic access point for your place
[20:22] <kamstrup> It's a standard .ini or .desktop format what ever we call it
[20:22] <kamstrup> [Place]
[20:22] <kamstrup> DBusName=Well known bus name the place can be found under
[20:22] <kamstrup> DBusObjectPath=DBus object path the place object lives at
[20:22] <kamstrup> This is the main section
[20:22] <kamstrup> defining the dbus name and dbus object path your place can be found on
[20:22] <kamstrup> doing it like this allows you to have more than one place inside the same process
[20:22] <kamstrup> although noone is doing that right now
[20:23] <kamstrup> A "place" consist of a set of "place entries"
[20:23] <kamstrup> A place in itself has no icon in the launcher - it's just a container for place entries
[20:23] <kamstrup> For each Place Entry you implement there will be one icon in the launcher
[20:23] <kamstrup> (or you can hide it if you want)
[20:24] <kamstrup> So in the .place files you specify each of the place entries you expose
[20:24] <kamstrup> It can look like:
[20:24] <kamstrup> [Entry:Stuff]
[20:24] <kamstrup> DBusObjectPath=DBus path for the place entry (must be a direct child of Places' DBusPath)
[20:24] <kamstrup> Icon=Icon for the place entry
[20:24] <kamstrup> Name=Display name for the entry
[20:24] <kamstrup> Description=Short description of what the entry provides. Suitable for display as tooltip or other
[20:24] <kamstrup> ShowGlobal=True|False (defaults to True)
[20:24] <kamstrup> ShowEntry=True|False (defaults to True)
[20:24] <kamstrup> In theory Unity could just as well look all this up over DBus once it has your address from the main [Place] group in the .place file
[20:25] <kamstrup> but
[20:25] <kamstrup> having it in the .place file allows unity to put icons on screen even before you place has started up
[20:25] <kamstrup> so this is good for startup time
[20:25] <kamstrup> So going over the [Entry:Stuff]
[20:25] <kamstrup> There is another dbus path for the place entry itself
[20:26] <kamstrup> And you can assign an icon, name, and description
[20:26] <kamstrup> ShowGlobal tells unity whether or not this entry has search result to show in the Dash
[20:26] <kamstrup> Dash - aka the homescreen
[20:26] <kamstrup> you get when you click the ubuntu button in the top left corner
[20:27] <kamstrup> so setting ShowGlobal=False will make unity not call you when it needs to update the results for the Dash
[20:27] <kamstrup> Likewise the SHowEntry
[20:27] <kamstrup> it determines whether you have a tile in the Launcher on the right
[20:28] <kamstrup> You can check out your  current .place files in /usr/share/unity/places
[20:28] <kamstrup> You'll also notice a "Shortcut" entry in the .place files you have
[20:28] <kamstrup> It defines the letter you need to press in combo with <super> to bring up the dash showing your particular place
[20:29] <kamstrup> And you'll also notice
[20:29] <kamstrup> that since the groups in the .place file are formatted like [Entry:NameOfEntry]
[20:29] <kamstrup> You can define more than one entry per .place file
[20:29] <kamstrup> so far so good - given a .place file unity can now find you
[20:30] <kamstrup> so before we proceed I need to talk to you about how unity shares datamodels with the place daemons
[20:30] <kamstrup> There is a central library called Dee (or libdee if you will)
[20:31] <kamstrup> Dee implements a set of datamodels you can share across dbus
[20:31] <kamstrup> And they are like peer-2-peer models
[20:31] <kamstrup> So both unity and the place daemon can modify the models
[20:31] <kamstrup> although in practice it's mostly just the place daemons
[20:32] <kamstrup> This makes implement searching and all that very convenient
[20:32] <kamstrup> So when you search (fx. with Zzeitgeist) you don't have to collect a result set an send it to unity
[20:32] <kamstrup> you simply update your model
[20:32] <kamstrup> this gives a neat way to implement "incremental searches" if you want
[20:33] <kamstrup> meaning - iteratively removing hits from the result set as the user types
[20:33] <kamstrup> so we don't have to send the entire result set over and over
[20:33] <kamstrup> you just update your model removing the rows that no longer match
[20:33] <kamstrup> under the hood Dee basically sends a "diff" to all the peers sharing the model
[20:34] <kamstrup> So Dee is very powerful
[20:34] <kamstrup> If we go back to the wiki page...
[20:34] <kamstrup> https://wiki.ubuntu.com/Unity/Places
[20:35] <kamstrup> We need to establish the "terminology" on the top of the page
[20:35] <kamstrup> There are three words you need to know the meaning of:
[20:35] <kamstrup>  - result model
[20:35] <kamstrup>  - groups model
[20:35] <kamstrup>  - sections model
[20:36] <kamstrup> It's probably easiest if we take the Apps place as an example
[20:36] <kamstrup> The "result model" here is (surprise!) what you see when you search
[20:36] <kamstrup> The "groups model" defines the user visible grouping of the result model
[20:36] <kamstrup> If you open the apps place
[20:37] <kamstrup> (super-a)
[20:37] <kamstrup> You'll see two groups there
[20:37] <kamstrup> or wait - maybe you don't just yet
[20:37] <kamstrup> ... sorry
[20:37] <kamstrup> But there are 3 groups - let me write them for you
[20:37] <kamstrup> Installed
[20:37] <kamstrup> Available for Install
[20:37] <kamstrup> and Most Popular Apps
[20:38] <kamstrup> These partition the result set in 3
[20:38] <kamstrup> So on to the "sections"
[20:38] <kamstrup> Sections in the apps place are like "Accesories", "Media", "System", ...
[20:38] <kamstrup> Ie they partition not the result set, but more the "browsable space"
[20:38] <kamstrup> or the entire set of items you can potentially find
[20:39] <kamstrup> I think it'll be most easy for all if I spring my surprise now
[20:39] <kamstrup> So the surprise is that just today I have a fully working stack supporting place daemon implementations in Python!
[20:40] <kamstrup> This makes playing around with this stuff so much easier
[20:40] <kamstrup> So let me point you to a fully working place implemented in Python
[20:41] <kamstrup> Here: http://bazaar.launchpad.net/~unity-team/unity-place-sample/unity-place-python/files
[20:41] <kamstrup> So let's dig into unity-place-pythhon.py
[20:42] <kamstrup> Let's start at line 28 http://bazaar.launchpad.net/~unity-team/unity-place-sample/unity-place-python/view/head:/unity-place-python.py#L28
[20:42] <kamstrup> Here we create the Place Entry i talked about
[20:42] <kamstrup> we give it some random dbus path
[20:42] <kamstrup> The models we create are all DeeSharedModels
[20:43] <kamstrup> On each of the models we need to call set_schema()
[20:43] <kamstrup> The schema *must* be like this
[20:43] <kamstrup> you can see the definitions on https://wiki.ubuntu.com/Unity/Places#Results%20Model
[20:44] <kamstrup> The "model schemas" is really just a list of GVariant or DBus signatures
[20:44] <kamstrup> one signature for each column you want to have in the model
[20:44] <kamstrup> and you can even shove arbitrarily complex variants in the schema
[20:44] <kamstrup> it works
[20:44] <kamstrup> but for unity places we only use simple types such as strings "s" and uints "u"
[20:45] <kamstrup> On line 42
[20:45] <kamstrup> I create the sections model
[20:45] <kamstrup> i give it a bus name
[20:45] <kamstrup> which the model will use to rendevouz with other models with the same name
[20:45] <kamstrup> and sync up with them
[20:45] <kamstrup> and on line 44 i tell the place entry that i want to use this model as my sections
[20:46] <kamstrup> ditto for all the other models created in there
[20:46] <kamstrup> notice the models with a _global in the variable names
[20:46] <kamstrup> these models will be used for searches via the Dash
[20:47] <kamstrup> while those without global_ will be used when you search dedicated within this particular place
[20:47] <kamstrup> Let's skip a bit forward an look at line 73: http://bazaar.launchpad.net/~unity-team/unity-place-sample/unity-place-python/view/head:/unity-place-python.py#L73
[20:48] <kamstrup> here I connect to a bog standard Gobject signal from the place entry
[20:48] <kamstrup> The notify signal when the "active-search" property changes
[20:48] <kamstrup> On line 127 http://bazaar.launchpad.net/~unity-team/unity-place-sample/unity-place-python/view/head:/unity-place-python.py#L127
[20:48] <kamstrup> you'll see the callback i connect to this signal
[20:49] <kamstrup> Here i simply figure out what the new search string is and I start updating the model
[20:49] <kamstrup> the results model that is
[20:49] <kamstrup> To keep this example simple i always just call model.clear()
[20:50] <kamstrup> the "real" places - files and apps - don't do this, but they iteratively narrow down the results_model as you type
[20:50] <kamstrup> but that's quite a lot more complex and it works very well without it
[20:50] <kamstrup> So what does this particular place do..?
[20:51] <ClassBot> There are 10 minutes remaining in the current session.
[20:51] <kamstrup> It simply just splits the search string into letters and adds a hit for each letter pointing to the wikipedia article for that letter
[20:51] <kamstrup> You can see it splits the results into different groups
[20:51] <kamstrup> ok, I need to start wrapping up
[20:52] <kamstrup> One important note:
[20:52] <kamstrup> If you want to run the Python example you need a small hack for now
[20:52] <kamstrup> because all the latest jazz isn't in the package archives just yet
[20:52] <kamstrup> The hack you need is to take this file: http://bazaar.launchpad.net/~unity-team/dee/trunk/view/head:/bindings/python/Dee.py
[20:52] <kamstrup> and then:
[20:53] <kamstrup> download it somewhere and copy it to the right location like so:
[20:53] <kamstrup> sudo cp Dee.py /usr/lib/pymodules/python2.7/gi/overrides/Dee.py
[20:53] <kamstrup> This is needed to make Dee play well with Python
[20:53] <kamstrup> With that in place you should follow the guidelines in http://bazaar.launchpad.net/~unity-team/unity-place-sample/unity-place-python/view/head:/README
[20:55] <kamstrup> We probably don't have a lot of time to debug any problems now, but if you poke at it  and find problems don't hesitate to ping me on the #ayatana channel
[20:55] <kamstrup> While I'm throwing links around - the most basic Vala example is lp:unity-place-sample
[20:56] <kamstrup> but you can dig in and find an example a tad more complex - doing youtube searches
[20:56] <ClassBot> There are 5 minutes remaining in the current session.
[20:56] <kamstrup> You can see the list of example places here https://code.launchpad.net/unity-place-sample
[20:56] <kamstrup> I'll try and put all illustrative examples there
[20:56] <kamstrup> when new ones crop up
[20:57] <kamstrup> So quickly on the future of libunity:
[20:57] <kamstrup>  - We'll have API docs for C, Python, and Vala up very soon
[20:57] <kamstrup>  - Dee already have good docs for C in the libdee-doc package . but we'll have Vala and Python docs for it too
[20:58] <kamstrup>  - the longer term goal for libunity is to be able to integrate and instrument the entire Unity shell from top to bottom
[20:58] <kamstrup> So launcher and places is just the prelimanry goodies we can deliver for Natty
[20:58] <kamstrup> For N+1 you see some nice APIs to work with the various indicators and menus
[20:59] <kamstrup> And lastly - a disclaimer
[20:59] <kamstrup> Sorry to end with that
[20:59] <kamstrup> But we can't guarantee API or ABI stability at this point
[20:59] <kamstrup> we hope there will be no landslide changes
[20:59] <kamstrup> but small changes will trickle in
[21:00] <kamstrup> but we we'll provide stability at some point
[21:00] <kamstrup> Maybe N+1 or +2
[21:00] <kamstrup> and that's a wrap!
[21:00] <kamstrup> Any questions can go in #ayatana
[21:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/03/02/%23ubuntu-classroom.html