=== vanhoof_ is now known as vanhoof [00:28] Hello friends I am from india. I want to attend the Ubuntu Developer Week. So plz. tell the time? [00:29] awanti: the second day starts in 15.5 hours [00:29] awanti: The schedule's at https://wiki.ubuntu.com/UbuntuDeveloperWeek . Click the times on it to get conversions to your timezone. [00:32] ok thanks I got the timings. In India it will start at 9.30 pm. === MTecknology is now known as billmeye === billmeye is now known as MTecknolgoy === MTecknolgoy is now known as MTecknology === jmarsden_ is now known as jmarsden === jledbetter_ is now known as jledbetter === kenvandine_ is now known as kenvandine === MTecknology is now known as pfSensory === pfSensory is now known as MTecknology [05:08] Hello === Pete is now known as Guest77399 === lag` is now known as lag [08:22] ubuntu wired network problem [08:22] wireless works, wired does not work [08:23] hi laxmi for support please join #ubuntu [08:23] via /join #ubuntu [08:23] ok === qwebirc76859 is now known as geco2 [10:45] !log [10:45] Logs for all classroom sessions that take place in #ubuntu-classroom can be found on http://irclogs.ubuntu.com/ [10:45] 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] hello !! [11:19] hi all [11:19] hey guy [11:21] the schedule link seems to be down [11:40] hi, i'm new in this classroom, i'd like to know how i can join ubuntu developers community... === Ursinha-afk is now known as Ursinha [11:41] could someone help me?? === shadeslayer_ is now known as shadeslayer [13:22] !log [13:22] Logs for all classroom sessions that take place in #ubuntu-classroom can be found on http://irclogs.ubuntu.com/ [13:22] 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] hello,boys and grils [14:53] can i know when the sessions start ? in how many hours ? 3 ? [14:55] anirudh24seven: http://is.gd/8rtIi [14:55] (Link from topic) [14:56] 16:00utc [15:02] thanks [15:02] sorry for not having looked through earlier [15:02] was checking it out before looking at your link... thanks anyway === Ursinha is now known as Ursinha-lunch [15:08] wen the class is gonna start?? [15:08] Vishal_, http://people.ubuntu.com/~nhandler/classroom.html [15:09] Vishal_: in about 1 hour [15:09] thnx [15:12] what would be the topic of discussion in class? [15:20] hellyeah_, 16.00 - How to write a compiz plugin === seiflotfy_ is now known as seiflotfy === s1aden is now known as sladen [15:41] * fisch246 puts on atom heart mother album to bring him into the mood of Learning Ubuntu :D [15:44] msg NickServ identify atzenmusik [15:46] misterxyz: If that is your password, you should change it immidiatly. [15:47] Or maybe it's too late. [15:51] hi [15:57] dholbach: are we good to start ? [15:57] we are [15:57] awesome [15:57] let me do a quick introduction :) [15:57] sure thing! [15:57] HELLO MY FRIENDS! ARE YOU READY FOR DAY 2? [15:57] smspillaz, :) so we are begining right ? [15:57] (woohoo!) [15:57] dholbach, smspillaz yeah :) [15:57] please join #ubuntu-classroom-chat if you haven't done that yet [15:58] it's the place where all the questions and chat goes [15:58] and if you do have questions, please ask [15:58] but please prefix them with QUESTION: [15:58] ie: QUESTION: smspillaz: Do you have pets? [15:58] I have one cat ;-) [15:58] all the information you need should be available at https://wiki.ubuntu.com/UbuntuDeveloperWeek [15:58] he is very awesome :) [15:58] have a great day 2 [15:58] it's great to have you! [15:58] now let's kick off the day [15:59] smspillaz, yaa we aready. [15:59] dholbach: let me know when I'm good to start :) [15:59] 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] smspillaz, the stage is yours! [15:59] horray! [16:00] 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] 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] so the first one is the internal architecture of compiz [16:00] which can be found here: [16:00] http://smspillaz.ucc.asn.au/unity/compiz_arch/compiz_arch.pdf === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu Developer Week - Current Session: How to write a compiz plugin - Instructors: smspillaz [16:01] 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] 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] http://smspillaz.ucc.asn.au/unity/compiz_arch/writing.odt [16:01] so feel free to grab those :) [16:01] alrighty, so starting from the beginning [16:02] first of all, a quick introduction to how compiz works, and what exactly its function is [16:02] and then how to get and compile a development version of compiz, or just develop for it on ubuntu [16:02] and then I'll do a quick walkthrough of the basic structure of a plugin and some commonly done things in plugins [16:03] ok, so as for how compiz works, and what exactly it does [16:04] 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 === m4n1sh is now known as manish [16:04] 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] along with its plugin interface, this makes it pretty much possible to do any bling that you want === manish is now known as manish__ [16:05] so, now moving on to exactly how to set up a development environment [16:05] luckly, ubuntu makes this pretty easy [16:06] just sudo apt-get install compiz-dev and compiz-plugins-main-dev and you're done [16:06] (On maverick, it is compiz-fusion-plugins-main) === manish__ is now known as manish_ [16:06] but, if you want to do development in a little more, I usually suggest having a local build of compiz handy. [16:07] Luckily, most of that is relatively straightforward these days, since there are scripts to do that [16:07] http://git.compiz.org/~soreau/scripts/ <- like these fantastic ones [16:08] just clone the git repo there and with the script you'll have a full working installation from source. [16:08] 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] so, a quick question I've recieved [16:09] QUESTION: What about Ubuntu 11.04 [16:09] so, this tutorial here, as I probably should have explained will be for Ubuntu 11.04 [16:09] since compiz was re-written in between the 0.8 and 0.9 series (maverick and natty) [16:09] however, those git scripts about should also work on maverick [16:10] Now on to the nitty gritty of writing your first plugin [16:10] 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] we only use boost to a small extent, glib more recently and sigc [16:11] CMake is also used for building rather than automake [16:11] to answer another quick question [16:11] 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] 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] in addition, I'm not sure about how to make it build and install locally [16:12] (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] so I'd suggest you stick to the scripts or to the master source [16:13] (A link to the build tutorial is in the documents I linked to earlier) [16:13] so now back to writing plugins [16:13] so the basic knowledge, you will need once again, is C++, boost or CMake [16:14] 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] it's just that if you want to go down the road of bling-bling, then OpenGL is nice [16:14] ok, so now for creating your plugin project [16:14] 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] so, your directory structure would be [16:15] moveleft [16:15] - [16:15] -> src [16:15] ---> moveleft.cpp [16:15] ---> moveleft.h [16:15] -> moveleft.xml.in [16:15] -> CMakeLists.txt === qwebirc46515 is now known as geco2 [16:16] now to explain each component of that [16:16] basically, the .cpp and .h files are the implementation of your plugin, eg the loadable object code [16:16] the .xml.in describes information about your plugin for CCSM and also its options [16:16] and the CMakeLists.txt is the buildsystem [16:16] now, lucky for plugin authors, the buildsystem for compiz plugins is insanely easy [16:17] all you need is three lines [16:17] find_package (Compiz REQUIRED) [16:17] include (CompizPlugin) [16:17] compiz_plugin (moveleft PLUGINDEPS foo bar PKGDEPS baz) [16:17] so now on to what each line dos [16:17] *does [16:18] the first basically finds compiz with pkgconfig [16:18] the second imports all the plugin buildsystem [16:18] 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] so to disect that further [16:19] now that you've called your plugin "moveleft" you must stick with that shortname everywhere [16:19] so for example, the .xml.in must be named "moveleft" [16:19] However in the src/ tree, you don't need to worry about that [16:19] another interesting thing is that you can depend on other plugins [16:20] compiz 0.9 was designed in mind with inter-plugin dependency with each plugin providing objects to other plugins [16:20] so, a common example of this is the fact htat the opengl and composite bits of compiz are in fact plugins themselves [16:20] so most plugins that need to access this functionality will set those as their PLUGINDEPS [16:21] now on to the metadata file [16:21] I've explained this in more detail in the documents I linked to earlier [16:21] but basically, here you need to define your plugin name too [16:21] so [16:21] [16:22] the useBcop is crucial if you want your life to be easier with autogenerated options code [16:22] you can also define some options there [16:22] but we will get back to that later [16:22] so close all the tags and save it [16:22] next, you need to define the classes of your plugin [16:23] so the way things work in compiz is that each plugin is responsible for one or both of two things [16:23] 1) attaching their own information and hooks to existing objects [16:23] 2) creating their own objects [16:23] the vast majority of plugins only do 1) [16:23] and they usually hook two very important existing object [16:23] CompWindow and CompScreen [16:24] so, starting with the second [16:24] compiz runs per X-screen [16:24] so, this means that CompScreen is kind of like the "master class" where everything relating to everything going on on screen happens [16:24] CompWindow is a representation of some managed X11 window [16:25] (and believe me, there are a lot of them, see xwininfo -root -tree for how much there is to manage) [16:25] now each plugin works by attaching their own structures to those core objects [16:25] so if you defined a MoveLeftScreen as attaching to CompScreen [16:25] there would be one MoveLeftScreen per CompScreen [16:26] same thing with MoveLeftWindow [16:26] this allows you to store data and functions on those core structures [16:26] 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] so you would store that information in MoveLeftWindow [16:27] the actual attaching [16:27] ok [16:27] so the actual attaching is done by a special class called PluginClassHandler [16:27] it's basically a template class that sets up some special indexes in the base object and attaches your class to it [16:28] so that, whenever you want to get your own data for the base object, you just call MoveLeftWindow::get (CompWindow *) [16:28] so in constructing your MoveLeftWindow, you'll get something like: [16:28] class MoveLeftWindow : [16:28] public PluginClassHandler , [16:28] public WindowInterface [16:28] { [16:28] } [16:28] etc [16:28] (See the handout) [16:29] the WindowInterface is for interfacable functions and will be explained in a bi [16:29] so now that you've got your MoveLeftScreen and MoveLeftWindow defined as classes attaching to the relevant core structures [16:29] there are a few final things to do [16:29] the first is to define a VTable for your plugin [16:30] this tells core how to load and what "attaching classes" to initialize when objects are created [16:30] we have templates for the most common usecases [16:30] so, you'd have [16:30] class MoveLeftPluginVTable : [16:30] public CompPlugin::VTableForScreenAndWindow [16:31] { [16:31] public [16:31] bool init (); [16:31] } [16:31] the only thing yout need to put in your init function for now is a core ABI version check [16:31] eg [16:31] if (CompPlugin::checkPluginABI ("core", CORE_ABIVERSION)) return true; else return false; [16:32] and finally, a extern C object definition for core to look up the VTable on plugin load [16:32] and like all good things, we have a macro for that [16:33] COMPIZ_PLUGIN_20090315 (MoveLeftPluginVTable, moveleft); [16:33] note the use of "moveleft" again [16:33] that is *crucial* [16:33] since the library is going to be named "moveleft" and core will be loading a plugin called "moveleft" [16:33] so its going to be looking for the right symbol [16:33] As a quick aside, I've been asked to explain what CCSM is [16:34] in fact, I should probably explain some of the other compiz modules [16:34] so "compizconfig" == our library to handle configuration and desktop integration amongst different settings backends (eg ini, dconf, gconf, kconfig4) [16:35] "ccsm" == "compizconfig-settings-manager" which is a tool to adjust all the settings in compiz (seriously, there are tons) [16:35] "core" == the core executable of compiz, where the base window management logic and API comes from [16:35] ok, so back to plugins [16:36] once you have checked off implementing your MoveLeftScreen, MoveLeftWindow, MoveLeftPluginVTable, COMPIZ_PLUGIN_20090315 etc [16:36] and #included [16:36] you now have an installing plugin! [16:36] however, it doesn't really do all that much [16:36] so lets get on to something more interesting [16:37] what about being able to "plug-in" to things that core or other plugins do [16:37] ah, QUESTION: how can we make sure there isn't another plugin called "moveleft" [16:37] well, the simple answer to that is, you don't [16:37] 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] ok, back to being able to plugin-in to things [16:38] so, as I was saying a bit before, we have another special thing in compiz called "wrapable interfaces" [16:39] these are basically just call chains of function objects in doubly linked lists [16:40] 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] 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] this allows us to, on each core function call, call lots of other functions at the same time [16:41] So the first thing you would have seen in the MoveLeftWindow definition was that we inherited a class called "WindowInterface" [16:42] this is the "Interface class" to all of these Intefacable functions [16:42] so if you have a look in core/include/window.h, you will see all the functions that plugins can hook [16:42] by inheriting this class you are said to be "implementing" this interface [16:43] by default, the functions in WindowInterface all do nothing, but that is because they are all virtual! [16:43] so to change that, you overload one of the functions [16:43] for example, void moveNotify (int, int, bool); is a function that tells us when a window has moved and by how much [16:44] so if we implement a function like that in our MoveLeftWindow class which inherits WindowInterface, we will have implemented that [16:44] next, in the MoveLeftwindow constructor, we have a call to WindowInterface::setHandler (window); [16:45] what this does, is set the handler of the interface class that we inherited to the base class that owns the function [16:45] so that now whenever we call the base class function [16:45] our function will be called first [16:46] then functions from the previously loaded plugin [16:46] etc etc [16:46] until you get to the main function in the class [16:46] ok, another question! [16:46] QUESTION: so, can i write a separate MoveLeft function, embed in Window.h, and then call n override it whenever n wherever i want? === dholbach_ is now known as dholbach [16:47] 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] plugins should generally only overload the functions in the interface classes [16:48] anyways, interfaces are explained a bit more in the document I posted [16:48] next up: options [16:48] so say you've interfaced CompWindow::windowNotify from WindowInterface [16:48] so now whenever someone else calls window->windowNotify (), MoveLeftWindow::windowNotify is also called [16:49] 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] but now, you want to play with an option whereby it actually moves windows to the right instead of the left! [16:50] so you need to go back into your moveleft.xml.in and add some information about this option [16:50] so [16:51] that defines the option, with the default value of false [16:51] 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] ok, so now here is where it gets funky [16:52] that options code is owned by MoveLeftScreen [16:52] so you need to MoveLeftScreen *mls = MoveLeftScreen::get (screen) in your ::windowNotify [16:53] then, you want to read the option to see what it says [16:53] so for "right" that would be [16:53] mls->optionGetRight () [16:53] and it returns true or false depending on the option value [16:53] now, here is how the generation code works [16:53] first you have optionGet, which is prepended to call getters [16:54] then you have "Right" right came from "right" in the xml file [16:54] so the parser replaces underscores with CamelCase [16:54] so if you had right_foo [16:54] it would be come [16:54] optionGetRightFoo () [16:54] Ok, cool so now you've read the option [16:54] so with some simple math [16:54] and that skeleton [16:55] you should be able to make everything go to the left when a new window is mapped [16:55] or at your choosing [16:55] go to the right [16:55] I'll open the floor to questions [16:55] ok [16:55] 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] Good question [16:55] There are 5 minutes remaining in the current session. [16:55] so, compiz 0.9 was written independently, and has only been started to be used for unity until early this year [16:56] so it is still an upstream project [16:56] and as such I keep the API consistent between all version [16:56] there used to be an API inconsistency with the glib mainloop stuff, but that has been upstreamed [16:56] any other questions? [16:57] (I might just paste again those documents I'm referring to in case you missed them) [16:57] http://smspillaz.ucc.asn.au/unity/compiz_arch/compiz_arch.pdf [16:57] and [16:57] http://smspillaz.ucc.asn.au/unity/compiz_arch/writing.odt [16:57] QUESTION: What happened to the compiz mindcontrol? [16:57] I love it [16:58] 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] plus it requires shaving your head [16:58] which I would never do since I have awesome hair [16:58] any more questions before I wrap it up? [16:59] ok, well it is 16:59, I should probably wrap it up [16:59] thanks for attending! [16:59] now go write some awesome plugins! === RobertM is now known as Guest11535 [17:00] Hi folks, === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu Developer Week - Current Session: How Stable Release Updates work - Instructors: jibel [17:01] 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] Thanks to smspillaz for this awesome introduction to compiz. [17:01] my name is Jean-Baptiste Lallement, I live in France and I'm working on the QA Team. [17:02] 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] In this session we will talk about Stable Release Updates, and how the QA process contributes to rock solid stable releases. [17:03] Once an Ubuntu release is out, updates for it follow a very specific procedure called a "Stable Release Update" aka "SRU" [17:03] Updates are only released under certain circumstances. [17:04] Why this SRU process ? [17:05] Unlike development releases (at the moment Natty), official releases of Ubuntu are widely deployed and used by a wide variety of users. [17:05] 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] 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] Any problem can be really disruptive and the system should not requires the intervention of the user. [17:08] 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] Therefore, when updates are proposed, they must be accompanied by a strong rationale and present a low risk of regressions. [17:09] Some will argue "It's just a one line change, go ahead" [17:09] Right, let me give you one example, with bug 559822 and its friend bug 610975 [17:10] 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] It was not a one line change, it was a no change at all bug. [17:11] So people, when dealing with SRU, expect the unexpected. [17:12] When should you request a Stable Release Update ? === dholbach_ is now known as dholbach [17:12] Not all bugs are good candidates to Stable release updates, [17:13] and in general only those that fix high impact bugs are [17:13] examples of such bugs include: [17:14] * security vulnerabilities. These are done by the security team and follow a slightly different but somewhat similar process [17:14] * severe regressions from a previous release. [17:15] This includes packages which are unusable, like being uninstallable or crashing on startup. [17:15] * bugs which may cause data loss [17:15] bugs which doesn't fit under the above categories but have an obviously safe patch [17:16] and affect an application rather than critical infrastructure packages (like X or the Kernel) [17:17] * for Long Term Support (LTS) we regularly want to enable new hardware. [17:17] such changes are appropriate provided that we can ensure to not affect upgrades on existing hardware [17:17] And the last type of SRU [17:18] * New version of commercial software in the canonical partner archive [17:18] wolfpack asked: Is stable release update has only bug fixes or can it have features upgrade ? [17:19] SRU doesn't introduce new feature, or with rare exceptions. [17:20] For new features, or new upstream versions of packages, but don't fix critical bugs you should request a backport instead. [17:20] New features are usually not good candidates. [17:22] So How to proceed ? [17:22] 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] First of all, the bug must be fixed in the current development release [17:23] and the task in the bug report set to "Fix Released" [17:24] 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] If it is not fixed, in the development version, the request for SRU will be rejected. [17:26] 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] 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] We can accept an SRU for 10.04 but which is not necessarily a good candidate for 10.10 [17:29] 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] * 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] * 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] At this point, if you think that preparing the patch will be time consuming, [17:30] you should get approval from the SRU Team first. [17:31] On the other hand its useless to spend time on a patch that is not critical enough to match SRU criteria. [17:31] So, in doubt, don't hesitate to ping the SRU team [17:32] An important part, document the test case with detailed instructions how to reproduce the bug. [17:33] Document the test case with detailed instruction how to reproduce the bug [17:33] for example https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/639701 [17:33] includes 3 easy steps to reproduce the issue, and verify the fix. [17:34] 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] * Add information about potential regressions and inadvertent side effects. [17:35] 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] Once you've provided all the required documentation [17:35] * Target to the appropriate serie and subscribe ubuntu-sru [17:36] * Upload the fixed package. If you can not do it yourself, attach a debdiff and subscribe ubuntu-sponsor. [17:36] * If everything goes right, the archive admins will approve and publish you fixed package to the -proposed repository. [17:36] And please, keep this rule in mind: One bug = One report === drubin_ is now known as drubin [17:36] Then we enter in the second phase of the Stable Release Update: SRU Verification [17:36] The current set of pending SRUs is tracked at http://people.ubuntu.com/~ubuntu-archive/pending-sru.html [17:37] On this page, you'll find a list of packages currently in -proposed [17:37] and available for testing. [17:38] 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] The process we follow to verify a package is roughly: [17:38] - setup a testing environment [17:39] - Try to reproduce the issue in the most recent published version of the software [17:39] - Enable the -proposed repository and install the proposed update for that software [17:39] - Try to reproduce the issue with the updated software [17:40] The first step is to create a clean testing environment of the release the fix is targeted for. [17:40] We want to eliminate any outside effects and control the changes brought by the update of the package. [17:41] To create this environment any virtualization solution is good: KVM, VirtualBox, VMWare, ... are very useful to create an isolated testing environment [17:41] You can use snamshot to quickly setup a fresh env or rollback to a previous state. [17:42] Doing testing in a chroot is also good enough. [17:42] If you are trying to reproduce hardware related issues, then, of course, VM technologies are not the right choice. [17:42] Hardware specific bugs offer their own special problems; if we don't have the hardware, it's much harder to reproduce [17:42] 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] These are often kernel, X, libc (where the compiler is bounded to CPU capabilities) problems [17:43] 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] We want to do this so that we know what we're testing for when we install the proposed package. [17:44] 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] 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] 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] l'll illustrate the verification phase with bug https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/494096 [17:47] This is a critical usability defect. Clicking on a window send the events to the underneath window. [17:47] 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] The description is fairly complete, the issue is easy to understand and it includes a test case. [17:48] 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]