[00:28] <awanti> Hello friends I am from india. I want to attend the Ubuntu Developer Week. So plz. tell the time?
[00:29] <pleia2> awanti: the second day starts in 15.5 hours
[00:29] <rww> awanti: The schedule's at https://wiki.ubuntu.com/UbuntuDeveloperWeek . Click the times on it to get conversions to your timezone.
[00:32] <awanti> ok thanks I got the timings. In India it will start at 9.30 pm.
[05:08] <sssssss> Hello
[08:22] <laxmi> ubuntu wired network problem
[08:22] <laxmi> wireless works, wired does not work
[08:23] <leoquant> hi laxmi for support please join #ubuntu
[08:23] <leoquant> via /join #ubuntu
[08:23] <laxmi> ok
[10:45] <c2tarun> !log
[10:45] <ClassBot> Logs for all classroom sessions that take place in #ubuntu-classroom can be found on http://irclogs.ubuntu.com/
[10:45] <ubot2> Official channel logs can be found at http://irclogs.ubuntu.com/ . LoCo channels are now logged there too; for older LoCo channel logs, see http://logs.ubuntu-eu.org/freenode/
[10:51] <deepraj> hello !!
[11:19] <ana_s> hi all
[11:19] <coz_> hey guy
[11:21] <ana_s> the schedule link seems to be down
[11:40] <maxpish> hi, i'm new in this classroom, i'd like to know how i can join ubuntu developers community...
[11:41] <maxpish> could someone help me??
[13:22] <c2tarun> !log
[13:22] <ClassBot> Logs for all classroom sessions that take place in #ubuntu-classroom can be found on http://irclogs.ubuntu.com/
[13:22] <ubot2> Official channel logs can be found at http://irclogs.ubuntu.com/ . LoCo channels are now logged there too; for older LoCo channel logs, see http://logs.ubuntu-eu.org/freenode/
[14:18] <view666> hello,boys and grils
[14:53] <anirudh24seven> can i know when the sessions start ? in how many hours ? 3 ?
[14:55] <Mkaysi> anirudh24seven: http://is.gd/8rtIi
[14:55] <Mkaysi> (Link from topic)
[14:56] <duanedesign> 16:00utc
[15:02] <anirudh24seven> thanks
[15:02] <anirudh24seven> sorry for not having looked through earlier
[15:02] <anirudh24seven> was checking it out before looking at your link... thanks anyway
[15:08] <Vishal_> wen the class is gonna start??
[15:08] <serfus> Vishal_, http://people.ubuntu.com/~nhandler/classroom.html
[15:09] <lmontrieux> Vishal_: in about 1 hour
[15:09] <Vishal_> thnx
[15:12] <hellyeah_> what would be the topic of discussion in class?
[15:20] <Nijabo> hellyeah_, 16.00 - How to write a compiz plugin
[15:41]  * fisch246 puts on atom heart mother album to bring him into the mood of Learning Ubuntu :D
[15:44] <misterxyz> msg NickServ identify atzenmusik
[15:46] <Mkaysi> misterxyz: If that is your password, you should change it immidiatly.
[15:47] <roelandt> Or maybe it's too late.
[15:51] <kaydsoft> hi
[15:57] <smspillaz> dholbach: are we good to start ?
[15:57] <dholbach> we are
[15:57] <smspillaz> awesome
[15:57] <dholbach> let me do a quick introduction :)
[15:57] <smspillaz> sure thing!
[15:57] <dholbach> HELLO MY FRIENDS! ARE YOU READY FOR DAY 2?
[15:57] <techbreak_> smspillaz, :) so we are begining right ?
[15:57] <smspillaz> (woohoo!)
[15:57] <techbreak_> dholbach, smspillaz yeah :)
[15:57] <dholbach> please join #ubuntu-classroom-chat if you haven't done that yet
[15:58] <dholbach> it's the place where all the questions and chat goes
[15:58] <dholbach> and if you do have questions, please ask
[15:58] <dholbach> but please prefix them with QUESTION:
[15:58] <dholbach> ie: QUESTION: smspillaz: Do you have pets?
[15:58] <smspillaz> I have one cat ;-)
[15:58] <dholbach> all the information you need should be available at https://wiki.ubuntu.com/UbuntuDeveloperWeek
[15:58] <smspillaz> he is very awesome :)
[15:58] <dholbach> have a great day 2
[15:58] <dholbach> it's great to have you!
[15:58] <dholbach> now let's kick off the day
[15:59] <chandan_kumar> smspillaz, yaa we aready.
[15:59] <smspillaz> dholbach: let me know when I'm good to start :)
[15:59] <dholbach> smspillaz, also known as Sam Spilsbury graciously agreed to give a session, and he'll talk to you about bringing more bling to compiz by writing spiffy plugins
[15:59] <dholbach> smspillaz, the stage is yours!
[15:59] <smspillaz> horray!
[16:00] <smspillaz> ok, awesome, so yes, here I am, I am the maintainer of the Compiz 0.9 series, i.e the version of compiz that will be used in Ubuntu 11.04 and Unity as well as most upcoming distros
[16:00] <smspillaz> first things' first, because I overprepare for everything, I made some documents that you all might find useful (and me too!) when following me
[16:00] <smspillaz> so the first one is the internal architecture of compiz
[16:00] <smspillaz> which can be found here:
[16:00] <smspillaz> http://smspillaz.ucc.asn.au/unity/compiz_arch/compiz_arch.pdf
[16:01] <smspillaz> and the second is a 7 page guide on writing compiz plugins, which is half-finished, since I've been quite busy this week
[16:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/03/01/%23ubuntu-classroom.html following the conclusion of the session.
[16:01] <smspillaz> http://smspillaz.ucc.asn.au/unity/compiz_arch/writing.odt
[16:01] <smspillaz> so feel free to grab those :)
[16:01] <smspillaz> alrighty, so starting from the beginning
[16:02] <smspillaz> first of all, a quick introduction to how compiz works, and what exactly its function is
[16:02] <smspillaz> and then how to get and compile a development version of compiz, or just develop for it on ubuntu
[16:02] <smspillaz> and then I'll do a quick walkthrough of the basic structure of a plugin and some commonly done things in plugins
[16:03] <smspillaz> ok, so as for how compiz works, and what exactly it does
[16:04] <smspillaz> to take a page from the compiz wiki, compiz is basically what we call a "Compositing Window Manager" in X land, which means that as well as managing windows on screen, it also is in charge of drawing those windows. This technology came about in around 2005ish when XComposite came about
[16:04] <smspillaz> so this means that in terms of your scope of compiz plugins, you can affect how windows are actually managed, affect how they are drawn, and affect how the entire scene is drawn
[16:05] <smspillaz> along with its plugin interface, this makes it pretty much possible to do any bling that you want
[16:05] <smspillaz> so, now moving on to exactly how to set up a development environment
[16:05] <smspillaz> luckly, ubuntu makes this pretty easy
[16:06] <smspillaz> just sudo apt-get install compiz-dev and compiz-plugins-main-dev and you're done
[16:06] <smspillaz> (On maverick, it is compiz-fusion-plugins-main)
[16:06] <smspillaz> but, if you want to do development in a little more, I usually suggest having a local build of compiz handy.
[16:07] <smspillaz> Luckily, most of that is relatively straightforward these days, since there are scripts to do that
[16:07] <smspillaz> http://git.compiz.org/~soreau/scripts/ <- like these fantastic ones
[16:08] <smspillaz> just clone the git repo there and with the script you'll have a full working installation from source.
[16:08] <smspillaz> This helps if, for example, some plugin does something similar to what you want to do, and you can start hacking on that plugin first.
[16:08] <smspillaz> so, a quick question I've recieved
[16:09] <smspillaz> QUESTION: What about Ubuntu 11.04
[16:09] <smspillaz> so, this tutorial here, as I probably should have explained will be for Ubuntu 11.04
[16:09] <smspillaz> since compiz was re-written in between the 0.8 and 0.9 series (maverick and natty)
[16:09] <smspillaz> however, those git scripts about should also work on maverick
[16:10] <smspillaz> Now on to the nitty gritty of writing your first plugin
[16:10] <smspillaz> Compiz plugins are written in C++. We don't really use very many advanced features of the languages or external libraries that heavily, so if you have a basic knowledge of that, then you should be good
[16:11] <smspillaz> we only use boost to a small extent, glib more recently and sigc
[16:11] <smspillaz> CMake is also used for building rather than automake
[16:11] <smspillaz> to answer another quick question
[16:11] <smspillaz> QUESTION:Is it possible to do some type of local build using  the ubuntu packaging and pbuilder or something like that so  that you can remove it easily?
[16:12] <smspillaz> So, the answer to this is is that you can indeed clone lp:compiz , however, this is the packaging branch of compiz core, and doesn't get all the modules
[16:12] <smspillaz> in addition, I'm not sure about how to make it build and install locally
[16:12] <smspillaz> (plus, adding extra stuff to it is a pain since you need to rebuild the whole thing all the time using bzr bd)
[16:12] <smspillaz> so I'd suggest you stick to the scripts or to the master source
[16:13] <smspillaz> (A link to the build tutorial is in the documents I linked to earlier)
[16:13] <smspillaz> so now back to writing plugins
[16:13] <smspillaz> so the basic knowledge, you will need once again, is C++, boost or CMake
[16:14] <smspillaz> note that OpenGL isn't really a strict requirement, since a lot of the graphics functions that are commonly used are abstracted through the API of compiz
[16:14] <smspillaz> it's just that if you want to go down the road of bling-bling, then OpenGL is nice
[16:14] <smspillaz> ok, so now for creating your plugin project
[16:14] <smspillaz> so to start off with, say you want to create a plugin called "moveleft" which, every time a window is opened, if moves every other window to the left
[16:15] <smspillaz> so, your directory structure would be
[16:15] <smspillaz> moveleft
[16:15] <smspillaz> -
[16:15] <smspillaz> -> src
[16:15] <smspillaz> ---> moveleft.cpp
[16:15] <smspillaz> ---> moveleft.h
[16:15] <smspillaz> -> moveleft.xml.in
[16:15] <smspillaz> -> CMakeLists.txt
[16:16] <smspillaz> now to explain each component of that
[16:16] <smspillaz> basically, the .cpp and .h files are the implementation of your plugin, eg the loadable object code
[16:16] <smspillaz> the .xml.in describes information about your plugin for CCSM and also its options
[16:16] <smspillaz> and the CMakeLists.txt is the buildsystem
[16:16] <smspillaz> now, lucky for plugin authors, the buildsystem for compiz plugins is insanely easy
[16:17] <smspillaz> all you need is three lines
[16:17] <smspillaz> find_package (Compiz REQUIRED)
[16:17] <smspillaz> include (CompizPlugin)
[16:17] <smspillaz> compiz_plugin (moveleft PLUGINDEPS foo bar PKGDEPS baz)
[16:17] <smspillaz> so now on to what each line dos
[16:17] <smspillaz> *does
[16:18] <smspillaz> the first basically finds compiz with pkgconfig
[16:18] <smspillaz> the second imports all the plugin buildsystem
[16:18] <smspillaz> the third sets up a new "compiz plugin" project in CMake with the name "moveleft" depending on other plugins "foo" and "bar" and depending on external packages "baz"
[16:18] <smspillaz> so to disect that further
[16:19] <smspillaz> now that you've called your plugin "moveleft" you must stick with that shortname everywhere
[16:19] <smspillaz> so for example, the .xml.in must be named "moveleft"
[16:19] <smspillaz>  However in the src/ tree, you don't need to worry about that
[16:19] <smspillaz> another interesting thing is that you can depend on other plugins
[16:20] <smspillaz> compiz 0.9 was designed in mind with inter-plugin dependency with each plugin providing objects to other plugins
[16:20] <smspillaz> so, a common example of this is the fact htat the opengl and composite bits of compiz are in fact plugins themselves
[16:20] <smspillaz> so most plugins that need to access this functionality will set those as their PLUGINDEPS
[16:21] <smspillaz> now on to the metadata file
[16:21] <smspillaz> I've explained this in more detail in the documents I linked to earlier
[16:21] <smspillaz> but basically, here you need to define your plugin name too
[16:21] <smspillaz> so <compiz>
[16:21] <smspillaz>  <plugin name="myplugin" useBcop="true">
[16:22] <smspillaz> the useBcop is crucial if you want your life to be easier with autogenerated options code
[16:22] <smspillaz> you can also define some options there
[16:22] <smspillaz> but we will get back to that later
[16:22] <smspillaz> so close all the tags and save it
[16:22] <smspillaz> next, you need to define the classes of your plugin
[16:23] <smspillaz> so the way things work in compiz is that each plugin is responsible for one or both of two things
[16:23] <smspillaz> 1) attaching their own information and hooks to existing objects
[16:23] <smspillaz> 2) creating their own objects
[16:23] <smspillaz> the vast majority of plugins only do 1)
[16:23] <smspillaz> and they usually hook two very important existing object
[16:23] <smspillaz> CompWindow and CompScreen
[16:24] <smspillaz> so, starting with the second
[16:24] <smspillaz> compiz runs per X-screen
[16:24] <smspillaz> so, this means that CompScreen is kind of like the "master class" where everything relating to everything going on on screen happens
[16:24] <smspillaz> CompWindow is a representation of some managed X11 window
[16:25] <smspillaz> (and believe me, there are a lot of them, see xwininfo -root -tree for how much there is to manage)
[16:25] <smspillaz> now each plugin works by attaching their own structures to those core objects
[16:25] <smspillaz> so if you defined a MoveLeftScreen as attaching to CompScreen
[16:25] <smspillaz> there would be one MoveLeftScreen per CompScreen
[16:26] <smspillaz> same thing with MoveLeftWindow
[16:26] <smspillaz> this allows you to store data and functions on those core structures
[16:26] <smspillaz> so, for moveleft, you might want to track if you've moved a window already, and if it has moved since you've moved it
[16:26] <smspillaz> so you would store that information in MoveLeftWindow
[16:27] <smspillaz> the actual attaching
[16:27] <smspillaz> ok
[16:27] <smspillaz> so the actual attaching is done by a special class called PluginClassHandler
[16:27] <smspillaz> it's basically a template class that sets up some special indexes in the base object and attaches your class to it
[16:28] <smspillaz> so that, whenever you want to get your own data for the base object, you just call MoveLeftWindow::get (CompWindow *)
[16:28] <smspillaz> so in constructing your MoveLeftWindow, you'll get something like:
[16:28] <smspillaz> class MoveLeftWindow :
[16:28] <smspillaz>     public PluginClassHandler <MoveLeftWindow, CompWindow>,
[16:28] <smspillaz>     public WindowInterface
[16:28] <smspillaz> {
[16:28] <smspillaz> }
[16:28] <smspillaz> etc
[16:28] <smspillaz> (See the handout)
[16:29] <smspillaz> the WindowInterface is for interfacable functions and will be explained in a bi
[16:29] <smspillaz> so now that you've got your MoveLeftScreen and MoveLeftWindow defined as classes attaching to the relevant core structures
[16:29] <smspillaz> there are a few final things to do
[16:29] <smspillaz> the first is to define a VTable for your plugin
[16:30] <smspillaz> this tells core how to load and what "attaching classes" to initialize when objects are created
[16:30] <smspillaz> we have templates for the most common usecases
[16:30] <smspillaz> so, you'd have
[16:30] <smspillaz> class MoveLeftPluginVTable :
[16:30] <smspillaz>     public CompPlugin::VTableForScreenAndWindow <MoveLeftScreen, MoveLeftWindow>
[16:31] <smspillaz> {
[16:31] <smspillaz>     public
[16:31] <smspillaz>         bool init ();
[16:31] <smspillaz> }
[16:31] <smspillaz> the only thing yout need to put in your init function for now is a core ABI version check
[16:31] <smspillaz> eg
[16:31] <smspillaz> if (CompPlugin::checkPluginABI ("core", CORE_ABIVERSION)) return true; else return false;
[16:32] <smspillaz> and finally, a extern C object definition for core to look up the VTable on plugin load
[16:32] <smspillaz> and like all good things, we have a macro for that
[16:33] <smspillaz> COMPIZ_PLUGIN_20090315 (MoveLeftPluginVTable, moveleft);
[16:33] <smspillaz> note the use of "moveleft" again
[16:33] <smspillaz> that is *crucial*
[16:33] <smspillaz> since the library is going to be named "moveleft" and core will be loading a plugin called "moveleft"
[16:33] <smspillaz> so its going to be looking for the right symbol
[16:33] <smspillaz> As a quick aside, I've been asked to explain what CCSM is
[16:34] <smspillaz> in fact, I should probably explain some of the other compiz modules
[16:34] <smspillaz> so "compizconfig" == our library to handle configuration and desktop integration amongst different settings backends (eg ini, dconf, gconf, kconfig4)
[16:35] <smspillaz> "ccsm" == "compizconfig-settings-manager" which is a tool to adjust all the settings in compiz (seriously, there are tons)
[16:35] <smspillaz> "core" == the core executable of compiz, where the base window management logic and API comes from
[16:35] <smspillaz> ok, so back to plugins
[16:36] <smspillaz> once you have checked off implementing your MoveLeftScreen, MoveLeftWindow, MoveLeftPluginVTable, COMPIZ_PLUGIN_20090315 etc
[16:36] <smspillaz> and #included <core/core.h>
[16:36] <smspillaz> you now have an installing plugin!
[16:36] <smspillaz> however, it doesn't really do all that much
[16:36] <smspillaz> so lets get on to something more interesting
[16:37] <smspillaz> what about being able to "plug-in" to things that core or other plugins do
[16:37] <smspillaz> ah, QUESTION: how can we make sure there isn't another plugin called "moveleft"
[16:37] <smspillaz> well, the simple answer to that is, you don't
[16:37] <smspillaz> there aren't too many compiz plugins around, but if a plugin with the same name is already loaded then yours fails to load
[16:38] <smspillaz> ok, back to being able to plugin-in to things
[16:38] <smspillaz> so, as I was saying a bit before, we have another special thing in compiz called "wrapable interfaces"
[16:39] <smspillaz> these are basically just call chains of function objects in doubly linked lists
[16:40] <smspillaz> when you thing you are calling some core function that was implemented in an "interfacable way" you are actually just calling a function which increments the linked list counter by 1 and calls the next function in the list
[16:40] <smspillaz> the convention is that at the end of each of the plugin's function calls, they will call the same core function again, which increases the function counter, calls the next function and so forth
[16:41] <smspillaz> this allows us to, on each core function call, call lots of other functions at the same time
[16:41] <smspillaz> So the first thing you would have seen in the MoveLeftWindow definition was that we inherited a class called "WindowInterface"
[16:42] <smspillaz> this is the "Interface class" to all of these Intefacable functions
[16:42] <smspillaz> so if you have a look in core/include/window.h, you will see all the functions that plugins can hook
[16:42] <smspillaz> by inheriting this class you are said to be "implementing" this interface
[16:43] <smspillaz> by default, the functions in WindowInterface all do nothing, but that is because they are all virtual!
[16:43] <smspillaz> so to change that, you overload one of the functions
[16:43] <smspillaz> for example, void moveNotify (int, int, bool); is a function that tells us when a window has moved and by how much
[16:44] <smspillaz> so if we implement a function like that in our MoveLeftWindow class which inherits WindowInterface, we will have implemented that
[16:44] <smspillaz> next, in the MoveLeftwindow constructor, we have a call to WindowInterface::setHandler (window);
[16:45] <smspillaz> what this does, is set the handler of the interface class that we inherited to the base class that owns the function
[16:45] <smspillaz> so that now whenever we call the base class function
[16:45] <smspillaz> our function will be called first
[16:46] <smspillaz> then functions from the previously loaded plugin
[16:46] <smspillaz> etc etc
[16:46] <smspillaz> until you get to the main function in the class
[16:46] <smspillaz> ok, another question!
[16:46] <smspillaz> QUESTION: so, can i write a separate MoveLeft function,  embed in Window.h, and then call n override it whenever n  wherever i want?
[16:47] <smspillaz> So, I'm not too sure what is meant by this, but if you mean adding a new wrapable function to core, I am afraid that is out of the scope of this tutorial
[16:47] <smspillaz> plugins should generally only overload the functions in the interface classes
[16:48] <smspillaz> anyways, interfaces are explained a bit more in the document I posted
[16:48] <smspillaz> next up: options
[16:48] <smspillaz> so say you've interfaced CompWindow::windowNotify from WindowInterface
[16:48] <smspillaz> so now whenever someone else calls window->windowNotify (), MoveLeftWindow::windowNotify is also called
[16:49] <smspillaz> and you've handled the CompWindowNotifyMap there to loop over all windows in screen->windows () (eg, loop over an std::list) and call w->move (x, y, immediate) to move them to the left
[16:50] <smspillaz> but now, you want to play with an option whereby it actually moves windows to the right instead of the left!
[16:50] <smspillaz> so you need to go back into your moveleft.xml.in and add some information about this option
[16:50] <smspillaz> so <option name="right" type="bool">
[16:50] <smspillaz>   <_short>Move right</_short>
[16:50] <smspillaz>   <_long>Do the wrong thing </_long>
[16:51] <ClassBot> There are 10 minutes remaining in the current session.
[16:51] <smspillaz>  <default>false</default>

[16:51] <smspillaz> that defines the option, with the default value of false
[16:51] <smspillaz> now, in your MoveLeftScreen make sure you inherit MoveleftOptions (note the small case l) to get access to autogenerated code from this option
[16:52] <smspillaz> ok, so now here is where it gets funky
[16:52] <smspillaz> that options code is owned by MoveLeftScreen
[16:52] <smspillaz> so you need to MoveLeftScreen *mls = MoveLeftScreen::get (screen) in your ::windowNotify
[16:53] <smspillaz> then, you want to read the option to see what it says
[16:53] <smspillaz> so for "right" that would be
[16:53] <smspillaz> mls->optionGetRight ()
[16:53] <smspillaz> and it returns true or false depending on the option value
[16:53] <smspillaz> now, here is how the generation code works
[16:53] <smspillaz> first you have optionGet, which is prepended to call getters
[16:54] <smspillaz> then you have "Right" right came from "right" in the xml file
[16:54] <smspillaz> so the parser replaces underscores with CamelCase
[16:54] <smspillaz> so if you had right_foo
[16:54] <smspillaz> it would be come
[16:54] <smspillaz> optionGetRightFoo ()
[16:54] <smspillaz> Ok, cool so now you've read the option
[16:54] <smspillaz> so with some simple math
[16:54] <smspillaz> and that skeleton
[16:55] <smspillaz> you should be able to make everything go to the left when a new window is mapped
[16:55] <smspillaz> or at your choosing
[16:55] <smspillaz> go to the right
[16:55] <smspillaz> I'll open the floor to questions
[16:55] <smspillaz> ok
[16:55] <smspillaz> QUESTION: since you mentioned compiz 0.9 written for  Ubuntu, do you use any distro specific API  implementations which may break if I write a plugin for,  say, Arch?
[16:55] <smspillaz> Good question
[16:55] <ClassBot> There are 5 minutes remaining in the current session.
[16:55] <smspillaz> so, compiz 0.9 was written independently, and has only been started to be used for unity until early this year
[16:56] <smspillaz> so it is still an upstream project
[16:56] <smspillaz> and as such I keep the API consistent between all version
[16:56] <smspillaz> there used to be an API inconsistency with the glib mainloop stuff, but that has been upstreamed
[16:56] <smspillaz> any other questions?
[16:57] <smspillaz> (I might just paste again those documents I'm referring to in case you missed them)
[16:57] <smspillaz> http://smspillaz.ucc.asn.au/unity/compiz_arch/compiz_arch.pdf
[16:57] <smspillaz> and
[16:57] <smspillaz> http://smspillaz.ucc.asn.au/unity/compiz_arch/writing.odt
[16:57] <smspillaz> QUESTION: What happened to the compiz mindcontrol?
[16:57] <smspillaz> I love it
[16:58] <smspillaz> that project would be cool, except that the developer with that idea didn't cobble together the funds to buy a headset for that
[16:58] <smspillaz> plus it requires shaving your head
[16:58] <smspillaz> which I would never do since I have awesome hair
[16:58] <smspillaz> any more questions before I wrap it up?
[16:59] <smspillaz> ok, well it is 16:59, I should probably wrap it up
[16:59] <smspillaz> thanks for attending!
[16:59] <smspillaz> now go write some awesome plugins!
[17:00] <jibel> Hi folks,
[17:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/03/01/%23ubuntu-classroom.html following the conclusion of the session.
[17:01] <jibel> Thanks to smspillaz for this awesome introduction to compiz.
[17:01] <jibel> my name is Jean-Baptiste Lallement, I live in France and I'm working on the QA Team.
[17:02] <jibel> I've started my QA activity with lot of bug triaging, then I moved to ISO Testing, Automated Desktop Testing and Stable Release Updates.
[17:02] <jibel> In this session we will talk about Stable Release Updates, and how the QA process contributes to rock solid stable releases.
[17:03] <jibel> Once an Ubuntu release is out, updates for it follow a very specific procedure called a "Stable Release Update" aka "SRU"
[17:03] <jibel> Updates are only released under certain circumstances.
[17:04] <jibel> Why this SRU process ?
[17:05] <jibel> Unlike development releases (at the moment Natty), official releases of Ubuntu are widely deployed and used by a wide variety of users.
[17:05] <jibel> During the development, the population are developers, early adopters or advanced users, they are aware that pre-release software may break and they accept the risk.
[17:06] <jibel> When you are using an official release, you use your system for your day to day work and are expecting a high degree of stability.
[17:06] <jibel> Any problem can be really disruptive and the system should not requires the intervention of the user.
[17:08] <jibel> Stable release updates are automatically recommended to a very large number of users. So it is critically important to be paranoïd and to treat them with extreme cuation.
[17:08] <jibel> Therefore, when updates are proposed, they must be accompanied by a strong rationale and present a low risk of regressions.
[17:09] <jibel> Some will argue "It's just a one line change, go ahead"
[17:09] <jibel> Right, let me give you one example, with bug 559822 and its friend bug 610975
[17:10] <jibel> The cause of the bug wasa C++ library (wxwidgets2.8) was uploaded with no code changes. Due to an underlying toolchain change/bug, this caused an ABI change, causing a lot of unrelated packages to break.
[17:10] <jibel> It was not a one line change, it was a no change at all bug.
[17:11] <jibel> So people, when dealing with SRU, expect the unexpected.
[17:12] <jibel> When should you request a Stable Release Update ?
[17:12] <jibel> Not all bugs are good candidates to Stable release updates,
[17:13] <jibel> and in general only those that fix high impact bugs are
[17:13] <jibel> examples of such bugs include:
[17:14] <jibel> * security vulnerabilities. These are done by the security team and follow a slightly different but somewhat similar process
[17:14] <jibel> * severe regressions from a previous release.
[17:15] <jibel> This includes packages which are unusable, like being uninstallable or crashing on startup.
[17:15] <jibel> * bugs which may cause data loss
[17:15] <jibel> bugs which doesn't fit under the above categories but have an obviously safe patch
[17:16] <jibel> and affect an application rather than critical infrastructure packages (like X or the Kernel)
[17:17] <jibel> * for Long Term Support (LTS) we regularly want to enable new hardware.
[17:17] <jibel> such changes are appropriate provided that we can ensure to not affect upgrades on existing hardware
[17:17] <jibel> And the last type of SRU
[17:18] <jibel> * New version of commercial software in the canonical partner archive
[17:18] <ClassBot> wolfpack asked: Is stable release update has only bug fixes or can it have features upgrade ?
[17:19] <jibel> SRU doesn't introduce new feature, or with rare exceptions.
[17:20] <jibel> For new features, or new upstream versions of packages, but don't fix critical bugs you should request a backport instead.
[17:20] <jibel> New features are usually not good candidates.
[17:22] <jibel> So How to proceed ?
[17:22] <jibel> You've found a good candidate ? There are a few steps that you must follow in order to see your fix land in a Stable Release.
[17:23] <jibel> First of all, the bug must be fixed in the current development release
[17:23] <jibel> and the task in the bug report set to "Fix Released"
[17:24] <jibel> This ensures that the fix won't be missed on newer version of the package and that the bug won't be reintroduced
[17:24] <jibel> If it is not fixed, in the development version, the request for SRU will be rejected.
[17:26] <ClassBot> darkdevil58 asked: if suppose i fix a bug on my 10.04 system, still the fix release be rejected as i m not using 10.10?
[17:28] <jibel> If you want a fix in 10.04 LTS, it must be fixed in the latest development release - Natty - before being ported to 10.04
[17:28] <jibel> We can accept an SRU for 10.04 but which is not necessarily a good candidate for 10.10
[17:29] <jibel> When filing an SRU add all necessary the information to the bug description to help with the review of the report. Ideally, make sure it contains:
[17:29] <jibel> * The rationale for the SRU. the impact of the bug on users, and a justification for backporting the fix to the stable release
[17:30] <jibel> * Explain how the bug has been addressed in the dev branch, and attach a minimal patch against the current stable version of the package.
[17:30] <jibel> At this point, if you think that preparing the patch will be time consuming,
[17:30] <jibel> you should get approval from the SRU Team first.
[17:31] <jibel> On the other hand its useless to spend time on a patch that is not critical enough to match SRU criteria.
[17:31] <jibel> So, in doubt, don't hesitate to ping the SRU team
[17:32] <jibel> An important part, document the test case with detailed instructions how to reproduce the bug.
[17:33] <jibel> Document the test case with detailed instruction how to reproduce the bug
[17:33] <jibel> for example https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/639701
[17:33] <jibel> includes 3 easy steps to reproduce the issue, and verify the fix.
[17:34] <jibel> The steps should allow anyone, not familiar with the package to reproduce the bug and verify that the issue is fixed with the updated package.
[17:34] <jibel> * Add information about potential regressions and inadvertent side effects.
[17:35] <jibel> For example in https://bugs.launchpad.net/ubuntu/+source/txaws/+bug/634022 , the dev explains why there's very little risk of regression
[17:35] <jibel> Once you've provided all the required documentation
[17:35] <jibel> * Target to the appropriate serie and subscribe ubuntu-sru
[17:36] <jibel> * Upload the fixed package. If you can not do it yourself, attach a debdiff and subscribe ubuntu-sponsor.
[17:36] <jibel> * If everything goes right, the archive admins will approve and publish you fixed package to the -proposed repository.
[17:36] <jibel> And please, keep this rule in mind: One bug = One report
[17:36] <jibel> Then we enter in the second phase of the Stable Release Update: SRU Verification
[17:36] <jibel> The current set of pending SRUs is tracked at http://people.ubuntu.com/~ubuntu-archive/pending-sru.html
[17:37] <jibel> On this page, you'll find a list of packages currently in -proposed
[17:37] <jibel> and available for testing.
[17:38] <jibel> For each package, there's an indication of which version is in which pocket (-security, -updates, -proposed) and a list of bugs fixed by the upload
[17:38] <jibel> The process we follow to verify a package is roughly:
[17:38] <jibel> - setup a testing environment
[17:39] <jibel> - Try to reproduce the issue in the most recent published version of the software
[17:39] <jibel> - Enable the -proposed repository and install the proposed update for that software
[17:39] <jibel> - Try to reproduce the issue with the updated software
[17:40] <jibel> The first step is to create a clean testing environment of the release the fix is targeted for.
[17:40] <jibel> We want to eliminate any outside effects and control the changes brought by the update of the package.
[17:41] <jibel> To create this environment any virtualization solution is good: KVM, VirtualBox, VMWare, ... are very useful to create an isolated testing environment
[17:41] <jibel> You can use snamshot to quickly setup a fresh env or rollback to a previous state.
[17:42] <jibel> Doing testing in a chroot is also good enough.
[17:42] <jibel> If you are trying to reproduce hardware related issues, then, of course, VM technologies are not the right choice.
[17:42] <jibel> Hardware specific bugs offer their own special problems; if we don't have the hardware, it's much harder to reproduce
[17:42] <jibel> There's not much we can do except prompt on the bug report for people affected by the bug to do the testing and install the package ourselves to look for regressions.
[17:43] <jibel> These are often kernel, X, libc (where the compiler is bounded to CPU capabilities) problems
[17:43] <jibel> Then we want to make sure that all updates are applied to the testing environment and we can start the testing and try to reproduce the bug
[17:43] <jibel> We want to do this so that we know what we're testing for when we install the proposed package.
[17:44] <jibel> Often, just doing this will offer us more insights into the actual problem being solved and sometimes discover a regression or another bug.
[17:44] <jibel> If we can't reproduce the initial problem, we have much less confidence that the update actually is going to fix the issue.
[17:45] <jibel> In this situation, whether the Test Case is wrong or incomplete, or the condition to reproduce the bug are not well defined, so we can have a doubt that the fix will really fix the bug in every conditions.
[17:47] <jibel> l'll illustrate the verification phase with bug https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/494096
[17:47] <jibel> This is a critical usability defect. Clicking on a window send the events to the underneath window.
[17:47] <jibel> wrt to this bug a patch has been attached in comment #23 and the bug has been nominated for SRU between comments 25 and 26.
[17:48] <jibel> The description is fairly complete, the issue is easy to understand and it includes a test case.
[17:48] <jibel> That's not always the case, so sometimes you get to figure out how to test for the condition, or if that's really unclear what the bug is and how to reproduce, you can simply set the status back to 'in progress' asking for more info from the reporter or the dev.
[17:48] <jibel> The first task is to reproduce the issue.
[17:49] <jibel> Just follow the steps described in the bug report. Once this is done you can enable -proposed
[17:49] <jibel> You can do this through the menus, via System -> Admin -> Software Sources menu
[17:49] <jibel> The details to enable -proposed are at https://wiki.ubuntu.com/Testing/EnableProposed
[17:50] <jibel> As part of reproducing, make sure to double-check exactly which version you are testing
[17:50] <jibel> From the command line, apt-cache policy is your friend, and in this case
[17:50] <jibel> $ apt-cache policy metacity
[17:50] <jibel> metacity:
[17:50] <jibel>   Installed: 1:2.30.1-0ubuntu1
[17:50] <jibel>   Candidate: 1:2.30.1-0ubuntu1.1
[17:51] <jibel>   Version table:
[17:51] <jibel>      1:2.30.1-0ubuntu1.1 0
[17:51] <ClassBot> There are 10 minutes remaining in the current session.
[17:51] <jibel>         500 http://archive.ubuntu.com/ubuntu/ lucid-proposed/main Packages
[17:51] <jibel>  *** 1:2.30.1-0ubuntu1 0
[17:51] <jibel>         500 http://fr.archive.ubuntu.com/ubuntu/ lucid/main Packages
[17:51] <jibel>         100 /var/lib/dpkg/status
[17:51] <jibel> We see that 1:2.30.1-0ubuntu1 is installed and the candidate 1:2.30.1-0ubuntu1.1 from -proposed is available for update.
[17:51] <jibel> You can install it either with update-manager or from the command line:
[17:51] <jibel> $ apt-get install metacity
[17:52] <jibel> Only update this package and its dependencies, but not all the packages from -proposed as they may introduce some other issues.
[17:52] <jibel> Once it is installed logout/login and try to reproduce the bug again.
[17:53] <jibel> If the result is what you expect from the test case, we can start looking for regressions as well.
[17:53] <jibel> Some things to look for in term of regressions:
[17:53] <jibel> * install requirements; does it depend on other packages in proposed, particularly ones not from the same source package?
[17:54] <jibel> if it does, and both packages aren't moved into updates at the same time, the package will be uninstallable.
[17:54] <jibel> * possible differences in behavior for fresh install versus update from buggy version
[17:54] <jibel> sometimes the fixes only show up for new installations, particularly for packaging problems
[17:54] <jibel> just generally play with the app; helps here if you're familiar with it.
[17:54] <jibel> For metacity, that's pretty straightforward, we'll go ahead use our desktop, and see if things still work properly
[17:54] <jibel> If everything passes then tag the report with verification-done
[17:54] <jibel> Quicky another example where things didn't went so well, which affects ssh
[17:55] <jibel> https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/713002
[17:55] <jibel> ssh is a key component of  the system and it is critical to not break it.
[17:55] <jibel> The bug is that you cannot disable access from IPv4 hosts to IPv6 only hosts. This makes life of sysadmins harder to keep sane access control where IPv6 is the primary protocol.
[17:55] <ClassBot> There are 5 minutes remaining in the current session.
[17:56] <jibel> You can see that the bug description has been rewritten by the developer to improce the documentation. He was kind enough to keep the history of the original report for reference.
[17:56] <jibel> He also added a test case, every commenters and tester on the report agreed to say that the bug was fixed.
[17:56] <jibel> But...
[17:56] <jibel> A security guy comes in and said "STOP! this fix doesn't includes the fixes from previous version"
[17:56] <jibel> This is what is called a regression. The report has been tagged as verification-failed and the package will be removed from proposed.
[17:56] <ClassBot> akshatj asked: What if a bugfix fixes a security issue but introduces another type of bug that is not security related like a usablity bug(not sure if this is possible)
[17:57] <jibel> If a fix introduces a regression it is rejected.
[17:58] <jibel> I don't have bug in mind to illustrate your question though.
[17:58] <jibel> Finally both failures and successes are important to report!
[17:58] <jibel> also report anything out of the ordinary or unexpected you had to do in testing
[17:59] <jibel> it's also helpful to update the description of the bug if elements are missing (eg. you created a TESTCASE)
[17:59] <jibel> We could use help in doing verifications and looking for regressions
[17:59] <jibel> There's an SRU verification team on launchpad at https://launchpad.net/~sru-verification which tracks the SRUs,
[17:59] <jibel> And if, when doing all this, you run into problems, you can always solicit for help on #ubuntu-bugs and #ubuntu-testing, as well as asking directly on the bug report.
[17:59] <jibel> Anyone can contribute by doing SRU verification.
[18:00] <jibel> any question ?
[18:00] <jibel> aquarius, the floor is yours
[18:00] <aquarius> jibel, thanks, and thanks for a great talk! I now know loads more about SRUs :-)
[18:01] <aquarius> Hi, all!
[18:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/03/01/%23ubuntu-classroom.html following the conclusion of the session.
[18:01] <aquarius> I'm Stuart Langridge, from the Ubuntu One team, and I'm here to talk about our upcoming app developer programme.
[18:01] <aquarius> Do please ask questions throughout the talk: in the #ubuntu-classroom-chat channel, write QUESTION: here is my question
[18:02] <aquarius> Up until now, your ability as developers to do cool things with Ubuntu One has been limited.
[18:02] <aquarius> But I'm going to change all that.
[18:02] <aquarius> We want to make it possible, and easy, for you to add the cloud to your apps and to make new apps for the cloud
[18:02] <aquarius> So we do all the heavy lifting, and your users (and you!) get the benefits.
[18:03] <aquarius> Imagine, for example, you've made a recipe manager application.
[18:03] <aquarius> So you can type in all the recipes you like to cook, and you've got a permanent record of them.
[18:04] <aquarius> (For me, that would be: get a pizza base; put pepperoni on it. You'll be better at that than me.)
[18:04] <aquarius> Don't really want to take your laptop into the kitchen, though, of course.
[18:04] <aquarius> So, build a mobile app which you sign into with Ubuntu One, and have that show all your recipes too.
[18:04] <aquarius> And a web app which you sign into with Ubuntu One, so that you can look up recipes while you're at a friend's house.
[18:05] <aquarius> This is the sort of thing that we want to make easy; giving your users and you quick access to the Ubuntu One technology.
[18:05] <aquarius> Mobile access to your data; web app access to your data; saving files direct into Ubuntu One; publishing files and photos from all your apps; adding playlists to the Ubuntu One music streaming app; streaming the user's own music into a game you've written.
[18:06] <aquarius> This stuff is all being heavily worked on right now as we speak.
[18:06] <aquarius> So this talk won't be too detailed with specifics, because they might change.
[18:06] <aquarius> I want to give you a flavour of what will soon be possible, and answer questions, and give some pointers, and get your thoughts.
[18:06] <aquarius> Also, this is Developer Week, so I can talk about what the components we're working on are and then admire all the cool ways you all come up with for snapping them together, rather than waiting for marketing to come up with a "product" for you to use :)
[18:07] <aquarius> So, some components that can be snapped together.
[18:08] <aquarius> You'll be able to sign in to a web application with Ubuntu One.
[18:08] <aquarius> This means that you don't have to manage your own identity system, think about password renewal, all that.
[18:09] <aquarius> This is just like "sign in with Facebook" or "sign in with Twitter"; it's OpenID-based, and lets your users sign in to a web app and you'll know their Ubuntu identity.
[18:10] <aquarius> And that identity is shared everywhere; you can build web apps and mobile apps and Windows apps and Ubuntu apps which all share the same identity and know who they're talking to.
[18:11] <aquarius> Once you've signed in to an app with Ubuntu One, that app can ask for permission to work with your data.
[18:11] <aquarius> This lets you, developers, build applications that work on the desktop, on the web, on mobile phones.
[18:12] <aquarius> The recipe manager example I mentioned above is one sort of thing you could do, there
[18:12] <aquarius> Your users use the nice recipe manager app on Ubuntu, which you've build with Quickly or whatever you prefer
[18:12] <aquarius> And then they can go to yourrecipemanager.com and sign in with Ubuntu One
[18:13] <aquarius> yourrecipemanager.com then asks them for permission to access their "recipes" database
[18:13] <aquarius> and can then show them all their recipes on the web!
[18:14] <aquarius> Your app (yourrecipemanager.com) does this via OAuth; it goes through the standard OAuth dance to get an OAuth token which can be used to access the user's recipes CouchDB database
[18:14] <aquarius> And your users can be happy that it's secure, because yourrecipemanager.com will only have access to their recipes database; it can't read their contacts, or their files, or their credit card info.
[18:15] <ClassBot> fisch246 asked: about when can this kind of stuff be implemented? 11.04? 11.10? 12.04?
[18:16] <aquarius> fisch246, everything I'm talking about today should be available for the 11.04 release.
[18:16] <ClassBot> th3pr0ph3t asked: Isn't it too early to start building apps for ubuntu one? -- I mean that thing can hardly sync files
[18:17] <aquarius> th3pr0ph3t, the 11.04 release will bring some massive improvements to all the Ubuntu One services -- data, music, files
[18:18] <aquarius> the stuff I've talked about so far is around data, and I'll get on to files in a bit :)
[18:18] <aquarius> But you can imagine sharing other sorts of data between applications.
[18:18] <aquarius> Imagine, for example, an achievements system.
[18:19] <aquarius> You write a few games; some on the web, some on mobile phones, some on the Ubuntu desktop, some on Windows.
[18:19] <aquarius> And every time the user achieves something in a game, you save that achievement to that user's "achievements" database.
[18:19] <aquarius> On Ubuntu, you'd save it into desktopcouch, and Ubuntu One will take care of synchronising that into the cloud.
[18:20] <aquarius> On Android, your game would include the DroidCouch library which gives you simple access to save data directly into the user's personal cloud databases.
[18:20] <aquarius> On the web, your game's backend could use the u1couch Python library to do the same thing, save directly into the cloud, or you could just use the underlying REST API (which is just standard CouchDB with OAuth signing; u1couch is just a wrapper)
[18:21] <aquarius> Or you could write your own wrapper library for PHP or Rails or Flash or whatever you prefer (and then tell me about it so I can point to the documentation for it!)
[18:21] <aquarius> At that point, all your games save achievements to the same place, so all your games can show you the achievements you've won in any game
[18:22] <aquarius> And, as before, you can set up yourachievements.com where a user can log in and see all their achievements.
[18:22] <ClassBot> dael99 asked: everything will be web-based? Will some kid of API be available to use trough Python, Java or C directly?
[18:23] <aquarius> dael99, certainly not everything is web-based. Ubuntu One is about you working with your stuff on your own terms
[18:23] <aquarius> So part of that is that your data is everywhere, if you want it to be.
[18:23] <aquarius> You can work with the copy that's in the cloud, or with the local copy of it, whether that's data, files, music, whatever.
[18:24] <aquarius> For working with data in the cloud, there'll be web-based APIs, and then wrappers for those APIs for various languages.
[18:24] <aquarius> So you'll be able to, for example, just import a Python library and write code Pythonically with that API, and hardly even have to care that that API goes off to the cloud to do its work. As far as you're concerned, it's just Python.
[18:25] <ClassBot> chadadavis asked: How does local caching of settings and data work? Can there be a bidirectional pipe between gconf (or dconf, or whatever) and ubuntuone?
[18:25] <aquarius> chadadavis, yes, there could be; it would be possible to write a desktopcouch backend for {g,d}conf.
[18:26] <aquarius> There are a couple of interesting problems to solve, there; most applications don't distinguish between "stuff I care about which is specific to this machine" and "stuff I care about generally".
[18:26] <aquarius> Imagine, for example, that an app stores its window position in dconf
[18:26] <aquarius> syncing that to your netbook might be a problem.
[18:26] <aquarius> So there are some fun issues around that, but it would certainly be possible to do if you wanted to.
[18:27] <ClassBot> darkdevil_ asked: will there be any feature with which I will be able to sync my Ubuntu One cloud with any existing non Ubuntu One clouds?
[18:27] <aquarius> darkdevil_, that depends on precisely what you mean.
[18:28] <aquarius> Your data is stored in CouchDB. So you can replicate data from Ubuntu One to any other CouchDB anywhere, and the reverse.
[18:28] <aquarius> Your files are also accessible via the API, so you can pull files out of Ubuntu One directly and push them into another cloud provider if you want to, and the reverse.
[18:28] <aquarius> These are the components that you'll be able to snap together.
[18:29] <ClassBot> davidboy asked: There's going to be PHP bindings right?  So I can write web apps that take advantage of U1, etc.
[18:29] <aquarius> Certainly it will be entirely possible to write PHP bindings; the APIs that your web apps will talk to are just HTTP, so anything that can do HTTP requests (which PHP happily can) will be able to use them.
[18:30] <aquarius> So you will be able to use PHP to talk to Ubuntu One out of the box.
[18:30] <aquarius> It might be cool for someone to write a wrapper library to make that sort of thing even easier for PHP developers
[18:31] <aquarius> I don't think we'd do that on the Ubuntu One team ourselves, because (a) we're not PHP developers, and (b) it's best for us to concentrate on making the APIs great. But one of the things I'd love to do is point at those wrapper libraries from the main API documentation
[18:31] <aquarius> There's loads of stuff you can do with shared data.
[18:31] <aquarius> But Ubuntu One's not just about data.
[18:32] <aquarius> Take the music streaming service, for example.
[18:32] <aquarius> You can currently stream music to Android and iPhone, and you'll be able to add that music to the cloud from Ubuntu and Windows.
[18:32] <aquarius> Maybe you want to be able to stream music back to your Ubuntu machine without syncing it, or your Mac, or your Palm Pre, or your LG mobile phone, or your toaster.
[18:33] <aquarius> So, just use the music streaming API, which is a simple REST HTTP API, based on the Subsonic API, or help people to get at their music by showing them our HTML5 web player for streaming music.
[18:33] <aquarius> But there's more interesting ideas around music streaming than just "listen to the music".
[18:33] <aquarius> Playlists, for example. The Ubuntu One Streaming apps on Android and iPhone know how to create playlists.
[18:34] <aquarius> But how they do that is not a secret. Your playlists are just stored in your cloud databases.
[18:34] <aquarius> (well, they will be once this stuff exists. See above point about how all this is being written. :))
[18:35] <aquarius> So, why not sync your playlists from Banshee or Rhythmbox or Amarok or Exaile or Quod Libet or iTunes or Windows Media Player?
[18:35] <aquarius> Copy the playlists from your media player into desktopcouch on Ubuntu or into the cloud directly with u1couch on Windows or the Mac or anywhere else, in the correct format, and those playlists will instantly show up on your phone!
[18:35] <aquarius> A simple example of this is https://code.launchpad.net/~sil/%2Bjunk/m3u2u1ms/ which is a quick script I wrote to take an m3u playlist and store it in desktopcouch on Ubuntu.
[18:35] <aquarius> So you can make your Banshee playlists available to the Ubuntu One app on your Android phone by exporting them as m3u and then importing them with the script.
[18:36] <aquarius> Tighter integration is great, here; what we want to do is to make it easy for you all to build the stuff that you want on top of Ubuntu One.
[18:36] <aquarius> So if you want to have your Amarok playlists available for streaming, it should be possible to do.
[18:36] <aquarius> I rather like the idea of playing a Flash game on the web and having the background music be the most appropriate music chosen from *my* music collection. That'd be cool.
[18:37] <ClassBot> jderose asked: Will U1 ever offer continuous CouchDB replication? Like say *someone* was developing a distributed video editor with real-time collaboration :)
[18:37] <aquarius> jderose, cor, just imagine if someone was doing that, eh? (you should all watch jderose's lightning talk at the end of the week ;))
[18:38] <aquarius> Continuous replication: not planned right now. (There are some big issues with turning it on for lots and lots and lots and lots and lots of databases, which is what we have.)
[18:38] <aquarius> It's something I want to continue to investigate, though.
[18:39] <aquarius> Ubuntu One also, as you know, does file sync.
[18:39] <aquarius> But just syncing files is already taken care of by Ubuntu One itself, on Ubuntu and Windows.
[18:39] <aquarius> What's more interesting is working with those files.
[18:39] <aquarius> So, for example, imagine being able to instantly, one-click-ly, publish a file from your application to a public URL and then tweet that URL.
[18:40] <aquarius> Instant get-this-out-there-ness from your apps.
[18:40] <aquarius> The screenshot tool Shutter, for example, can do this already; PrtSc to take a screenshot, then "Export > Ubuntu One".
[18:41] <aquarius> They did a bunch of hard work to do that, and I massively applaud them; nice one Shutter team!
[18:41] <aquarius> Based on what they did, that's the sort of thing that should be easier to do.
[18:41] <aquarius> So there will be easy-to-use APIs so your apps can do the same. Imagine quickly sharing your newly created image or document or recipe with the world.
[18:41] <aquarius> Your app could have a button to "store all my files in the cloud", or "publish all my files when I save them", or "automatically share files that are part of Project X with my boss".
[18:42] <aquarius> More to the point, you'll be able to work with files directly *in* the cloud.
[18:42] <aquarius> So a backup program, for example, could back up your files straight into Ubuntu One and not sync them to your local machines.
[18:43] <aquarius> And of course being able to save things in and out of the cloud means that you can get an Ubuntu One sync solution on other platforms.
[18:43] <aquarius> So you could work with your files from your non-Android mobile phone (we've already got the great mkarnicki working on that for Android!)
[18:44] <aquarius> Build a fuse or gvfs backend for Ubuntu or Fedora or SuSE or Arch Linux. Build a WebDAV server which works with Ubuntu One and mount your Ubuntu One storage as a remote folder on your Mac.
[18:44] <aquarius> And web apps can work with your cloud too, for files as well as data.
[18:45] <aquarius> Imagine, say, a torrent client, running on the web, which can download something like a movie or music from legittorrents.info and save it directly into your cloud storage.
[18:45] <aquarius> So you see an album you want on that torrent site (say, Ghosts I by Nine Inch Nails) and go tell this web torrent client about it (and you've signed in to that web torrent client with Ubuntu One)
[18:45] <aquarius> And the website then downloads that NIN album directly into your personal cloud -- which of course makes it available for streaming direct to your phone.
[18:47] <aquarius> You could do that with videos as well: choose a torrentable video (say, Beyond the Game, the documentary about World of Warcraft) and download that directly into your cloud, if someone built the web torrent client.
[18:47] <aquarius> (Of course, that would be cooler if Ubuntu One offered a video streaming service as well as music streaming, wouldn't it. Hm... ;-)
[18:48] <aquarius> But it's not just about your content for yourself; think about sharing.
[18:48] <aquarius> Ubuntu One lets you share a folder with people. This would be great for distribution.
[18:48] <aquarius> Imagine that you publish an online magazine.
[18:48] <aquarius> So, you create a folder on your desktop, and put issues of the magazine in it.
[18:49] <aquarius> Then, you put a button on your website saying "Sign in with Ubuntu One to get our magazine".
[18:49] <aquarius> When someone signs in, your website connects to the Ubuntu One files API, with your private OAuth token, and adds that signed-in user to the list of people that your magazine folder is shared with.
[18:49] <aquarius> Then, whenever your magazine has a new issue, you just drop it into that folder on your desktop.
[18:49] <aquarius> (Or even upload it to Ubuntu One directly through the website.)
[18:49] <aquarius> All the subscribed people will get the new issue instantly, on all the machines they want it on, and in the cloud.
[18:50] <aquarius> You could distribute anything like this. Imagine a podcast, or chapters of a novel.
[18:50] <aquarius> It would also work for paid-for content; when someone pays, have your code share a folder with them, and put their paid-for stuff in that folder. That's all doable through the files API.
[18:51] <aquarius> We're building the files API itself (an HTTP-based REST API) and also some wrappers for it to make it easier to use in your apps from Python and the like.
[18:51] <ClassBot> There are 10 minutes remaining in the current session.
[18:51] <aquarius> OK, I've talked about a blizzard of ideas that'll be made possible, and shown you almost no code.
[18:51] <aquarius> Which is because, as mentioned at the beginning, a lot of this code is currently being written and tested as part of the 11.04 release :)
[18:52] <aquarius> However, code is nothing without documentation, and that's really important.
[18:52] <aquarius> My main task for this cycle is to build documentation for all of this stuff; how to use Ubuntu One and all the APIs we provide in the cloud, on Android, on Windows, on iOS, on Ubuntu.
[18:52] <aquarius> So there'll be documentation for all this stuff so all of you clever people can build things that I haven't even dreamed of.
[18:53] <aquarius> We did some user research (thanks ivanka and the user research team!) on which sites have great API documentation and which don't, so we have an idea of good directions to go in.
[18:53] <aquarius> And I'm working away feverishly on getting an alpha version out!
[18:54] <aquarius> So, to summarise, since I'm running out of time: what the app developer programme is all about is giving all of you the chance to use Ubuntu One as a piece of infrastructure...like Gtk, or Python's urllib module, or PHP's curl bindings.
[18:55] <aquarius> When you want your users, or you, to be able to get at their data on their terms, from anywhere, then you should be able to use Ubuntu One to do that
[18:55] <aquarius> So, what I'd like to know is: what are your cool ideas? What help do you need from me in making them happen? What do you want to use Ubuntu One for in your apps and your scripts and your work?
[18:55] <ClassBot> davidboy asked: So when will the documentation be up? :D
[18:56] <ClassBot> There are 5 minutes remaining in the current session.
[18:56] <aquarius> davidboy, at 11.04 release! That's the deadline :)
[18:57] <aquarius> So you'll be able to start working with this stuff once natty comes out -- but we're documenting and building APIs for all sorts of platforms, as I said; for Ubuntu 11.04, for the web, for Windows and Android.
[18:57] <aquarius> So your apps can be anywhere and all work together :)
[18:57] <ClassBot> chadadavis asked: URL to current code / docs / wiki, so that we can follow development?
[18:58] <aquarius> at the moment there isn't one, because half of the APIs aren't yet written. There are blueprints you can look at which show some of this work
[18:58] <aquarius> and I'd like to get an alpha version of the documentation up as early as possible
[18:58] <aquarius> OK, I've got 2 minutes left: any final questions?
[18:59] <aquarius> Then I shall hand you over to the seif and manish show to hear about the greatness that is Zeitgeist :)
[19:00] <seiflotfy> thanks :)
[19:00] <aquarius> seiflotfy, manish, it's all yours. Thanks, everyone!
[19:00] <manish> Thanks aquarius
[19:00] <seiflotfy> thank you aquarius
[19:01] <seiflotfy> manish, ready
[19:01] <seiflotfy> ?
[19:01] <manish> yes
[19:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/03/01/%23ubuntu-classroom.html following the conclusion of the session.
[19:01] <manish> Hello everyone
[19:01] <manish> This session will introduce you to zeitgeist
[19:01] <manish> and its related to components
[19:01] <manish> the agenda is here https://wiki.ubuntu.com/UbuntuDeveloperWeek/Sessions
[19:01] <manish> scroll down
[19:01] <manish> I will post it here
[19:01] <manish> What is Zeitgeist and what it is not - 10 mins
[19:02] <manish> Security Implications - 5 mins
[19:02] <manish> Technologies used - 5 mins
[19:02] <manish> Components of Zeitgeist - 10 mins
[19:02] <manish> Integration of Zeitgeist in applications - 10 mins
[19:02] <manish> Latest release numbers and installing zeitgeist - 5 mins
[19:02] <manish> and finally FAQ for 15 mins
[19:03] <manish> I have allocated FAQ for 15 mins because I see there are a lot of confusion reguarding what zeitgeist is
[19:03] <manish> Let us start with first
[19:03] <manish> What is zeitgeist?
[19:03] <manish> Zeitgeist is an event logger which keeps a track of your activities while you are using your computer (any supported computing device).
[19:03] <manish> Events such as opening files, closing files, recieveing calls, sending a message on Instant Messenger (GTalk, Yahoo etc) are logged by Zeitgeist.
[19:04] <manish> The logging can be configured, so you have the complete control on what is logged and what is not.
[19:04] <manish> This data can then be used for variety of useful activities.
[19:04] <manish> Some of the possibilities are having a complete skype, empathy, pidgin call log.
[19:04] <manish> Finding out with you converse the most.
[19:04] <manish> You can check which applications you launch the most and how many times you have opened a specific file.
[19:05] <manish> People ask me - what are the possibilities of the things we can do with this
[19:05] <manish> I reply - The possibilities are endless, the sky is the limit
[19:05] <manish> I am hoping on you people to come up with innovative ideas after this session
[19:05] <manish> after coming to know what zeitgeist is exactly an what it is not
[19:05] <manish> so now what zeitgeist is not?
[19:06] <manish> First and formost - Zeitgeist is not a search engine!!!
[19:06] <manish> remember this
[19:06] <manish> it is an event logged
[19:06] <manish> *logger
[19:06] <manish> If you have some file on your system, then don't expect zeitgeist to search for it.
[19:07] <manish> It is not the work of zeitgeist to scan you disks and find files.
[19:07] <manish> It's work is to track your activities and log it.
[19:07] <manish> As opposed to general misconception, zeitgeist doesn't track files
[19:07] <manish> Zeitgeist deals with events and not files.
[19:07] <manish> There are events where no file is involved like recieveing a call.
[19:07] <ClassBot> UndiFineD asked: are there apps for mobiles, to be keeping track of my android
[19:08] <manish> actually work is going on to port it to phones too
[19:08] <manish> we had a prototype for Maemo
[19:08] <seiflotfy> and android
[19:08] <manish> but sadly Maemo's future is not clear after it got merged with Meego which again is a bit confusing
[19:08] <manish> we are working on android
[19:09] <seiflotfy> http://zeitgeist-android.com/
[19:09] <manish> since Android doesn't use the standard linux stack, some work is needed for making it run on android
[19:09] <manish> esp testing the port is very important
[19:09] <ClassBot> darkdevil71 asked: is it a key logger ?
[19:10] <seiflotfy> darkdevil71, no its not
[19:10] <manish> darkdevil71: I will come to it. It is the next topic. The security implication
[19:10] <manish> darkdevil71: it doesnt track each and every key you press
[19:11] <manish> it just logs your activity
[19:11] <manish> most opening and closing of files
[19:11] <manish> and some other events
[19:11] <manish> which events you want to send is configurable
[19:11] <manish> though the api is still a bit crippled
[19:11] <manish> Next is - Security Implications
[19:11] <manish> You might heard that Zeitgeist is a malware/spyware which tracks your activities.
[19:11] <manish> This is not an exact definition of malware/spyware.
[19:12] <manish> Malwares record your activity, steal your data without your approval and sneak into the system without system. They have a destructive intention.
[19:12] <manish> Contrast this with zeitgeist, it records events so that it can be used for constructive purposes.
[19:12] <manish> It's like nuclear technology.
[19:12] <manish> Use it constructively, it will benefit mankind, use it destructively and you will be harmed.
[19:12] <manish> One concern people raise is that if some malware is installed, then it can steal the zeitgeist data.
[19:13] <manish> In this scenario, if a malware is installed, then you are at a bigger risk than just getting your zeitgeist data stolen.
[19:13] <manish> Your pidgin passwords are stored in plain text in your home directory.
[19:13] <manish> (last when I used pidgin)
[19:13] <manish> Your browser's history is very easily accessible.
[19:13] <manish>  If you have not set the master password in Firefox, then even your passwords are available to the malware.
[19:14] <manish> any questions related to security implications?
[19:15] <manish> Next up we have - Technologies used in Zeitgeist
[19:15] <manish> Zeitgeist is written using Python and uses sqlite to store the events.
[19:15] <manish> It exposes an API using DBus using which other applications can communicate with it.
[19:16] <manish> Below the hood, it is basically dependent on glib which makes zeitgeist portable.
[19:16] <manish> Get a proper port of dbus and glib on windows and zeitgeist should run there without much issues.
[19:17] <manish> or in this case any other OS
[19:17] <manish> Next up -  Components of zeitgeist
[19:18] <manish> Zeitgeist is not a single project
[19:18] <manish> but a collection is components
[19:18] <manish> helper libraries etc
[19:18] <seiflotfy> a framework more or less
[19:18] <manish> yeah
[19:18] <manish> the core part is the engine
[19:18] <manish> or the daemon
[19:19] <manish> At the core of zeitgeist is an engine which stores all the events and acts as the store.
[19:19] <manish>  It recieves and provides relevant information(events) to other process.
[19:19] <manish> The information is exposed via a DBus Session bus.
[19:19] <manish> If the zeitgeist server is not running, the first time an application invokes a method over DBus, the daemon is started.
[19:20] <manish> I don't remember the exact name what this is called - autostarting a session bus when first call is made. Hope someone can tell me on #ubuntu-classroom-chat
[19:20] <manish> The second component is called the datahub
[19:20] <manish> I know sounds dangerous a bit
[19:21] <manish> it is a passive logger
[19:21] <manish> there needs to be some component which keeps on pushing data to the daemon
[19:21] <manish> or the daemon is nothing more than a white elephant
[19:21] <manish> Thanks to aquarius that is called DBus activation --  autostarting a session bus when first call is made.
[19:21] <manish> coming back
[19:22] <manish> so datahub is a logger
[19:22] <manish> which also runs as a daemon
[19:22] <manish> and looks at the recently used files
[19:22] <manish> and pushes them in the daemon
[19:23] <manish> so basically when you open a file by double clicking using nautilus datahub comes in picture
[19:23] <manish> I wont go much in the geekery of implementation
[19:23] <manish> for adventurous people - "bzr branch lp:zeitgeist-datahub" is your friend
[19:24] <manish> one more thing I forgot was telling you people about our website, sorry
[19:24] <manish> http://zeitgeist-project.com/
[19:24] <manish> Download section: http://zeitgeist-project.com/download/
[19:24] <manish> development - http://zeitgeist-project.com/development/
[19:24] <manish> and we are always available at #zeitgeist on freenode
[19:25] <manish> next up - Activity Journal
[19:25] <manish> it was formely called gnome-activity-journal
[19:25] <manish> it is a GUI viewer for your events
[19:25] <manish> like a dashboard
[19:26] <manish> With proper zeitgeist extensions you can even have more detailed logs including when you joined an IRC channel or when you received or dropped a call over your IM client.
[19:26] <manish> you can install it, it is in the repos
[19:26] <manish> as gnome-activity-journal
[19:26] <manish> If you right click on any event and select "More Information", you can come to know what other files were opened or which other activity you were engaged in during this event. You can delete the event if you do not like it.
[19:26] <manish> next up is - Dataproviders
[19:27] <manish> Dataproviders are small extension/addins/addons/plugins into applications which can push events to zeitgeist.
[19:27] <manish> we also call it datasources
[19:27] <manish> same thing
[19:27] <manish>  Datahub cannot push everything to the daemon.
[19:27] <manish> It mostly tracks opening of files by double-clicking from file browser.
[19:27] <manish> Using data-providers more *relevant* events can be added like "Creating a new playlist", "Buying a track from foo music store"
[19:27] <manish> next up is - Extensions
[19:28] <manish> When we say extensions, it refers to zeitgeist daemon extensions.
[19:28] <manish> means the extensions for the daemon
[19:28] <manish> and not the client
[19:28] <manish> Zeitgeist extensions are those components using which you can control he behavior of how the daemon behaves. You can expose additional information via DBus.
[19:28] <manish> In a nutshell, you this is your tool of trade if you are not satisfied with how zeitgeist behaves. One size doesn't fit all. :)
[19:28] <manish> If you want to have an inner scoop of extensions behavior, check
[19:28] <manish> http://milky.manishsinha.net/2010/11/27/zeitgeist-daemon-extensions-explained/
[19:29] <ClassBot> chadadavis asked: facilities for plugins, e.g. Facebook to include external activity streams?
[19:29] <manish> chadadavis: yes
[19:29] <manish> that is what I was telling about dataproviders
[19:29] <manish> I or you can write dataprovieders
[19:29] <manish> which can probably run as a daemon pulling data from all your web apps
[19:29] <manish> and logging them in zeitgeist
[19:30] <manish> which is again browsable
[19:30] <manish> chadadavis: nice idea. Added to my TODO
[19:30] <ClassBot> MickStep asked: is it likly that a syncing service will every be created for zeitgeist, like tomboy created snowy
[19:30] <manish> MickStep: yes. We were working on it
[19:30] <manish> but due to some shortage of time
[19:30] <manish> personal lie
[19:31] <manish> and other important priorities related to zeitgeist pushed this feature a bit below our priority queue
[19:31] <manish> thanks for bringing it up
[19:31] <manish> will look into it
[19:31] <manish> People, ask your questions :)
[19:31] <ClassBot> jderose asked: Speaking of syncing, are alternate storage backends a possibility for Zeitgeist, like say desktopcouch?
[19:31] <manish> jderose: right now none. It can be looked into
[19:32] <manish> but the thing is that is not worth the effort as of now. Since right now we are spending our time in deploying zeitgeist
[19:32] <manish> integration with applications
[19:33] <manish> for you call,  you can add our zeitgeist ppa or latest packages. Sadly most of the packages are for Maverick
[19:33] <manish> https://launchpad.net/~zeitgeist/+archive/ppa
[19:33] <manish> this PPA
[19:33] <manish> there are many zeitgeist-datasources-* packages
[19:33] <manish> like one for tomboy
[19:34] <manish> if you install that package
[19:34] <manish> zeitgeist-datasource-tomboy
[19:34] <manish> then your opened, closed notes will appear in GAJ :)
[19:34] <manish> if you install the -xchat datasource
[19:34] <manish> it will show you which all channels you joined
[19:34] <manish> when you talked
[19:34] <manish> when you quit, parted
[19:35] <manish> cando_ is the current maintainer of gnome-activity-journal
[19:35] <manish> there are many datasources/dataproviders have a look at them in the PPA
[19:36] <manish> next is Language bindings
[19:40] <manish> by language bindings I mean, language specific wrappers over zeitgeist api
[19:40] <manish> you can use zeitgeist using it's python client
[19:40] <manish> which is shipped along with the daemon
[19:40] <manish> for C/Vala we have libzeitgeist
[19:40] <manish> http://launchpad.net/libzeitgeist
[19:40] <manish> for mono (C#) we have zeitgeist-sharp http://launchpad.net/zeitgeist-sharp
[19:40] <manish> Qt - libqzeitgeist
[19:40] <manish> http://gitorious.org/kde-zeitgeist/libqzeitgeist
[19:40] <manish> and we also have for javascript
[19:40] <manish> but still it is not not yet mature
[19:40] <manish> needs work
[19:40] <manish> next is Zeitgeist integration
[19:40] <manish> 1) Unity
[19:40] <manish> okay I will come to it
[19:40] <manish> now lets goto questions
[19:40] <ClassBot> techbreak_ asked: its in gsoc ?
[19:40] <manish> if you asked if zeitgeist is in gsoc, then we are trying, not sure if we need to apply independently
[19:40] <manish> it doesnt make sense
[19:40] <manish> we need zeitgeist integration in applications like kde, gnome apps
[19:40] <seiflotfy> zeitgeist will be offering some work over several organizations
[19:40] <seiflotfy> such as KDE, GNOME and hopefully Ubunut
[19:40] <ClassBot> UndiFineD asked: can we read out data from zeitgeist, if so could we get some statistics, maybe people would like to compare productivity
[19:40] <manish> UndiFineD: yes. you can
[19:40] <manish> use the API
[19:40] <manish> if you like, you can use the language of your choice
[19:40] <manish> Python, C, Vala, C#, Javascript
[19:41] <manish> as I can see in the -chat channel, there is some confusion
[19:41] <manish> zeitgeist doesnt look for any data
[19:41] <manish> it just sits and waits for events to be pushed
[19:41] <manish> when asked it hands out events
[19:42] <manish> the pushing it done by datasources
[19:42] <ClassBot> jeyd asked: what about the xchat datasource in LUCID?
[19:43] <manish> jeyd: we need to put that too. I can see that -datasources package is there for lucid
[19:43] <manish> and the lucid package doesnt have xchat
[19:43]  * manish puts this in TODO
[19:43] <manish> for more info https://launchpad.net/~zeitgeist/+archive/ppa/+packages
[19:44] <ClassBot> godbyk asked: Does Zeitgeist only pay attention to the channel part/join events and ignore what was actually said in the channel?
[19:44] <manish> godbyk: it wont log each and every line you said
[19:44] <manish> use your irc client's logging functionality
[19:45] <ClassBot> techbreak_ asked: which language it is written inn ?
[19:45] <manish> as I said zeitgeist is written in Python
[19:46] <ClassBot> MickStep asked: What is the simplest example you can provide for how to write a dataprovider
[19:46] <manish> there is one
[19:46] <manish> I will use Python's example
[19:47] <manish> you can check it in git.
[19:47] <manish> git.gnome.or
[19:47] <manish> this one
[19:48] <manish> http://git.gnome.org/browse/rhythmbox/tree/plugins/rbzeitgeist/rbzeitgeist/__init__.py
[19:48] <manish> the RB plugin
[19:48] <manish> We have implemenation for Unity
[19:48] <manish> Unity makes use of Zeitgeist in its dash where it provides the user with easy access to its most and recently used data (files/folders/applications) as well as searching over the Zeitgeist FTS (Full Text Search) extension.
[19:48] <manish> There is more development going on to bring the same features to a contacts dash where the user can browse his contacts by most/recently used.
[19:49] <manish> a snapshot by seiflotfy
[19:49] <manish> http://zeitgeist-project.com/wp-content/uploads/2010/12/unity-most-used-apps.png
[19:49] <manish> then we have it integrated in Synapse
[19:49] <manish> the uber-cool launcher written by mhr3 and his team
[19:49] <manish> Other than heavily depending on the Zeitgeist FTS (Full Text Search) extension for searching, you can also browse recent items which were logged by Zeitgeist, in case you close a document by mistake or just want to hear again the music track that played a few minutes ago.
[19:50] <manish> ﻿﻿It also has a relevancy service, which makes sure that applications you use often end up among the first results of a search – this is done using Zeitgeist, so you can also track the popularity also in other Zeitgeist clients.
[19:50] <manish> obligatory snapshot - http://zeitgeist-project.com/wp-content/uploads/2010/12/synapse-search-sort-apps-ranking.png
[19:50] <manish> I already told about Activity Journal
[19:50] <manish> http://zeitgeist-project.com/wp-content/uploads/2010/12/gaj-diary.png
[19:50] <manish> http://zeitgeist-project.com/wp-content/uploads/2010/12/gaj-timeline.png
[19:50] <seiflotfy> manish, i think it would be cool to show them the tomboy plugin that provides "used with"
[19:50] <manish> yeah
[19:51] <ClassBot> There are 10 minutes remaining in the current session.
[19:51] <manish> The used with is here http://thoughts.manishsinha.net/photo/1280/2890463378/1/tumblr_lfh52cBm7g1qcwfsm
[19:51] <manish> here you can even see bzr plugin in action
[19:51] <manish> and xchat plugin in action
[19:51] <manish> seiflotfy: you have a snapshot with tomboy plugin
[19:51] <manish> can you take one and upload before this session gets over?
[19:52] <seiflotfy> yeah
[19:52] <manish> last in integration section is Docky
[19:52] <manish> The integration with Zeitgeist is in the form of generating jump-lists for applications and folders
[19:52] <manish> An application that is provided a jump-list is populated with the most and recently used data that was used with it. This also applies for folder where the most and recently used files are displayed in its jump-list.
[19:52] <manish> snapshot: http://zeitgeist-project.com/wp-content/uploads/2010/12/docky-folder-jump1-300x289.png
[19:52] <manish> http://zeitgeist-project.com/wp-content/uploads/2010/12/docky-app-jump-300x300.png
[19:53] <seiflotfy> http://seilo.geekyogre.com/2010/08/zeitgeist-hearts-tomboy/
[19:53] <seiflotfy> this is a video of zeitgeist being used by tomboy
[19:53] <manish> Next is Installation:
[19:53] <manish> Stable PPA: http://launchpad.net/~zeitgeist/+archive/ppa
[19:53] <manish> I have an experimental PPA where i love to upload packages
[19:53] <manish> bleeding edge
[19:53] <manish> enough to break your system
[19:53] <manish> http://launchpad.net/~manishsinha/+archive/experimental
[19:54] <manish> use it with care, if you are adventurous, this is you best best
[19:54] <manish> The best way to install zeitgeist is from PPA of official repos
[19:54] <manish> *or
[19:54] <manish> or if you want to check the latest versions
[19:54] <manish> Zeitgeist Engine - 0.7 "All I have is this woodchuck"
[19:54] <manish> http://launchpad.net/zeitgeist/0.7/0.7
[19:54] <manish> Zeitgeist Datahub - 0.7.0
[19:54] <manish> http://launchpad.net/zeitgeist-datahub/0.7/0.7.0
[19:54] <manish> Activity Journal - 0.6.0 "Pink Unicorns don't exist"
[19:54] <manish> http://launchpad.net/gnome-activity-journal/0.6/0.6.0
[19:55] <manish> libzeitgeist - 0.3.2 Rattleweed
[19:55] <manish> http://launchpad.net/libzeitgeist/0.3/0.3.2
[19:55] <manish> zeitgeist-sharp - 0.1.1 Lily
[19:55] <manish> Lily is the character from HIMYM (I love that series) :)
[19:55] <manish> http://launchpad.net/zeitgeist-sharp/0.1/0.1.1
[19:55] <manish> libQZeitgeist - 0.1 "Hit ‘n Run"
[19:55] <manish> http://www.gitorious.org/kde-zeitgeist/libqzeitgeist/archive-tarball/master
[19:55] <manish> and for dataproviders we have only snapshot releases
[19:55] <manish> which we package
[19:56] <ClassBot> There are 5 minutes remaining in the current session.
[19:56] <ClassBot> godbyk asked: What are some of your favorite future plans for Zeitgeist? How and where would you like to see it be used in the future?
[19:56] <manish> godbyk: nice question
[19:56] <seiflotfy> godbyk, alot
[19:56] <manish> fav plans are
[19:56] <manish> having a good blacklist plugin
[19:56] <manish> that is wat everyone wants
[19:56] <manish> and Banshee integration
[19:56] <manish> which is my fav thing
[19:56] <seiflotfy> and the geolocation deployment
[19:56] <manish> yes
[19:57] <manish> and syncing service
[19:57] <manish> which is half implemented
[19:57] <manish> it uses django
[19:57] <manish> seiflotfy: shall we move to next quesiton?
[19:57] <ClassBot> JackyAlcine asked: Zeitgeist is a semantic framework, like NEPOMUK, no? Is it possible to use this to do automation tasks like perhaps, backups of the last few used documents?
[19:57] <seiflotfy> JackyAlcine, no its not like NEPOMUK
[19:57] <manish> seiflotfy: your turn to answer this
[19:57] <seiflotfy> NEPOMUK is a ontology
[19:57] <seiflotfy> NEPOMUK KDE is a repository
[19:58] <seiflotfy> NEPOMUK KDE knows about what your files are about
[19:58] <seiflotfy> Zeitgeist is a log
[19:58] <seiflotfy> it knows how you use your files and how they are contextually related
[19:58] <seiflotfy> !q
[19:59] <ClassBot> techbreak_ asked: any video log it keeps ?
[19:59] <seiflotfy> what do you mean
[19:59] <seiflotfy> if u have any questions please join #zeitgeist
[19:59] <seiflotfy> we will be happy to help you out there
[19:59] <seiflotfy> our time is up
[19:59] <seiflotfy> so thanks you
[19:59] <manish> we have most of our discussion on irc
[19:59] <manish> and we hardly use mailing lists
[19:59] <manish> thanks you everyone
[20:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/03/01/%23ubuntu-classroom.html following the conclusion of the session.
[20:01] <Rhonda> So, let's continue with the schedule without further interruption, to keep you satisfied.
[20:02] <Rhonda> Please reminded to ask your questions in #ubuntu-classroom-chat and prefix them with QUESTION: so that ClassBot can pick them up.
[20:02] <Rhonda> I'm Rhonda and I'm your host for the last session today which is about "Getting your fixes into Debian, how to make community happy"
[20:03] <Rhonda> I will be your host alone, unfortunately nigelb had to rest.
[20:04] <Rhonda> Anyway, I'm a longtime Debian Developer and have stumbled maintained a fair amount of packages for Debian for a long time, so I managed to get a good overview on how to work with the Debian Bug Tracking System (BTS).
[20:04] <Rhonda> First let me tell you why you want to send bugreports to Debian and get fixes done there instead of in Ubuntu.
[20:05] <Rhonda> You might have attended the great session of tumbleweed yesterday where he mentioned the why.
[20:05] <Rhonda> Let me quote him, "we should rather report the mistake to the upstream, and we'll get the benefit of the fix, without extra effort, when the upstream releases a new version"
[20:05] <Rhonda> And: "during [regular development time], any uploads to debian get pulled over pretty quickly (assuming we haven't deviated from Debian)"
[20:06] <Rhonda> Having a difference within Ubuntu requires a lot of overhead because a merge can't happen automatically. It requires someone to take a look at it, requires testing, wether it still applies, and stuff.
[20:06] <Rhonda> And then there is also our Code of Conduct which asks us to be collaborative, to give back.
[20:07] <Rhonda> So every patch that is pushed upstream is a patch less for us to keep care of, with the additional benefit to the rest of the Free Software ecosystem.
[20:08] <Rhonda> Unfortunately (for certain definitions of that word) Debian doesn't use launchpad but debbugs, a special tailored BTS done for the requirements within Debian.
[20:08] <Rhonda> The first interface I want you to get familiar with is the website: http://bugs.debian.org/
[20:09] <Rhonda> It offers you simply and quite convenient query shortcuts - and it's just that: A query interface.
[20:09] <Rhonda> The Debian BTS is run and operated only by emails, the website is a read-only tool.
[20:10] <Rhonda> But it still offers a lot: If you want to see e.g. the bugreports about a certain package, you just add the packagename to the URL, like in http://bugs.debian.org/wesnoth-1.8
[20:10] <Rhonda> There you get an overview of all the open bugreports against said package.
[20:11] <Rhonda> From there you can click through and end up with different queries, like for a specific bugreport (which can also be reached through http://bugs.debian.org/bugnumber, like http://bugs.debian.org/12345)
[20:12] <Rhonda> Or for a specific package maintainer address, it's http://bugs.debian.org/maintainer@email.address
[20:12] <Rhonda> But more interesting for you, when you are reporting bugs, probably is to query all of your reported bugs that weren't dealt with yet. This is mine: http://bugs.debian.org/from:rhonda@debian.at
[20:13] <ClassBot> hugohirsch asked: I need to know the exact version of the package I'm looking for bugs in Debian, right?
[20:13] <Rhonda> No, the overview page for the bugs for a package aren't for a specific version, or release. You get them all on one page there.
[20:14] <Rhonda> If you scroll down to the end of the overview page you have a form where you can narrow down the list, but in general you get them all.
[20:15] <Rhonda> If your question was related to wesnoth-1.8, the 1.8 is part of the package name, it's not the package version. Sorry for having used a confusing example here. :)
[20:16] <Rhonda> Please notice that a source package can have multiple binary packages, and if you want an overview for all the bugs for a certain source package, you go to http://bugs.debian.org/src:sourcepackagename
[20:16] <Rhonda> Anyway, like said, the website is just a query interface. The actual working stuff behind debbugs is its email interface.
[20:17] <Rhonda> There is one commandline tool that is very popular because it prepares a report template for you and fills in some additional information that are helpful for the package maintainer. That tool is called reportbug.
[20:18] <Rhonda> Within Ubuntu though, you need to add pass the -B debian option to reportbug, otherwise it will tell you that you should use launchpad (for Ubuntu) instead to report bugs. :)
[20:19] <Rhonda> So if you run reportbug -B debian somepackage, you will be asked a few questions, an editor will get fired up into which you enter the description of the bug, and then you can send it.
[20:19] <Rhonda> This though requires usually a local installed mail transport agent, which might be a bit cumbersome. But even in those cases, reportbug can be very useful.
[20:20] <Rhonda> It has a --template option which can produce the template text for you to paste into your preferred email client to get the additional information for the package maintainers.
[20:20] <ClassBot> hugohirsch asked: Is reportbug similar to ubuntu-bug (reporting to LP instead)?
[20:21] <Rhonda> Actually I've never used ubuntu-bug, this is where I would have hoped for a person deeper involved in Ubuntu to jump in to the rescue. ;)
[20:22] <Rhonda> The general overview about debbugs can be found on https://wiki.ubuntu.com/Debian/Bugs, and the specific description about the email interface is at http://www.debian.org/Bugs/Reporting
[20:23] <Rhonda> Actually reporting a bug to Debian is sending an email to submit@bugs.debian.org and add a few pseudo header lines in the first lines of your mail text.
[20:24] <Rhonda> The most important here is "Package: packagename" so that the BTS knows where to sort your bugreport to.
[20:24] <Rhonda> There are additional ones, like "Version: 1.2.3" to note that you found the bug in said version.
[20:25] <Rhonda> Then there is "Severity: important" - this tells the BTS the severity of the bugreport. Valid values here are grave, critical, serious, important, normal, minor and wishlist
[20:25] <Rhonda> Please don't choose the first three unless you are very certain here, they have a special meaning, I'll return to them later.
[20:26] <Rhonda> If you are uncertain, just leave it out and it will default to normal. All these things can be adjusted later.
[20:26] <Rhonda> You will receive an email in return telling you that your bugreport was received and telling you the number of the bugreport, for a reference.
[20:27] <Rhonda> And here we come to the control bot of the BTS, reachable through control@bugs.debian.org
[20:27] <Rhonda> You can send it commands to manipulate the bugs, and for this you need the bugnumber.
[20:28] <Rhonda> The documentation for that can be found at http://www.debian.org/Bugs/server-control - you can see the list of commands in the table at the top.
 Is this debian method of dealing with bugs through email descended from the days before the WWW really took off
[20:30] <Rhonda> Actually to some degree, or rather not. Yes, there weren't these possibilities in the early days of html, but forms were already there.
[20:30] <Rhonda> But what actually is important for us to be able to reach the bug reporters, and an email interface is very convenient in that way because email is quite universal.
[20:32] <Rhonda> With the commands for the control bot you can see that you can adjust almost all values, like with "severity 12345 important" you'd change the severity of that bug, with "forwarded 123 http://upstream.bugtracker/456" you can note down that this bug was also reported to some upstream project
[20:32] <Rhonda> The "tag" command is also very useful, bugs can be marked with certain tags.
[20:33] <Rhonda> Commonly used ones are moreinfo, unreproducible, wontfix, patch, help, security, pending, and releasename tags, like squeeze or wheezy or sid.
[20:34] <Rhonda> retitle will set the bugtitle new, in case when the original bugreporter didn't provide a useful summary in the subject
[20:34] <Rhonda> With found one can note down additional affecting versions, and with fixed one can note down that the bug is fixed in said version.
[20:35] <Rhonda> Though, usually when bugs get closed in a version, it is done similar to how it's done in Ubuntu: with a changelog entry.
[20:35] <Rhonda> For Debian this goes like "Closes: #12345" (in Ubuntu it's "LP: #12345")
[20:36] <Rhonda> That will do two things in the end: It sets the fixed version in the bugreport, and it will mark the bugreport as done.
[20:36] <Rhonda> And this is where I want to start with explaining how version tracking works in the Debian BTS.
[20:37] <Rhonda> Because usually, after a while, bugs get archived so they disappear from the overview page.
[20:37] <Rhonda> I wrote this down in a blog post of mine last year, but I'll explain it here nevertheless. The blogpost as a reference can be found here: http://rhonda.deb.at/blog/debian/on-BTS-usage.html
[20:38] <Rhonda> Bugs get archived after 28 days they are done.
[20:39] <Rhonda> Though, there might be certain delaying factors here: The bug has to be done on all architectures in unstable and in testing.
[20:39] <Rhonda> When that's the case, the counter start.
[20:39] <Rhonda> Well, it has to be done in testing only when the version tracking also sees testing as affected.
[20:40] <Rhonda> When the bugreport was filed against a version that is only in unstable and all archs are in sync in unstable the counter starts then already.
[20:40] <Rhonda> Also there are these special bug severities that I mentioned earlier: grave, critical and serious.
[20:41] <Rhonda> Those are considered Release Critical bugs, and such bugs have to get fixed in _all_ affected distributions, not only in the ones in development.
[20:41] <Rhonda> That means, bugreports for RC bugs that are done in unstable will still stay around in the overview for the package as a reminder.
[20:42] <Rhonda> Sometimes though version tracking gets a bit tricky.
[20:42] <Rhonda> I've dug up some bugreports that we can take a look at to learn to understand it.
[20:43] <Rhonda> And actually, I want to also mention another great helpful tool, which is parts of the devscripts package: It's called "bts".
[20:43] <Rhonda> bts is a commandline client to the BTS. Actually what it does is create a mail to control@bugs built from the options you give.
[20:44] <Rhonda> The former mentioned example of setting the severity of a bugreport would be as easy with bts as "bts severity 12345 important".
[20:44] <Rhonda> Please notice again that this requires a local configured MTA (ssmtp is quite easy for simple sending out mails)
[20:45] <Rhonda> And it takes your DEBEMAIL environment variable as email address, so make sure to set that to your preferred value.
[20:45] <ClassBot> MickStep asked: That debian ssl bug was a "grave"?
[20:46] <Rhonda> Quite certainly. :)  You can read up on the definitions of the servities in the BTS documentation on http://www.debian.org/Bugs/
[20:47] <Rhonda> So, coming back to my examples. Let's start to dig through the overview page that I mentioned before first, explaining a few more interesting parts there.
[20:48] <Rhonda> http://bugs.debian.org/wesnoth-1.8 - you see the bugreports grouped by severities. You have links to the Bugs themself in the number, after that is a box of [m| | ] which notes down some flags.
[20:48] <Rhonda> If you hover the characters you get their meaning in a tooltip - but you can also click there to get additional overview information
[20:49] <Rhonda> Like who reported the bug, when, the tags, and such#
[20:49] <Rhonda> If you actually go to the bug page, you find overview information at the top, and a version graph on the righthand side.
[20:49] <Rhonda> Red circles mark affected versions, green boxes fixed versions.
[20:50] <Rhonda> You also can see the distribution parts in there to see wether stable, testing and unstable are affected
[20:50] <Rhonda> Let's look at a specific bug: http://bugs.debian.org/612780
[20:51] <ClassBot> There are 10 minutes remaining in the current session.
[20:51] <Rhonda> You don't see a version graph here because there aren't any version information given.
[20:51] <Rhonda> The total lack of version information makes the BTS think the bug affects all versions of the package.
[20:52] <Rhonda> Actually, building against a package from experimental isn't a release critical bug, so what am I going to do?
[20:52] <Rhonda> I call this command:
[20:52] <Rhonda> bts severity 612780 important '# FTBFS against packages in experimental is not RC'
[20:53] <Rhonda> Leave the page open, we will reload it in a few minutes. :)
[20:53] <Rhonda> This bugreport is also interesting: http://bugs.debian.org/456558
[20:53] <Rhonda> It actually does have a bug graph, and both found and fixed versions.
[20:53] <Rhonda> But why isn't there a green box?
[20:54] <Rhonda> If one looks close then one can see that it was found in the audacious package but fixed in the audacious-plugins package.
[20:55] <Rhonda> The BTS though doesn't find any information that audacious package is fixed, and the bugreport is assigned to that package.
[20:55] <Rhonda> So the proper fix to get that bugreport really done is a reassign to audacious-plugins package.
[20:56] <ClassBot> There are 5 minutes remaining in the current session.
[20:56] <Rhonda> Please notice that a reassign deletes all version information, so we have to re-add the fixed version afterwards.
[20:56] <Rhonda> Here bts comes to the rescue again, and this is a good example for a chained command: One can give multiple commands that are sent to the control bot in one commandline. This is what I am using:
[20:56] <Rhonda> bts reassign 456558 audacious-plugins '# done in different source package' . fixed 456558 2.0.1-1
[20:57] <Rhonda> Actually there are more than just this bug in that state, so I rather leave this up to a team member responsible for audacious: bdrung, please reassign them all appropriately. ;)
[20:58] <Rhonda> The next example is more interesting: http://bugs.debian.org/src:mail-notification
[20:58] <Rhonda> You will find a fair amount of still non-archived bugs at the bottom of the page.
[20:58] <Rhonda> Let's pick out http://bugs.debian.org/383159 as example
[20:59] <Rhonda> The version graph is pretty unreadable here, so let's click on it to get it in bigger size.
[20:59] <Rhonda> If you look closer, you'll notice something pretty interesting: unstable is listed both in a green _and_ in a red box.
[21:00] <Rhonda> That's … special indeed. What's going on here? For that we use another fine resource as help: http://packages.debian.org/unstable/mail-notification
[21:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/03/01/%23ubuntu-classroom.html
[21:01] <Rhonda> You might know a similar page, http://packages.ubuntu.com/ offers the same service for you, it's the same codebase.
[21:02] <Rhonda> At the end you'll find that the hurd-i386 package has a different version than the others.
[21:03] <Rhonda> So actually the build for that architecture is having troubles. Given that that architecture is not really an official yet, filing a bugreport against ftp.debian.org and asking for removal of the package on that architecture will fix that.
[21:03] <Rhonda> … and I guess I should conclude the session, we run out of time.
[21:04] <Rhonda> The fineprint is: Version tracking in the Debian BTS is still something rather new, not all Debian Developers have a good understanding of it and it needs a fair amount of cleanup.
[21:04] <Rhonda> Don't be shy, feel free to ask, stumble by in #debian-ubuntu on irc.debian.org (different network than irc.ubuntu.com) and we'll try to help.
[21:15] <djflor> Bonsoir tout le monde !