=== astro76_ is now known as astro76 === neversfelde|mobi is now known as neversfelde [13:07] Ah finally... [13:07] Next Lesson in 01:53h? [13:08] Is that correct? [13:10] in 2:53h [13:17] oh, yes [13:17] sorry [13:17] np === never|mobi is now known as neversfelde [14:32] Hi all! [14:33] warp10: hello, you're 01:28h early [14:34] db-keen: indeed! But early is better then late, imho ;) [14:35] * db-keen concedes (after all, he's been here for over 6 hours) [14:36] LOL === asac_ is now known as asac === emgent is now known as emgent`work [15:48] Is the firefox-session already completed ? [15:48] phoenix24: will start in 10 minutes [15:49] this channel itself, I believe ? [15:49] yes [15:52] Oh! asac, you'd be delivering the talk :) [15:52] Nice to meet ye! [15:53] ;) [15:55] ok we will start in 5 minutes on firefox 3 extension packaging!! [15:56] maybe do the Prerequisites on https://wiki.ubuntu.com/MozillaTeam/Firefox3Extensions/Packaging now so you don't get distracted later on :) [15:58] asac: will questions be in #ubuntu-classroom-chat as usual? [16:00] db-keen: yes you can ask questions there [16:00] Hi all! [16:00] good morning! [16:01] Welcome to Ubuntu Developer Week and welcome to the firefox extension world ;) [16:01] asac: Thank you.. [16:01] i will give first some basic background and then will go on to a practicing part [16:02] lets get started [16:02] packaging extensions is a good starter task as the technical side is rather straight-forward. [16:02] However, nothing comes for free :-P and extensions also have a backdraft: the upstream world is quite different compared to other software we distribute. [16:03] One important backdraft is on the communication part with upstream [16:03] ffox extension upstreams usually don't care about properly releasing sources that include license information [16:03] Sometimes they often don't even have a homepage and don't release sources. Further, its sometimes even hard to find an appropriate upstream contact. [16:04] if we cannot find the required information we should not package it. we should rather contact the developers and ask them for clarifying licensing and so on [16:04] Thats why I created https://wiki.ubuntu.com/MozillaTeam/Firefox3Extensions [16:05] At that place we should collect the required information needed to decently maintain a package _before_ we start to package one. [16:05] So if you want an extension packaged (or want to package one), adding the required information on that page is required and comes handy later! [16:06] so much for the basics. === neversfelde is now known as neversfelde_ [16:07] if you have any questions afterthis session, you can always ask on #ubuntu-mozillateam [16:07] ok, lets go for some practice ;) [16:07] please do the "Before you package an extension" section on https://wiki.ubuntu.com/MozillaTeam/Firefox3Extensions/Packaging [16:08] i'll wait a bit for those that have joined late to install the basics === neversfelde_ is now known as neversfelde [16:09] its important that you need mozilla-devscript package from my ppa (see wiki page) :) [16:09] aeh mozilla-devscripts, sorry [16:10] this practice part will teach two ways of packaging ffox extensions; both using the new xpi.mk feature shipped by the new mozilla-devscripts [16:11] sorry: above should have read "please do the Prerequisites on https://wiki.ubuntu.com/MozillaTeam/Firefox3Extensions/Packaging" [16:12] any questions so far? any problems installing the packages? [16:12] or branching? [16:12] * jetsaredim updating the sources.list [16:13] ok ... ill wait a few more minutes i guess :) [16:14] these bzr commands take a while [16:14] yes. thats known :) ... but should be pretty fast if you have bzr 1.0 or higher [16:14] jetsaredim: yes [16:14] ok [16:15] so ubufox.upstream will be our upstream source code we use to practice [16:15] we will produce a package called "myubufox" based on that :) [16:16] let me know when you are ready ;) [16:16] asac: I'm ready...I think :) [16:16] Ready! [16:17] yeah great. [16:17] so the first approach is to package .xpi files directly [16:17] we usually don't want to package .xpi files, but if upstream doesn't release proper sources, we can still do it [16:17] to produce an ubufox.xpi, please change to the ubufox.upstream directory and run [16:17] "sh build.sh" [16:18] now lets assume that thats the extension you found on the net that you want to package, we first have to create a proper orig.tar.gz out of it [16:19] lets assume that the package has version 0.1 ... then create a directory myubufox-0.1 [16:19] and copy the ubufox.xpi into that directory [16:20] the name of the .xpi file doesn't matter much, so you can just keep it [16:20] just to ensure that you have the right directory layout, here its how it looks for me now: http://paste.ubuntu.com/4843/ [16:21] if you are not yet there, let me know :) [16:21] ok ... next create an orig.tar.gz out of that [16:22] tar cvzf myubufox_0.1.orig.tar.gz myubufox-0.1/ [16:22] asac: ok [16:22] asac: ok! [16:22] the XPI.TEMPLATE you branched further above is a pretty good template and should work for a lot of extensions [16:23] so just copy the debian directory out of it into your myubufox-0.1 directory [16:23] like: cp -r XPI.TEMPLATE/debian myubufox-0.1/debian [16:24] my ubufox directory looks now like: http://paste.ubuntu.com/4845/ [16:25] yes! [16:25] ok lets look at the debian/rules ... at best open it in an editor [16:26] there are a few variables with some documentation on what they do. for basic .xpi based packages you should not need to change anything except the package name [16:26] asac: phoenix24 ok! [16:26] MOZ_EXTENSION_PKG := example-extension => MOZ_EXTENSION_PKG := myubufox [16:27] for the second example later, we make use of MOZ_XPI_BUILD_COMMAND as well, but for simple .xpi thats not needed [16:28] ok, upon request here the folder structure i pastebined above (for the logs) [16:28] $ find myubufox-0.1/ [16:28] myubufox-0.1/ [16:28] myubufox-0.1/debian [16:28] myubufox-0.1/debian/compat [16:28] myubufox-0.1/debian/rules [16:28] myubufox-0.1/debian/copyright [16:28] myubufox-0.1/debian/control [16:28] myubufox-0.1/debian/changelog [16:28] myubufox-0.1/ubufox.xpi [16:28] thats how it looked like before we started looking at the debian/rules file [16:29] btw, the magic in the rules file is the include include /usr/share/mozilla-devscripts/xpi.mk which makes everything else pretty trivial [16:29] you can look at that file after the session if you are interested in makefile/cdbs wizardry ;) ... but it should not be required to understnd that file [16:29] ok, i assume that you have changed the package name in debian/rules? [16:30] asac: yes! [16:30] yes! [16:31] ok good ... then we need to fix debian/control [16:32] its again just the package name. for our case we use myubufox for Source: as well as for Package: [16:32] usually you would fill in a good package description, set a proper maintainer as well, but we don't need this for practice [16:33] further the section might be wrong, as there might be office extensions and so on [16:35] ok after fixing the debian/control file we are pretty much done [16:35] for me it looks like this now: [16:35] Source: myubufox [16:35] Section: web [16:35] Priority: optional [16:35] Maintainer: Yourname [16:35] Build-Depends: debhelper (>= 5), cdbs, mozilla-devscripts (>= 0.5~) [16:35] XS-Vcs-Bzr: https://code.launchpad.net/~LPID/firefox-extensions/example-extension.ubuntu/ [16:35] Standards-Version: 3.7.3 [16:35] Package: myubufox [16:35] Architecture: all [16:35] Depends: firefox | firefox-3.0 | firefox-2 [16:35] Description: one line for short description Long descriptions can span multiple lines . and as above empty lines [16:36] well .. some linebreaks removed for the extensions [16:36] but you get the point i guess [16:36] i just changed the Source: and Package: line [16:37] ok last thing: fix the version and the package name in changelog [16:37] .e.g debian/changelog === tsmithe` is now known as tsmithe [16:37] and of course your name [16:38] are you ready? [16:38] yes! [16:38] then give it a spin and produce your binary test package :) [16:38] just run: debuild -b [16:38] ok [16:39] the output i get during that build is like: http://paste.ubuntu.com/4847/ [16:40] at the end of the build i get some lintian warning/errors: [16:40] E: myubufox_0.1-1_i386.changes: bad-distribution-in-changes-file UNRELEASED [16:40] E: myubufox: copyright-should-refer-to-common-license-file-for-lgpl [16:40] W: myubufox: maintainer-not-full-name Yourname [16:40] W: myubufox: new-package-should-close-itp-bug [16:40] W: myubufox: wrong-bug-number-in-closes l3:#XXXXXX [16:40] the first error would be fixed by using hardy instead of UNRELEASED [16:40] and the second one, by filling the debian/copyright file with proper content [16:41] the others should be self-explanatory [16:41] but we don't need to fix them ;) [16:41] now [16:42] ok ... do you all have a myubufox_0.1-1_all.deb now? [16:42] asac: yes [16:42] Grazieno: congrats!! [16:43] you win ;) [16:43] asac: :) [16:43] you could install it now and it should install the extension in your firefox. you don't need to test that now, if it doesn't work then its a bug in mozilla-devscripts that you can always bug me about ;) [16:44] but it should work :) [16:44] (well maybe you need to uninstall the main ubufox package first, because they have the same extension id) [16:46] ok ... lets go on with second approach then (which should be quicker as we know how it works a bit) [16:46] asac: How can I see the extension in firefox? Is it possible? [16:46] Grazieno: well ... you need to uninstall the ubufox package first [16:47] then you should see the new one [16:47] (they conflict and firefox will just display one) [16:47] ok the second approach is to use the realy ubufox sources [16:48] and we will use bzr for real :) [16:48] to start you create a package branch locally thats based on the ubufox.upstream branch you have [16:48] just do: bzr branch ubufox.upstream myubufox.ubuntu [16:48] that should create a new directory "myubufox.ubuntu" [16:49] now the same procedure as before: copy the debian/ directory from the XPI.TEMPLATE directory into it [16:49] cp -r XPI.TEMPLATE/debian myubufox.ubuntu/debian [16:49] you can also use the debian directory from the other package we created [16:50] so cp -r myubufox-0.1/debian/ myubufox.ubuntu/debian [16:50] now commit those changes to your packaging branch and push it to launchpad ;) [16:51] https://wiki.ubuntu.com/MozillaTeam/Firefox3Extensions/Packaging [16:51] ^^ thats the last step in section "Packaging Procedure" [16:51] you are still up? [16:51] ;) [16:51] or should i wait a bit ? [16:52] as we don't have a .xpi in the upstream branch anymore, we have to produce one before the package building can go on. [16:53] you can enable that by setting a proper build command in debian/rules [16:54] conventiently ubufox has a build.sh script to produce the .xpi ... so you can just enable: [16:54] #MOZ_XPI_BUILD_COMMAND = sh build.sh [16:54] => [16:54] MOZ_XPI_BUILD_COMMAND = sh build.sh [16:55] after that edit you can commit this to your packaging branch like: [16:55] bzr commit -m "* enable sh build.sh to build the .xpi" debian/rules [16:56] ok, to build the package, just run debuild -b again [16:56] if you have that ... then we are through! [16:57] if you couldn't finish everything, but want to learn more, you can always join #ubuntu-mozillateam and ask questions [16:58] sorry for the quick pace in the end ... 1hour is so little ;) ... i tried to best to squeeze quite a bit out of it and show you that most extensions are pretty easy to package [16:58] one more question which i find important: [16:58] jetsaredim> Q: what is the reason to package an extension vs letting people just get them from the addons.mozilla site? [16:58] Thanks for the lesson [16:58] thats frequently asked. but the answer is simple. The same reason why we want to package everything [16:59] we can better integrate it and quality assure it [16:59] fair enough [16:59] Prof. Asac: thank you very much! [16:59] and even auto-updates are not wanted in many environemtns [16:59] (like corporations) [16:59] they want to test and only get tested stuff [16:59] which is what we provide [16:59] thanks all! [16:59] Thanks! [16:59] looking forward to see you all in #ubuntu-mozillateam helping to get a lot of extensions ready for hady [16:59] hardy [16:59] asac: Thanks a lot! [16:59] you can make a big difference! [17:00] asac: thanks! [17:00] * asac hugs you all [17:00] next one please ;) [17:00] \o/ [17:00] I guess it's my turn now [17:01] I'm going to lead a session on writing scripts for automated desktop testing [17:02] I would like to have a volunteer to relay questions from the -chat channel so that I don't have to do that at the same time as talking here -- anyone? [17:02] but let's start [17:03] the first part of this session is going to be about running existing scripts [17:03] liw: I can do it [17:03] Grazieno, thank you! [17:04] there is going to be a nice framework to run the tests automatically, but that isn't done yet, so we're going to concentrate on the scripts themselves, running them manually and writing them [17:05] we're using the AT-SPI framework for the scripts; it was originally written for accessibility, but provides a way for external programs to poke GUI applications and get them to do things, and to examine some of their internal state [17:05] AT-SPI only works in GNOME, not in KDE (and may work in Xfce, but I haven't investigated) [17:06] to enable it, go to System -> Preferences -> Universal Access -> Assistive Technology, then tick the "Enable..." checkbox [17:06] you may want to set up a dedicated account for this, though [17:06] or run things in kvm, or virtualbox, or another emulator [17:07] because there's a fair chance that the scripts don't work they way they're supposed to work, and they may then break things [17:08] I use kvm myself, and I am making a Qemu image file (which kvm can use) that has everything already set up to run the tests, but that's still uploading (it's amazing how long it can take to upload big files), so I won't point you at the url yet [17:09] kvm is basically qemu, but with hardware acceleration; you can run the following command to see if your CPU can run kvm: egrep '^flags.*(vmx|svm)' /proc/cpuinfo [17:09] if that returns anything, and you want kvm, upgrade to hardy, install the kvm package, do "adduser $LOGIN kvm" (where $LOGIN is your username), and log out and log back in again [17:10] oh, and I forgot: if you want to enable the assistive technologies stuff, you need to log out and back in again as well, it's not enough to just tick the checkbox (the AT-SPI services need to be started when you log in) [17:11] anyone here already have an environment where they have assistive technology enabled? [17:11] liw: ok, I'll be back :) [17:11] if anyone else wants to enable it, now would be a good time, I can wait a few minutes [17:12] liw: ready! [17:13] https://wiki.ubuntu.com/Testing/Automation/DogtailTutorial has instructions for enabling AT and is generally useful for this automated testing stuff, please bookmark [17:14] ok, next step is to install the python-dogtail package [17:14] (please do so now if you want to experiment today) [17:14] also, we're going to be using a sample script for gThumb, so install that, too, if you don't have it already [17:15] https://wiki.ubuntu.com/Testing/Automation/Coverage has some scripts that have been written and collected -- there's way too few of them, since I've been tinkering with the framework to run them instead of writing new scripts, but let's hope some people here will get excited and help with the script writing (which is the more interesting part of the job) :) [17:16] eddyMul, just in case you missed things: https://wiki.ubuntu.com/Testing/Automation/DogtailTutorial is a useful link, and if you want to play with things tonight, install python-dogtail and gthumb packages [17:17] liw: thanks [17:17] those wanting to try running a script, download the gthumb.tar.gz file from the Coverage page (url above) and unpack it [17:18] then, from the command line, enter the directory with the unpacked files, and run this command: LC_ALL=C python gthumb-preferences.py [17:18] magical things should now be happening [17:18] is anyone seeing magic? [17:18] or is anyone trying to see magic and failing? [17:19] liw: failing.. [17:19] hi [17:19] Grazieno, what's the error? [17:20] liw: http://paste.ubuntu.com/4851/ [17:20] Grazieno, weird... are you running this in hardy? [17:21] liw: yes :) [17:21] liw: wrong? [17:21] Grazieno, hardy is right [17:22] liw: gutsy is wrong? :( [17:22] eddyMul, I know hardy is right, but I don't know if gutsy will work or not [17:22] liw: failed for me: http://paste.ubuntu.com/4852/ :( [17:23] ok, this is a bit disturbing, but I think I'll want to continue with the session -- I'd like to help you guys get this working, but we can perhaps do that later? [17:23] is that ok? [17:23] liw: yes! [17:24] liw: yes. carry on. [17:24] I should'v emade a movie about how the gthumb-preferences.py script runs and opens gthumb and toggles various preferences [17:24] you'll have to just believe me that it does... [17:25] the crucial bit here would have been to get it to work so that we can progress to writing new scripts [17:25] but well, we'll fix that later [17:25] QUESTION: I see dogtail can work with GTK-enabled OpenOffice; is this the default in gutsy? [17:26] the way we determine that a script worked is that it exits with a zero exit code -- this will hide some problems, but we'll worry about those at a later stage -- if a scipt crashes, it will return non-zero, so we'll notice that [17:27] jimcooncat, I don't know if that is the default in gutsy, sorry [17:27] It is, yes [17:27] thanks, this will be very useful [17:27] but more generally speaking, AT-SPI / dogtail should be able to work with any gtk+ application, with few exceptions [17:27] I've run dogtail scripts on openoffice [17:28] oh, and to see the exit code of a script, run this right after the script: echo $? [17:28] openoffice also works fairly well with Orca the screen reader [17:28] $? is the shell's charming way to express "exit code of the previous command2 [17:28] and that relies on AT-SPI [17:28] (sorry to interrupt) [17:29] yeah, at-spi (and atk from -chat) is all part of the assistive technology stuff, and it's meant for screenreaders and such aids, and the way we're using it for testing is really an afterthought, but it works (really! it does!) [17:29] ok, my qemu image upload finished, so you should be able to download http://people.ubuntu.com/~liw/autoguitest/autoguitest.qemu.lzma for a working hardy i386 basic gnome setup [17:30] uncompress with unlzma, and run with: kvm -m 512 -hda autoguitest.qemu -snapshot [17:31] the -m 512 is the amount of emulated memory, and -snapshot means that any changes you make won't be writte into the image (also meaning you will lose them once you quit kvm) [17:31] but continuing to writing scripts [17:31] er, not yet [17:31] the username is "tomjon", the password is "password1" (the industry standard password!) [17:31] and now, writing scripts [17:32] the easy way of writing scripts is by using the dogtail-recorder program (part of python-dogtail) and use the program you want to write a test for with the keyboard only [17:32] dogtail seems to be missing almost all mouse events, but gets keyboard events reliably, so it's best to stick to keyboarding [17:33] so: start the program you want to write a script for, start dogtail-recorder, click on "record", do stuff, click on "stop", and then on "save", and you have a script [17:33] this sounds too easy and wonderful to be true [17:33] and it is [17:33] the scripts pretty much always need some manual tweaking [17:34] http://paste.ubuntu.com/4837/ has one example script [17:34] straight from dogtail-recorder [17:34] the first problem is that this script does not actually start the program, it assumes the program is already running [17:35] we can fix this by replacing the first two "focus...." lines with "run('gcalctool')" [17:35] http://paste.ubuntu.com/4836/ -- this is the script after editing -- there's more changes, I'll go through them next [17:37] I find that it is best to write the scripts such that they are independent: they don't assume the program is already running, or anything else, except possibly that there aren't other programs running at the same tiem that might interfere (jimcooncat, hi), because those other programs are going to make things very complicated if we allow for them [17:37] so, at least for now, we're keeping things simple [17:37] the other problem with the original script in my pastebin is that I messed up while keyboarding and some silly and wrong stuff got recorded [17:38] basically: I was driving the app with the keyboard, but making assumptions about the order of things in menus, which is dangerous, if we want to keep the scripts running from release to release [17:38] and we want to be able to run the scripts from release to release, if possible [17:38] less work for testers... :) [17:39] so, I removed some useless keyboarding from the beginning of the script [17:39] the final difference is that dogtail-recorder inserts focus.something stuff in various places, and it is meant to do that [17:39] those focus things affect dogtails's idea of what has focus, not the window manager's [17:40] unfortunately, when I run the scripts, the focus setting doesn't really work, and I'm not entirely sure why, but luckily it is OK to just remove them, at least as long as we stick to an application with one window (and no dialog windows) [17:40] so the new version of the script is much shorter, and just toggles the various settings in the View menu of gcalctool [17:41] any questions about this so far? [17:41] those interested in danger and excitement may want to save http://paste.ubuntu.com/4836/ to foo.py and run it and see if it works [17:42] liw: it's ok for me [17:42] So I can intersperse python code with the dogtail commands? [17:42] oh, right: the dogtail scripts are pure Python code, which calls the dogtail Python library [17:42] so if you know what you're doing, you can add any Python stuff in there that you wish [17:43] hello [17:43] is this where the bughelper session going to be held? [17:44] getting scripts to work is sometimes a bit of a hassle: I haven't figured out a way to do it systematically yet, so that things always work the first time, but a little tweaking is usually all that is required [17:44] it's best to keep scripts fairly small -- this means that when they break, or when they find a problem, it is easier to see what happens [17:45] a 1000 line script that tests all of an application is harder to debug than a hundred 10-line scripts that each test a small part of the application [17:46] pranith: you're interrupting a running session. join #ubuntu-classroom-chat and i'll fill you in [17:46] oops, sorry everyone [17:46] if you write any scripts, we would like to ask you to upload them to https://wiki.ubuntu.com/Testing/Automation/Coverage and we can hopefully include them in the automatic desktop testing suite and eventually run them automatically as part of the Ubuntu release process [17:47] if you can attach a small text file that explains what the tests are about (or include that in comments in the script itself), even better, but as long as you get scripts done, we're happy :) [17:48] so, any questions now? [17:48] can't get dogtail to run do they have an IRC? [17:48] #dogtail on this IRC network, but I don't know how active that is [17:49] Can dogtail read text from a widget back into a python variable? [17:49] QUESTION: Where can I get the schedule for the #ubuntu-classroom ? [17:49] jimcooncat, in theory, yes, through the at-spi interfaces, but I'm not sure how to do that [17:49] phoenix24_, https://wiki.ubuntu.com/UbuntuDeveloperWeek [17:52] ok, I think we're about done, then ... ahead of time, even (my keyboard is smoking and my fingers are numb...) [17:53] liw, what kinds of script would you like to see on your wiki page? [17:54] jimcooncat, any script that verifies that some part of a GUI application in Ubuntu works [17:54] jimcooncat, anything that interests you is good, and we're most interested in stuff that is included in the default installation [17:55] those who had trouble getting dogtail to work: I am goign to have to leave in a few minutes, and I'm at fosdem over the weekend, but e-mail me at lars@canonical.com or ask me on irc on Monday, and I'll help you as best I can [17:56] thank you, everyone [17:56] * liw bows and exits gracefully [17:56] liw: very thanks! [17:56] liw: thanks [17:58] a few minutes until Brian Murray and Markus Korn with Bughelper [18:00] Grazieno: Shall we start now? [18:01] I'm ready :) [18:02] Hello thekorn and I devlop the bughelper suite and python-launchpad-bugs and wanted to tell you about how they can help you work with bug reports. [18:02] bdmurray: yes, sure! [18:02] If you want to tryout the examples we provide in our session, please install bughelper and python-launchpad-bugs. Some of the examples will only work with the latest versions of this tools. [18:03] thekorn has setup a ppa for the latest version of them and you can get them by adding * [18:03] thekorn has setup a ppa for the latest version of them and you can get them by adding deb [WWW] http://ppa.launchpad.net/bughelper-dev/ubuntu hardy main [18:03] to your /etc/apt/sources.list, and replace 'hardy' with the version of ubuntu you use [18:04] Then you can should update via 'sudo apt-get update' and install bughelper and python-launchpad-bugs [18:05] pranith asked: 'what all packages do we need to install to get started?' [18:05] So what is python-launchpad-bugs? It is a python interface to work with bugs, and blueprints to a degree, in Launchpad. [18:05] sorry ;) [18:06] You should install bughelper and python-launchpad-bugs to get started. [18:06] Bughelper is a suite of utilies that uses python-launchpad-bugs to help you find specific bugs in Launchpad. [18:06] We'll start off talking about the bughelper suite and then move on to python-launchpad-bugs. [18:07] The bughelper suite has 3 main applications - buginfo, bugnumbers and bughelper [18:07] buginfo is designed for reporting information about one specifc bug [18:07] for example 'buginfo --title 38442' will return the bugs title [18:08] While bugnumbers is designed for returning a list of bugs based off a query in launchpad [18:09] Starting points for a query include '-p' for a package in Ubuntu, '-l' for a url of a search in Launchpad [18:10] Or now you can search a whole distribution using '-D' or an upstream project using '-P' [18:10] Using those starting points you can then filter using features in Launchpad (bug status and importance) and some not in Launchpad [18:11] some features not in Launchpad are querying on the quantity of duplicates, subscribers, comments, attachments [18:11] in addition to the date or author of the last comment or the bug reporter [18:11] For example lets say I'm the gdm maintainer and I know Brian Murray reports some useful bug reports I could find all the bugs he's reported using 'bugnumbers -p gdm --reporter=brian-murray' or if I wanted just the new ones I could add that as a filter too so 'bugnumbers -p gdm --reporter=brian-murray --status New' [18:12] Another example is xorg bug reports which should always contain 2 attachments /etc/X11/xorg.conf and /var/log/Xorg.0.log. We could look for New bug reports with more than 1 attachment using 'bugnumbers -p xorg --na ">1"' to find "more complete" bug reports that might be worth triaging first. [18:13] I run reports on busy packages for bugs with more than 2 duplicates, more than 5 subscribers and more than 5 comments at http://people.ubuntu.com/~brian/reports/ [18:13] Additionally, you can modify the output of bugnumbers - formats available include just the bug numbers, urls, moinmoin wiki markup, html to name a few [18:14] You can also check out statistics for your package via 'bugnumbers -p gnome-power-manager --stats -C' where -C includes closed bug reports [18:14] Are there any questions about buginfo or bugnumbers? [18:16] bdmurray: QUESTION: Do the "bughelper python-launchpad-bugs" support Proxy Server ? [18:16] thekorn: Do you know the answer to that? [18:16] phoenix24_, I did not try it with the latest code, [18:17] but we had a bugreport on this in the past [18:17] but I'm not sure [18:17] bdmurray: I think does not works [18:18] Okay, we'll look into that then. Anything else? [18:19] bdmurray: QUESTION: could you elaborate on the usage of -l? what urls can you/ are you supposed to give it? [18:20] yuriy: you can give it any valid search in Launchpad. Let's say we wanted to find bugs tagged apport-bug with more than 2 attachments. We could use 'bugnumbers -l --na ">2"' [18:21] It'd be useful to use a url search in this case because those bugs be reported about multiple packages. [18:22] So your starting point really depends on the scope of bug reports you want to find. [18:22] bdmurray: so you would just search whatever you want on launchpad, then copy/paste the resulting URL? [18:23] yuriy: that's correct the advantage here is that you could have it then output into html or moinmoin markup or add an additional filter that doesn't exist in launchpad [18:23] Does that help? [18:23] bdmurray: yeah, thanks [18:24] bdmurray: QUESTION: is there API documentation online for python-launchpad? [18:24] yuriy: yes, we'll get to that shortly [18:24] moving on [18:24] bughelper, the application, searches bug reports and attachments for a specific string and provides with a clue about that bug === emgent`work is now known as emgent [18:25] clue files use a separate bzr branch bughelper-data and are stored on your local disk in ~/.bughelper/packages [18:25] this is a separate project in Launchpad - https://code.launchpad.net/bughelper-data/ and anyone in the bugsquad can add clues for packages so feel free to add clues for your package [18:26] et's have a look at '~/.bughelper/packages/bughelper.info' as an example [18:26] this file is also online at http://tinyurl.com/2zwm7a [18:26] as you can see clue-file are in a xml format and can contain multiple clues [18:27] you can combine operations by using logical operators like 'and' or 'or' [18:27] this is done in the "contains" portion of the clue file [18:27] Regular Expressions are also supported as you can see in the first clue, this clue matches all bugs with 'importance' set to 'Undecided' and which are tagged with 'xpath' or 'commandline' [18:28] When a bug with those attributes are found we'll be presented with the hint in [18:29] This can be useful for finding duplicate bug reports or managing bug workflow [18:29] So a crash report might have a specifc string in it and we can search all bug reports in a package for that string [18:29] Or the kernel team wants confirmed or triaged bugs assigned to a specific team [18:29] bdmurray, QUESTION: can you give us an example so that we can see it live? [18:30] Here is the output of a matched clue: [18:30] http://launchpad.net/bugs/191834 [update-manager (Ubuntu): New/Undecided] - This is expected when someone is running a development release of Ubuntu [18:31] We are presented with a link to the matched bug report and a hint as to what the issue might be [18:31] pranith: Is that what you are looking for? [18:32] Writing clue files is a way for us to easily share our knowledge with other bug triagers [18:32] bdmurray, how do i get this bug report using bughelper? [18:32] bdmurray, ok [18:32] bdmurray, i got it now [18:32]