[08:53] امروز کلاس چه ساعتی شروع می‌شه؟ [13:00] Guys, our QA Classroom sessions starts 1 hour later. Make sure you join us through #ubuntu-classroom and #ubuntu-classroom-chat! [13:01] https://wiki.ubuntu.com/Testing/Activities/Classroom/Saucy [14:13] 17 minutes till the first classroom session begins! [14:22] Hi Phill [14:23] Yeah! [14:23] * smartboyhw does anticipate for his own session a week later. === 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 || Current Session: Introduction to QA / Testing: Overview of testing tools and areas - Instructors: balloons [14:30] Logs for this session will be available at http://irclogs.ubuntu.com/2013/06/24/%23ubuntu-classroom.html following the conclusion of the session. [14:31] Hello and welcome to the ubuntu quality team session. My name is Nicholas Skaggs and I'm the QA Community Coordinator. Thanks for attending (or reading this log later!)! [14:32] This is the first of many being held over the next few weeks serving as a introduction to the ubuntu quality community team [14:32] in this sessions I'll be giving a brief overview of what we do as a team and some of the ways to be involved. [14:33] This will be a high-level introduction with plenty of time for questions. So let's get started [14:33] You may ask questions at any point.. Just be sure to utilize the #ubuntu-classroom-chat channel. Prefix your question with QUESTION: to ensure I see it. [14:34] So first I'm going to give a brief overview of what QA is and how the team works, then I'll dive into the activities we do during the cycle. Along the way, we'll talk about the tools we use as well. Finally, we'll talk about how you can get involved and then do a Q & A. [14:34] So to start off, let’s take a look at the wiki page for the team [14:34] http://wiki.ubuntu.com/QATeam. On the page you can see some of the teams goals and purpose. Simply put, we help ensure everyone's work in ubuntu is presented in the best possible way [14:35] From designing good process, to testing, to making sure things 'just work', we want the culmination of work that results in the ubuntu image to be the best it can be [14:35] The ubuntu community site also has a page worth checking out on quality; re-iterating these goals and some team background [14:35] http://community.ubuntu.com/contribute/quality/ [14:36] So who are we and where do we hang out? [14:36] We're people from all over the physical world, and from many different aspects of ubuntu [14:37] I held a blog series recently snapshotting of few of the people who are on the team: http://www.theorangenotebook.com/search/label/peoplebehindquality [14:37] So where do we hang out? As you can imagine many different places. A quick list of where to find us: [14:37] right here on IRC, #ubuntu-quality [14:37] on our mailing list: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality [14:37] in the forums; http://ubuntuforums.org/forumdisplay.php?f=427 [14:37] on askubuntu; http://askubuntu.com/questions/tagged/quality [14:38] and even on social sites like facebook; https://www.facebook.com/groups/UbuntuQA/ [14:38] twitter; https://twitter.com/ubuntutesting [14:38] and google+; https://plus.google.com/b/108452779163647535106/108452779163647535106/ [14:39] christoffer asked: So this is not about how I can utilize launchpad (and other tools) for my own app development, is it more general about Ubuntu development? [14:39] christoffer, this is intended to server as an introduction to the quality team. you can see the full schedule we have planned here: https://wiki.ubuntu.com/Testing/Activities/Classroom [14:40] I'm not sure if there is a specific session that meets your needs or not. Most of the sessions come from a quality perspective not development. [14:40] Sorry that link should be: https://wiki.ubuntu.com/Testing/Activities/Classroom/Saucy [14:40] Ok, So, what do we do exactly as a team? [14:41] During the course of the cycle, we as a team participate by providing test results for the packages as they are undergoing development. If we find a bug, we'll also report and file it. [14:41] In addition, we develop testcases, best practices and even tools to help us test more effectively [14:42] We test different types of things and utilize some terms to describe them [14:42] The frst is cadence testing, https://wiki.ubuntu.com/Testing/Cadence. [14:42] Cadence testing is simply the term we use to describe that we test at regular intervals. [14:43] In practice, this amounts to us testing every ~2 weeks during the cycle -- we test images, packages and and hardware. [14:44] The second is smoke testing, or dogfooding as some would call it, the development version of ubuntu. This means simply installing or upgrading to the development release and using it as a regular machine. By attempting to work and perform tasks under the development version you may encounter a bug. Your unique usage of the development version of ubuntu represents a testcase in of itself and helps us achieve broad general coverage across a [14:44] variety of hardware and workflows [14:44] The third is a call for testing. This is a call to test a specific piece of software, with an accompanying set of tests and instructions for testing. [14:44] This call could happen at anytime throughout the cycle, and is utilized by developers to help ensure the software they are landing in the development version is ready for general consumption. [14:44] This type of testing is generally for a new package landig in the development version of ubuntu [14:45] So collecting the results and running these different types of tests requires us to have a tool to help [14:45] The tool we use is called the QATracker [14:45] https://wiki.ubuntu.com/Testing/QATracker [14:45] The tracker is where we submit the test results and get information needed to complete the test, such as the testcase and installation instructions. [14:46] There are actually several qatracker instances each geared towards testing different things [14:46] http://iso.qa.ubuntu.com is used to report results for image testing [14:46] http://packages.qa.ubuntu.com is used to report results for package testing [14:46] http://laptop.qa.ubuntu.com is used for laptop/hardware testing [14:46] Each one has a specific focus and keeps track of results and testcases in the specific domain we're testing [14:47] The wiki page I linked above gives more specific details on how the qatracker works and it's usage [14:47] smartboyhw asked: Why should people join Quality when there are other aspects of contributing to consider? (I know the answer, but not all people here do:)) [14:48] Joining the quality is a great way to get started with contributing to ubuntu. [14:49] you get to work with many different teams inside ubuntu and therefore get a taste of all the different areas. Quality is never the same from cycle to cycle; there's always new things to test and new ways to do it [14:50] There are 10 minutes remaining in the current session. [14:50] In addition, it covers a wide variety of skills. From very technical to writing to creativity [14:50] We'll talk more about the opportunities in a moment [14:50] هیشکی اینجا فارسی حرف نمیزنه ؟ [14:51] Are a technical person? Do you like to code? [14:51] or perhaps your just wanting to learn a little python? [14:51] You could consider writing some automated testcases using autopilot and contributing them to the ubuntu-autopilot-tests project [14:51] you could also work on some of the tools we use, such as testdrive; https://launchpad.net/testdrive [14:51] Perhaps you enjoy writing, or are skilled with explaining things step by step [14:51] we need your skills in our ubuntu-manual-tests project writing manual testcases! [14:51] Maybe you just like breaking things, or running bleeding edge software -- contributing test results is right up your alley! [14:51] Even if your not running ubuntu, but a flavor instead, we still need and welcome contributions in all of the above areas. We share many things like testcases and tools across the ubuntu family [14:52] smartboyhw, I hope that helps to answer your question :-) [14:52] smartboyhw asked: I accidentally stumbled upon http://desktop.qa.ubuntu.com/ . What's that for? [14:53] Well as you can see at one time that was used for testing the desktop -- specifically new unity features. Nowadays we simply utilize packages.qa.ubuntu.com for those sorts of tests [14:54] Ask any questions if you have them :-) Let me share with you the next steps for joining the team and being more involved [14:54] The steps for joining the team are quite simple. It's an open membership. You simply need a ubuntu SSO account [14:54] https://login.launchpad.net/+new_account, if you don't have one [14:54] That will allow you to contribute results to the tracker. In addition you should join our launchpad team and mailing list.. And then leave us a message and say hello! We're happy to help you get started and guide you through an area you'd like to help in [14:55] There are 5 minutes remaining in the current session. [14:55] You can consider contributing testcases, test results, or even some new artwork for our pages (we always need those with an eye for creativity ;-) ) [14:56] Here's the links to our launchpad team and mailing list [14:56] LP team: https://launchpad.net/~ubuntu-testing [14:56] mailing list: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality [14:56] jlking3_ asked: The process, when I look at it, seems overwhelming and intimidating. I'm afraid that I'll report something wrong or in the wrong place or in the wrong way. I don't want to make things worse for the developers. [14:59] jlking3, yikes! we're here to help you feel more comfortable about the process. You don't have to jump into the technical deep end of kernel debugging or some other exotic testing right away (or ever :-) ). Our tests are intended to be run by folks like yourself. We work together to share knowledge and help each other test and file bugs. You don't have to be an expert to participate === 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 || Current Session: Introduction to QA / Testing: Using md5 checksum and Zsync - Instructors: phillw [15:00] I don't know everything (surprise!). However collectively as a team we are able to help each other out and solve most problems [15:00] Logs for this session will be available at http://irclogs.ubuntu.com/2013/06/24/%23ubuntu-classroom.html following the conclusion of the session. [15:01] Hi everyone, my name is Phill. Whiteside and I'm the QA Team leader for lubuntu [15:01] This short session is to introduce zsync and md5sum [15:02] Firstly, why use zsync? [15:02] each iso image is quite large and as they usually get updated each 24 hours, that's a lot of data! [15:03] zsync only downloads the parts of the ISO that have changed, it is faster AND uses less bandwidth [15:03] Why use md5sum? [15:04] it is quite possible for a corruption to occur when downloading the ISO, if this happens your ISO will either not install, or exhibit very odd behaviour [15:05] the other nice thing about zsync is that when it has downloaded the update, it automatically checks the MD5 checksum for you (one less step to carry out). [15:07] You will see the zsync links if you go to the iso tracker and select the 'cd' icon to the left of the ISO you want to download at http://iso.qa.ubuntu.com/qatracker/milestones/270/builds [15:08] in my example, the alternate install for lubuntu in 1386 architecture would be zsync http://cdimage.ubuntu.com/lubuntu/daily/20130623/saucy-alternate-i386.iso.zsync [15:09] zsync can also be scripted up to do various tasks automatically. Further details on that can be found at https://wiki.ubuntu.com/Testing/Activities/Classroom/Saucy/Zsync [15:09] jlking3_ asked: so you always add .zsync to the end of the URL to get the zsync'd version of the iso? [15:11] jlking3: the tracker has several ways to down load an ISO (direct, rsync etc.) the filename ends .zsync to make it obvious that it is the zsync version [15:12] if you wish to manually check an ISO, move to the directory with the ISO in it and issue the command [15:12] md5sum *iso [15:13] this will give you the md5sum of the ISO's in the directory, which you can then check against what is on the iso-tracker, in my example, that would be http://cdimage.ubuntu.com/lubuntu/daily/20130623/MD5SUMS [15:14] Using zsync elliminates this step, as it does it for you. [15:15] That's the end of this introduction, if you have any questions, please feel free to ask (Preface them QUESTION: ) [15:17] Vasudevan asked: Which is a faster way to update daily isos over a slow home dsl connection - apt-get dist-upgrade or download zsync version? Thanks. [15:19] Vasudevan: if you are UPDATING a running install,. use apt-get update && apt-get upgrade. The dist-upgrade is to go from, say, 12.10 to 13.04. Zysnc will refresh (or create) and ISO already on your system. They have different uses depending on the circumstances. [15:19] jlking3_ asked: So you manually compare the MD5 checksums? [15:20] There are 10 minutes remaining in the current session. [15:21] Vasudevan: if you use zsync to update an ISO, it will automatically do the md5sum check for you. [15:22] sorry that was for jlking3 :) [15:24] QUESTION : Thnaks, in terms of download which is faster - apt-get upgrade or zsync - over dsl conn? [15:24] Vasudevan: I've never compared them, so cannot answer that, sorry. [15:25] There are 5 minutes remaining in the current session. [15:25] apt-get update & upgrade for use on an already installed system, zsync is to get the ISO to install a system. [15:28] Thanks everyone for attending and for the questions. Happy testing :D [15:29] The next session start at 21:00 UTC / GMT, and it's me up 1st :) [15:29] https://wiki.ubuntu.com/Testing/Activities/Classroom/Saucy/ [15:30] Logs for this session will be available at http://irclogs.ubuntu.com/2013/06/24/%23ubuntu-classroom.html === 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 || No Sessions Currently in Progress === H is now known as Guest46344 [20:49] کسی اینجا هست که فارسی بلد باشه و جواب من رو بده؟ === sebbu2 is now known as sebbu === ajmitch_ is now known as ajmitch === 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 || Current Session: An introduction to bug reporting - Instructors: phillw [21:00] Logs for this session will be available at http://irclogs.ubuntu.com/2013/06/24/%23ubuntu-classroom.html following the conclusion of the session. [21:00] Hi everyone, my name is Phill. Whiteside and I'm the QA Team leader for lubuntu [21:01] This session is to briefly outline two systems of bug reporting with the development releases [21:01] Firstly, why report a bug? [21:02] For the testers, Often we are using the latest, unmodified alpha code for various projects during the development release [21:02] do NOT assume someone else will report a bug! [21:03] Another important thing to remember is that Discussing a bug on IRC, email, forum or facebook areas etc. does not raise a bug. The devs do not monitor those areas [21:03] By all means use them to discuss a problem. Once your discussion about the bug is at a stage where you can report it, then for it to be actioned by the devs you must raise a bug. [21:03] When 12.04 came along, it had added in an extra system for automated reporting of crashes. [21:04] It is still being enhanced. [21:04] But, there were blog reports of 'Canonical spying on your system', this is untrue. [21:06] The system that runs is called whoopsie and reports to launchpad and if you 'say yes' also to errors.ubuntu.com [21:06] it keeps an eye on your /var/crash area and if it sees something arrive, it springs into action [21:07] Apport actually writes the crash file to /var/crash and if the release being run is the development release of Ubuntu, the .crash files is submitted to Launchpad [21:08] it also looks out for .crash files as well. (i.e. not generated by apport). [21:08] Whoopise is an ongoing and active project. Fuller details all about it can be found at https://wiki.ubuntu.com/ErrorTracker [21:09] For most of running test cases, we will still use apport (ubuntu-bug) [21:09] going onto launchpad and manually creating a bug often results in a bug report that can not be actioned owing to a lack of information. [21:09] the best way to prevent this is to use the ubuntu-bug command. [21:10] For bugs that happen at install time, it can be a bit difficult to work out what to raise the bug against. [21:10] To this end, for testing of ISO's a quick list can be found at https://wiki.ubuntu.com/QATeam/Overview/Install_Bugs [21:10] So, if the error occurred whilst trying to install an iso, you would issue the command ubuntu-bug ubiquity [21:11] if you are testing an application, e.g. GClac and it failed, you would issue the command ubuntu-bug gcalc [21:11] using ubuntu-bug ensures that as much information relevant to the bug is obtained and put onto the bug report. [21:11] Again, there is a full explanation at https://wiki.ubuntu.com/Bugs/FindRightPackage [21:11] If you are unsure on what package to allocate a bug against, please feel free to ask on #ubuntu-bugs and one of the people there will be more than happy to assist. [21:12] incomplete bugs do take time up which could be better spent actually dealing with bugs. [21:12] Brian will be holding a session immediately after this introduction to explain this further. [21:13] by the way, please do feel to ask Questions, but I will get as much covered as I can, which should leave ~ 10 mins at the end for a Q & A session [21:13] Within the quality team, we have a brief section on the basics of bug reporting as it affects quality. This can be found at https://wiki.ubuntu.com/QATeam/Overview#Bugs [21:14] That's the basics covered, last time I ran this, there were a couple of questions - which I will now cover. [21:15] My bug goes to Private, what does it mean? [21:15] Usually, when a bug is marked "Private" there's some good reason for it. With a lot of segfault (crash) bugs I see, a lot of them get marked as private, either because they contain information that *could* be private or could identify your system, or similar reasons [21:15] Typically, I see this with bugs which have core dumps or tracebacks which could contain information to identify someone: passwords, account numbers, etc. fall in the category of information that needs to be "removed" from the bug before it goes to a public view. [21:15] Those private bugs are therefore exactly what they are: hidden from the public eye until someone's gotten to it and actually looked through to see if there's anything that needs removal on those bugs, and then we usually make the bug visible after such things. [21:16] Also, The bot that goes looking for duplicated bugs does not worry if the bug it is using as master is private. If this happens please go to #ubuntu-bugs and raise it with them [21:16] What about reporting kernel bugs, could it be a duplicate? [21:17] For kernel bugs, *always* report a new one. It is difficult to say, a priori, if your affected system is *identical* with another in an already reported bug [21:18] There is a 3rd type of bug, in the test cases... This is to report an error in the test case (Typo, things out of order in the sequence etc). [21:18] on each test case, for example, http://iso.qa.ubuntu.com/qatracker/testcases/1301/info [21:19] it is not for reporting bugs found by using the test case, but only in the test case itself (these are written by humans, and we do make mistakes, even with over sight and proof reading :) ) [21:20] There are 10 minutes remaining in the current session. [21:20] That sums up all I have to say, Brian will be following. Please feel free to ask questions [21:25] There are 5 minutes remaining in the current session. [21:28] Well, thanks for attending. I hope it was of use to you.... I'm never sure if no questions means I've covered it all - or scared everyone away :) === 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 || Current Session: Filing and following up a good bug report - Instructors: bdmurray [21:30] Hi, I'm Brian Murray an ubuntu developer and leader of the Ubuntu Bug Squad. [21:30] Logs for this session will be available at http://irclogs.ubuntu.com/2013/06/24/%23ubuntu-classroom.html following the conclusion of the session. [21:31] I'd like to elaborate a bit more on what philw waid regarding reporting bugs. [21:31] ubuntu-bug is useful for reporting bugs about specific packages via the command 'ubuntu-bug' and the name of the package [21:32] However, sometimes you don't always know the name of the package. Like what is the name of the package for the "Software Updater". [21:33] In that case you can use "ubuntu-bug -w" and then a dialog will appear indicating that you should click on the window for the problem application [21:33] apport will then gather information about your system and the application to add to a new bug report [21:34] Its also possible to use apport with symptoms for example if you are having an issue with an USB disk drive. You can use 'ubuntu-bug storage'. [21:34] This will run through a series of tests to determine which package is the problem and then open a bug report about that package. [21:35] Additional symptoms live in /usr/share/apport/symptoms/ and include issues as vague as audio and display. [21:36] As you can see ubuntu-bug is a great help when reporting bugs, but is also a great help for us developers as detailed information about your system and specific information for the package is gathered. [21:37] However, having said that there is still one critical bit of information missing! Detailed steps to recreate the bug report. [21:37] When I say detailed steps I really mean a list like [21:37] 1) click on the file menu [21:37] 2) choose print [21:38] 3) click on this other thing [21:38] 4) watch it explode! [21:38] This makes it easy for us to follow the same steps with little confusion [21:38] Additionally, an important part of the bug life cycle is having a bug confirmed [21:39] this also allows another Ubuntu user to come along and see your bug and follow the same steps you did and if they get the same result, confirm the bug report [21:42] It also helps for us to know how often the problem occurs. Was it one in every ten attempts to scan something? [21:42] Or did it happen every single time? [21:44] I believe philw already mentioned this but is ususally best to open new bug reports rather than possibly adding additional issues to an existing bug report. [21:44] Having said that if you do find a bug that you think is about the same issue please mention it in the bug you are filing, either in the description or as an additional comment. [21:46] It is also important to know that every issue you may experience should be a separate bug report. We don't want to hear about your printer and your DVD drvie in the same issue as they are unlikely to be related or be fixed with the same change. [21:47] balloons asked: does that mean I can use ubuntu-bug and say something like ubuntu-bug display or ubuntu-bug graphics if I'm having graphical issues, and ubuntu-bug audio for audio issues, etc? [21:48] balloons: yes, you can use 'ubuntu-bug display' to help you file a bug about graphic issues and the same is true for audio issues. [21:48] It's pretty neat, feel free to give a try, just don't send the bug to Launchpad! [21:49] (There will be a final confirmation dialog where you can review the details of the bug report.) [21:49] Let's say we've filed bug 1192332 and want to see what other bugs there are reported about update-manager [21:50] https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1192332 [21:50] You can find them by clicking on update-manager (Ubuntu) in the "Affects" table [21:50] There are 10 minutes remaining in the current session. [21:50] Or by click on the word Bugs next to Code and Blueprints [21:51] Then you could review those new bug reports about the package and see if you can confirm them. [21:51] A bug can be confirmed when you can recreate the same issue. [21:52] You can confirm a bug by clicking the pencil next to "This bug affects you" [21:52] or by clicking the pencil next to the bugs status in the "Affects" table [21:53] You can learn more about confirming a bug here [21:53] http://www.youtube.com/watch?v=Vl-cQDAlPFc [21:53] Also keep in mind that bug reports can frequently be dialogs between developers and testers. [21:54] As such watch for additional requests for information or testing and reply promptly. [21:55] There are 5 minutes remaining in the current session. [21:56] Another part in the bug life cycle process is verifying that fixes actually work and as someone experiencing the issue you are in a good position to do that. As I understand it that will be covered in the next section. [21:56] balloons asked: is there a recommended way to filter bugs against a package that one might be interested in? for example, I see 1700 bugs for update-manager at the moment. [21:57] I'd generally use the search box. For example I was looking for configuration file prompts so I typed in 'conf file' in the dialog and clicked search and found some good results. [21:57] One can also filter on bug tags by clicking on advanced search [21:58] generally bugs are tagged with the release code name (e.g. saucy) so you could search for bugs affecting saucy [21:58] well really reported from saucy [21:58] any other questions? [21:58] I'm available in #ubuntu-bugs most of the time === 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 || Current Session: Verifying SRU updates - Instructors: chilicuil [22:00] Logs for this session will be available at http://irclogs.ubuntu.com/2013/06/24/%23ubuntu-classroom.html following the conclusion of the session. [22:00] my name is Javier Lopez http://wiki.ubuntu.com/~chilicuil [22:01] this session will be practical so prepare your lp id and terminal =) [22:01] I made some slides, you can fetch them from: http://people.ubuntu.com/~chilicuil/pdf/sru-updates.pdf [22:02] if you have any question at any point feel free to ask in the #ubuntu-classroom-chat channel and I'll be glad to answer them [22:02] so, to begin [22:03] a SRU is a proposed update which has already been accepted in the ubuntu dev version and now is trying to make its way to a stable release (precise, quantal or raring) [22:04] not every update is candidate for SRU, to become a SRU an update needs to: === 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 || Current Session: Verifying SRU updates - Instructors: chilicuil - Slides: http://is.gd/GFWXJ1 [22:04] * fix a severe regression [22:04] Slides for Verifying SRU updates: http://people.ubuntu.com/~chilicuil/pdf/sru-updates.pdf [22:04] Logs for this session will be available at http://irclogs.ubuntu.com/2013/06/24/%23ubuntu-classroom.html following the conclusion of the session. [22:04] * fix a program which loss user data [22:05] * be simple and safe [22:05] this page summarize all the details: https://wiki.ubuntu.com/StableReleaseUpdates [22:05] so why stable ubuntu versions have a different policy? [22:06] *stability* [22:06] in the past even one liner fixes have brought important issues, bugs #81125, #309674 and #559822 are some examples [22:07] so we're trying to ensure updates archived in -updates don't break everything =) [22:07] unfortunately, this policy has an issue [22:08] if no one actually test that a proposed update is good enough to get copied to stable releases, it could stay at -proposed starving for ever =( [22:08] a complete list of current -proposed updates can be found here: http://people.canonical.com/~ubuntu-archive/pending-sru.html [22:09] if you open the link, you'll see that there are updates for all stable releases, lucid, precise, quantal and raring [22:10] and once saucy get released, proposed updates will be visible there before any other place [22:10] blue and green updates are optimal to test [22:11] I'd like that we test a couple of them right now [22:13] you won't need many things, and it's relative easy to do [22:13] you'll require: [22:13] * any stable ubuntu release, I'll asume raring for this example [22:14] * a lp account [22:14] * optionally, pbuilder, virtualbox or a spare machine [22:15] there are chances that a proposed update could be really wrong and burn your machine, but tipically that's not the case [22:15] personally, I use pbuilder for testing cli applications and virtualbox for apps with a graphical interface [22:17] however, right now, I'll test directly on my main machine, since I've picked a safe update to test =P, and because I don't want to overcomplicate the example, learning pbuilder and virtualbox require a session for themselves [22:17] if you don't have a lp account you can create one in a couple of minutes: https://launchpad.net/+login [22:18] I'll wait here for those who don't have one =) [22:22] ok, I'll assume you've created a lp account, let's review some of the pending updates: http://people.canonical.com/~ubuntu-archive/pending-sru.html [22:22] as you can see, there are plenty of opportunities to help [22:23] for now I'd like that we could focus on software-properties, specifically bug #1047424 [22:23] https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1047424 [22:24] this report was opened to fix a problem with the additional drivers dialog [22:24] reports related to a sru are exceptional good, so it's generally easy to follow instructions [22:25] if they're not clear enough you can put a comment in the report and add the tag: 'verification-failed' [22:25] the 'test case' section is specially helpful so try to not overlook it [22:26] when a sru is requested, and it's accepted, members of the sru team, add the 'verification-needed' tag, our work as part of the QA team is to change those tags for 'verification-done' | 'verification-failed' depending of the result of our tests [22:26] before going further, I recommend to upgrade the system [22:26] $ sudo apt-get update && sudo apt-get upgrade [22:27] even if you use pbuilder or virtualbox, is generally a good idea to make sure we have the latest updates before testing any SRU [22:28] I'll give a couple of minutes for those who want to follow the live SRU testing session and need to update their machines [22:29] in the meantime, I'll talk more about the SRU reports [22:30] when you open a SRU report, you'll usually see these sections: [Impact], [Test case], [Regression potential], [Original description] [22:31] the Impact section refers to the main problem, why this SRU should be introduced to stable releases [22:33] the [Test case] sections usually have instructions step by step to reproduce the bug, it's a mandatory section, so you can be feel safe to find clear instructions [22:34] the [Regresssion potential] section list some issues who could appear after adding this update, the less the better [22:35] finally the [original section], well, it has the original post for reference [22:36] now, I'll asume we had enought time to update our systems, so we can look at the report #1047424 and see how if we can reproduce the bug [22:37] so the bug refers to a incorrect dialog after installing any driver using the software properties application [22:38] we'll launch the application by typing 'drivers' at the dash and selecting 'Software & Updates' [22:39] after opening it, we can click the latest tab 'Additional Drivers' and install or remove a driver, let's do it [22:40] you don't need to worry, we won't reboot our systems, so if you don't have a driver to install, remove one, we'll reinstall it before leaving the session [22:41] after selecting one driver we can press 'Apply changes', this will triage the installation|uninstalling process [22:41] after doing it, you'll see a 'Restart ...' button [22:42] a dialog asking for confirmation will appear, and it'll only have 'cancel' and 'shutdown' as options, that's the bug! [22:42] instead of asking for shutting down the system, it should ask for rebooting [22:42] so, we've confirmed the issue [22:43] so, once we've seen the bug, we'll apply the -proposed update [22:43] detailed instructions are here: https://wiki.ubuntu.com/Testing/EnableProposed [22:44] the fastest to do it IMO is to modify /etc/apt/sources.list [22:44] so, if you don't feel like reading the wiki right now, you can trust me and run: [22:44] $ echo 'deb http://mx.archive.ubuntu.com/ubuntu/ raring-proposed main restricted multiverse universe' | sudo tee /etc/apt/sources.list.d/proposed.list [22:45] that command will create a file in /etc/apt/sources.list.d/proposed.list with the following 'deb http://mx.archive.ubuntu.com/ubuntu/ raring-proposed main restricted multiverse universe' [22:46] apt uses those files to know from where to pull software [22:46] after adding the proposed repository the system needs to update the index and apply the updates [22:46] $ sudo apt-get update && sudo apt-get install software-properties-gtk [22:47] those commands will download the new index and after that will update the software-properties-gtk program, sudo apt-get install can install or update (if the package is already installed) [22:48] after completing the last step, it's time to retry the dialog [22:49] close the 'Software & Updates' [22:49] program [22:49] and then open it again, go the driver tab and renable the uninstalled driver [22:50] There are 10 minutes remaining in the current session. [22:50] one hint to know that you applied correctly the update is that after executing sudo apt-get install software-properties-gtk you should see your computer downloading a package from -proposed [22:51] if you don't see it, something went wrong, and you should review your /etc/apt/sources.list.d/proposed.list file [22:52] so, once you've applied the proposed update, you need to follow the test case steps and ensure the issue has gone [22:53] if you are following this example, you should see that after applying the driver installation and selecting the 'Restart...' button you'll see this time a dialog with two buttons, 'cancel' and 'reboot' [22:53] the -proposed update works! [22:54] that's it, that's exactly what SRU testing is about [22:54] so, once we've tested and confirm that the proposed update fixes the reported issue, we can add comments, those who completed the sru testing, please do so [22:55] There are 5 minutes remaining in the current session. [22:55] something like, 'the proposed update work in Ubuntu raring amd64' should be enough [22:55] and don't forget to add the appropiate tag, in this case, 'verification-done' [22:57] after completing all these steps a member of the SRU team will review the report and probably will copy the -proposed update to -update, after that, a lot of people will improve its Ubuntu experience [22:58] if have any problem while doing SRU testing feel free to ping me, or to join #ubuntu-quality [22:58] if you* [22:58] I think that's all, any question? [22:59] thanks Skini151, you rock! [23:00] Logs for this session will be available at http://irclogs.ubuntu.com/2013/06/24/%23ubuntu-classroom.html === 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 || No Sessions Currently in Progress