[15:52] <Ape3000> Thank you
[15:53] <Bodom> hiho
[15:53] <Ape3000> Nah.. Maybe it's better if random users can't spam here?
[15:53] <Bodom> do you mean me?
[15:53] <intellectronica> hi Bodom
[15:53] <Ape3000> I mean generally
[15:53] <Ape3000> The users should use the #ubuntu-classroom-chat, so why do they have to have voice in here?
[15:55] <dholbach> Ape3000: no worries, it'll quieten down soon
[15:55] <a7p> Ape3000: for the sake of volantary disciplin
[15:55] <a7p> works astonishingly well ;)
[15:55] <Myrtti> Ape3000: the channel will be most probably set +m soon
[15:55] <Ape3000> There is good sides with -m, too
[15:56] <dholbach> it worked fine without it yesterday
[15:56] <dholbach> and the other developer weeks before :)
[15:56] <Ape3000> Yeah..
[15:56] <Ape3000> We can do: /me applauses
[15:56] <dholbach> :)
[15:57] <dholbach> OK my friends... who's here for Day 2 of the Week of Awesome?
[15:57] <dholbach> Who's excited? :-)
[15:57] <zerwas> me :D
[15:57] <Chris`> Me :o
[15:57] <MarkoKaa> o/
[15:57] <Chris`> ö
[15:58] <dholbach> is that everybody? or is the rest of the 172 people in here so shy? :-)
[15:58] <dholbach> Welcome everybody to Day 2 of the Ubuntu Developer Week
[15:58] <Ape3000> intellectronica?
[15:58] <intellectronica> i'm not shy ;)
[15:58] <cool2k> yeah!!!!!
[15:58] <dholbach> The schedule is up here https://wiki.ubuntu.com/UbuntuDeveloperWeek
[15:58] <Riddell> woo
[15:58] <sianis> date -u
[15:59] <sianis> use it :P
[15:59] <dholbach> and we have Tom Berger, Mr intellectronica here who will talk to us about "Launchpad Bug Tracking"
[15:59] <pedro_> rock and roll!
[15:59] <dholbach> if you have questions, PLEASE ASK
[15:59] <dholbach> but PLEASE ask in #ubuntu-classroom-chat
[15:59] <dholbach> and prefix your questions with   QUESTION:
[15:59] <dholbach> ie. QUESTION: Tom, what is your favourite colour?
[15:59] <dholbach> ALRIGHT
[15:59] <intellectronica> hi everone
[15:59] <dholbach> have a great Day 2 everybody, hope you enjoy it!
[16:00] <dholbach> intellectronica: the stage is yours :-)
[16:00] <intellectronica> thanks dholbach. hugs aplenty
[16:00] <dholbach> :-)
[16:00] <intellectronica> so, we gathered here today to celebrate an historic event :)
[16:00] <intellectronica> thanks to everyone who joined despite the obvious competition
[16:01] <intellectronica> i'd like to introduce you to, and mainly answer your questions about, Malone, the Launchpad bug tracker
[16:01] <intellectronica> (which I am taking part in developing)
[16:01] <intellectronica> and which is the bug tracker ubuntu uses
[16:02] <intellectronica> i haven't prepared much in advance, since i don't know what's the level of familiarity you guys already have with LP
[16:02] <slavik> how does it compare with bugzilla from the administration and setting up side?
[16:02] <intellectronica> so let's start with a survey (you can answer here). on a scale of 1-10, how familiar are you guys with Malone
[16:02] <intellectronica> ?
[16:02] <slavik> 0 :(
[16:02] <Chris`> 1
[16:02] <addc182> 0
[16:02] <schmiedc> 1
[16:02] <Ape3000> 7
[16:03] <creek23> 1
[16:03] <Riddell> 8
[16:03] <ccm> 5 i guess
[16:03] <zerwas> 1
[16:03] <sianis> 5
[16:03] <porthose> 0
[16:03] <cool2k> 1
[16:03] <thekorn> 7.99
[16:03] <dholbach> 8
[16:03] <theseas> 0
[16:03] <toobuntu_> 0
[16:03] <intellectronica> thekorn: give me a break, you're more like 11 :)
[16:03] <TheEnd2012> 0
[16:04] <slavik> intellectronica: you're 11, we're all lowly -1 :(
[16:04] <thekorn> intellectronica, hehe ;)
[16:04] <intellectronica> slavik: the obvious difference is that Launchpad is a hosted service. there's no set up at all for the users
[16:05] <intellectronica> unlike bugzilla, which you have to install on a server and administrate, launchpad runs off launchpad.net and the launchpad team takes care to maintain it
[16:05] <intellectronica> so the only setup procedure you might have, is registering a new project you might want to track. that's quite simple to do
[16:06] <intellectronica> and for your use of LP as a bug tracker for ubuntu, there's absolutely no setup you need to do. just create an account and start messing with bugs
[16:06] <slavik> intellectronica: I see. Can Launchpad authenticate against LDAP/AD?
[16:07] <dholbach> slavik: can you please ask questions in #ubuntu-classroom-chat?
[16:07] <Chris`> slavik: Just a note, we've been asked to prefix our questions in #ubuntu-classroom-chat with "QUESTION: Question to person?" there
[16:07] <intellectronica> slavik: no. launchpad provides its own authentication system, which can also be used as an Open ID provider, and is widely used across the ubuntu landscape
[16:08] <intellectronica> Ape3000 is asking whether LP is available for private installations. the answer not yet. LP will become free software this summer, at which point you'll be able to install it anywhere (and modify it and help developing it)
[16:08] <intellectronica> but we very strongly believe that a lot of the value you get from Launchpad comes from it being a central hub in the middle of the free software ecosystem
[16:09] <intellectronica> the ability to track and and connect bugs from ubuntu, as well as many other projects, using the same site, makes launchpad.net a very powerful tool
[16:09] <intellectronica> one example of that, which we will look at shortly, is the ability to connect bugs in ubuntu to bugs upstream projects
[16:10] <intellectronica> slavik asks what tools and languages are used for the development of LP
[16:11] <intellectronica> LP is written in Python and uses Zope3 as its main web framework, Postgres as a database, Storm (the canonical-developed ORM) as a data layer and lots of other goodies
[16:12] <intellectronica> you can also access launchpad using a public web service API which uses the REST protocol, from any language. we provide a python library which helps you use that service (more about that later today, when Leonard Richardson will present the API and library right here)
[16:13] <intellectronica> and yes, Launchpad, obviously, runs on Ubuntu :)
[16:13] <intellectronica> let's get on with some action!
[16:14] <intellectronica> https://bugs.launchpad.net/ubuntu is the top level page in LP for ubuntu bugs
[16:14] <intellectronica> it gives you an overview, and allows you to run simple searches for bugs
[16:15] <intellectronica> for example, just type some (plausible) text into the text box and hit [Search] to get a bug listing
[16:16] <intellectronica> for all the following examples i will use staging.launchpad.net
[16:17] <intellectronica> staging.launchpad.net is a server we keep for testing and experimenting with LP. it has a copy of the launchpad database that is being restored daily
[16:17] <intellectronica> IMPORTANT: please use the staging for trying out anything that changes the data (like creating new bugs, adding bogus comments, etc)
[16:17] <intellectronica> that way you'll know that you can experiment freely without polluting LP itself with bad data
[16:18] <intellectronica> likewise, remember that any changes you make on the staging server will be wiped out. do not use it for real work
[16:19] <intellectronica> Chris` is asking whether data from staging will be wiped out after posting. the answer is yes - it is being wiped out daily, so you've got anything from a few minutes to whole day to still work with this data
[16:20] <intellectronica> so, you all see what a bug listing in LP looks like
[16:21] <intellectronica> you can choose a new sort order and search again
[16:21] <intellectronica> or, if you need a more complex search, you can click _Advanced search_
[16:21] <intellectronica> let's do just that
[16:22] <intellectronica> i'm looking at https://bugs.launchpad.net/ubuntu/+bugs?advanced=1
[16:23] <intellectronica> the status and importance sections are obvious, i think. they will select any _inclusive_ combination of the values you tick
[16:24] <intellectronica> the people section allows you to select bugs that are related to certain people. for example, you might want to look only at bugs reported by someone, or assigned to someone, and so on
[16:25] <intellectronica> using the series and component section, you can filter so that only bugs specific to a series or a component within the distribution are selected. this is particularly relevant to you folks working with ubuntu, because as you might have noticed, dealing with all the bugs for ubuntu is pretty much impossible
[16:26] <intellectronica> the upstream status section is very useful when you try to get bugs found in ubuntu and see how they are connected to the upstream projects where they originated
[16:27] <intellectronica> this is, i think an especially important concept, so let's try and talk about it a bit more
[16:28] <intellectronica> many bugs that are found it ubuntu, are actually bugs that originated in some upstream project which is being distributed as part of ubuntu
[16:28] <intellectronica> reporting it in ubuntu itself is a great first step, but it's usually not enough. we have to make sure that the upstream project knows about it, if we hope to get it fixed one day
[16:29] <intellectronica> any questions so far?
[16:30] <intellectronica> Chris` is asking what is edge.launchpad.net and how it differs from staging
[16:31] <intellectronica> edge is a launchpad server which uses the _real_ data, just like launchpad.net
[16:31] <intellectronica> it is available to LP beta testers (which you are all very welcome to join - it's fun and gives you an opportunity to help and influence LP development)
[16:32] <intellectronica> launchpad is released monthly with new features and bug fixes to launchpad.net
[16:32] <intellectronica> on edge, these changes are released as soon as they are available
[16:33] <intellectronica> so, you can 'live on the edge' and use a constantly changing version of launchpad - giving you a chance to test (and comment on) the latest features, or you can use launchpad.net and get a very stable version that gets updated once a month
[16:34] <intellectronica> shankhs is asking whether it is the responsibility of upstream devs to look for bugs in ubuntu that may be related to their project, or the responsibility of ubuntu devs
[16:35] <intellectronica> the answer is that the relationship is collaborative, and anyone can deal with this, but you must remember that upstream devs have many things to deal with, and many other distributions. we can't expect them to always follow ubuntu
[16:35] <intellectronica> which is why we try to make it very easy for people to forward bugs upstream
[16:36] <intellectronica> let's look at https://bugs.staging.launchpad.net/ubuntu/+source/pidgin/+bug/162701
[16:37] <intellectronica> notice anything special about this bug?
[16:38] <intellectronica> this bug might look like it's affecting two packages, but that isn't really the case
[16:38] <intellectronica> we can see that it's affected the pidgin package in ubuntu
[16:38] <intellectronica> but above it, we see that it also affects PulseAudio, which is an upstream project, not part of ubuntu
[16:39] <intellectronica> this is a good example of how LP can represent the link between ubuntu and upstream projects
[16:40] <intellectronica> if you click the _Also affectes project_ link, you can mark a bug as affecting other projects
[16:40] <intellectronica> come on, give it a try (on STAGING)
[16:41] <intellectronica> if you clicked, you can see that the pidgin package is already associated with the pidgin upstream project. we sometimes know this in advance, which can help you
[16:42] <intellectronica> it also tells you that pidgin tracks its bug outside of launchpad, using Trac, and gives you the url to the trac server it uses
[16:43] <intellectronica> if you manage to find a relevant bug in trac, you can paste the url into the first box - launchpad will follow that bug on your behalf and update the status
[16:43] <intellectronica> launchpad can do this for many bug trackers: Trac, Bugzilla, Sourceforge (and some of its derivatives), Roundup, etc'...
[16:44] <intellectronica> for Trac and Bugzilla, we provide a plug in which makes the communication with Launchpad especially efficient, and allows the bug trackers to exchange comments too (but it's the responsibility of the upstream project to install that plugin)
[16:45] <intellectronica> ah, i can see that many of you experimented with creating new tasks for that bug, linking it to other projects, distros and packages. you guys are quick learners! :)
[16:46] <intellectronica> if you click the status of one of the lines that show the bug reported in an upstream project, you'll see that it's different from normal launchpad bugs
[16:47] <intellectronica> that's the stuff pertaining to bug watches, the mechanism LP uses for tracking bugs in external bug trackers
[16:48] <intellectronica> shall we quickly look at reporting a bug? we're rapidly running out of time, so in parallel, please go ahead and ask questions if you have any
[16:49] <intellectronica> i'm looking at https://bugs.staging.launchpad.net/ubuntu/+filebug
[16:49] <intellectronica> this is the start of the bug filing process, but it's way too general. it is very rare that you'll want to file a bug about ubuntu as a whole. it's almost always the case that a specific package would be more appropriate
[16:51] <intellectronica> you can always start from something like https://bugs.staging.launchpad.net/ubuntu/+source/pidgin/+filebug and report the bug directly on the package
[16:52] <intellectronica> notice how slow the staging server is, b.t.w :)   obviously, it doesn't have the same amount of resources as the real launchpad servers
[16:53] <intellectronica> after i enter a bug description, LP tries to find similar bug descriptions, so that i don't unnecessarily report a bug that's already reported
[16:53] <intellectronica> if i don't identify the bug in the list of similar bugs, i can click 'No, i'd lke to report a new bug' and the details are shown
[16:54] <intellectronica> first, we're asked in what package the bug was found. it is really important to try and find out. otherwise, the ubuntu qa and development teams will have a very hard time dealing with it
[16:55] <intellectronica> you can also look at the instructions at the bottom of the page for what to do and not to do
[16:56] <intellectronica> you can include an attachment - perhaps some data for helping diagnose the problem
[16:57] <intellectronica> if you suspect that the bug is a security vulnerability, it's important that you indicate that using the checkbox. the bug will become private until further notice and will be treated more urgently in many cases
[16:57] <intellectronica> ongolaBoy is asking about the different bug statuses
[16:57] <intellectronica> New: the bug has just been reported
[16:58] <intellectronica> Incomplete: more information is needed for people to be able to work on the bug. the reporter, or other people, should add more information in comments
[16:58] <intellectronica> Invalid: actually, this bug isn't relevant, or is not really a bug. you can ignore it
[16:59] <intellectronica> Won't Fix: this bug will not be fixed. maybe it's impossible to fix it...
[16:59] <intellectronica> Confirmed: not used by ubuntu, but in some other projects it means that someone managed to reproduce the bug
[17:00] <intellectronica> Triaged: the relevant team has looked at the bug and decided what to do with it, what importance to give it, etc
[17:00] <intellectronica> In Progress: the bug is being worked on
[17:00] <intellectronica> Fix Commited: the fix is ready and commited to the source tree
[17:00] <intellectronica> Fix released: the latest version of the software no longer has the bug
[17:01] <intellectronica> i see that we're running out of time. of course, i managed to cover about 10% of what i wanted to :-/
[17:01] <intellectronica> but let's take more questions before i'm being kicked out
[17:02] <intellectronica> and of course, i hang out in #launchpad all the time, and you are all very welcome to drop by, ask me or any of the other devs questions and enjoy the view
[17:03] <intellectronica> Ape3000 is asking what my favourite colour. black, at least for today
[17:03] <intellectronica> shankhs: is asking about patches and fixing bugs
[17:04] <intellectronica> when you upload an attachment to launchpad, you can mark it as a patch
[17:04] <intellectronica> it is later easy to search for patches (you may have noticed it in the bug search form)
[17:05] <intellectronica> if a project uses launchpad for code hosting, you can use bazaar for making fixes, which is really cool. there's a session on that later this week
[17:05] <intellectronica> oright, i think it's time for ara to start her show
[17:06] <intellectronica> thanks everyone, and please, do feel free to continue asking questions on #launchpad
[17:06] <intellectronica> --------------------------------------------
[17:07] <dholbach> next up is Ara Pulido who will talk about QA Tools!
[17:07] <dholbach> let's hear a round of applause! :)
[17:07] <Arc> *cheers*
[17:07] <Bodom> *applause*
[17:07] <kranichTheII> *applause*
[17:07] <jpds> \o/ ara \o/
[17:07] <B_a_l_a_k> *applause*
[17:08] <theseas> *applause*
[17:08] <porthose> *applause*
[17:08] <ara> ok, enough, I am not Madonna
[17:08] <ara> Thanks all for coming and the warm welcome ;-)
[17:09] <ara> Questions in #ubuntu-classroom-chat, please
[17:09] <ara> My name is Ara and I am part of the Ubuntu QA Team (https://wiki.ubuntu.com/QATeam/)
[17:09] <ara>  Do you guys know what are the duties of the QA team?
[17:09] <kranichTheII> Quality Assurance ?
[17:10] <Arc> making sure the devs don't seriously break something for every Ubuntu user with an update
[17:11] <ara> yes, yes, it is Quality Assurance, and yes we have to try to make sure that devs don't break many things (something always break...)
[17:11] <ara> But the two most important duties are Triaging (https://wiki.ubuntu.com/BugSquad) and Testing (https://wiki.ubuntu.com/Testing).
[17:12] <ara> triaging bugs is about making bugs report better, or ask for more information, or provide better information, etc. so the devs can start working on them
[17:12] <ara> and testing gives a try to Ubuntu before it reaches the wider public
[17:13] <ara> both the buqsquad team, and the testing team are open to new contributors ;-)
[17:13] <ara> To perform our daily activities we have a set of tools to make the process easier and automate some of these tasks.
[17:14] <ara> To be able to try some of the tools that I am going to present, you will need to have installed 'bzr' in your computers. If you don't have it, you can install it easly:
[17:15] <ara> $ sudo apt-get install bzr
[17:15] <ara> all set?
[17:15] <kranichTheII> jup
[17:15] <ara> Let's start grabbing the LP project (https://code.edge.launchpad.net/ubuntu-qa-tools) that contains several QA tools.
[17:16] <ara> shankhs: complains that bzr doesnt support proxy and aythentication ... :(
[17:17] <ara> shankhs: I am not a bzr expert, but I am sure there must be some workaround there
[17:17] <ara> The trunk is the branch that it is better maintained, get the source using bzr:
[17:17] <ara> $ bzr branch lp:ubuntu-qa-tools
[17:18] <ara> The first set of scripts that we are going to visit are those that parse the bug mailing list. Those scripts are available in the newly created folder ./ubuntu-qa-tools/bug-mailinglist/
[17:18] <ara> all of these scripts are python scripts. be sure to have python on your machines
[17:19] <ara> The mailing list that receive every bugmail generated in Ubuntu has a copy at http://people.ubuntu.com/~listarchive/ubuntu-bugs/
[17:20] <ara> To use the bug-mailinglist scripts you have to grab a copy of one of the available archives and save it locally.
[17:20] <ara> this files are too big, for testing purposes you can just trim one of them
[17:20] <ara> The first script, triager-query.py queries the mailing list archive for actions performed by a specific bug triager.
[17:21] <ara> actions like "add tag", "set as incomplete", "set as triaged", etc
[17:21] <ara> syntax go as
[17:21] <ara> python triager-query.py [email] [file]
[17:22] <ara> example:
[17:22] <ara> python triager-query.py sinzui.is@verizon.net ../test_bugs_mailing_list.txt
[17:22] <ara> From sinzui.is@verizon.net: 1
[17:22] <ara> sinzui.is@verizon.net triaged: 1
[17:22] <ara> this is the output of a trim of the January archive
[17:22] <ara> why this information is useful?
[17:23] <ara> As you might know, triagers in Ubuntu are divided in two teams. The bug-squad team is open to anyone, but to enter the bug-control team you have to be an experienced triager
[17:23] <ara> because bug-control members have access to potentially sensitive data
[17:24] <ara> If you're part of the bug-control team, one of your duties is to review new membership applications to the team
[17:24] <ara> count-senders.py parses the mailing list archive and returns the quantity of messages sent by individuals. This includes any activity in the bugs.
[17:24] <ara> python count-senders.py [email] [file]
[17:24] <ara> body-searching.py searches the mailing list archive for a user defined string, sys.argv[1], and returns bug numbers containing that string.
[17:24] <ara> python body-searching.py [string] [file]
[17:25] <ara> tagged-bugs.py searches the mailing list for tags, and creates a HTML report with the date the tag was added to the bug
[17:25] <ara> python tagged-bugs.py [tag] [file]
[17:25] <ara> all this information can be retrieve directly through Launchpad, of course, but if you have to do it daily, it is much easier to use the scripts
[17:25] <ara> and faster
[17:26] <ara> not saying that the launchpad web interface is slow... (in case some of the LP is watching...
[17:27] <furicle> ls
[17:27] <ara> any questions about the bugs-mailinglist scripts? If not I am going to move to a script to help testers
[17:28] <ara> bullgard4:  QUESTION: ':~$ python triager-query.py; python: can't open file 'triager-query.py': [Errno 2] No such file or directory'. What went wrong?
[17:29] <ara> bullgard4: did you move to the right folder? once you branch you have to move to ubuntu-qa-tools/bugs-mailinglist
[17:30] <ara> Let's move now to another tool, the dl-ubuntu-test-iso, a script that will help you keeping your testing images ISO up to date.
[17:30] <ara> have you ever helped with ISO images testing?
[17:32] <ara> then start now! ;-) https://wiki.ubuntu.com/Testing/ISO/
[17:32] <ara> each milestone released (alpha-1, alpha-2, point releases, etc.) need some ISO verification
[17:33] <ara> to avoid having to download every single iso each time you can have them synced
[17:33] <ara> dl-ubuntu-test-iso is based on rsync and can be configured to download only the necessary images.
[17:34] <ara> shankhs: and it is not a python script. it is bash scripting ;-)
[17:34] <ara> To configure the tool you need to save your configuration file as ~/iso/iso.cfg. You can see an example here: http://people.ubuntu.com/~ara/udw/qatools/iso.cfg
[17:35] <ara> In the example configuration file we have set to download jaunty release, only for i386 architectures, and alternate, desktop and server.
[17:35] <ara> Once you have set up the configuration file, and running ./dl-ubuntu-test-iso, the images will start to be download to the ~/iso folder.
[17:36] <ara> Please, take into account that by default all the images are download, so if you do not have a configuration file, you will download every possible image.
[17:37] <ara> If you run the script daily (or weekly), you will need to download only the changes between both images
[17:37] <ara> saving you time
[17:37] <ara> and bandwidth for your movies and music ;-)
[17:38] <ara> If you want to start helping with Ubuntu, ISO testing is a great way to start. and really, really helpful
[17:38] <ara> And now that we are talking about the dl-ubuntu-test-iso script to test ISO images, do you know the ISO tracker?
[17:39] <ara> The ISO tracker is a web application that we, at the QA team, use to track the testing of the ISO images. It is located at http://iso.qa.ubuntu.com/ and it is updated with the ISO images that we should be focusing in (right now the focus is taking by Hardy's point release).
[17:40] <ara> It is really helpful to create an account in the ISO tracker (if you have an account in the Brainstorm site, that one would work in the ISO tracker site as well) and submit your testing results.
[17:41] <ara> On the menu on the left, you can select the flavour that you're testing. Let's select Ubuntu flavour.
[17:41] <ara> Then you have to click on the ISO image that you're testing. Let's say that we are going to test Alternate i386 (the installer that does not have a Live session)
[17:42] <ara> When you click in one of the options, a list of testcases will appear, and a link to the ISO image, in case you haven't downloaded yet.
[17:42] <ara> Nice and easy
[17:43] <ara> In the list of testcases you can see what it is outstanding and have your pick taking that into account. Click on the chosen testcase to read it and submit your results.
[17:43] <ara> Any questions about the ISO testing site or ISO testing in general? (before I move back to bug triaging)
[17:44] <ara> bullgard4:  QUESTION: What is 'Hardy's point release'?
[17:45] <ara> bullgard4: Hardy (Ubuntu 8.04) is a LTS release (Long Term Support)
[17:46] <ara> bullgard4: we realease "point release" 8.04, 8.04.1, 8.04.2... that contain the latests updates already in the ISO images
[17:47] <ara> let's move to some useful reports that will make triagers life easier. When triaging bugs is useful to have access to some important information through the reports. Here's a list of some of them:
[17:47] <ara> Yesterday bugs: http://qa.ubuntu.com/reports/bugnumbers/yesterday.html
[17:47] <ara> Bugs reported yesterday. Useful to Invalid, Mark as Duplicate or request more information.
[17:48] <ara> With more duplicated bugs: http://qa.ubuntu.com/reports/launchpad-database/bugs-with-most-duplicates.html
[17:48] <ara> this is really useful when you're reading a bug that you "feel" "sure, this has been reported before"
[17:50] <ara> 25 oldest bug task that are <put here>:
[17:50] <ara> new: http://qa.ubuntu.com/reports/launchpad-database/oldest-new-ubuntu-bug-tasks.html
[17:50] <ara> Incomplete http://qa.ubuntu.com/reports/launchpad-database/oldest-incomplete-ubuntu-bug-tasks.html
[17:50] <ara> Confirmed http://qa.ubuntu.com/reports/launchpad-database/oldest-confirmed-ubuntu-bug-tasks.html
[17:50] <ara> Triaged http://qa.ubuntu.com/reports/launchpad-database/oldest-triaged-ubuntu-bug-tasks.html
[17:50] <ara> Progress http://qa.ubuntu.com/reports/launchpad-database/oldest-in-progress-ubuntu-bug-tasks.html
[17:50] <ara> Fix Committed http://qa.ubuntu.com/reports/launchpad-database/oldest-fix-committed-ubuntu-bug-tasks.html
[17:51] <ara> Helpful if you want to clean Launchpad from obsolete bugs
[17:51] <ara> The newest addition to the list, just announced a week ago, is the team assigned reports. As you might know, Canonical gives support to the packages in main, therefore, it is useful to have a list of the tasks assigned to one of this teams. The format of the URL of these reports is
[17:51] <ara> http://qa.ubuntu.com/reports/team-assigned/canonical-<team>-assigned-bug-tasks.html
[17:52] <ara> i.e. for the mobile team:
[17:52] <ara> http://qa.ubuntu.com/reports/team-assigned/canonical-mobile-assigned-bug-tasks.html
[17:52] <ara> A list of them can be found at http://qa.ubuntu.com/reports/team-assigned/
[17:52] <gman16k> http://qa.ubuntu.com/reports/team-assigned/
[17:53] <ara> These reports can be useful, in case a triager sees that an already assigned bug with high importance hasn't been touched in a while, he or she could ping the correct person directly, to try to push the resolution.
[17:54] <ara> triaging bugs involves a lot of talking through the IRC. If you like IRC, you will love triaging bugs!
[17:54] <ara> I am running out of time, I would like to move to testing again before I finish
[17:54] <ara> any questions on the triaging side?
[17:55] <ara> ok, let's move back to testing
[17:55] <ara>  we will talk a bit about SRU testing. Does anyone know what SRU stands for?
[17:55] <davmor2> stable release update
[17:56] <ara> SRU stands for Stable Release Updates. This is, those updates that are found in the Update Manager when we are running a stable release of Ubuntu.
[17:56] <ara> davmor2: you're a great student! ;-)
[17:57] <ara> Briefly, the process goes as:
[17:57] <ara> * An important bug, that needs to be fixed through updates, is found in a stable release.
[17:57] <ara> * A fixed is written and apply to the package. The package gets updated in the -proposed archive.
[17:57] <ara> * A tester willing to help with the SRU process (and has the -proposed repositories enabled; https://wiki.ubuntu.com/Testing/EnableProposed) installs the package and verifies that the bug has been fixed.
[17:57] <ara> * The fix is apply to the -updates repository.
[17:57] <ara> For more information about the SRU process you can go to https://wiki.ubuntu.com/StableReleaseUpdates
[17:57] <ara> To help tracking the outstanding bugs to test and help people coordinate the efforts, we have a very helpful tool, the SRU tracker:
[17:58] <ara> http://people.ubuntu.com/~sbeattie/sru_todo.html
[17:58] <ara> In this tracker you can easily spot what fixes need verification (and for which release) and a test case if available.
[17:58] <ara> If you're running a stable release of Ubuntu (hardy, intrepid...) this is a great way to help the QA team to make Ubuntu better.
[17:59] <ara> any questions before leonardr starts the following session?
[18:00] <ara> counting down:
[18:00] <ara> 5...
[18:00] <ara> 4...
[18:00] <ara> 3...
[18:00] <ara> 2...
[18:00] <ara> 1...
[18:00] <charlie-tca> Thanks ara, That was GREAT!
[18:00] <ara> Ok, that's it for today! I will be running another session on Thursday, to explain how to use Ubuntu Desktop Testing to create automated tests for the desktop.
[18:00] <davmor2> thanks ara
[18:01] <dinxter> cheers!
[18:01] <ara> Thanks all for coming!!
[18:01] <bullgard4> Thank you, ara.
[18:01] <porthose> thank you ara
[18:02] <leonardr> ok, i'll get started now
[18:02] <leonardr> Hi all.
[18:02] <leonardr> My name is Leonard Richardson. I'm on the Launchpad Foundations team and I'm the co-author of the O'Reilly book "RESTful Web Services".
[18:03] <leonardr> I'm here to talk about the Launchpad web service API--how to use it and what advances have been made since the last UDW.
[18:03] <leonardr> I'll do an infodump and then take your questions.
[18:03] <leonardr> If you have questions in the meantime just put them in #ubuntu-classroom-chat.
[18:03] <leonardr> Most of this infodump will be familiar to those of you who were at this chat at the last UDW. I ask you to bear with me so I can get everyone up to speed.
[18:03] <leonardr>  
[18:03] <leonardr> 1. Intro
[18:03] <leonardr> First thing to know is that we've got docs talking about the API here: https://help.launchpad.net/API
[18:03] <leonardr> Put simply, we've created an easy way for you to integrate Launchpad into your own applications.
[18:03] <leonardr> If you perform the same tasks on Launchpad over and over again, you can now write a script that automates the tasks for you.
[18:04] <leonardr> You don't have to rely on fragile screen-scraping.
[18:04] <leonardr> If you're a developer of an IDE, testing framework, or some other program that has something to do with software development, you can integrate Launchpad into the program to streamline the development processes.
[18:04] <leonardr> If you run a website for a project hosted on Launchpad, you can get project data from Launchpad and publish it on your website.
[18:04] <leonardr> And so on. You'll eventually be able to use the API to do most of the things you can do through the Launchpad web site.
[18:04] <leonardr>  
[18:04] <leonardr> 2. Tools
[18:04] <leonardr> The simplest way to integrate is to use launchpadlib, a Python library we've written.
[18:04] <leonardr> (see https://help.launchpad.net/API/launchpadlib)
[18:04] <leonardr> This gives you a Pythonic interface to the Launchpad API, so you don't have to know anything about HTTP client programming:
[18:05] <leonardr> >>> launchpad.me.name
[18:05] <leonardr> u'leonardr'
[18:05] <leonardr> >>> launchpad.bugs[1].title
[18:05] <leonardr> u'Microsoft has a majority market share'
[18:05] <leonardr> But it's also easy to learn the API's HTTP-based protocol and write your own client in some other language.
[18:05] <leonardr> (see https://help.launchpad.net/API/Hacking)
[18:05] <leonardr>  
[18:05] <leonardr> 3. Progress and Roadmap
[18:05] <leonardr> At the last UDW I said that the web service publishes information about people, bugs, and the Launchpad registry, (the projects, milestones, etc.).
[18:05] <leonardr> Since then, the bugs work has been more or less completed. CVEs have also been published through the web service.
[18:05] <leonardr> Code branches have come online.
[18:06] <leonardr> Merge proposals have been published but are currently read-only. They should be read-write within a week.
[18:06] <leonardr> Additional bits of the registry, like milestones, have been published since the last UDW.
[18:06] <leonardr> Some of the Soyuz functionality has come online: archives and archive permissions.
[18:06] <leonardr> The hardware database will be the next thing to be published, hopefully within a month.
[18:06] <leonardr> Publication through the web service is still not a priority for translations, answers, and blueprints.
[18:06] <leonardr> so, that's the infodump, i invite your questions
 QUESTION: do you plan write API for Rosetta?
[18:08] <leonardr> so, the team that does some part of launchpad, like rosetta, is also responsible for publishing that part of launchpad through the web service
[18:08] <leonardr> i talked to the translations team today and they don't have plans to publish translations through the web service, per se
[18:09] <leonardr> however, we will also be using the web service to add ajax functionality to the launchpad website
[18:09] <leonardr> and they will be publishing some of the translations functionality for that, so you will get at least some of the translations
[18:09] <leonardr> but there's no plan right now to publish the whole things as there was for bugs--what they publish might be useful to you, it might not
 QUESTION: What is a " Pythonic interface "?
[18:10] <leonardr> a pythonic interface is one that "looks like python". it presents objects that act like built-in python data structures, as opposed to (eg.) one with a lot of getters and setters
 Question: can you please explain (in short) the different access-level?
 and especially: why is there a "no access level"
[18:11] <leonardr> is there a no access level? let me check
[18:11] <leonardr> i'm opening up the list of access levels
[18:12] <leonardr> all right
[18:12] <leonardr> so, we've set up authorization to the launchpad web service using the oauth standard
[18:12] <leonardr> which is basically a way for the end-user to delegate a certain amount of authority to a program
[18:13] <leonardr> the problem is that although you trust your web browser enough to type in your launchpad password
[18:13] <leonardr> you probably don't extend that same level of trust to other programs, like IDEs or "portal" websites that promise to show you a dashboard of your launchpad activity
[18:14] <leonardr> you shouldn't trust those sites with your launchpad password
[18:14] <leonardr> oauth is a way to delegate a certain amount of power to those sites, without giving them your password
[18:14] <leonardr> in that context, the access levels are the different amounts you can trust a particular site or application
[18:14] <leonardr> if a site promises to make a dashboard for you, then you can give the site read-only access to your data
[18:15] <leonardr> it has no business modifying your data
[18:15] <leonardr> similarly, you can authorize an application to only access public data on your behalf
[18:15] <leonardr> as for the 'no access' level, flacoste said in classroom-chat:
 thekorn: say a rogue application try to ask for a token, the user can click on no access level to dismiss the request
[18:15] <leonardr> it's a 'cancel' button
[18:16] <leonardr> hopefully that provides at least some enlightenment
 QUESTION: Will it become possible to use launchpadlib without needing to login, if all you want is read-only programmatic access to public data?
[18:16] <leonardr> our initial decision was to prohibit this altogether. we're now reconsidering but we haven't made a decision one way or the other yet
 QUESTION: could you just name, please, a few apps, which uses LP API?
[18:17] <leonardr> i think thekorn could name more than i can
[18:17] <leonardr> i'm also bad with names
[18:17] <thekorn> there are some tools switching from screenscraping to lplib,
 the is a bzr plugin for eclipse
[18:18] <thekorn> like ubuntu-dev-tools
[18:19] <leonardr> also, for every publicly available tool there are several private scripts
[18:19] <leonardr> people write everyday scripts to get around whatever annoys them about launchpad or to do batch operations
 QUESTION: Rationale for prohibiting launchpadlib access to data which can be screen-scraped without auth would be interesting?
[18:20] <leonardr> there's a general worry about access to the web service getting out of control
[18:21] <leonardr> we have various ways to throttle usage for different scenarios, and one of the scenarios is when one person is using too many resources, whether by accident, due to a bug, or maliciously
[18:21] <leonardr> in that case we'd throttle all access by that person
[18:21] <leonardr> like i said, we're reconsidering it
 QUESTION: Is there a way to ask for change to be Pushed to you  instead of having to poll?
[18:22] <leonardr> no, not really
[18:22] <leonardr> are you thinking something like email?
[18:23] <leonardr> in general the web works on polling, even if you're just polling a summary of what's changed
 leonardr: yes
[18:23] <leonardr> no, there's no email or other kind of push architecture
[18:24] <leonardr> if you're worried about bandwidth usage, there are standard http techniques like conditional get that we use and plan to use more of
[18:24] <leonardr> launchpadlib automatically uses them
[18:25] <leonardr> xmpp is an interesting possibility but i don't think you should expect it anytime soon
[18:28] <leonardr> any other questions?
 Question: is there any work on a javascript implementation of the API, like launchpadlib for python
[18:29] <leonardr> yes, there is, actually
[18:29] <leonardr> because as i said, we are going to be using the web service to add ajax ui elements to launchpad
[18:29] <leonardr> you can actually see it now
[18:30] <leonardr> https://launchpad.net/+icing/rev7479/launchpad-ajax.js
[18:30] <leonardr> but right now it only works on pages on launchpad itself
[18:30] <leonardr> this is partly because of the design and partly because of the 'same-origin policy' that makes it difficult to have a page on foo.com that makes an XMLHTTPRequest to bar.com
[18:31] <leonardr> it's not a huge priority for us but eventually the javascript library should be usable outside of launchpad
[18:31] <leonardr> however, note that it's very different from launchpadlib
[18:32] <leonardr> because it doesn't have access to the wadl file, you have to know a lot more about the url structure and what the web service looks like on the http level
[18:33] <leonardr> anything else?
[18:36] <leonardr> ok, i'll stick around until the next presentation in case there are any more questions
 QUESTION: Can we extract XML for Flash display?
[18:37] <leonardr> the web service serves JSON, not xml
[18:37] <leonardr> it's also pretty likely that a flash application will run afoul of the same-domain policy, just like a javascript application
[18:38] <leonardr> if you can get around the same-domain policy somehow, there's got to be a json parser written in flash
[18:38] <leonardr> but that's not a case we're really thinking about
[18:59] <redclover> date -u
[19:01] <kees> I'll go ahead and get started.  As usual, please ask questions at any time in the -chat room, and we'll answer them as we see them.  :)
[19:01] <kees> welcome everyone!  I'm Kees Cook, and I'm the technical lead of the Ubuntu Security Team (and employed by Canonical).
[19:01] <kees> this is going to be a quick intro to how the Security Team operates within Ubuntu, and how people can help create high-quality updates.
[19:02] <kees> I'm joined by Jamie Strandboge and Marc Deslauriers, who will be helping with the presentation.
[19:02] <kees> the main wiki page for information about the team is here: https://wiki.ubuntu.com/SecurityTeam
[19:02] <kees> our page is still a bit young, so pardon the lack of details in the FAQ and KnowledgeBase areas.
[19:03] <kees> we might be able to populate some of the FAQ with today's classroom's questions.  :)
[19:03] <jdstrand> \o/
[19:03] <kees> the most active subteams within the Security Team are "ubuntu-security" and "motu-swat"
[19:04] <kees> 19:03 < ScottK> QUESTION: Since Marc is new(ish) perhaps he could introduce himself ...
[19:04] <mdeslaur> yes, I guess I could :)
[19:04] <mdeslaur> I'm from Quebec City, Canada, and have been a Canonical employee since the beginning of November
[19:05] <mdeslaur> I used to be a security and open source consultant for various companies
[19:05] <mdeslaur> And used to build security updates for the defunct Fedora Legacy project
[19:06] <kees> we're glad to have him as part of the team.  :)
[19:06] <mdeslaur> uhmm...that's about it I guess, feel free to ask me any question you may have
[19:06] <jdstrand> *very* glad :)
[19:07] <kees> so, when there are security updates that need to happen, "ubuntu-security" and "motu-swat" are the ones handling it usually, though we have many additional contributors.
[19:07] <kees> in general, our "update procedure" is here: https://wiki.ubuntu.com/SecurityUpdateProcedures
[19:07] <kees> we focus on fixing "CVE"s in published ubuntu releases
[19:07] <kees> (CVE stands for Common Vulnerabilities and Exposures)
[19:08] <kees> a CVE is basically a number identifying a flaw in software that has security implications
[19:08] <kees> the central collection of CVEs here: http://cve.mitre.org/
[19:08] <kees> some of the URLs for more information that I'm listing here can also be found in our KnowledgeBase: https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase
[19:08] <kees> since CVEs are global identifiers, they cover software (and hardware) from any vendor in the world -- only some CVEs apply to Ubuntu software.
[19:08] <kees> the first step to fixing security problems in Ubuntu is keeping up to date with new CVEs, and checking to see in Ubuntu is affected.
[19:09] <kees> 19:08 < bullgard4> QUESTION: What does 'swat' stand for in  "motu-swat"?
[19:09] <kees> 'swat' is in reference to "Special Weapons and Tactics", a specialize police force
[19:09] <kees> http://en.wikipedia.org/wiki/SWAT
[19:10] <jdstrand> I like to think of them as swat'ing security bugs
[19:10] <kees> that works too :)
[19:10] <kees> to help coordinate between teams and people, we have an ubuntu-specific reponsitory for tracking CVEs: https://code.launchpad.net/~ubuntu-security/ubuntu-cve-tracker/master
[19:11] <kees> this is a bzr branch, with details about every CVE that has been issued.
[19:11] <kees> Once you have a local branch of ubuntu-cve-tracker, the first thing to do is read, surprisingly, the README file.  :)
[19:11] <kees> most of the CVEs are flagged "ignore" since they apply to unpackaged software, different vendors like Apple or Microsoft, etc.
[19:11] <kees> since not everyone is interested in digging into a bzr repo just to see how things look, it is also published: http://people.ubuntu.com/~ubuntu-security/cve/main.html
[19:11] <kees> and universe: http://people.ubuntu.com/~ubuntu-security/cve/universe.html
[19:12] <kees> and for individual CVEs, those can be examined too, e.g. http://people.ubuntu.com/~ubuntu-security/cve/CVE-2008-2327
[19:12] <kees> (thanks ubot5)
[19:12] <kees> once CVEs have been identified, the team will prioritize them, and start either tracking down patches or making our own.
[19:12] <kees> some CVEs are initially private, while upstream (and the vendors) try to figure out solutions.  This is called an "embargoed" issue.
[19:13] <kees> the ubuntu tracker only shows public CVEs, since none of the vendors are allowed to discuss embargoed issues until they reach their "coordinated release date"
[19:13] <kees> once the teams gets a patch to fix a problem, they test them, and finally publish the fixes.
[19:13] <kees> (I'll be coming back to this in a moment...)
[19:13] <kees> presently, security updates for main/restricted packages (mostly handled by "ubuntu-security") get "Ubuntu Security Notices" (USNs) published: http://www.ubuntu.com/usn/
[19:13] <kees> there is a mailing list for this as well: http://lists.ubuntu.com/archives/ubuntu-security-announce/
[19:14] <kees> the Universe Security Team ("motu-swat") handles updates for universe and multiverse.
[19:14] <kees> besides the two teams handling security updates, we also have a team dedicated to providing better security globally to Ubuntu.  this is the "ubuntu-hardened" team.
[19:14] <kees> It started very SELinux-centric, but has grown to include people interested in AppArmor and other hardening techniques.
[19:14] <kees> we also have a "white hat" team ("ubuntu-whitehat") that is dedicated to hunting down new security issues.  it is still young and has plenty of room for growth.
[19:15] <kees> since all of the teams are rather small, we still use a single IRC channel (#ubuntu-hardened) and a single mailing list (ubuntu-hardened)
[19:15] <kees> switching back to update process, once we've tracked down an issue and a fix, we have to test it.  for details on this process, I'll turn it over to jdstrand!
[19:15] <jdstrand> that's my cue
[19:15] <jdstrand> Hi! I'm Jamie Strandboge. I am a member of the Ubuntu Security Team and a Canonical employee.
[19:16] <jdstrand> As many of us know, it is estimated that Ubuntu has 10 million installations world-wide, with only several thousand running the latest development release (10,000 IIRC).
[19:16] <jdstrand> Users of released versions of Ubuntu expect and deserve a stable system with as few regressions as possible. As such, ensuring high quality updates to released versions of Ubuntu is of utmost importance.
[19:16] <jdstrand> Hopefully this part of the session will help people to understand the processes, information and tools available to help create high-quality updates.
[19:16] <jdstrand> Before an update to an Ubuntu release can be made, typically a patch must be created and submitted to Launchpad for review.
[19:17] <jdstrand> https://wiki.ubuntu.com/StableReleaseUpdates discusses when and how a bug fix can be incorporated into a released version of Ubuntu, while https://wiki.ubuntu.com/SecurityUpdateProcedures discusses the process of fixing security bugs.
[19:17] <jdstrand> In general, whether the update is a stable release update (SRU) or security update, the updated package should follow the process described in https://wiki.ubuntu.com/SecurityUpdateProcedures#Preparing%20an%20update.
[19:17] <jdstrand> Most importantly:
[19:17] <jdstrand> 1. Make the minimum changes necessary to fix the bug
[19:17] <jdstrand> 2. Prefer packaging the changes as proper patches (ie, when there is a patch system (eg, cdbs, dpatch, quilt, et al), use it. When the patch system supports it, follow https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines)
[19:18] <jdstrand> 3. Properly test that the package builds and still works (see qa-regression-testing, discussed later)
[19:18] <jdstrand> 4. Make sure the changelog has the proper formatting. This includes the proper version, distribution, bug references, patch origin, and CVE. All of this information is needed for review and so it is clear to anyone who looks at the changelog what changed.
[19:19] <jdstrand> (the CVE is needed only if it's a security update, of course)
[19:19] <jdstrand> 5. If Debian is still affected, send the patch to them by following https://wiki.ubuntu.com/Debian/Bugs. We need to always give back to Debian, because it is the right thing to do and because it helps Ubuntu in the next development cycle.
[19:19] <jdstrand> When submitting patches, please read through and follow this section of SecurityUpdateProcedures in its entirety, as the above only touched on the most important points.
[19:19] <jdstrand> When performing a security update or SRU, it is of utmost importance to make sure that the update does not introduce any regressions and verify that the package works as intended after an update.
[19:20] <jdstrand> While we are all human and some regressions are inevitable, we can go a long way towards ensuring that we do everything possible to be reasonably sure the update works as intended.
[19:20] <jdstrand> This is where the QA Regression Testing bzr branch (https://code.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master) can help.
[19:20] <jdstrand> qa-regression-testing was started by Martin Pitt (pitti), and continued by me, kees, mdeslaur and others.
[19:20] <jdstrand> qa-regression-testing is used extensively by the Ubuntu Security team, as well as the Ubuntu QA Team, Ubuntu Server Team and others. It is also used in the SRU (Stable Release Update) process and when testing Apparmor profiles.
[19:21] <jdstrand> The bzr branch contains a lot of information to help with an update.
[19:21] <jdstrand> I highly recommend reading README.testing, which talks about things to look out for in an update, best practices, checklists and more.
[19:21] <jdstrand> For example, README.testing discusses checking the differences between builds, exercising patched code, running build tests, checking for ABI changes, and more.
[19:21] <jdstrand> It also lists various software that can be helpful in debugging, analysis, auditing, and ensuring package QA (among other things).
[19:22] <jdstrand> Finally, it contains a checklist that can be invaluable in making sure that you done/checked various tasks.
[19:22] <jdstrand> build_testing/ and notes_testing/ have notes and instructions on how to enable build testing, use testing frameworks for a particular application and any other notes pertinent to testing. For example, build_testing/apache2 has notes on using the Perl-Framework from http://httpd.apache.org/test/.
[19:22] <jdstrand> The scripts/ directory contains scripts for testing various programs. As of today, there are 58 test scripts.
[19:23] <jdstrand> The main idea behind these scripts is not build/compile testing, but rather application testing for default and non-default configurations of packages.
[19:23] <jdstrand> For example, the test-openldap.py script will test slapd for various configurations like ldap://, ldapi://, ldaps://, sasl, overlays, different backends and even kerberos integration.
[19:23] <jdstrand> test-openoffice.org.py opens various files that openoffice.org supports to make sure they still work.
[19:24] <jdstrand> *IMPORTANT* the scripts in the scripts/ directory are often destructive, and should NOT typically be run on a production machine. We typically run these in a virtual machine, but often a chroot is sufficient.
[19:24] <jdstrand> Most of the scripts use python-unit. At the top of each script are instructions for how to use it, caveats, etc. There is also a skeleton.py script along with libraries (testlib*.py) that can be used when developing new scripts.
[19:25] <jdstrand> While python-unit doesn't perfectly lend itself to GUI testing, it may be able to be used to automate some aspects of the testing of certain files, such as test-openoffice.org.py and test-xine.py.
[19:25] <jdstrand> Work is being done to help automate GUI functionality, and can be seen in https://wiki.ubuntu.com/Testing/Automation and later this week in the 'Automated Desktop Testing' session.
[19:25] <jdstrand> The scripts in qa-regression-testing typically are written when there is a new security update, and specifically tests the functionality that pertained to a given patch.
[19:26] <jdstrand> As such, the scripts are in varying states of completeness, and any help in creating and extending these is most welcome. :)
[19:27] <jdstrand> Help is also welcome in any of the q-r-t parts-- eg build_testing/ information for applications not listed
[19:27] <jdstrand> By following the checklists, best practices, developing new scripts and using existing scripts for qa-regression-testing, we all can go a long way in helping to ensure as few regressions as possible.
[19:27]  * kees <3 q-r-t
[19:27]  * jdstrand hands it back over to kees
[19:28] <kees> the work in q-r-t is very important, so if anyone wants to help with updates, that's by far one of the best places to focus on.
[19:29] <jdstrand> it also is not hard to get started, and often a fun/small coding project
[19:29] <kees> I did a quick overview of the various other areas of the security team.  are there any specific questions or areas that people would like to hear more about?
[19:31] <jdstrand> Something I didn't mention while discussing testing
[19:31] <jdstrand> as we all know, Ubuntu is split up into different releases, such as dapper, gutsy, hardy, intrepid, and jaunty
[19:32] <jdstrand> in the changelog, after the version, there is a 'distribution' field
[19:32] <jdstrand> for the development release (eg 'jaunty'), the distribution field is simply the release name
[19:32] <jdstrand> for security updates, you should append -security to the release name, eg hardy-security
[19:33] <jdstrand> for SRUs, you should append -proposed (updates are tested in -proposed first)
[19:33] <jdstrand> many people know about all that, however, what is less widely known is how security updates and SRUs end up getting built
[19:34] <jdstrand> when testing an update destined for -security (eg, hardy-security), keep in mind that security updates are *only* built with the release pocket and the security pocket enabled
[19:35] <jdstrand> specifically, -updates and -proposed are not in sources.list when a -security update is being built
[19:35] <jdstrand> this is important to note when testing, because sometimes subtle (and not so subtle) bugs can creep in when you test your package with -updates enabled, but upload to -security
[19:36] <jdstrand> which doesn't have -updates enabled (they are essentially different packages)
[19:36] <jdstrand> another thing to keep in mind, is what components a package is built with
[19:37] <jdstrand> the components are main, restricted, universe and multiverse
[19:37] <jdstrand> a package destined for main is only built with the main component
[19:37] <jdstrand> restricted is built with only main and restricted
[19:37] <jdstrand> universe is built with main and universe
[19:37] <jdstrand> multiverse is built with main, restricted, universe and multiverse
[19:38] <jdstrand> why is this important? sometimes debian/control has a Build-Depends like (foo | bar)
[19:39] <jdstrand> if foo is in universe and bar is in main, a package destined for main will be built with bar, but if the universe component was in sources.list during your testing, you might have tested with the package built against foo
[19:39] <jdstrand> QUESTION: How do backports and security updates fit in with each other?  Do we patch the original released or the backported version?
[19:40] <jdstrand> good question
[19:40] <jdstrand> -backports is a different pocket entirely, and does not receive official support from the Security Team, and often doesn't receive backported fixes from motu-swat
[19:41] <jdstrand> updated packages that fix a CVE will pull from -updates though
[19:42] <jdstrand> so the source will come from -updates, but will be built against only -security (and release)
[19:42] <jdstrand> it is general policy to backport fixes to the packages that exist at release time, rather than doing an upload of a new version
[19:43] <jdstrand> for example, if package foo is at version 1.2.3, and upstream releases version 1.2.4 (that has a CVE fix), we will backport the security fix in 1.2.4 to 1.2.3, rather than upgrading foo to 1.2.4
[19:43] <jdstrand> there are exceptions though-- firefox, postgresql and clamav are some of them
[19:44] <jdstrand> QUESTION: What is "the release pocket and the security pocket"?
[19:44] <jdstrand> the release pocket is simply the release name, eg "jaunty"
[19:45] <jdstrand> after a version of Ubuntu is official, then the release pocket is frozen, and updates must go to other pockets (these can be seen in your /etc/apt/sources.list file)
[19:46] <jdstrand> so, "hardy" is the release pocket for hardy, "hardy-security" gets security only fixes, and "hardy-updates" gets bug fixes (and security fixes are copied into it)
[19:46] <jdstrand> "hardy-proposed" is the pocket people upload to when they want a bug fix ultimately destined for "hardy-updates"
[19:47] <jdstrand> QUESTION: You are doing your best to create high-quality updates. Where is laid down what an Ubuntu user should do to have a very secure Ubuntu computer and network?
[19:49] <jdstrand> Ubuntu by default is installed with no open ports
[19:49] <jdstrand> as long as you keep your system up to date, the typical Ubuntu user will have a secure system
[19:50] <jdstrand> once you start adding services to it, like a web server, Ubuntu can keep the package up to date, but misconfiguration can always be a problem
[19:51] <jdstrand> there are various tools such as apparmor and ufw that can help lock down services and network capabilities, but this is really a question that can't be sufficiently answered in this session
[19:51] <jdstrand> QUESTION: If -security is built without -updates, what happens  when you need to prepare a security update to a package which has  an update already published in -updates?
[19:51] <jdstrand> we pull the version in upddates, patch the security fix in it, and change the version such that it is higher than in -updates
[19:55] <jdstrand> we are about out of time. are there any more questions?
[19:57] <jdstrand> Ok. thanks to kees and to everyone who attended. Please feel free to jump in with patches for security, SRUs or testing scripts :)
[19:57] <jdstrand> happy hacking!
[19:58] <ickis> nice talk
[19:58] <ickis> thanks!
[19:58] <jdstrand> thanks you :)
[19:59]  * pitti args
[19:59] <pitti> I just did something *incredibly* stupid
[19:59] <pitti> I deleted my talk!
[19:59] <bullgard4> jdstrand, kees: Thank you for a most interesting class!
[19:59] <pitti> I'm terribly sorry, I'm afraid I have to cancel this and move it to a later place
[20:00] <jdstrand> bullgard4: :)
[20:00] <ickis> ups
[20:00] <bekks> pitti: may i take you into a short query regarding talks at general?
[20:00] <pitti> anyone knows how to undelete on ext3?
[20:00] <pitti> bekks: let me try to rescue this file
[20:01] <bullgard4> pitti: Oh, no. Start it now without your document.
[20:01] <pitti> sorry, it's a bit too complicated to do it from scratch
[20:01] <Delkia> god luck pitti !
[20:01] <bekks> pitti: on ext3, there is not a fair chance to undelete, cause inode entries are overwritten with zero.
[20:01] <bekks> I'm sorry for those bad news.
[20:02] <walthari> good evening to everybody
[20:02]  * pitti looks in .viminfo
[20:02] <pitti> apparently not
[20:03] <pitti> and my backup didn't catch it yet
[20:03] <stefanlsd> pitti: maybe the grep idea   http://www.linuxforums.org/forum/linux-security/13416-ext3-filesystem-can-undelete-work.html
[20:04] <Ape3000> pitti: You should use trash, so that you can recover accidentally deleted files from there
[20:04] <pitti> yeah, I will next time
[20:04] <pitti> argh, this has cost me 3 hours to write
[20:05] <mnemo> ubuntu should have a "delete to trash" version of "rm" :(
[20:05] <Ape3000> And don't automatically empty the trash. Wait for at least an hour before emptying the trash. You might still want to get that file back.
[20:05] <mneptok> ext2 just marks these blocks as unused in the block bitmaps and marks the inode as "deleted" and leaves the block pointers alone.
[20:05] <bekks> mnemo: you could do that with an alias
[20:06] <mneptok> gah
[20:06] <istaz_> mneptok: take a look at http://pages.stern.nyu.edu/~marriaga/software/libtrash/
[20:06] <istaz_> s/ mneptok / mnemo /
[20:06] <Ape3000> You could use: alias rm='rm -i'
[20:06] <mneptok> istaz_: not much help now, though
[20:07] <istaz_> it a lib you preload and remove all call to rm and replace them to mv .trash
[20:07] <istaz_> mneptok: no but for the future
[20:07] <Ape3000> pitti: Can we still have the session with debugging?
[20:08] <mnemo> or will you re-write the notes for tomorrow maybe?
[20:08] <pitti> I'll have it later in the week
[20:08] <pitti> 4112384 inodes scanned, 0 deleted files found
[20:08] <pitti> :(
[20:08] <pitti> seems I'll rewrite it from scratch then
[20:09] <theseas> bye everyone!!!
[20:09] <mnemo> javaJake has some idea about grepping the HDD image
[20:09] <pitti> I'm sorry everyone
[20:10] <javaJake> That came from stefanlsd's link
[20:10] <jpds> pitti: That's a shame, I personally use something like: http://paste.ubuntu.com/107438/ which make a copy of the doc on save.
[20:11] <pochu> pitti: don't worry. I'll be here when/if you can do it, as long as it's not the day before an exam :)
[20:12] <pochu> pitti: I guess, no mydocument~ (like gedit does by default for backups)?
[20:12] <Ape3000> So you pressed some keys that did "delete all text" on vim?
[20:12] <pitti> pochu: no, .vim removes the swap file after you exit
[20:19] <xnox> use bzr next time you write it and commit after every pragraph =)
[20:19] <gh1234> date -u
[21:22] <evolu_> date -u
[21:22] <evolu_> 'date -u'
[21:46] <mneptok> thanks, but i'm taken
[22:12] <istaz_> what is the date -u things everybody write?
[22:12] <istaz_> date -
[22:12] <istaz_> date -u
[22:13] <jpds> istaz_: Type it into the console.
[22:13] <holloway> istaz_: put it in your terminal
[22:14] <istaz_> yes it give the date but why is everybody typing it on the chan?
[22:16] <jpds> istaz_: Cos they read the topic and just type it...
[22:17] <istaz_> oh