[01:59] <timotheus> What is the next Ubuntu release scheduled for? And how would I find that information on-line? Thanks.
[02:29] <hggdh> timotheus, please see https://wiki.ubuntu.com/
[07:57] <davmor2> Morning All :)
[08:49] <sbeattie> davmor2: are you interested in testing a python version of the dl-iso script? You don't use a config file, right?
[08:50] <davmor2> I don't use a config file you're correct.  And yes I can test it for you :)
[08:51] <sbeattie> davmor2: kewl. bzr up the ubuntu-qa-tools tree, and there should be a new dl-ubuntu-test-iso.py in that directory
[08:52] <sbeattie> davmor2: oh, you should probably install the zsync package as well.
[08:52]  * sbeattie hasn't implemented a bunch of the sanity checking, like verifying zsync is installed before attempting to use it.
[08:57] <davmor2> sbeattie: http://paste.ubuntu.com/259709/ I'm also assuming that the command I ran is correct
[08:58] <sbeattie> davmor2: bah, is that hardy or intrepid you're running on?
[08:58] <davmor2> sbeattie: hardy server
[08:58] <sbeattie> one sec.
[08:59] <davmor2> sbeattie: I setup a cron job on my server as it's up 24/7 to grab the latest dailies each morning
[09:01] <sbeattie> no worries, I just used a language feature that only became official in python2.6, which isn't present on hardy. Fixing.
[09:04] <sbeattie> davmor2: updated.
[09:07] <davmor2> sbeattie: http://paste.ubuntu.com/259714/
[09:12] <sbeattie> davmor2: one more time, with feeling.
[09:14] <davmor2> sbeattie: Yay :)
[09:20] <davmor2> sbeattie: I'm getting lots of iso.zsync failed's
[09:21] <sbeattie> davmor2: is it still working on hardy isos?
[09:21]  * sbeattie doh!s and removes one of the debugging statements.
[09:22] <davmor2> that was the hardy ones yeah now it's on karmic and looking happier :)
[09:25] <sbeattie> davmor2: FYI, the new tool support --release RELEASE, which is like --only, except for releases (e.g. karmic)
[09:27] <sbeattie> there's still a bunch of bogosities around zsync (you can disable it with --no-zsync) like it leaving around .part files when interrupted and not supporting bandwidth limits.
[09:33] <davmor2> sbeattie: cool.  So I can run it with just karmic until there is something to test on hardy :)
[09:39] <davmor2> sbeattie: is it me or does the whole zsync thing seem to take ages or is that just because it is a first run
[09:40] <davmor2> ah no it's kubuntu-netbook that why sorry
[09:41]  * sbeattie does a happy dance since he hadn't actually tested downloading that image yet.
[09:43] <sbeattie> I'm not convinced it offers much of an improvement over rsync; when I can get around to doing some jigdo magic, I think that'll be a decent source of improvements (especially for silly people such as myself who have local mirrors)
[09:44] <sbeattie> ... at the expense of some disk space, of course.
[09:52] <davmor2> sbeattie: I don't what you mean I have more iso's than cdimages :)
[09:55] <davmor2> sbeattie: currently my iso folder is about 100gb
[10:15] <davmor2> sbeattie: no my bag again.  I'ts me looking at the address in front thinking it is doing the same as rsync.  the address was for hardy's copy of kubuntu-netbook.  and now it is reading the sha256 id's for the files I have on my drive as I only have the md5sums from the old script and that is what is taking the time.  the download takes the same as rsync maybe slightly faster :)
[10:19] <sbeattie> oh, bah, I see I've left another debug statement in there (the rsync line), sorry for the confusion.
[10:21] <sbeattie> I'm honestly not sure whether to bother with the sha256 verification if the zsync succeeded.
[10:22] <davmor2> sbeattie: I thought it was reading the sha256 before downloading
[10:23] <davmor2> sorry creating a sha256 before downloading
[10:27] <davmor2> sbeattie: app reads reading seed file ubuntu/karmic-desktop-amd64.iso: ************************  then it starts the download from Read ubuntu/karmic-desktop-amd64.iso. Target 76.4% complete.
[10:27] <davmor2> downloading from http://cdimages.ubuntu.com//daily-live/current/karmic-desktop-amd64.iso:
[10:28] <sbeattie> no, the zsync metadata file is the what's downloaded first. the SHA256SUMS are last.
[10:29] <sbeattie> and it reads the existing iso (if any) to see what it doesn't need to re-download.
[10:30] <davmor2> sbeattie: in that case the zsync metadata download is slow as crap 15-20 minutes each one and the actual sync takes about 2 minutes
[10:32] <sbeattie> one thing zsync does is periodically restate the downloading line; e.g. http://paste.ubuntu.com/259751/
[10:34] <sbeattie> It also doesn't tell you when it's downloading the .zsync file, it just shows you a progress bar.
[10:38]  * sbeattie disappears fora few hours sleep before today's meeting.
[10:40] <davmor2> sbeattie: http://paste.ubuntu.com/259754/  this is what I've been getting the ******
[10:40] <davmor2> takes for ever
[10:41] <sbeattie> The "reading seed file ubuntu/karmic-desktop-i386.iso: *************[...]" stuff is taking forever?
[10:42] <sbeattie> that's zsync looking at the existing iso and determining what out of it it needs to download.
[10:44] <davmor2> okay cool :)
[10:44] <davmor2> nn
[10:44] <sbeattie> emitting the "******"s takes roughly 15 seconds here, if it's taking longer for you, you might be short on memory or disk bandwidth for some reason.
[10:45] <davmor2> sbeattie: I'll look into it after
[10:45] <sbeattie> you can use --no-zsync if you want to force it to use rsync only.
[10:47] <sbeattie> if I really wanted to get tricky, I could do something like the sha256 computation in another thread and try to parallelize some of the operations.
[10:48] <sbeattie> ... but not tonight, that's for sure.
[10:48] <sbeattie> s/tonight/this morning/
[10:49] <davmor2> sbeattie: go to bed :)
[12:44] <davmor2> morning fader
[12:47] <fader> davmor2: Hey, how's tricks?
[12:50] <davmor2> fader: Sound thanks.  think I might of broken sbeattie's new python script by accident :(  I just need to figure out where zsync stores it's data and kill it to death muhahahahahaha :)
[12:50] <davmor2> I got todays alternate images fixed :)
[12:50] <fader> davmor2: Oh, if it's broken python scripts you're after, I can churn out a million of those.
[12:50] <fader> davmor2: \o/  Excellent!
[12:52] <davmor2> fader: it was working but then I had a bit of a power cut and my server died and now I just get a list of errors instead of a working download.  I might try a purge of zsync and try again :)
[12:53] <davmor2> well server switched off partway through a download
[12:53] <fader> Bleh... I'd have thought you had your own backup generator, seeing as how you have a DC in your house :)
[12:54] <davmor2> fader: there are some things I can sneak into our flat without my wife noticing I don't think a generator is one of them :)
[12:54] <davmor2> fader: it's not the kinda thing you can drop in your pocket
[12:56] <fader> You need bigger pockets!
[12:56] <davmor2> or a tardis
[13:05]  * davmor2 -> Lunch
[13:09] <fader> davmor2: Give me a ping when you're back and we can start looking at checkbox test descriptions... lots of fun! :)
[14:04] <davmor2> fader: I don't believe you :)
[14:04] <davmor2> back :)
[14:05] <fader> davmor2: Hah, you'll see... it's like math problems, or a trip to the dentist!  Everybody loves them!
[14:05]  * davmor2 runs screaming
[14:06] <fader> So here's the official documentation: https://wiki.ubuntu.com/Testing/Automation/Checkbox/WritingTestsHowTo
[14:07] <fader> Though it's probably more useful to open up /usr/share/checkbox/tests/* and just take a look at some of them
[14:07] <fader> Tests are stored in flat text files.  One or more tests can be in a given file; the files are useful for grouping related tests together
[14:08] <fader> Each test has to have a unique "name", a "plugin", and a "description".
[14:08] <fader> The plugin for any test that has user interaction is going to be "manual", even if it runs a script as part of the test
[14:09] <davmor2> fader: two ticks
[14:09] <fader> You can also have a "command" if you need to run a script or a shell command to gather information, e.g. if you want to ask the user if something is correct or have them click the 'test' button to have an action performed
[14:09] <fader> davmor2: "two ticks"?
[14:09] <fader> Remember, I'm an American, so British is a second language for me.  And we all know Americans can only speak one language. ;)
[14:09] <davmor2> hang on a minute :)
[14:13] <davmor2> fader: right I've opened up /usr/share/checkbox/suites/manual.txt to give me more of an idea
[14:13] <davmor2> on jaunty
[14:14] <fader> davmor2: I don't remember which tests are specifically in that file, as it's changed in the version I have.  (But I'm using cr3's PPA version, so it's bleeding edge and possibly crackrock :) )
[14:14] <fader> But regardless, they should all be about the same
[14:14] <fader> The format should be pretty self-evident, I think
[14:15] <fader> You need to have a blank line between tests (and at the end of the file), and if a field takes multiple lines (e.g. a long description) you just prepend each line with a space
[14:15] <fader> That's the trickiest bit :)
[14:15] <davmor2> fader: http://paste.ubuntu.com/259832/
[14:16] <davmor2> fader: what are the lines with dot for?
[14:16] <fader> davmor2: Ah, good question.  Since a blank line indicates the end of one test, a single "." will become a blank line in the test description
[14:17] <davmor2> right so it signifies blank line mid test then :)
[14:17] <fader> Exactly.
[14:18] <davmor2> fader: should the mouse test have click buttons too?
[14:19] <fader> davmor2: To be really thorough, probably.  I think cr3 took a stance of not wanting to annoy the user *too* much on these and assuming some basic knowledge on the part of the user for these simpler tests
[14:19] <fader> e.g. if your mouse won't click but you still run checkbox, you're probably going to make a note of it and say the mouse is broken :)
[14:20] <cr3> somebody say crack?
[14:20] <fader> cr3: Go back to sleep... this was metaphorical crack. ;)
[14:21] <davmor2> cr3, fader: but it might only be the middle mouse button or right mouse button that has been misconfigured
[14:21] <davmor2> ha
[14:21] <cr3> fader: the format of the file is strictly rfc822 format, same as debian template files for example
[14:21] <fader> cr3: Yeah, you've mentioned that before but I've never felt compelled to read the RFC.  It's pretty straightforward :)
[14:22] <cr3> fader: you get emails in that format every day, I hope :)
[14:22] <fader> cr3: Believe it or not, I'm even capable of telnetting to port 25 and writing 'em myself :)
[14:23] <fader> davmor2: If you wanted to add a mouse-buttons test, I don't think anyone would complain :)
[14:23] <davmor2> Right okay so where or what are the new tests you want writing or do I need to make them up as I go along?
[14:23] <fader> We've got a checkbox-qa package for more in-depth tests that are useful but not necessarily something we expect everyone to put up with
[14:24] <fader> davmor2: We've got a spreadsheet of tests that need to go in, but I need to find out which ones have already been written
[14:24] <davmor2> fader: okay so maybe mouse clicks can go in there then :)
[14:25] <fader> davmor2: It might belong in the standard vanilla Checkbox package... I'd make an argument for that if it's turning up useful results
[14:25] <cr3> fader: can you telnet and write tests?
[14:26] <davmor2> fader: I think a simple click left middle right mouse button takes a couple of seconds shouldn't bother a user too much
[14:26] <cr3> fader: dude, that would be awesome: a protocol that would enable you to write tests through telnet, everyone would use it! :)
[14:26] <fader> cr3: rcpt-to: marc@canonical.com\nsubject: write some tests!
[14:27] <davmor2> did I just hear a whip crack :)
[14:27] <fader> davmor2: I agree... it just needs to be clear what the expected results are in all cases so we don't get false negatives/positives
[14:27] <davmor2> box changes from click left to passed
[14:28] <davmor2> moves onto the next click
[14:33] <davmor2> So as I type the crap out of these what do you want doing with them?
[14:34] <fader> Could you email them to me and Marc?
[14:35] <fader> ronald.mccollam@canonical.com, marc.tardif@canonical.com
[14:35] <fader> So for tests that need to be run after suspend or hibernate, we can cheat a bit and make them easier to write up
[14:36] <fader> You'll notice that tests can have dependencies -- "depends:"
[14:36] <fader> If you make a test "depends: foo" then the test named "foo" must be passed before the test with the dependency will run
[14:36] <fader> So "depends: suspend" will mean a test won't run until after the test named "suspend" has run successfully
[14:37] <fader> I think it's safe to assume the existence of a test named "suspend" and one named "hibernate"; if they end up called something different it's easy enough to update the dependencies.  Especially if you keep all of the "depends on suspend" and "depends on hibernate" in their own files.
[14:39] <davmor2> fader: to be honest if they call it anything else slap them silly :)
[14:40] <fader> davmor2: Well, in fairness we might have "suspend-auto-resume" and "suspend-manual-resume" or something
[14:40] <fader> :)
[14:41] <davmor2> no that's just daft :)
[15:30] <fader> cr3: In order to have the description marked as translatable, does it need to be "_description:"?
[15:31] <davmor2> cr3: not everyone speaks english you see.  I know it's shocking news and they should be made to instantly but hey :)
[15:34] <fader> I know the checkbox packages get translated but I'm not sure how the tests work.
[15:34] <cr3> fader: yep
[15:34] <cr3> davmor2: je ne comprends pas
[15:35] <fader> cr3: Thanks.  I have some updates I'll need to make to the branches I submitted for merge then :)
[15:35] <fader> Je suis le fromage grande!
[15:35] <davmor2> you are not the big cheese :P
[15:35] <fader> ^^^ one year of high school French.  I remember that and "un chape du pape".
[15:37] <davmor2> I don't remember that :( hangs head in shame
[15:37] <cr3> fader: that should be: je suis le grand fromage. "fromage grande" sounds like a combination of french and spanish: queso grande
[15:38] <cr3> fader: and "chape" is feminin, so probably "la chape du pape"
[15:38] <fader> cr3: I thought standard order in French was noun then adjective?
[15:38] <fader> Heh, my French is worse than I thought.  Merde!
[15:38] <cr3> fader: dude, french isn't so easy as to have such simple rules :)
[15:39] <fader> Not like English, which is totally regular :P
[15:39] <cr3> for example, "petit cheval" and "manteau rouge"... different ordering
[15:40] <fader> Huh.  We need to join #comparative-linguistics so you can explain why to me. :)
[15:40] <davmor2> le chat est suos la table I think or maybe sous I can't remember
[15:43] <fader> La kato estas sur la tablo.
[15:43] <davmor2> fader: are you trying to prove that your spanish is better than you french?
[15:44] <fader> My Spanish is about on par with my French.  My Esperanto is somewhat better :)
[15:44] <davmor2> next you'll be saying that your english is good :P
[15:51] <davmor2> right so from all this tom foolery we should add a _ to the description line is that correct?
[15:52] <fader> davmor2: Yup, sounds like
[15:53] <davmor2> fader: Right np's then.  What about commands it is just a case of playing about till I find one that works?
[15:54] <fader> davmor2: Don't sweat the commands for anything that isn't immediately obvious.  If you can write a series of steps that results in a yes/no answer ("Did it work?"), that is all we need
[15:54] <fader> You can leave the "command:" field out of anything that doesn't have a script or command to run
[15:55] <davmor2> fader: okay cool :)
[15:55] <fader> So e.g. "Open your mail client.  Email your credit card numbers and passwords to davmor2@shiftyeyes.com.  Did the mail go through?" would be fine.
[15:56] <davmor2> fader: or more realistically send a mail to yourself :P  did it get through
[15:56] <fader> Sure, if you want to be boring about it ;)
[15:56]  * davmor2 hits fader with his fix it hammer
[16:04] <jtatum_> hey, mikefletcher
[16:16] <mikefletcher> jtatum_: hello, I just got back from the vet.  Sick puppy :(.
[16:18] <davmor2> fader: wow that email address exists so it must be true :P
[16:19] <fader> Heh :)
[16:22] <jtatum_> very sorry to hear that, mikefletcher :(
[16:23] <davmor2> sbeattie: I found out why the script is so slow first run zsync is creating it's own database type file in ~/iso if I shut it down and rerun the new pyhton script it steams through the part that it has already catalogued and slows down again once it get's to a part that isn't.
[16:23] <davmor2> so it is a first run thing
[16:23] <mikefletcher> jtatum_: he got some antibiotics so he should be fine
[16:25] <jtatum_> mikefletcher: well, that's good news, anyway. do let me know if I may lend a hand with your merge proposal. I spent some time last night working on a branch for gcalctool. I did not expect the calculator to be so complex :)
[16:28] <mikefletcher> jtatum_: thanks!
[16:46] <sbeattie> davmor2: hunh. I wonder if zsync is behaving significantly differently between hardy and karmic
[16:48] <davmor2> sbeattie: It's the same version number in hardy and jaunty
[16:49] <davmor2> sbeattie: I'm not fussed I'll try it again tomorrow if it still as slow I'll throw in the -no-zsync
[16:49] <davmor2> right need to grab tea
[16:49] <sbeattie> right, but all my testing has been on karmic hosts, which has a newer upstream release.
[16:50] <sbeattie> davmor2: thanks, BTW, for throwing caution to the wind and testing it out!
[16:55] <sbeattie> hrm, zsync 0.6 didn't appear to add major optimizations, according to the upstream changelog. /me shrugs.
[17:14] <davmor2> is there no meeting today?
[17:15] <davmor2> or am I ahead of myself?
[17:16] <fader> davmor2: In 45 minutes
[17:16] <davmor2> me then cool I'll go and enjoy tea then :)
[17:16] <fader> I think the fridge is UTC rather than GMT, despite what it says at the bottom
[17:17]  * fader thinks that time zones should be abolished.  Everyone can live on EST!
[17:19] <jtatum_> GMT and UTC are effectively the same :) England is on BST now
[17:20] <fader> jtatum_: Gah, I thought they were an hour off right now
[17:20] <fader> I guess BST != GMT
[17:21]  * fader looks around for a box of clocks and a bottle of aspirin.
[17:21] <jtatum_> fader: exactly :)
[17:23] <jtatum_> time zones are as fun to test as they are to decipher ;)
[17:26] <fader> Yeah, time/clock code is very high on my list of Things I'm Grateful I Don't Have To Do
[17:32] <davmor2> fader: screw you we came up with time you move to our clock :P
[17:32] <fader> davmor2: How about Swatch Internet Time then?  At least it's decimal.
[17:33] <jtatum_> hahahaha
[17:34] <davmor2> fader: still taken from our time :P
[17:34] <davmor2> even est is taken from our time +x hours
[17:34] <fader> davmor2: If you really want to take credit for something based on 24s and 60s, you be my guest. :P
[17:35] <jtatum_> actually 0 beats were based on midnight in switzerland if I remember correctly
[17:35] <fader> jtatum: Yup :)
[17:36] <davmor2> fader: and who still use imperial when pretty much the rest of the world are metric? :P
[17:36] <fader> davmor2: Ooh, I know!  It's the Brits! :D  Everything was still pints and miles when I was there last :)
[17:37] <fader> We can talk about this after you folks switch to the dollar anyway ;)
[17:37] <jtatum_> if you want to get really pedantic, UTC isn't based on latitudes and longitudes anymore - it was based on astronomical measurements and coordinated to times above greenwich. now it's based on cesium decay with an offset to astronomical time.
[17:37]  * davmor2 takes on board the american way of life buys a gun and shoots fader 
[17:38] <jtatum_> Hilarious :D
[17:39] <fader> "An armed society is a polite society." ;)
[17:40] <davmor2> fader: sensible query now
[17:40] <fader> I was up in America's Hat^W^WCanada a while back and mentioned that I might want to buy a gun.  I'd never seen a group of people actually shift away quickly like in a cartoon before. :)
[17:40] <fader> davmor2: Sure, what's up?
[17:41] <davmor2> I'm looking at the list and one is to check volume level after s3/s4 is there a test to check it pre s3/s4 other wise you need that one too to check that it is at the right level.  Or can the one test be split between pre and post?
[17:43] <fader> davmor2: Right, good catch -- we don't have a volume test before s3/s4.  Think you could write one up?
[17:44] <fader> I imagine they should be the same test with slightly different descriptions and names (and one be dependent on suspend or hibernate, obviously)
[17:44] <davmor2> fader: No Problems
[17:45] <fader> One idea that manjo had recently that I thought was a good one was to split out the 'button' tests from the 'function' tests... e.g. have two tests where the user is asked to raise or lower the volume.  One tests to make sure they get the OSD notification, the other asks them to verify that the volume actually goes up or down
[17:45] <fader> That might be overkill for this though; being manual we can ask the user to verify both
[17:46] <davmor2> is there a way that, the percentage can be recorded and recalled though.  ie ask the user on first run to hover over the volume and type in the % and then on second run say is you volume still at x% y/n?
[17:47] <davmor2> fader, cr3: ^
[17:48] <fader> davmor2: I'm sure there's a way to do it using alsamixer or something, but I'd have to do some research to write a script
[17:49] <fader> davmor2: Offhand I'd say just ask them to verify that the volume is at an 'acceptable' level or something and we can script it later
[17:52] <davmor2> fader: no problems I just thought it might add another nice metric for cr3 :D /me runs away
[17:52] <fader> davmor2: Agreed -- we want to automate as much of this as possible, and the parts that can't be automated should be reduced to something like "Click this button.  Did something good happen?"
[17:52] <fader> The manual stuff is just expedience.
[17:53] <davmor2> fader: I know ;)
[17:53]  * fader now imagines a Checkbox test that makes chocolate fall out of the CD drive.
[17:53] <fader> ^^ *that* is good stuff happening.
[17:54] <davmor2> no all wrong image a cup of coffee being delivered from the machine and now your rocking
[17:55] <fader> Ah, I would finally have an excuse to use this: http://www.oidview.com/mibs/0/COFFEE-POT-MIB.html
[17:55] <fader> (And an appropriate RFC: http://www.faqs.org/rfcs/rfc2324.html )
[17:56] <davmor2> :D
[18:08] <davmor2> bdmurray: I wouldn't worry I've probably just jinxed it to a flaming death now anyway get ready for the reports :)
[18:09] <bdmurray> heh
[18:19] <davmor2> sbeattie: I'm getting a whole bunch of Failed! Forbidden and Failed! Not Found which I'm assuming are the dvd's as it has found all the alternates now
[18:19] <sbeattie> yeah,
[18:19] <sbeattie> sensible error reporting is um, a little lacking at the moment.
[18:20] <mikefletcher> quick launchpad question: I have made a number of changes to my gnome-screenshot branch of mago based on requests from the merge proposal.  Should I push 'Request another review' now or will people rereview the code on their own?
[18:27] <jtatum_> mikefletcher: I think you should at least add a comment to the review
[18:27] <mikefletcher> jtatum_: thanks
[18:31] <davmor2> fader: in the cases is there a way to specify yes/no boxes or is that an assumption that they are there?
[18:32] <fader> davmor2: Yes/no/skip are guaranteed to be there; 'yes' is 'pass', no is 'fail'
[18:33] <davmor2> fader: that's what I assumed and then I remembered my moto assumption the mother of all fsck ups :)
[18:37] <davmor2> fader: you know the depends does that cover things like wireless and bluetooth etc?
[18:37] <davmor2> and can you have more than one depends in the depends line and how do you seperate them?
[18:41] <fader> davmor2: You can depend on any other test, so if there is a 'bluetooth' test you can depend on it
[18:41] <fader> There is also a 'required' field for requiring specific hardware, etc. that we can add as well
[18:42] <fader> davmor2: I think you  can have multiple depends separated by whitespace
[18:42] <fader> cr3: ^^ is this true?
[18:42] <fader> (I don't see any that do this currently)
[18:43] <jtatum_> mikefletcher: sounds like maybe I led you astray :) Someone did tell me there's a LP bug where updates to the proposed branch don't show up in diffs but I'm not an expert :(
[18:43] <davmor2> fader: I can't see the point in run bluetooth test or wireless tests if the test is running on a pc with no bluetooth or wireless
[18:44] <cr3> fader: which part? the yes/no/skip part? depends part?
[18:44] <fader> cr3: depends
[18:44] <fader> davmor2: right, we'd normally use 'requires' for this but that is going through some changes atm
[18:44] <cr3> depends can be given other tests names so that if a test fails or is skipped,then its dependents will be skipped
[18:45] <fader> cr3: you can have multiple depends?
[18:45] <cr3> fader: yep
[18:45] <fader> cr3: thought so, thanks
[18:46] <davmor2> cr3: so I could have depends: suspend bluetooth ? or something like?
[18:46] <cr3> davmor2: yep
[18:46] <davmor2> cool :)
[18:46] <davmor2> checkbox rocks
[18:46] <davmor2> cr3: and just whitespace to seperate them yes?
[18:47] <cr3> davmor2: yep, just whitespace
[18:47] <davmor2> cool :)
[18:49] <jtatum_> nagappan: you can see mikefletcher's changes at https://code.launchpad.net/~mikefletcher/mago/gnome-screenshot rev 108 and 109
[18:50] <nagappan> jtatum, I could not
[18:51]  * nagappan checking the above link - jtatum 
[18:51] <jtatum_> nagappan: they don't appear in the diffs of the merge proposal for some reason but they should be at the link I just posted...
[18:51] <nagappan> jtatum, sure
[18:52] <nagappan>  Sorry, something just went wrong in Launchpad.
[18:52] <nagappan> We’ve recorded what happened, and we’ll fix it as soon as possible. Apologies for the inconvenience.
[18:52] <nagappan> Trying again in a couple of minutes might work.
[18:52] <nagappan> (Error ID: OOPS-1334F2342)
[18:52] <ubot4> https://devpad.canonical.com/~jamesh/oops.cgi/1334F2342
[18:52] <nagappan> jtatum, I get the above error message
[18:53] <nagappan> jtatum, I think, I clicked his name link
[18:53] <jtatum_> nagappan: try edge: https://code.edge.launchpad.net/~mikefletcher/mago/gnome-screenshot
[18:54] <jtatum_> I checked - the diff issue is an LP bug - bug 338002
[18:54] <ubot4> Launchpad bug 338002 in launchpad-code "'Review Diff' on merge proposal page can be out-of-date" [High,In progress] https://launchpad.net/bugs/338002
[18:57] <fader> davmor2: Don't let cr3 know how cool Checkbox is... I've been trying to crush his spirit for months and you're going to undo my work!
[18:58] <davmor2> D'oh
[19:09] <jtatum_> mikefletcher: what version of ubuntu was the gnome-screenshot test written in?
[19:27] <mikefletcher> jtatum_: 9.04
[19:27] <jtatum_> mikefletcher: Ah OK :) In 9.10, GRAB_A_SELECTED_AREA = 'rbtnSelectareatograb' - just FYI in case it comes up
[19:28] <jtatum_> everything else ran perfectly
[19:31] <mikefletcher> jtatum_: is the trunk mago intended to test the latest ubuntu?  And then do you branch mago for each release?
[19:31] <mikefletcher> jtatum_: I never really throught about which release I should be testing against.
[19:31] <mikefletcher> throught=thought
[19:32] <jtatum_> mikefletcher: I'm not sure things are that well thought out. There really aren't that many test cases yet anyway and quite a few of them are broken in 9.10. I'm as new as you, pretty much, but intuitively I'd guess the readme for the test suite would document that?
[19:35] <jtatum_> You're right that there should be branches. There aren't, but there should be :)
[19:37] <mikefletcher> jtatum_: doh!  Ok, well then I should get this working on 9.10.
[19:39] <jtatum_> OK - in that case, it's just the one line change. I think the screenshot suite has a lot in common with the gedit suite, in terms of the sorts of things they do... In case you're looking for inspiration :)
[19:39] <jtatum_> for more random stuff to add, I mean, mikefletcher
[19:41] <jtatum_> mikefletcher: can I /msg you?
[19:41] <mikefletcher> jtatum_: yup
[19:42] <_UsUrPeR_> can somebody point me towards the karmic koala source code please?
[19:46] <thedonvaughn> _UsUrPeR_: source for what?  there is a source repo where you can download source of any package you need
[19:46] <thedonvaughn> apt-get source <package>
[19:48] <_UsUrPeR_> thedonvaughn: I need to apply a patch to an intel video driver for atom thin clients. This is pertaining to https://bugs.launchpad.net/ubuntu/+bug/418779
[19:48] <ubot4> Launchpad bug 418779 in xserver-xorg-video-intel "video artifacts in Intel 945GSE (atom chipset) dual monitor VGA output" [Unknown,Confirmed]
[19:48] <_UsUrPeR_> I have never compiled from source, and have no idea what I am doing
[19:50] <_UsUrPeR_> cool bot, btw :)
[19:56] <fader> _UsUrPeR_: There is some info here: http://www.cyberciti.biz/faq/rebuilding-ubuntu-debian-linux-binary-package/
[19:56] <fader> _UsUrPeR_: Though I can't help you much more than that, I'm afraid :/
[19:57] <fader> _UsUrPeR_: If you're building from upstream source (e.g. it comes in a .tar.gz or similar) there are instructions here as well: https://help.ubuntu.com/community/CompilingSoftware
[20:04] <_UsUrPeR_> thanks fader