| === astro76_ is now known as astro76 | ||
| === neversfelde|mobi is now known as neversfelde | ||
| dennda | Ah finally... | 13:07 |
|---|---|---|
| dennda | Next Lesson in 01:53h? | 13:07 |
| dennda | Is that correct? | 13:08 |
| Unksi | in 2:53h | 13:10 |
| dennda | oh, yes | 13:17 |
| dennda | sorry | 13:17 |
| Unksi | np | 13:17 |
| === never|mobi is now known as neversfelde | ||
| warp10 | Hi all! | 14:32 |
| db-keen | warp10: hello, you're 01:28h early | 14:33 |
| warp10 | db-keen: indeed! But early is better then late, imho ;) | 14:34 |
| * db-keen concedes (after all, he's been here for over 6 hours) | 14:35 | |
| warp10 | LOL | 14:36 |
| === asac_ is now known as asac | ||
| === emgent is now known as emgent`work | ||
| phoenix24 | Is the firefox-session already completed ? | 15:48 |
| asac | phoenix24: will start in 10 minutes | 15:48 |
| phoenix24 | this channel itself, I believe ? | 15:49 |
| asac | yes | 15:49 |
| phoenix24 | Oh! asac, you'd be delivering the talk :) | 15:52 |
| phoenix24 | Nice to meet ye! | 15:52 |
| asac | ;) | 15:53 |
| asac | ok we will start in 5 minutes on firefox 3 extension packaging!! | 15:55 |
| asac | maybe do the Prerequisites on https://wiki.ubuntu.com/MozillaTeam/Firefox3Extensions/Packaging now so you don't get distracted later on :) | 15:56 |
| db-keen | asac: will questions be in #ubuntu-classroom-chat as usual? | 15:58 |
| asac | db-keen: yes you can ask questions there | 16:00 |
| asac | Hi all! | 16:00 |
| daishujin | good morning! | 16:00 |
| asac | Welcome to Ubuntu Developer Week and welcome to the firefox extension world ;) | 16:01 |
| InsClusoe | asac: Thank you.. | 16:01 |
| asac | i will give first some basic background and then will go on to a practicing part | 16:01 |
| asac | lets get started | 16:02 |
| asac | packaging extensions is a good starter task as the technical side is rather straight-forward. | 16:02 |
| asac | 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:02 |
| asac | One important backdraft is on the communication part with upstream | 16:03 |
| asac | ffox extension upstreams usually don't care about properly releasing sources that include license information | 16:03 |
| asac | 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:03 |
| asac | 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 |
| asac | Thats why I created https://wiki.ubuntu.com/MozillaTeam/Firefox3Extensions | 16:04 |
| asac | At that place we should collect the required information needed to decently maintain a package _before_ we start to package one. | 16:05 |
| asac | 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:05 |
| asac | so much for the basics. | 16:06 |
| === neversfelde is now known as neversfelde_ | ||
| asac | if you have any questions afterthis session, you can always ask on #ubuntu-mozillateam | 16:07 |
| asac | ok, lets go for some practice ;) | 16:07 |
| asac | please do the "Before you package an extension" section on https://wiki.ubuntu.com/MozillaTeam/Firefox3Extensions/Packaging | 16:07 |
| asac | i'll wait a bit for those that have joined late to install the basics | 16:08 |
| === neversfelde_ is now known as neversfelde | ||
| asac | its important that you need mozilla-devscript package from my ppa (see wiki page) :) | 16:09 |
| asac | aeh mozilla-devscripts, sorry | 16:09 |
| asac | 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:10 |
| asac | sorry: above should have read "please do the Prerequisites on https://wiki.ubuntu.com/MozillaTeam/Firefox3Extensions/Packaging" | 16:11 |
| asac | any questions so far? any problems installing the packages? | 16:12 |
| asac | or branching? | 16:12 |
| * jetsaredim updating the sources.list | 16:12 | |
| asac | ok ... ill wait a few more minutes i guess :) | 16:13 |
| jetsaredim | these bzr commands take a while | 16:14 |
| asac | yes. thats known :) ... but should be pretty fast if you have bzr 1.0 or higher | 16:14 |
| Grazieno | jetsaredim: yes | 16:14 |
| barcc | ok | 16:14 |
| asac | so ubufox.upstream will be our upstream source code we use to practice | 16:15 |
| asac | we will produce a package called "myubufox" based on that :) | 16:15 |
| asac | let me know when you are ready ;) | 16:16 |
| Grazieno | asac: I'm ready...I think :) | 16:16 |
| phoenix24 | Ready! | 16:16 |
| asac | yeah great. | 16:17 |
| asac | so the first approach is to package .xpi files directly | 16:17 |
| asac | we usually don't want to package .xpi files, but if upstream doesn't release proper sources, we can still do it | 16:17 |
| asac | to produce an ubufox.xpi, please change to the ubufox.upstream directory and run | 16:17 |
| asac | "sh build.sh" | 16:17 |
| asac | 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:18 |
| asac | lets assume that the package has version 0.1 ... then create a directory myubufox-0.1 | 16:19 |
| asac | and copy the ubufox.xpi into that directory | 16:19 |
| asac | the name of the .xpi file doesn't matter much, so you can just keep it | 16:20 |
| asac | just to ensure that you have the right directory layout, here its how it looks for me now: http://paste.ubuntu.com/4843/ | 16:20 |
| asac | if you are not yet there, let me know :) | 16:21 |
| asac | ok ... next create an orig.tar.gz out of that | 16:21 |
| asac | tar cvzf myubufox_0.1.orig.tar.gz myubufox-0.1/ | 16:22 |
| Grazieno | asac: ok | 16:22 |
| phoenix24 | asac: ok! | 16:22 |
| asac | the XPI.TEMPLATE you branched further above is a pretty good template and should work for a lot of extensions | 16:22 |
| asac | so just copy the debian directory out of it into your myubufox-0.1 directory | 16:23 |
| asac | like: cp -r XPI.TEMPLATE/debian myubufox-0.1/debian | 16:23 |
| asac | my ubufox directory looks now like: http://paste.ubuntu.com/4845/ | 16:24 |
| phoenix24 | yes! | 16:25 |
| asac | ok lets look at the debian/rules ... at best open it in an editor | 16:25 |
| asac | 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 |
| Grazieno | asac: phoenix24 ok! | 16:26 |
| asac | MOZ_EXTENSION_PKG := example-extension => MOZ_EXTENSION_PKG := myubufox | 16:26 |
| asac | for the second example later, we make use of MOZ_XPI_BUILD_COMMAND as well, but for simple .xpi thats not needed | 16:27 |
| asac | ok, upon request here the folder structure i pastebined above (for the logs) | 16:28 |
| asac | $ find myubufox-0.1/ | 16:28 |
| asac | myubufox-0.1/ | 16:28 |
| asac | myubufox-0.1/debian | 16:28 |
| asac | myubufox-0.1/debian/compat | 16:28 |
| asac | myubufox-0.1/debian/rules | 16:28 |
| asac | myubufox-0.1/debian/copyright | 16:28 |
| asac | myubufox-0.1/debian/control | 16:28 |
| asac | myubufox-0.1/debian/changelog | 16:28 |
| asac | myubufox-0.1/ubufox.xpi | 16:28 |
| asac | thats how it looked like before we started looking at the debian/rules file | 16:28 |
| asac | 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 |
| asac | 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 |
| asac | ok, i assume that you have changed the package name in debian/rules? | 16:29 |
| Grazieno | asac: yes! | 16:30 |
| phoenix24 | yes! | 16:30 |
| asac | ok good ... then we need to fix debian/control | 16:31 |
| asac | its again just the package name. for our case we use myubufox for Source: as well as for Package: | 16:32 |
| asac | usually you would fill in a good package description, set a proper maintainer as well, but we don't need this for practice | 16:32 |
| asac | further the section might be wrong, as there might be office extensions and so on | 16:33 |
| asac | ok after fixing the debian/control file we are pretty much done | 16:35 |
| asac | for me it looks like this now: | 16:35 |
| asac | Source: myubufox | 16:35 |
| asac | Section: web | 16:35 |
| asac | Priority: optional | 16:35 |
| asac | Maintainer: Yourname <your@email.tld> | 16:35 |
| asac | Build-Depends: debhelper (>= 5), cdbs, mozilla-devscripts (>= 0.5~) | 16:35 |
| asac | XS-Vcs-Bzr: https://code.launchpad.net/~LPID/firefox-extensions/example-extension.ubuntu/ | 16:35 |
| asac | Standards-Version: 3.7.3 | 16:35 |
| asac | Package: myubufox | 16:35 |
| asac | Architecture: all | 16:35 |
| asac | Depends: firefox | firefox-3.0 | firefox-2 | 16:35 |
| asac | Description: one line for short description Long descriptions can span multiple lines . and as above empty lines | 16:35 |
| asac | well .. some linebreaks removed for the extensions | 16:36 |
| asac | but you get the point i guess | 16:36 |
| asac | i just changed the Source: and Package: line | 16:36 |
| asac | ok last thing: fix the version and the package name in changelog | 16:37 |
| asac | .e.g debian/changelog | 16:37 |
| === tsmithe` is now known as tsmithe | ||
| asac | and of course your name | 16:37 |
| asac | are you ready? | 16:38 |
| phoenix24 | yes! | 16:38 |
| asac | then give it a spin and produce your binary test package :) | 16:38 |
| asac | just run: debuild -b | 16:38 |
| Grazieno | ok | 16:38 |
| asac | the output i get during that build is like: http://paste.ubuntu.com/4847/ | 16:39 |
| asac | at the end of the build i get some lintian warning/errors: | 16:40 |
| asac | E: myubufox_0.1-1_i386.changes: bad-distribution-in-changes-file UNRELEASED | 16:40 |
| asac | E: myubufox: copyright-should-refer-to-common-license-file-for-lgpl | 16:40 |
| asac | W: myubufox: maintainer-not-full-name Yourname | 16:40 |
| asac | W: myubufox: new-package-should-close-itp-bug | 16:40 |
| asac | W: myubufox: wrong-bug-number-in-closes l3:#XXXXXX | 16:40 |
| asac | the first error would be fixed by using hardy instead of UNRELEASED | 16:40 |
| asac | and the second one, by filling the debian/copyright file with proper content | 16:40 |
| asac | the others should be self-explanatory | 16:41 |
| asac | but we don't need to fix them ;) | 16:41 |
| asac | now | 16:41 |
| asac | ok ... do you all have a myubufox_0.1-1_all.deb now? | 16:42 |
| Grazieno | asac: yes | 16:42 |
| asac | Grazieno: congrats!! | 16:42 |
| asac | you win ;) | 16:43 |
| Grazieno | asac: :) | 16:43 |
| asac | 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:43 |
| asac | but it should work :) | 16:44 |
| asac | (well maybe you need to uninstall the main ubufox package first, because they have the same extension id) | 16:44 |
| asac | ok ... lets go on with second approach then (which should be quicker as we know how it works a bit) | 16:46 |
| Grazieno | asac: How can I see the extension in firefox? Is it possible? | 16:46 |
| asac | Grazieno: well ... you need to uninstall the ubufox package first | 16:46 |
| asac | then you should see the new one | 16:47 |
| asac | (they conflict and firefox will just display one) | 16:47 |
| asac | ok the second approach is to use the realy ubufox sources | 16:47 |
| asac | and we will use bzr for real :) | 16:48 |
| asac | to start you create a package branch locally thats based on the ubufox.upstream branch you have | 16:48 |
| asac | just do: bzr branch ubufox.upstream myubufox.ubuntu | 16:48 |
| asac | that should create a new directory "myubufox.ubuntu" | 16:48 |
| asac | now the same procedure as before: copy the debian/ directory from the XPI.TEMPLATE directory into it | 16:49 |
| asac | cp -r XPI.TEMPLATE/debian myubufox.ubuntu/debian | 16:49 |
| asac | you can also use the debian directory from the other package we created | 16:49 |
| asac | so cp -r myubufox-0.1/debian/ myubufox.ubuntu/debian | 16:50 |
| asac | now commit those changes to your packaging branch and push it to launchpad ;) | 16:50 |
| asac | https://wiki.ubuntu.com/MozillaTeam/Firefox3Extensions/Packaging | 16:51 |
| asac | ^^ thats the last step in section "Packaging Procedure" | 16:51 |
| asac | you are still up? | 16:51 |
| asac | ;) | 16:51 |
| asac | or should i wait a bit ? | 16:51 |
| asac | 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:52 |
| asac | you can enable that by setting a proper build command in debian/rules | 16:53 |
| asac | conventiently ubufox has a build.sh script to produce the .xpi ... so you can just enable: | 16:54 |
| asac | #MOZ_XPI_BUILD_COMMAND = sh build.sh | 16:54 |
| asac | => | 16:54 |
| asac | MOZ_XPI_BUILD_COMMAND = sh build.sh | 16:54 |
| asac | after that edit you can commit this to your packaging branch like: | 16:55 |
| asac | bzr commit -m "* enable sh build.sh to build the .xpi" debian/rules | 16:55 |
| asac | ok, to build the package, just run debuild -b again | 16:56 |
| asac | if you have that ... then we are through! | 16:56 |
| asac | if you couldn't finish everything, but want to learn more, you can always join #ubuntu-mozillateam and ask questions | 16:57 |
| asac | 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 |
| asac | one more question which i find important: | 16:58 |
| asac | jetsaredim> Q: what is the reason to package an extension vs letting people just get them from the addons.mozilla site? | 16:58 |
| Wutz | Thanks for the lesson | 16:58 |
| asac | thats frequently asked. but the answer is simple. The same reason why we want to package everything | 16:58 |
| asac | we can better integrate it and quality assure it | 16:59 |
| jetsaredim | fair enough | 16:59 |
| Alucard | Prof. Asac: thank you very much! | 16:59 |
| asac | and even auto-updates are not wanted in many environemtns | 16:59 |
| asac | (like corporations) | 16:59 |
| asac | they want to test and only get tested stuff | 16:59 |
| asac | which is what we provide | 16:59 |
| asac | thanks all! | 16:59 |
| phoenix24 | Thanks! | 16:59 |
| asac | looking forward to see you all in #ubuntu-mozillateam helping to get a lot of extensions ready for hady | 16:59 |
| asac | hardy | 16:59 |
| Grazieno | asac: Thanks a lot! | 16:59 |
| asac | you can make a big difference! | 16:59 |
| barcc | asac: thanks! | 17:00 |
| * asac hugs you all | 17:00 | |
| asac | next one please ;) | 17:00 |
| asac | \o/ | 17:00 |
| liw | I guess it's my turn now | 17:00 |
| liw | I'm going to lead a session on writing scripts for automated desktop testing | 17:01 |
| liw | 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 |
| liw | but let's start | 17:02 |
| liw | the first part of this session is going to be about running existing scripts | 17:03 |
| Grazieno | liw: I can do it | 17:03 |
| liw | Grazieno, thank you! | 17:03 |
| liw | 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:04 |
| liw | 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 |
| liw | AT-SPI only works in GNOME, not in KDE (and may work in Xfce, but I haven't investigated) | 17:05 |
| liw | to enable it, go to System -> Preferences -> Universal Access -> Assistive Technology, then tick the "Enable..." checkbox | 17:06 |
| liw | you may want to set up a dedicated account for this, though | 17:06 |
| liw | or run things in kvm, or virtualbox, or another emulator | 17:06 |
| liw | 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:07 |
| liw | 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:08 |
| liw | 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 |
| liw | 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:09 |
| liw | 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:10 |
| liw | anyone here already have an environment where they have assistive technology enabled? | 17:11 |
| Grazieno | liw: ok, I'll be back :) | 17:11 |
| liw | if anyone else wants to enable it, now would be a good time, I can wait a few minutes | 17:11 |
| Grazieno | liw: ready! | 17:12 |
| liw | https://wiki.ubuntu.com/Testing/Automation/DogtailTutorial has instructions for enabling AT and is generally useful for this automated testing stuff, please bookmark | 17:13 |
| liw | ok, next step is to install the python-dogtail package | 17:14 |
| liw | (please do so now if you want to experiment today) | 17:14 |
| liw | also, we're going to be using a sample script for gThumb, so install that, too, if you don't have it already | 17:14 |
| liw | 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:15 |
| liw | 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:16 |
| eddyMul | liw: thanks | 17:17 |
| liw | those wanting to try running a script, download the gthumb.tar.gz file from the Coverage page (url above) and unpack it | 17:17 |
| liw | 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 |
| liw | magical things should now be happening | 17:18 |
| liw | is anyone seeing magic? | 17:18 |
| liw | or is anyone trying to see magic and failing? | 17:18 |
| Grazieno | liw: failing.. | 17:19 |
| charliecb | hi | 17:19 |
| liw | Grazieno, what's the error? | 17:19 |
| Grazieno | liw: http://paste.ubuntu.com/4851/ | 17:20 |
| liw | Grazieno, weird... are you running this in hardy? | 17:20 |
| Grazieno | liw: yes :) | 17:21 |
| Grazieno | liw: wrong? | 17:21 |
| liw | Grazieno, hardy is right | 17:21 |
| eddyMul | liw: gutsy is wrong? :( | 17:22 |
| liw | eddyMul, I know hardy is right, but I don't know if gutsy will work or not | 17:22 |
| eddyMul | liw: failed for me: http://paste.ubuntu.com/4852/ :( | 17:22 |
| liw | 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 |
| liw | is that ok? | 17:23 |
| Grazieno | liw: yes! | 17:23 |
| eddyMul | liw: yes. carry on. | 17:24 |
| liw | I should'v emade a movie about how the gthumb-preferences.py script runs and opens gthumb and toggles various preferences | 17:24 |
| liw | you'll have to just believe me that it does... | 17:24 |
| liw | the crucial bit here would have been to get it to work so that we can progress to writing new scripts | 17:25 |
| liw | but well, we'll fix that later | 17:25 |
| Grazieno | <jimcooncat>QUESTION: I see dogtail can work with GTK-enabled OpenOffice; is this the default in gutsy? | 17:25 |
| liw | 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:26 |
| liw | jimcooncat, I don't know if that is the default in gutsy, sorry | 17:27 |
| heno_ | It is, yes | 17:27 |
| jimcooncat | thanks, this will be very useful | 17:27 |
| liw | but more generally speaking, AT-SPI / dogtail should be able to work with any gtk+ application, with few exceptions | 17:27 |
| heno_ | I've run dogtail scripts on openoffice | 17:27 |
| liw | oh, and to see the exit code of a script, run this right after the script: echo $? | 17:28 |
| heno_ | openoffice also works fairly well with Orca the screen reader | 17:28 |
| liw | $? is the shell's charming way to express "exit code of the previous command2 | 17:28 |
| heno_ | and that relies on AT-SPI | 17:28 |
| heno_ | (sorry to interrupt) | 17:28 |
| liw | 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 |
| liw | 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:29 |
| liw | uncompress with unlzma, and run with: kvm -m 512 -hda autoguitest.qemu -snapshot | 17:30 |
| liw | 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 |
| liw | but continuing to writing scripts | 17:31 |
| liw | er, not yet | 17:31 |
| liw | the username is "tomjon", the password is "password1" (the industry standard password!) | 17:31 |
| liw | and now, writing scripts | 17:31 |
| liw | 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 |
| liw | dogtail seems to be missing almost all mouse events, but gets keyboard events reliably, so it's best to stick to keyboarding | 17:32 |
| liw | 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 |
| liw | this sounds too easy and wonderful to be true | 17:33 |
| liw | and it is | 17:33 |
| liw | the scripts pretty much always need some manual tweaking | 17:33 |
| liw | http://paste.ubuntu.com/4837/ has one example script | 17:34 |
| liw | straight from dogtail-recorder | 17:34 |
| liw | the first problem is that this script does not actually start the program, it assumes the program is already running | 17:34 |
| liw | we can fix this by replacing the first two "focus...." lines with "run('gcalctool')" | 17:35 |
| liw | http://paste.ubuntu.com/4836/ -- this is the script after editing -- there's more changes, I'll go through them next | 17:35 |
| liw | 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 |
| liw | so, at least for now, we're keeping things simple | 17:37 |
| liw | 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:37 |
| liw | 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 |
| liw | and we want to be able to run the scripts from release to release, if possible | 17:38 |
| liw | less work for testers... :) | 17:38 |
| liw | so, I removed some useless keyboarding from the beginning of the script | 17:39 |
| liw | the final difference is that dogtail-recorder inserts focus.something stuff in various places, and it is meant to do that | 17:39 |
| liw | those focus things affect dogtails's idea of what has focus, not the window manager's | 17:39 |
| liw | 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 |
| liw | so the new version of the script is much shorter, and just toggles the various settings in the View menu of gcalctool | 17:40 |
| liw | any questions about this so far? | 17:41 |
| liw | 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:41 |
| Grazieno | liw: it's ok for me | 17:42 |
| jimcooncat | So I can intersperse python code with the dogtail commands? | 17:42 |
| liw | oh, right: the dogtail scripts are pure Python code, which calls the dogtail Python library | 17:42 |
| liw | so if you know what you're doing, you can add any Python stuff in there that you wish | 17:42 |
| pranith | hello | 17:43 |
| pranith | is this where the bughelper session going to be held? | 17:43 |
| liw | 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 |
| liw | 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:44 |
| liw | 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:45 |
| pixelpapst | pranith: you're interrupting a running session. join #ubuntu-classroom-chat and i'll fill you in | 17:46 |
| pranith | oops, sorry everyone | 17:46 |
| liw | 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:46 |
| liw | 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:47 |
| liw | so, any questions now? | 17:48 |
| allinsane | can't get dogtail to run do they have an IRC? | 17:48 |
| liw | #dogtail on this IRC network, but I don't know how active that is | 17:48 |
| jimcooncat | Can dogtail read text from a widget back into a python variable? | 17:49 |
| Grazieno | <phoenix24_> QUESTION: Where can I get the schedule for the #ubuntu-classroom ? | 17:49 |
| liw | jimcooncat, in theory, yes, through the at-spi interfaces, but I'm not sure how to do that | 17:49 |
| liw | phoenix24_, https://wiki.ubuntu.com/UbuntuDeveloperWeek | 17:49 |
| liw | ok, I think we're about done, then ... ahead of time, even (my keyboard is smoking and my fingers are numb...) | 17:52 |
| jimcooncat | liw, what kinds of script would you like to see on your wiki page? | 17:53 |
| liw | jimcooncat, any script that verifies that some part of a GUI application in Ubuntu works | 17:54 |
| liw | jimcooncat, anything that interests you is good, and we're most interested in stuff that is included in the default installation | 17:54 |
| liw | 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:55 |
| liw | thank you, everyone | 17:56 |
| * liw bows and exits gracefully | 17:56 | |
| Grazieno | liw: very thanks! | 17:56 |
| barcc | liw: thanks | 17:56 |
| Grazieno | a few minutes until Brian Murray and Markus Korn with Bughelper | 17:58 |
| bdmurray | Grazieno: Shall we start now? | 18:00 |
| thekorn | I'm ready :) | 18:01 |
| bdmurray | 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 |
| Grazieno | bdmurray: yes, sure! | 18:02 |
| bdmurray | 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:02 |
| bdmurray | thekorn has setup a ppa for the latest version of them and you can get them by adding * | 18:03 |
| bdmurray | 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 |
| bdmurray | to your /etc/apt/sources.list, and replace 'hardy' with the version of ubuntu you use | 18:03 |
| bdmurray | Then you can should update via 'sudo apt-get update' and install bughelper and python-launchpad-bugs | 18:04 |
| thekorn | pranith asked: 'what all packages do we need to install to get started?' | 18:05 |
| bdmurray | So what is python-launchpad-bugs? It is a python interface to work with bugs, and blueprints to a degree, in Launchpad. | 18:05 |
| thekorn | sorry ;) | 18:05 |
| bdmurray | You should install bughelper and python-launchpad-bugs to get started. | 18:06 |
| bdmurray | Bughelper is a suite of utilies that uses python-launchpad-bugs to help you find specific bugs in Launchpad. | 18:06 |
| bdmurray | We'll start off talking about the bughelper suite and then move on to python-launchpad-bugs. | 18:06 |
| bdmurray | The bughelper suite has 3 main applications - buginfo, bugnumbers and bughelper | 18:07 |
| bdmurray | buginfo is designed for reporting information about one specifc bug | 18:07 |
| bdmurray | for example 'buginfo --title 38442' will return the bugs title | 18:07 |
| bdmurray | While bugnumbers is designed for returning a list of bugs based off a query in launchpad | 18:08 |
| bdmurray | Starting points for a query include '-p' for a package in Ubuntu, '-l' for a url of a search in Launchpad | 18:09 |
| bdmurray | Or now you can search a whole distribution using '-D' or an upstream project using '-P' | 18:10 |
| bdmurray | Using those starting points you can then filter using features in Launchpad (bug status and importance) and some not in Launchpad | 18:10 |
| bdmurray | some features not in Launchpad are querying on the quantity of duplicates, subscribers, comments, attachments | 18:11 |
| bdmurray | in addition to the date or author of the last comment or the bug reporter | 18:11 |
| bdmurray | 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:11 |
| bdmurray | 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:12 |
| bdmurray | 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 |
| bdmurray | 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:13 |
| bdmurray | 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 |
| bdmurray | Are there any questions about buginfo or bugnumbers? | 18:14 |
| phoenix24_ | bdmurray: QUESTION: Do the "bughelper python-launchpad-bugs" support Proxy Server ? | 18:16 |
| bdmurray | thekorn: Do you know the answer to that? | 18:16 |
| thekorn | phoenix24_, I did not try it with the latest code, | 18:16 |
| thekorn | but we had a bugreport on this in the past | 18:17 |
| thekorn | but I'm not sure | 18:17 |
| Grazieno | bdmurray: I think does not works | 18:17 |
| bdmurray | Okay, we'll look into that then. Anything else? | 18:18 |
| yuriy | bdmurray: QUESTION: could you elaborate on the usage of -l? what urls can you/ are you supposed to give it? | 18:19 |
| bdmurray | 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 <lpsearch> --na ">2"' | 18:20 |
| bdmurray | It'd be useful to use a url search in this case because those bugs be reported about multiple packages. | 18:21 |
| bdmurray | So your starting point really depends on the scope of bug reports you want to find. | 18:22 |
| yuriy | bdmurray: so you would just search whatever you want on launchpad, then copy/paste the resulting URL? | 18:22 |
| bdmurray | 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 |
| bdmurray | Does that help? | 18:23 |
| yuriy | bdmurray: yeah, thanks | 18:23 |
| yuriy | bdmurray: QUESTION: is there API documentation online for python-launchpad? | 18:24 |
| bdmurray | yuriy: yes, we'll get to that shortly | 18:24 |
| bdmurray | moving on | 18:24 |
| bdmurray | bughelper, the application, searches bug reports and attachments for a specific string and provides with a clue about that bug | 18:24 |
| === emgent`work is now known as emgent | ||
| bdmurray | clue files use a separate bzr branch bughelper-data and are stored on your local disk in ~/.bughelper/packages | 18:25 |
| bdmurray | 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:25 |
| bdmurray | et's have a look at '~/.bughelper/packages/bughelper.info' as an example | 18:26 |
| bdmurray | this file is also online at http://tinyurl.com/2zwm7a | 18:26 |
| bdmurray | as you can see clue-file are in a xml format and can contain multiple clues | 18:26 |
| bdmurray | you can combine operations by using logical operators like 'and' or 'or' | 18:27 |
| bdmurray | this is done in the "contains" portion of the clue file | 18:27 |
| bdmurray | 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:27 |
| bdmurray | When a bug with those attributes are found we'll be presented with the hint in <info> | 18:28 |
| bdmurray | This can be useful for finding duplicate bug reports or managing bug workflow | 18:29 |
| bdmurray | 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 |
| bdmurray | Or the kernel team wants confirmed or triaged bugs assigned to a specific team | 18:29 |
| pranith | bdmurray, QUESTION: can you give us an example so that we can see it live? | 18:29 |
| bdmurray | Here is the output of a matched clue: | 18:30 |
| bdmurray | http://launchpad.net/bugs/191834 [update-manager (Ubuntu): New/Undecided] - This is expected when someone is running a development release of Ubuntu | 18:30 |
| bdmurray | We are presented with a link to the matched bug report and a hint as to what the issue might be | 18:31 |
| bdmurray | pranith: Is that what you are looking for? | 18:31 |
| bdmurray | Writing clue files is a way for us to easily share our knowledge with other bug triagers | 18:32 |
| pranith | bdmurray, how do i get this bug report using bughelper? | 18:32 |
| pranith | bdmurray, ok | 18:32 |
| pranith | bdmurray, i got it now | 18:32 |
| bdmurray | pranith: via 'bughelper -p <package>' | 18:32 |
| bdmurray | you can add additional filters too like if you only wanted to search new bugs for a specific string | 18:33 |
| bdmurray | that would be 'bughelper -p <package> --status New' | 18:33 |
| pranith | bdmurray, thanks, i got it | 18:33 |
| bdmurray | We have time for one more question about bughelper before moving on to python-launchpad-bugs | 18:34 |
| bdmurray | I'll hand it over to thekorn then | 18:35 |
| thekorn | ok, let's have a deeper look at | 18:35 |
| thekorn | == python-launchpad-bugs == | 18:35 |
| thekorn | 18:35 | |
| thekorn | python-launchpad-bugs allows you to access bugs.launchpad.net via python. This python module is used by many tools like apport, ubuntu-dev-tools and of course bughelper and bugnumbers. | 18:35 |
| thekorn | 18:36 | |
| thekorn | Let me give you a short "Howto" on using python-launchpad-bugs. This requires some basic understanding of python. | 18:36 |
| thekorn | 18:36 | |
| thekorn | Let's start a python session and do some general preparation: | 18:36 |
| thekorn | >>> import launchpadbugs.connector as Connector | 18:36 |
| thekorn | >>> from launchpadbugs.basebuglistfilter import URLBugListFilter | 18:37 |
| thekorn | 18:37 | |
| thekorn | Ok, so far so good, let's get a list of all open bugs in the bughelper project | 18:37 |
| thekorn | >>> BugList = Connector.ConnectBugList() | 18:37 |
| thekorn | >>> bl = BugList("https://bugs.launchpad.net/bughelper/+bugs") | 18:37 |
| thekorn | Each member of this list has attributes like 'bugnumber', 'url', 'status' and 'importance'. | 18:38 |
| thekorn | 18:38 | |
| thekorn | Getting filtered lists is also very easy: | 18:38 |
| thekorn | >>> bug_filter = URLBugListFilter() | 18:38 |
| thekorn | >>> bug_filter.add_option("status", ("New","Confirmed")) | 18:39 |
| thekorn | >>> bug_filter.add_option("importance", ("Medium",)) | 18:39 |
| thekorn | >>> bl = BugList(bug_filter("https://bugs.launchpad.net/bughelper/+bugs")) | 18:39 |
| thekorn | It's also possible to use any python functions as a filter, but this would go too far right now. | 18:40 |
| thekorn | 18:40 | |
| thekorn | any questions so far? | 18:41 |
| pranith | thekorn, this is how the bughelper gets the list of bugs? | 18:41 |
| thekorn | pranith, yes bughelper/bugnumber is using python-launchpad-bugs to get buglists etc | 18:42 |
| thekorn | 18:42 | |
| thekorn | Okay, that's all about bug lists for now, for more information please visit http://tinyurl.com/yrmze9 | 18:42 |
| thekorn | 18:43 | |
| thekorn | yuriy, ^ this is one part of our API documentation | 18:43 |
| thekorn | Now, let's have a look on how to handle bugreports with python-launchpad-bugs: | 18:43 |
| rzr | hi there | 18:44 |
| thekorn | >>> Bug = Connector.ConnectBug() | 18:44 |
| thekorn | >>> b = Bug(123456) | 18:44 |
| thekorn | The argument of Bug() can either be a bug number, an url of a bugreport or an element of a BugList-object | 18:44 |
| thekorn | 18:44 | |
| thekorn | There is a huge amount of attributes of a bug-object. You can access almost all information of a bugreport. | 18:45 |
| thekorn | Let's have a look at some examples: | 18:45 |
| thekorn | >>> b.url | 18:45 |
| thekorn | 'https://bugs.launchpad.net/ubuntu/+source/xine-lib/+bug/123456' | 18:45 |
| thekorn | >>> print b.subscriptions | 18:45 |
| thekorn | set([<user ken-paulsen (Valyander)>, [...], <user kubuntu-sujee (LinuxLover)>]) | 18:45 |
| thekorn | >>> print b.comments | 18:45 |
| thekorn | [<Comment #1 by kubuntu-sujee on 2007-07-03 07:17:39 UTC>,[...],<Comment #6 by bersace on 2007-09-30 22:04:49 UTC>] | 18:46 |
| thekorn | For a list of all attributes of a Bug-object and some examples on using these attributes have a look at http://tinyurl.com/2mboze | 18:46 |
| thekorn | 18:46 | |
| thekorn | So far, we have only read bugs, but with python-launchpad-bugs you can also change bugreports in a very easy way! | 18:46 |
| thekorn | First of all, only registered user can change bugreports in launchpad, so let's authenticate with our account data: | 18:46 |
| thekorn | >>> Bug.authentication = {"password":"<your-password>","email":"<your-login-email>"} | 18:47 |
| thekorn | There is also another possibility of authentication: you can use a mozilla cookie-file (this for example works for cookies created by epiphany or firefox < 3.0) | 18:47 |
| thekorn | >>> Bug.authentication = "/path/to/the/cookiefile/cookie.txt" | 18:47 |
| thekorn | 18:47 | |
| thekorn | Now I want to show you, as an example, how to change the status of a bug: | 18:48 |
| thekorn | >>> demo = Bug(193948) | 18:48 |
| thekorn | >>> demo.status | 18:48 |
| thekorn | 'New' | 18:48 |
| thekorn | >>> demo.status = "Invalid" | 18:48 |
| thekorn | >>> demo.commit() | 18:48 |
| thekorn | Until you call the 'commit()'-method all changes are local, with 'commit()' you try to commit all changes you did locally to launchpad. | 18:49 |
| thekorn | 18:49 | |
| thekorn | yuriy> thekorn: QUESTION: can you authenticate using an ssh key? | 18:49 |
| thekorn | no, py-lp-bugs do not support this | 18:50 |
| thekorn | 18:50 | |
| thekorn | Like this you can for example change the description, add comments or attachments, subscribe to a bug or change the tags. | 18:50 |
| thekorn | 18:51 | |
| thekorn | Let's have a look at two more complex examples. | 18:51 |
| thekorn | You can get this scripts here: https://wiki.ubuntu.com/BugHelper/Dev/python-launchpad-bugs/Examples | 18:51 |
| thekorn | These two scripts show you how to use python-launchpad-bugs to do things you can't do in launchpad itself. | 18:51 |
| thekorn | 18:51 | |
| thekorn | Let's say you are a developer of an upstream project in launchpad. When you create a package of your tool and build it for ubuntu, bugs in ubuntu are closed by the (LP: #123456) syntax, but upstream bugs were not. The first example also closes this upstream bugs in your project and adds a comment containing the changelog-entry. | 18:51 |
| thekorn | 18:52 | |
| thekorn | I wrote the second example few days ago when we had all these python-central bugreports. This example returns you a list of bugs created in ubuntu after 2008-02-18 and filters this list by the following criteria: | 18:52 |
| thekorn | * 'pycentral' or 'python-central' in the content of the bugreport (that's no magic, launchpad can do this :)) | 18:52 |
| thekorn | * an attachment called 'DpkgTerminalLog.gz' which contains 'pycentral' or 'python-central' (this is magic! no way to do this in launchpad) | 18:53 |
| thekorn | 18:54 | |
| thekorn | <RainCT> QUESTION: Since the last python-launchpadbugs update I get «AssertionError: Parsing of this page (https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=[.........]) is not supported by python-launchpad-bugs» when I run some scripts I had that used it... What changed? | 18:54 |
| thekorn | that's simple you need either the latest version in hardy, or the latest versions of py-lp-bugs from the team PPA | 18:55 |
| thekorn | because the way launchpad presents the data changes with almost evry update | 18:55 |
| thekorn | but it should be fixed with the latest version of py-lp-bugs | 18:56 |
| thekorn | 18:56 | |
| thekorn | RainCT, I hope this helps | 18:56 |
| thekorn | as an explanation | 18:56 |
| thekorn | let's move on | 18:57 |
| thekorn | 18:57 | |
| thekorn | As a last example I want to show you how to create a bugreport with python-launchpad-bugs, it's only one line of code! | 18:57 |
| thekorn | >>> b = Bug.New( | 18:57 |
| thekorn | ... product = {"name":"buglog-data"}, | 18:57 |
| thekorn | ... summary = "this class is almost over", | 18:57 |
| thekorn | ... description = "UDW rocks! - but we need more time to show all features of bughelper and py-lp-bugs") | 18:57 |
| thekorn | This creates a new bugreport in the 'buglog-data'-project, if you would like to file a bugreport in ubuntu use | 18:57 |
| thekorn | 'product = {"target": "ubuntu", "name": "my-package"}' | 18:58 |
| thekorn | 18:58 | |
| thekorn | Ok, that's all about python-launchpad-bugs for now, time for some questions! | 18:58 |
| thekorn | no questions? | 18:59 |
| bdmurray | I realize this is a lot to absorb and think about | 18:59 |
| mruiz | go go pedro_ ! | 18:59 |
| thekorn | yeah, | 19:00 |
| thekorn | 19:00 | |
| thekorn | If you would like to use bughelper and/or python-launchpadbugs and have any questions, or even better if you want to help us improving this two packages, this are ways to get in with us: | 19:00 |
| dholbach | thanks thekorn, thanks bdmurray - you guys ROCK! :) | 19:00 |
| forsaken_ | do other bug trackers have an API? | 19:00 |
| * thekorn hugs dholbach | 19:00 | |
| thekorn | * bughelper has a separate mailing list, bughelper@l.u.c | 19:00 |
| thekorn | * browse https://launchpad.net/python-launchpad-bugs and https://launchpad.net/bughelper to file bugreports or get the code | 19:00 |
| * dholbach hugs thekorn back | 19:00 | |
| thekorn | * for more information check out our wiki pages at https://wiki.ubuntu.com/BugHelper | 19:01 |
| thekorn | * and last but not least ping us in #ubuntu-bugs | 19:01 |
| pranith | thekorn, bdmurray thanks for the class. it was really informative | 19:01 |
| thekorn | DONE! | 19:01 |
| phoenix24_ | Thanks!! | 19:01 |
| barcc | thanks | 19:01 |
| bdmurray | Thanks for coming to our class. | 19:01 |
| thekorn | thanks for joining our session! | 19:01 |
| cody-somerville | woot :) | 19:02 |
| pedro_ | Hello, are we ready ? | 19:02 |
| dholbach | Next up is Pedro Villavivencio, member of the QA and the Desktop mafia! | 19:02 |
| === holloway_ is now known as holloway | ||
| dholbach | He promised to plug https://wiki.ubuntu.com/5-A-Day a couple of times, thanks a lot for that pedro_ :-) | 19:03 |
| dholbach | pedro_: the stage is yours :) | 19:03 |
| pedro_ | thanks dholbach! | 19:03 |
| * mruiz waves | 19:03 | |
| pedro_ | hello everybody | 19:03 |
| Iulian | Hi there! | 19:03 |
| pedro_ | how many people we have here, can you raise your hand? | 19:03 |
| sourcercito | howdy | 19:03 |
| phoenix24_ | Hi pedro_ ! | 19:03 |
| phoenix24_ | +1 | 19:03 |
| Iulian | I am | 19:03 |
| mruiz | _0/ | 19:03 |
| fvenegas_ | hi pedro! | 19:03 |
| forsaken_ | +1 | 19:03 |
| barcc | raise | 19:03 |
| Grazieno | +1 | 19:04 |
| soneil | hand | 19:04 |
| daishujin | +1 | 19:04 |
| pedro_ | good! ok i'll going to introduce you into the triage world | 19:04 |
| rzr | \o_ | 19:04 |
| pedro_ | Iulian: offered himself to moderate the questions | 19:04 |
| pedro_ | he's also a member of the bugsquad :-) | 19:04 |
| pranith | +1 | 19:05 |
| pedro_ | ok so what's "TRIAGE" all about | 19:05 |
| andres | _o/ | 19:05 |
| InsClusoe | +1 | 19:05 |
| pedro_ | we often explains that the "triage" is very similar to the process that people do at the hospitals and i'm referring to the process of separating the very badly wounded from those who are lightly wounded | 19:05 |
| pedro_ | for us it's the process of separating and identifying bugs that are most severe and useful for the developers to fix | 19:06 |
| rzr | does this mean separating the injured part of body ? | 19:06 |
| pedro_ | a bug became "triaged" when it have all the information required and it have an status and an importance | 19:07 |
| pedro_ | one of the teams that do this at Ubuntu is the BugSquad team | 19:07 |
| pedro_ | https://launchpad.net/~bugsquad | 19:08 |
| pedro_ | it's an open team and everybody can join | 19:08 |
| pedro_ | and you may also want to have a look to https://wiki.ubuntu.com/BugSquad/GettingInvolved if you have a doubt about it | 19:09 |
| pedro_ | we also have a mailing list (ubuntu-bugsquad) and a channel #ubuntu-bugs | 19:09 |
| pedro_ | ok, how the bugs are get reported into Ubuntu | 19:10 |
| pedro_ | One of the ways of reporting a bug to Ubuntu is using the "Help-> Report a problem" menu entry on the application you're having issues with | 19:10 |
| pedro_ | for example if you going to gedit now, you'll see that menu there | 19:11 |
| rzr | what about command lines applications ? can't we use reportbug like on debian ? I tried once on ubuntu | 19:11 |
| pedro_ | rzr: yes you can i'm going to there | 19:11 |
| rzr | ok | 19:12 |
| pedro_ | rzr: questions at #ubuntu-classroom-chat please :-) | 19:12 |
| pedro_ | ok if you want to report a bug with the command line you can use this command: | 19:12 |
| pedro_ | apport-cli -f -p PACKAGE , where PACKAGE is the name of the package you're having problems | 19:12 |
| pedro_ | example : apport-cli -f -p gedit | 19:12 |
| pedro_ | if you don't know the name of the package and the program is running you can try to report the bug with his PID like: | 19:13 |
| pedro_ | apport-cli -f -P PID | 19:13 |
| pedro_ | Both process will collect information about the version of Ubuntu the reporter is using, the application and the version of it | 19:14 |
| pedro_ | both ways are extremely recommended :-) | 19:14 |
| pedro_ | Another way of report bugs to Ubuntu is trough the Launchpad website | 19:14 |
| pedro_ | if you go to https://bugs.launchpad.net/ you'll see a red button that say something like "report a bug" | 19:15 |
| pedro_ | then you'll be asked for a summary, a description and you'll be asked to select a package if you know it | 19:16 |
| pedro_ | most of the time the people that report bugs this way, don't really know which package is the one containing the bug | 19:16 |
| pedro_ | so they select "Ubuntu" | 19:16 |
| pedro_ | which leads to having lot of reports without a package; you can see a tiny list here http://tinyurl.com/32l4gd | 19:17 |
| pedro_ | When you Don't have to file a bug report: | 19:18 |
| pedro_ | when it's a support request, like "i don't know how to do this", you can ask that at https://answers.launchpad.net/ubuntu | 19:18 |
| pedro_ | when it's a policy discussion or you have development ideas, this should be discussed at the ubuntu-devel-discuss mailing list | 19:19 |
| pedro_ | and of course when the bug is already filed | 19:20 |
| pedro_ | Since we most of the time didn't get too many good quality reports, we need to improve them | 19:21 |
| pedro_ | There's a few things you can do for improving a bug report | 19:21 |
| pedro_ | as i mentioned we get a lot of reports without a package and this is a really good task for new brave triagers | 19:22 |
| pedro_ | because most of the time those bugs are easy to reassign to the right package | 19:22 |
| pedro_ | we also have a documentation about it here: https://wiki.ubuntu.com/Bugs/FindRightPackage | 19:22 |
| pedro_ | so if you want to start triaging that's a really good first step | 19:23 |
| pedro_ | another way of improve a bug report is asking or documenting the steps on how to reproduce the bug | 19:24 |
| pedro_ | sometimes you'll find reports with a summary that say "I clicked here and it doesnt work" | 19:24 |
| pedro_ | what we need is they to answers questions like: | 19:25 |
| pedro_ | How can the problem be reproduced? | 19:25 |
| pedro_ | What actually happens when you follow these steps? | 19:25 |
| pedro_ | What would you expect to happen when you follow them? | 19:25 |
| pedro_ | All of them in much detail as possible | 19:26 |
| Iulian | <mirrado> QUESTION: Is there any command line utility to list all bugs related to a especific package? I mean something that could help in identifying duplicated bugs, etc | 19:26 |
| pedro_ | mirrado: yes, there's bughelper, bdmurray and thekorn gave a talk a couple of minutes ago about it :-) | 19:26 |
| pedro_ | Another thing that we should worry about is to see if the bug report has a descriptive summary | 19:27 |
| pedro_ | if not we should edit it | 19:27 |
| pedro_ | as i said , we find a lot of bugs with things like "Doesn't work" or " I don't know what i was doing" | 19:28 |
| Iulian | <eddyMul> QUESTION: can any registered LP user change a bug's title/summary? | 19:29 |
| pedro_ | so if we ask for steps on how to reproduce we can improve a lot the summary and the developers can read it and have a really good idea of what's going on | 19:29 |
| pedro_ | eddyMul: yes basically anyone | 19:29 |
| pedro_ | for change the summary and the title you have to do the following | 19:30 |
| pedro_ | on the launchpad page of a bug for example https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/194052 | 19:30 |
| pedro_ | on the left side there's a column that say "Edit description/tags" | 19:31 |
| pedro_ | if you click there you'll be redirected to the edit form and there you can edit all that | 19:31 |
| pedro_ | if you're editing the summary or the description please make sure it's really consistent | 19:32 |
| pedro_ | for example a description like "rhythmbox hangs when click on a previous podcast" | 19:32 |
| pedro_ | is way better than one like "just hanged" | 19:32 |
| pedro_ | it doesn't matter if it's too long :-) | 19:32 |
| pedro_ | another thing you should take care of when you do triaging is the status of the bug | 19:33 |
| pedro_ | all the status on Ubuntu are described here: https://wiki.ubuntu.com/Bugs/Status | 19:33 |
| pedro_ | and currently we have 9 status New, Incomplete, Invalid, Confirmed, Triaged, In Progress, Won't Fix, Fix Committed, and Fix Released | 19:34 |
| pedro_ | some of them may confuse people but i'll try to explain them and if you have a question about them just ask | 19:34 |
| pedro_ | New: When a bug is first reported the status of it is New meaning that no one has touch it yet and these kind of bugs are a good candidates for new triagers | 19:35 |
| pedro_ | Incomple: means that the bug is missing some information, like steps to reproduce the bug | 19:35 |
| pedro_ | s/Incomple/Incomplete | 19:35 |
| pedro_ | Confirmed: means that someone than the original report has the same issue (was able to reproduce the bug) or the that the bug has a minimum of debugging information on it | 19:37 |
| pedro_ | triaged: means that the bug has enough information for a developer to start working and fix the problem | 19:37 |
| pedro_ | the Triaged status can only be set by a member of the ubuntu-bugcontrol team | 19:38 |
| pedro_ | Progress: means that a developer or another person is working on a fix for it | 19:38 |
| pedro_ | Fix Committed: means that there's a fix for the bug committed on a development branch but it's not yet available on a Ubuntu official package | 19:39 |
| Iulian | <InsClusoe> QUESTION: So many people log bugs saying functionality is this way. Should be that way. What would be correct status for such 'bugs'? | 19:39 |
| Iulian | <InsClusoe> QUESTION: (continue) Should status be invalid or should it be new and have importance set to 'wishlist'? | 19:40 |
| pedro_ | InsClusoe: it depends if that functionality is not working as it should it's a valid bug | 19:40 |
| Iulian | <eddyMul> QUESTION: does the bug status suggest an "evolution" of the bug? Can I start filing with a bug with "Work In Progress" instead of New? (e.g when I'm submitting a patch) | 19:41 |
| pedro_ | InsClusoe: if they're asking for a new one , it should be Wishlist , but Wishlist is an Importance not a bug status :-) | 19:42 |
| pedro_ | eddyMul: no, better to set it as New and select the "patch" check box when you submit the patch to it | 19:43 |
| pedro_ | then a developer will take a look to it | 19:43 |
| Iulian | <InsClusoe> QUESTION: Who can edit importance of a bug? | 19:43 |
| pedro_ | if the patch needs work he'll set it as "In Progress" | 19:43 |
| pedro_ | InsClusoe: any member of the ubuntu-bugcontrol team, if someone has been doing a good work triaging bug he can apply to the ubuntu-bugcontrol team | 19:44 |
| pedro_ | which gives you a few more permissions that just edit the importance of a bug :-) | 19:44 |
| pedro_ | ok so Fix Released | 19:45 |
| pedro_ | means that there's a official package available on Ubuntu that fix the problem | 19:45 |
| pedro_ | Won't Fix: means that the developers of the same determined that will not fix the issue | 19:45 |
| pedro_ | and last one the scary Invalid status | 19:46 |
| pedro_ | a bus is marked as Invalid when it doesn't have enough information to determine where the bug is or that the report isn't a bug itself | 19:46 |
| pedro_ | for asking all these things we have a page with stock responses that are really useful | 19:47 |
| pedro_ | http://wiki.ubuntu.com/Bugs/Responses | 19:47 |
| pedro_ | sometimes it's hard for new triagers what to ask on some reports | 19:48 |
| pedro_ | the stocks responses will help you with that | 19:48 |
| pedro_ | we also have debugging procedures that may help you to ask for files the reporter can submit in order to see where's the bug: https://wiki.ubuntu.com/DebuggingProcedures | 19:49 |
| Iulian | <InsClusoe> QUESTION: I feel a bug needs to be looked at by the bugcontrol team. Can I subscribe them to the bug? | 19:50 |
| pedro_ | InsClusoe: best way is to announce the bug at #ubuntu-bugs if you don't get attention in a few hours you can send an email to the bugsquad list | 19:51 |
| Iulian | <barcc> QUESTION: there are some reports "xy doesn't work" with answers "me too,me too,..." without providing more information. how is the correct status Incomplete or Confirmed? | 19:51 |
| pedro_ | barcc: that's one of the painful bugs we have to face the "me too" ones... if the bug doesn't have the enough information but lot of "me too" the status should be Incomplete | 19:52 |
| pedro_ | it doesn't matter if you have 10000 "me too" but there's no enough information | 19:53 |
| pedro_ | it should incomplete anyways | 19:53 |
| pedro_ | One of the fun things we do as a BugSquad are the Hug Days | 19:54 |
| pedro_ | A Hug or Bug Day it's a complete day where the BugSquad focus on a package or task | 19:54 |
| pedro_ | we celebrate the Hug days twice a week, that means Tuesdays and Thursdays | 19:54 |
| pedro_ | today we're running the GNOME Power Manager one and last Tuesday we had a Printing one | 19:55 |
| pedro_ | you can see both pages and progress here: | 19:55 |
| pedro_ | https://wiki.ubuntu.com/UbuntuBugDay/20080221 | 19:55 |
| pedro_ | https://wiki.ubuntu.com/UbuntuBugDay/20080219 | 19:55 |
| pedro_ | of course you can always join the #ubuntu-bugs channel and discuss bugs there | 19:56 |
| pedro_ | everyday everyhour | 19:56 |
| pedro_ | if you take a look to http://planet.ubuntu.com | 19:57 |
| pedro_ | you'll see a few posts in there with a "5" | 19:57 |
| dholbach | YES YES YES :) | 19:57 |
| pedro_ | :-) | 19:58 |
| Iulian | 5-a-day r0cKz! | 19:58 |
| pedro_ | that's a new and really funny way to work on bugs | 19:58 |
| pedro_ | 5-a-day means everybody have to do 5 bugs a day! | 19:58 |
| pedro_ | https://wiki.ubuntu.com/5-A-Day | 19:58 |
| dholbach | https://wiki.ubuntu.com/5-A-Day#Log for how to join up | 19:59 |
| pedro_ | there's a stats page http://daniel.holba.ch/5-a-day-stats/ and we really like to see your name on it | 19:59 |
| pedro_ | so if you have any questions on how to do more specific triage or a question on what to do with a bug, feel free to ask at #ubuntu-bugs or in our bugsquad mailing list everytime everyhour 24x7 :-) | 20:00 |
| dholbach | thanks a lot for plugging 5 a day and thanks for your great talk pedro_! :-) | 20:01 |
| pedro_ | thanks for the attention :-) | 20:01 |
| * dholbach hugs pedro_ | 20:01 | |
| InsClusoe | pedro_: Thanks a lot. | 20:01 |
| Iulian | Thanks all! | 20:01 |
| barcc | thanks | 20:01 |
| * pedro_ hugs dholbach back | 20:01 | |
| dholbach | :-) | 20:02 |
| pedro_ | let's squash some bugs at #ubuntu-bugs! | 20:02 |
| Iulian | <yuriy> QUESTION: I run derivative X with desktop Y, but all the bugs on those bugday pages are about gnome, how can I participate? | 20:02 |
| pedro_ | yuriy: may you ask it on #ubuntu-bugs, there's another talk here :-), thanks. | 20:02 |
| phoenix24_ | Thanks pedro_ ! | 20:02 |
| dholbach | ROCK ON! :) | 20:02 |
| dholbach | Next up is "Debdiffs And How To Get Them Submitted" :) | 20:03 |
| dholbach | How are you all doing? | 20:03 |
| daishujin | Great! | 20:03 |
| dholbach | How's Ubuntu Developer Week coming on this week for you? :) | 20:03 |
| * mruiz hugs pedro_ | 20:04 | |
| charliecb | fine | 20:04 |
| daishujin | very interesting | 20:04 |
| Grazieno | dholbach: very cool for me! | 20:04 |
| dholbach | ROCK ON! That's what I like to hear :-) | 20:04 |
| InsClusoe | dholbach: I am loving it. | 20:04 |
| holloway | we want more, we want more \o/ | 20:04 |
| dholbach | Ok, let's talk debdiffs. | 20:04 |
| mirrado | Amazing | 20:04 |
| dholbach | hehe :-) | 20:04 |
| mirrado | :) | 20:05 |
| dholbach | Debdiffs are your way to make other developers happy. In this session we'll try to create one and I'll tell you how you'd submit it | 20:05 |
| dholbach | This time I thought we're going to try to fix a real bug | 20:05 |
| dholbach | I picked a 'bitesize' one, which generally are bugs that are suited for new contributors | 20:06 |
| === ember_ is now known as ember | ||
| dholbach | all those bugs are linked from http://wiki.ubuntu.com/MOTU/TODO and http://wiki.ubuntu.com/MOTU/TODO/Bugs | 20:06 |
| dholbach | but first we need to set up our working environment | 20:07 |
| dholbach | please all edit your ~/.bashrc (or .zshrc if you use zsh) file and add something along the lines of: | 20:08 |
| dholbach | export DEBFULLNAME='Daniel Holbach' | 20:08 |
| dholbach | export DEBEMAIL='daniel.holbach@ubuntu.com' | 20:08 |
| dholbach | then save it and run source ~/.bashrc | 20:08 |
| dholbach | these two variables will be used by a couple of tools we're going to need | 20:08 |
| dholbach | everybody all set? | 20:08 |
| Grazieno | dholbach: or . .bashrc :) | 20:08 |
| dholbach | Grazieno: I don't understand | 20:09 |
| Grazieno | dholbach: in your home, do only '. .bashrc' | 20:09 |
| dholbach | right | 20:09 |
| dholbach | anyway... all set? give a quick '+1' too | 20:10 |
| TuxCrafter | + 1/2 | 20:10 |
| Grazieno | +1 | 20:10 |
| rzr | pedro_: thx, sorry for disturbing ... my RTFM list is overloading :) | 20:10 |
| barcc | +1 | 20:10 |
| mirrado | +1 | 20:10 |
| Iulian | +1 | 20:10 |
| dholbach | ok perfect | 20:10 |
| dholbach | we need a few tools next, please run: | 20:10 |
| dholbach | sudo apt-get install devscripts build-essential wget fakeroot patchutils debhelper | 20:10 |
| charliecb | +1 | 20:10 |
| rzr | +0.42 | 20:11 |
| mirrado | +1 | 20:11 |
| dholbach | devscripts contains packaging tools which make the job much easier | 20:11 |
| dholbach | build-essential is a meta-package which pulls in stuff like gcc, make and so on | 20:12 |
| dholbach | fakeroot is interesting too, because it simulates an environment where we work as 'root' | 20:12 |
| dholbach | ok... let's get working on https://bugs.launchpad.net/ubuntu/+source/xnetcardconfig/+bug/181494 together | 20:12 |
| dholbach | I don't know how tricky it's going to be, let's just all start working on it and let's see where we end up :) | 20:13 |
| dholbach | if you have questions or I'm too quick, please let me know on #ubuntu-classroom-chat | 20:13 |
| dholbach | the problem seems to be that xnetcardconfig depends on xsu which is going to be removed soon | 20:13 |
| dholbach | This seems to confirm it: | 20:14 |
| dholbach | apt-cache show xnetcardconfig | 20:14 |
| dholbach | ok, let's dive into the problem :-) | 20:14 |
| dholbach | apt-get source xnetcardconfig | 20:14 |
| dholbach | oh... I forgot: | 20:14 |
| dholbach | you might have to add a deb-src line to your /etc/apt/sources.list first | 20:15 |
| dholbach | for hardy that'd be "deb-src http://archive.ubuntu.com/ubuntu hardy main restricted universe multiverse" | 20:15 |
| dholbach | and please run sudo apt-get update afterwards | 20:15 |
| dholbach | then the apt-get source run is going to work :) | 20:15 |
| dholbach | <charliecb> QUESTION: what means -> Conflicts: menu (<< 2.1.12) | 20:15 |
| dholbach | charliecb: the package xnetcardconfig conflicts with the package menu (if it is older than 2.1.12) | 20:16 |
| dholbach | that means they're not installable at the same time | 20:16 |
| dholbach | the main reason for using conflicts is that no two packages can install the same file at the same time | 20:17 |
| dholbach | that's also the main reason breaking upgrades :) | 20:17 |
| dholbach | so you need to be very careful if you move files from one package to another | 20:17 |
| dholbach | OK, apt-get source downloaded the following files for us | 20:18 |
| dholbach | xnetcardconfig_0.2.0-1.dsc and xnetcardconfig_0.2.0-1.tar.gz | 20:18 |
| dholbach | which is REALLY weird | 20:18 |
| dholbach | does somebody see a problem with those two files? | 20:18 |
| dholbach | OK, the version number 0.2.0-1 indicates that: | 20:19 |
| dholbach | - the upstream version of xnetcardconfig is 0.2.0 (what the upstream author release on their homepage) | 20:19 |
| dholbach | - it's the first debian revision of it | 20:20 |
| dholbach | <rzr> no patches | 20:20 |
| dholbach | rzr: Exactly. | 20:20 |
| dholbach | if you package upstream software, you take the tarball you download from their webpage and rename it to | 20:20 |
| dholbach | <software>_<version>.orig.tar.gz | 20:20 |
| dholbach | this result in the debian/ubuntu packaging tools moving all the changes we apply to make it build properly into <software>_<upstreamversion>-<ubunturevision>.diff.gz | 20:21 |
| dholbach | there's no .diff.gz here, although the 0.2.0-1 version indicates that | 20:22 |
| dholbach | does that make sense for everybody? | 20:22 |
| dholbach | Ok, let's move on then :) | 20:22 |
| InsClusoe | yes | 20:22 |
| dholbach | cd xnetcardconfig-0.2.0/ | 20:22 |
| dholbach | let's fix the obvious problem first: xsu depends | 20:22 |
| dholbach | for those of you who have read the link on the bug report: http://packages.qa.debian.org/x/xsu/news/20040720T150036Z.html suggests to use 'gksu' instead | 20:23 |
| dholbach | let's take a look at debian/control | 20:23 |
| dholbach | it's the file that specifies (among other things): what is needed to build the package and what is needed to install and use the package | 20:24 |
| dholbach | let's, as a first measure, replace xsu with gksu | 20:24 |
| dholbach | <charliecb> QUESTION: isn't the name for the package wrong? it must be xnetcardconfig_0.2.0-1.orig.tar.gz? or not? | 20:24 |
| dholbach | charliecb: I'd agree with xnetcardconfig_0.2.0.orig.tar.gz - the debian maintainer might have overlooked it | 20:25 |
| geser | it was never in Debian, it got synced from some other source during for hoary and never touched since Dec 2005 | 20:25 |
| dholbach | everybody welcome geser - he's a great guy and always digs up these facts from somewhere - he's awesome! | 20:26 |
| dholbach | thanks geser | 20:26 |
| dholbach | ok, that's done now, let's document our change | 20:26 |
| dholbach | let's run dch -i to add a new changelog entry and increment the version number | 20:26 |
| dholbach | dch is a nifty tool from devscripts | 20:27 |
| dholbach | a few things we need to make sure here: | 20:27 |
| dholbach | - get the version right, which might be a bit controversial here :-) | 20:27 |
| dholbach | - upload to the right Ubuntu version | 20:27 |
| dholbach | - document our changes right | 20:27 |
| dholbach | as the version is wrong already, I suggest we just use 0.2.0-1ubuntu1 and go from there | 20:29 |
| dholbach | <charliecb> QUESTION: changelog has to look like this: xnetcardconfig (0.2.0-1ubuntu1) gutsy; urgency=low | 20:29 |
| dholbach | * removed dependence for xsu , add dependence for gksu | 20:29 |
| dholbach | charliecb: nearly | 20:29 |
| dholbach | we can't upload to gutsy, it's released already | 20:29 |
| dholbach | but if we replace gutsy with hardy, I think it looks OK already | 20:30 |
| dholbach | although I prefer to use changelog entries like | 20:30 |
| dholbach | * debian/control: replaced xsu dependency with gksu. | 20:30 |
| dholbach | or something | 20:30 |
| dholbach | it's important to point out which files you changed, so the next person who works on the package knows what happend and why | 20:30 |
| dholbach | who's done with that part of the story? quick +1 please? | 20:31 |
| charliecb | +1 | 20:31 |
| Iulian | +1 | 20:31 |
| barcc | +1 | 20:31 |
| dholbach | party on | 20:32 |
| Grazieno | +1 | 20:32 |
| mirrado | +1 | 20:32 |
| dholbach | what do we do now? is that all? | 20:32 |
| holloway | we need a new source package? | 20:33 |
| dholbach | before that | 20:33 |
| mirrado | we need to change the reference to the package mantainer in debian/control | 20:33 |
| dholbach | mirrado: good point, but even before that | 20:33 |
| charliecb | test the package with pbuilder? | 20:33 |
| dholbach | all good points, but something else | 20:33 |
| InsClusoe | get gksu | 20:34 |
| InsClusoe | ? | 20:34 |
| dholbach | if there's a dependency on xsu, it might be used somewhere in the code somewhere - we need to fix that reference | 20:34 |
| dholbach | grep -r xsu * | 20:34 |
| dholbach | seems that we need to get xnetcardconfig.in a proper treatment | 20:34 |
| dholbach | this line is the offending one: | 20:34 |
| dholbach | (xsu -c "$0" -u root -i "@PREFIX@/share/pixmaps/xnetcardconfig.png" -t "Configure network" -d -m "Network configuration requires^superuser priveleges.") >/dev/null 2>&1 || { | 20:35 |
| Grazieno | sed -i 's/xsu/gksu/g' xnetcardconfig.in | 20:35 |
| dholbach | just replacing 'xsu' with 'gksu' is not going to work | 20:36 |
| dholbach | if you look at the manpage of gksu, you'll find out that there is no '-c' or '-i' | 20:36 |
| dholbach | as I read the manpage, something like | 20:36 |
| dholbach | (gksu -c "$0" -D /usr/share/applications/xnetcardconfig.desktop) >/dev/null 2>&1 || { | 20:36 |
| dholbach | might work | 20:36 |
| dholbach | it's something we need to test in the end | 20:36 |
| Grazieno | hum.. | 20:36 |
| dholbach | Grazieno: you have a question? | 20:37 |
| Grazieno | dholbach: no | 20:37 |
| dholbach | ok good | 20:37 |
| dholbach | let's document that change too, please run | 20:37 |
| dholbach | dch -e | 20:37 |
| dholbach | something like this will do: | 20:38 |
| dholbach | * xnetcardconfig.in: replaced usage of xsu with gksu. | 20:38 |
| dholbach | now we come to mirrado's point | 20:38 |
| dholbach | mirrado: care to explain? | 20:38 |
| dholbach | <charliecb> QUESTION: why /usr/share/applications/xnetcardconfig.desktop ? who creates that file? | 20:38 |
| mirrado | we need to substitute the mantainer field with XSBC-original-mantainer tag | 20:39 |
| dholbach | charliecb: I'll make it short becaues it's not really relevant to the topic of the session... as I read the gksu manpage you can pass it the location of a Desktop file, where it get description of the program from (instead of the strings that were passed to xsu call before) | 20:39 |
| dholbach | charliecb: I saw it in gksu's manpage and found that the .desktop file in the tarball is available at ./xnetcardconfig.desktop | 20:40 |
| charliecb | ok. thanks | 20:40 |
| dholbach | charliecb: and grepping for .desktop in the source I found out that it's installed to "/usr/share/applications/xfld-xnetcardconfig.desktop" - thanks for prodding me, I was wrong :-) | 20:41 |
| dholbach | if you want to update the line in xnetcardconfig.in, it's now: | 20:42 |
| dholbach | (gksu -c "$0" -D /usr/share/applications/xfld-xnetcardconfig.desktop) >/dev/null 2>&1 || { | 20:42 |
| dholbach | mirrado is completely right in what he says, we need to follow https://wiki.ubuntu.com/DebianMaintainerField | 20:43 |
| === rzr is now known as rZr | ||
| dholbach | our friends at Debian asked us to preserve the debian maintainer in debian/control, but set a different maintainer address so that Ubuntu users are not going to mail them if the Ubuntu package is broken :) | 20:43 |
| dholbach | we'll replace this: | 20:44 |
| dholbach | Maintainer: Benedikt Meurer <bm@os-cillation.de> | 20:44 |
| dholbach | with | 20:44 |
| dholbach | XSBC-Original-Maintainer: Benedikt Meurer <bm@os-cillation.de> | 20:44 |
| dholbach | Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com> | 20:44 |
| dholbach | ok, let's document that too :) | 20:45 |
| dholbach | 'updated Maintainer field' should be fine | 20:46 |
| dholbach | now we'll do what holloway suggested: a new source package | 20:46 |
| mirrado | We need to register in the changelog our changes in the xnetcardconfig.in | 20:47 |
| holloway | debuild -S :) | 20:47 |
| dholbach | mirrado: exactly | 20:47 |
| geser | dpkg-source: error: syntax error in ./xnetcardconfig-0.2.0/debian/control at line 14: duplicate field Conflicts found | 20:47 |
| dholbach | holloway: exactly | 20:47 |
| dholbach | geser: good point - let's take a look at it | 20:47 |
| dholbach | geser is right - there are two Conflicts statements, let's merge them | 20:48 |
| dholbach | also let's document it | 20:48 |
| charliecb | i don't see conflicts when i run "debuild -S" | 20:48 |
| dholbach | charliecb: that's because you're on gutsy - the hardy build will fail | 20:49 |
| charliecb | ok | 20:49 |
| dholbach | you should get E: xnetcardconfig source: debian-control-with-duplicate-fields conflicts: 13, 15 though | 20:49 |
| dholbach | <Iulian> QUESTION: Standards-Version shouldn't be 3.7.3 ? | 20:49 |
| dholbach | Iulian: good question - can you explain what Standards-Version means? | 20:50 |
| Iulian | It's the Standards-Version from the debian policy. | 20:50 |
| dholbach | exactly | 20:50 |
| dholbach | so if you put standards version 3.7.3 in there, you're saying "this package complies to version 3.7.3 of the debian policy" | 20:51 |
| dholbach | which is something I wouldn't testify right now :) | 20:51 |
| Iulian | Right :) | 20:51 |
| dholbach | changing the Standards-Version is a good thing if it's a package that you maintain | 20:51 |
| dholbach | if it's a package we inherit from debian or some other place, we try to only introduce minimal changes that have a bigger effect | 20:52 |
| dholbach | so changing just the standards-version is probably not something we'd do | 20:52 |
| dholbach | Iulian: but a lot of people still do it - so the question is definitely justified :) | 20:52 |
| dholbach | alrighty | 20:52 |
| dholbach | did the debuild -S command work for everybody now that we merged the Conflicts fields? | 20:52 |
| dholbach | +1? | 20:53 |
| charliecb | +1 (with gutsy) | 20:53 |
| dholbach | anybody else? | 20:53 |
| Iulian | +1 | 20:53 |
| mirrado | +1 | 20:54 |
| barcc | +1 | 20:54 |
| dholbach | ahhh, here we go | 20:54 |
| dholbach | now | 20:54 |
| dholbach | cd .. | 20:54 |
| dholbach | debdiff xnetcardconfig_0.2.0-1.dsc xnetcardconfig_0.2.0-1ubuntu1.dsc | 20:54 |
| Grazieno | +1 | 20:54 |
| dholbach | This command will print out the diff the between the two source packages (0.2.0-1 and 0.2.0-1ubuntu1) | 20:55 |
| charliecb | +1 | 20:55 |
| dholbach | can you all put your debdiff up at http://paste.ubuntu.com and paste the link here? | 20:55 |
| charliecb | http://paste.ubuntu.com/4869/ | 20:57 |
| Grazieno | http://paste.ubuntu.com/4868/ | 20:57 |
| barcc | http://paste.ubuntu.com/4870/ | 20:57 |
| dholbach | Grazieno: you don't mention that you drop the xsu depends and don't mention which files you changes, but apart from that: very good | 20:58 |
| Iulian | http://paste.ubuntu.com/4871/ | 20:58 |
| mirrado | http://paste.ubuntu.com/4872/ | 20:58 |
| dholbach | charliecb: you did not mention the change in xnetcardconfig.in, other than that: good work | 20:58 |
| dholbach | barcc: good work :) | 20:59 |
| dholbach | Iulian: you didn't change xnetcardconfig.in and your changelog is a bit sparse | 20:59 |
| dholbach | mirrado: your changelog does not list all the changes either, other than that: good work | 21:00 |
| dholbach | WOW, I'm amazed - well done everybody! | 21:00 |
| dholbach | so what would be next: | 21:00 |
| mirrado | I'm correcting it right now. | 21:00 |
| dholbach | - what charliecb mentioned above: test building it with pbuilder (http://wiki.ubuntu.com/PbuilderHowto) | 21:01 |
| dholbach | - testing if our suggested xsu fix really works | 21:01 |
| dholbach | - then we'd add a (LP: #181494) to the bug report, so the bug will automatically closed once our patch gets uploaded | 21:02 |
| dholbach | then we'd run: | 21:02 |
| dholbach | debdiff xnetcardconfig_0.2.0-1.dsc xnetcardconfig_0.2.0-1ubuntu1.dsc > debdiff | 21:02 |
| dholbach | and attach the resulting debdiff file to the bug report | 21:02 |
| dholbach | and subscribe ubuntu-universe-sponsors to the bug report to get the fix uploaded | 21:03 |
| dholbach | https://wiki.ubuntu.com/SponsorshipProcess has more information on how to get it uploaded :) | 21:03 |
| dholbach | fixing this bug will actually two bugs: | 21:04 |
| dholbach | Once https://bugs.edge.launchpad.net/ubuntu/+source/xnetcardconfig/+bug/181494 is done | 21:04 |
| dholbach | https://bugs.edge.launchpad.net/ubuntu/+source/xsu/+bug/181495 can be fixed too :) | 21:04 |
| charliecb | dholbach: isn't it enough to attach the diff to https://bugs.launchpad.net/ubuntu/+source/xnetcardconfig/+bug/181494 ??? | 21:04 |
| dholbach | so I hope somebody of you will walk through all the additional steps I mentioned so we get those two bugs ironed out :) | 21:04 |
| dholbach | charliecb: the sponsoring process requires that the sponsors team is subscribed to the bug | 21:05 |
| dholbach | charliecb: if you look at the bug you will notice that just three people are subscribed to it right now | 21:05 |
| dholbach | having the sponsors team on it will make sure you don't block on just one person, but it will be dealt with by a bigger team | 21:05 |
| dholbach | any last questions? :) | 21:06 |
| charliecb | no. thanks for the nice lesson, dholbach!! | 21:06 |
| Iulian | All good here. | 21:06 |
| dholbach | rock on! | 21:06 |
| mirrado | http://paste.ubuntu.com/4874/ | 21:06 |
| Iulian | The next package will be much better than this one. | 21:06 |
| mirrado | Is it correct now? | 21:07 |
| dholbach | tomorrow we'll have a MOTU Q&A session - if anything came up in your mind after this session, bring your questions to that session instead :) | 21:07 |
| Iulian | Okies | 21:07 |
| Iulian | Thank you dholbach! | 21:07 |
| Grazieno | dholbach: thanks, really! | 21:07 |
| dholbach | mirrado: better, I'd just mention the other changes to debian/control too: maintainer field change and merge of the two conflicts lines | 21:07 |
| dholbach | mirrado: other than that: good work | 21:08 |
| dholbach | thanks everybody: you guys ROCK | 21:08 |
| Iulian | That was awesome! | 21:08 |
| mirrado | Thanks dholbach :) | 21:08 |
| dholbach | and I'd like to welcome you all to working with the MOTU team - it's big fun! | 21:08 |
| dholbach | http://wiki.ubuntu.com/MOTU/GettingStarted | 21:08 |
| barcc | you ROCK! | 21:08 |
| dholbach | have a great day everybody and see you tomorrow! | 21:08 |
| * Iulian hugs dholbach | 21:08 | |
| * dholbach hugs Iulian back | 21:09 | |
| * dholbach waves | 21:09 | |
| ewook | yay, hugging! :) | 21:10 |
| rZr | so who fix https://bugs.edge.launchpad.net/ubuntu/+source/xnetcardconfig/+bug/181494 ? | 21:17 |
| phoenix24_ | :wq | 21:22 |
| nrpil | rZr: good question! | 21:22 |
| rZr | nrpil: then I shouldnt have ask :) | 21:23 |
| rZr | ..ed it | 21:24 |
| rZr | will do then | 21:29 |
| nrpil | rZr: how do you fix it ? | 21:32 |
| rZr | nrpil: test it and join the debdiff like said ? | 21:34 |
| rZr | nrpil: did i miss something ? | 21:35 |
| nrpil | rZr: i don't know, i'm learning | 21:36 |
| phoenix24_ | I get the same "debuild -S" error, geser showed. | 21:52 |
| phoenix24_ | How do i correct it. ? | 21:52 |
| phoenix24_ | resultant build.. fails. | 21:52 |
| civija | phoenix24_: please post error message on paste.ubuntu.com | 21:55 |
| phoenix24_ | civija: http://paste.ubuntu.com/4878/ | 21:57 |
| civija | now paste control file | 21:57 |
| civija | it looks like you have duplicate Confilcts field | 21:58 |
| geser | phoenix24_: when you look at debian/control you will see two lines starting with Conflicts | 21:58 |
| geser | put the values from both lines into one field, seperated with ',' | 21:59 |
| phoenix24_ | done. | 21:59 |
| geser | you should end with something like that (don't remember the exact field values): Conflicts: dhcp-client, menu (<< 2.11.2) | 21:59 |
| geser | order doesn't matter | 22:00 |
| phoenix24_ | Conflicts: dhcp-client , menu (<< 2.1.12) | 22:00 |
| rZr | I plan to upload a package to my personnal package archive | 22:00 |
| charliecb | does anybody know, why a package from debian/sid is not in ubuntu hardy? | 22:00 |
| rZr | charliecb: i never was in debian | 22:00 |
| rZr | it not I :) | 22:00 |
| geser | phoenix24_: looks ok | 22:00 |
| rZr | I'll sumbit it to debian also | 22:01 |
| phoenix24_ | geser: now build it again ? | 22:01 |
| phoenix24_ | and document it using, dch -e ? | 22:01 |
| geser | phoenix24_: yes and yes | 22:01 |
| kdub432 | /join #svn | 22:02 |
| geser | phoenix24_: dch (without -e) should automatically add a new bullet | 22:02 |
| kdub432 | oops, sorry everyone | 22:02 |
| geser | charliecb: my guess is that it entered Debian after the automatic sync stopped and nobody filed a sync request for it | 22:03 |
| rZr | <geser> charliecb: my guess is that it entered Debian ? | 22:04 |
| rZr | are you sure ? | 22:04 |
| charliecb | rZr: sure for what? | 22:05 |
| geser | rZr: as I don't know which package charliecb is talking about I can only guess | 22:06 |
| geser | charliecb: which package are you missing? | 22:06 |
| rZr | xnetcardconfig-0.2.0 ? | 22:06 |
| phoenix24_ | geser: after rebuild, I get another error : http://paste.ubuntu.com/4879/ | 22:06 |
| charliecb | rZr: libjogl-jni | 22:06 |
| rZr | ok my mistake | 22:07 |
| charliecb | rZr: how can i find out the upstream date from this package? | 22:07 |
| geser | phoenix24_: only the signing failed (which is only important for uploading), you should have a new source package | 22:07 |
| phoenix24_ | ok | 22:08 |
| geser | charliecb: when you look at https://wiki.ubuntu.com/HardyReleaseSchedule you will that DebianImportFreeze (stop of automatic syncing) was on Dec 13th and when you look at http://packages.qa.debian.org/libj/libjogl-java.html you will see that the first upload got accepted on Dec 19th | 22:10 |
| phoenix24_ | geser: My debdiff output, http://paste.ubuntu.com/4880/ | 22:12 |
| charliecb | geser: thanks. thats the answer | 22:13 |
| geser | phoenix24_: the changes look nearly good: it was noted that the filename of the .desktop file is different (xfld-xnetcardconfig.desktop I guess) | 22:15 |
| geser | phoenix24_: and you called dch -i to often, you should have only one new entry (-1ubuntu1) instead of three | 22:15 |
| rZr | this apps seems obsolete anyway | 22:16 |
| phoenix24_ | ok, is that why I got -1ubuntu3 instead of -1ubuntu1 packaged? | 22:16 |
| geser | -i = increment | 22:17 |
| geser | dch -e = edit | 22:17 |
| kdub432 | im confused. is a debdiff analogous to standard patches, except that they are for debian packages? | 22:17 |
| phoenix24_ | geser: thanks a lot! | 22:18 |
| === ember_ is now known as ember | ||
| geser | kdub432: you can unpack the old source package and the new one to different dirs and run diff on them or if you are lazy use debdiff | 22:19 |
| kdub432 | and where are debdiffs submitted to? | 22:21 |
| geser | kdub432: to LP (Launchpad), file a bug if none exists, attach the debdiff and subscribe ubuntu-universe-sponsors (or ubuntu-main-sponsors if the source package is in main) | 22:22 |
| kdub432 | thanks geser. im coming up on a 10 day break from classes, hopefully thats enough time to sort this whole motu thing out... | 22:25 |
| === Wasserstoff is now known as Hydrogen | ||
| === mruiz is now known as mruiz_afk | ||
| === mruiz_afk is now known as mruiz_away | ||
| === Seeker`_ is now known as Seeker` | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!