[01:56] RAOF, what ISP are you using? [01:56] robert_ancell: Internode. [01:57] With what porpoise? [01:57] RAOF, good? I'm thinking of changing from TPG because the performance has been bad for months [01:57] Yeah, Internode have been generally great. [01:58] They may be more expensive, although I also bundle in a VoIP phone for free, so it's less so. [02:00] But I consistently pull ~ 1.4MiB/sec from the Ubuntu mirror on mirror.internode.on.net, and 300 ~ 1000KiB/sec from various overseas places. [02:00] RAOF, hmm, they have a lot of plans, what's the difference [02:00] nice [02:01] They've really only got about 5 plans, but 4 different ways of actually being connected ): [02:01] :) [02:03] Depending on how much you love Telstra's phone service you probably want one of the Naked ADSL2+ plans. [02:03] If Internode have some dslam hardware available at your exchange, of course. They probably do, Sydneysider! [02:04] You can have my old port on the Cammeray exchange :) [02:04] heh, so I don't get the difference between "Easy" and "Extreme" [02:05] I don't think they had them when I signed up. [02:07] I think “Extreme” == ADSL2+ [02:08] why wouldn't they all be on ADSL2+ now, if there's the option? [02:08] It says "Easy" is 2+ as well. [02:09] * ajmitch really needs to find out how to get this laptop cooling better before it dies [02:11] ok, weird. "Easy"=internode or optus wholesale network, "Extreme"= internode only, "Ultra"=optus only. I have no idea why they're exposing these details to customers [02:12] There's probably some cash involved, but yeah. [02:12] It does seem rather silly. [02:28] RAOF, do you use a hardware phone for SIP? === asac_ is now known as asac [02:59] robert_ancell: Yeah, I do. [03:00] I got a SIP router/adsl modem with a rs-whatever port :) [03:00] I was thinking is it better to get that or a SIP phone [03:02] Oh, right. [03:03] Well, I already had a regular phone, didn't have an ADSL2+ router, and IIRC they gave it away for free with a 2 year contract, so it wasn't much of a decision for me. [03:56] robert_ancell, hey [03:56] robert_ancell, i haven't looked at that branch yet... but is it just this patch http://launchpadlibrarian.net/57067390/light.debdif-style.patch [03:56] ? [03:58] kenvandine, yes [03:58] robert_ancell, the light-themes package is done a bit different... probably be easier for me just to apply that patch :) [03:59] kenvandine, yeah, that's what I thought! Is there a problem with the upload to maverick-proposed though? (i.e. you probably want to take into account the version number I used) [03:59] ok, i'll grab the changelog :) [03:59] and fix it in trunk [03:59] thansk [03:59] lp:light-themes is upstream and packaging [04:00] and it is a native package [04:00] i messed it up a couple times when i was getting to know it :) [04:01] kenvandine, add the Vcs-Bzr link into the control file - that will make it clearer :) [04:01] good idea :) [04:01] actually i think i did once, and kwwii took it out again [04:05] merged [04:05] thx robert_ancell [05:24] pitti, can you let vala out of the new queue in natty? thanks === almaisan-away is now known as al-maisan [07:16] Hm. Are we going to be shipping the new pane-based gnome-control-centre in Natty? === smspilla1 is now known as smspillaz === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [08:45] morning [08:47] morning rodrigo_ [08:48] bonjour didrocks [08:55] hmm, where do I file a kernel module bug? https://edge.launchpad.net/~ubuntu-kernel-team doesn't have a 'report bug' link [08:56] ah, Kernel Bugs! [08:56] :) [08:56] no, https://edge.launchpad.net/~kernel-bugs doesn't have the link [08:59] ok, found the package [09:07] rodrigo_, hi [09:07] hi ricotz [09:08] rodrigo_, have you seen my merge proposal? [09:08] ricotz, hmm, no, still going over mail, looking now [09:08] ok [09:15] ricotz, ah, adding the online patch [09:15] rodrigo_, i also would suggest to clean up the changelog, i think there is no need to document ppa uploads, all changes for the official upload should go into one changelog entry [09:16] rodrigo_, yes it got dropped ;-) [09:16] ricotz, on my branch? [09:17] not sure, it was an inline patch, to might be happened while the upstream import [09:17] right [09:18] hey rodrigo_, ricotz [09:18] hi seb128 [09:18] seb128, hi [09:19] rodrigo_, ricotz: keeping the ppa uploads in a changelog is fine [09:19] what update are you working on? [09:19] seb128, https://code.launchpad.net/~ricotz/libcanberra/ubuntu/+merge/40051 [09:19] ricotz, looks good to me, if seb128 agrees, I'll merge it with my branch [09:20] seems fine, just don't use 0ubuntu2 yet [09:20] still use a ppa version until it lands in natty [09:20] it can't land before gtk3 lands [09:21] seb128, hmm, keeping the ppa revisions will create quite some clutter in the changelog, it can be added locally before the upload? [09:22] why clutter? [09:22] it's just the package history [09:22] seb128, I think we can do what ricotz says, keep the correct version in the merge proposal [09:22] ah, ok [09:22] well it's the same story that people tweaking git history before merges [09:22] some people like to keep things the way they have been done [09:22] some others like to tweak history to make things cleaner [09:23] seb128, i mean noise, it will look cleaner, and the official upload will get a nice changelog [09:23] it's a matter of taste, none is better than the other [09:23] ok, just my opinion [09:24] I've no strong opinion but I just want to point that either is fine [09:24] whoever is doing the work can decide [09:24] ok ;) [09:24] I tend to debuild -v to include the ppa upload changelog entries [09:24] but if other people prefer to merge things before upload that's fine as well [09:25] ricotz, are you using natty already? [09:25] rodrigo_, so it is up to you then ;-) [09:25] rodrigo_, yes [09:25] ok [09:25] I guess I need to upgrade asap [09:26] rodrigo_, keep a ppa version in the changelog for now [09:26] I mean 0ubuntu2~something [09:26] to not conflict with the official natty upload [09:26] ok [09:26] I'll leave it as 0.26-0ubuntu1~ppa1 [09:27] well, 0ubuntu2, yeah :) [09:29] thanks [09:29] didrocks, evo bug your way ;-) [09:30] didrocks, bug #670747 [09:30] Launchpad bug 670747 in evolution (Ubuntu) "cannot import outlook pst file (addressbook, calendar, email) (affects: 1) (heat: 6)" [Low,Triaged] https://launchpad.net/bugs/670747 [09:31] seb128: nooooooo, not from the morning! [09:31] didrocks, this one seems a one liner in the rules [09:31] but I'm not sure if you did it on purpose on not [09:31] seb128: let me have a look [09:32] didrocks, the pst-import is still listed in the control and .install [09:32] you just let the --disable-pst-import from debian it seems [09:33] rodrigo_, "bzr merge" is your friend on this [09:33] seb128: probably a merge error, right, as my previous SRU is still not accepted, I'll upload a new one [09:33] ricotz, yeah, I know, just that I got the patch in .txt for reviewing it, so it was easy to just patch < ... [09:33] seb128: can you kill my previous evolution upload to maverick-proposed? [09:33] didrocks, thanks ;-) [09:34] rodrigo_, no you didnt patched it right ;) [09:34] thank to you :) [09:34] ricotz, oh? [09:34] rodrigo_, the patch itself is missing [09:34] ah, forgot to bzr add [09:34] didrocks, upload cleaned from the queue [09:35] seb128: thanks [09:35] ricotz, fixed now [09:36] * rodrigo_ upgrades to natty [09:36] rodrigo_, ok :P, but using "bzr merge" is the right thing [09:36] ricotz, yeah [09:38] seb128, you are going to upload the gnome3 ppa packages to natty this week, right? [09:39] rodrigo_, yes, likely later today or tomorrow [09:39] why? [09:39] seb128, just wanted to know :) [09:39] well things in order, we will start this week [09:39] we might need to wait until gtk3 built to upload other things [09:39] so maybe earlier next week for some of the sources [09:39] yeah, right [09:46] rodrigo_, could you triage https://bugs.launchpad.net/ubuntu/+source/evolution-couchdb? [09:46] seb128, yes [09:46] rodrigo_, there is only 19 bugs on it so it should be easy enough [09:47] I just reassigned a bug about contact not being editable but I'm not sure what to ask on that [09:47] rodrigo_, thanks [09:47] there is also a "not synchronizing" bug with quite duplicate [09:47] yes, that's the couchdb error [09:47] it might be due to the server issues during the maverick cycle and fixed [09:48] in any case if you could drop some comments in bugs you have a clue about that would be nice ;-) [09:48] thanks [09:48] ok === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [10:42] morning [10:48] lut huats [10:49] hello seb128! === davidbarth is now known as dbarth [11:24] chrisccoulson: this paste being broken thing in gnome-terminal ... will you fix it? :) [11:26] asac - oh, i think i said i'd fix it ;) [11:27] chrisccoulson: you said "today" on oct 13 ;) [11:27] heh [11:27] i'll try and look at that this week ;) [11:58] chrisccoulson: it works if you open the top level Edit menu once [11:58] so its probably a keyboard shortcut lazily getting initialized :) [12:34] good morning everyone [12:34] seb128: would you be able to sponsor https://code.launchpad.net/~nataliabidart/ubuntu/maverick/ubuntu-sso-client/ubuntu-sso-client-1.0.7/+merge/40077 ? [12:34] nessita, hey [12:34] sure [12:35] thanks! [12:35] np [12:35] it's a stable update right? [12:36] seb128: are you waiting for anything in NEW? [12:36] * pitti just NEWed vala, as requested by Robert [12:37] but I can't see anything GTKish [12:37] pitti, not yet, got sidetracked by post UDS reviews and catching up [12:37] pitti, GTK will probably be latter today or tomorrow, I will drop you an email when I land it [12:37] seb128: that's fine; just want to make sure you aren't blocked on me [12:37] seb128: sounds great [12:37] pitti, thanks for checking [12:37] * pitti hugs seb128 [12:37] pitti, how if you ubuflu today? [12:37] * seb128 hugs pitti [12:38] urg [12:38] pitti, how is your ubuflu today? [12:38] I meant [12:39] seb128: it never reall broke out; I guess I'm just fighting with the very dry air here [12:39] ok [12:41] seif the question was for me, yes, is a stable release [12:41] seb128: ^ [12:41] nessita, it was, so don't panick if it doesn't go through until next week [12:41] nessita, the proposed queue is frozen until next week for linaro [12:41] seb128: ah, ok [12:53] session o'clock, cu later [13:07] * rodrigo_ -> lunch [13:43] hey guys, I'm building the natty package of ubuntu-sso-client, and when using bzr merge-upstream I'm getting: [13:43] nessita@dali:~/canonical/ubuntu/ubuntu-sso-client/ubuntu-sso-client-1.1.2$ bzr merge-upstream --version 1.1.2 ../ubuntu-sso-client_1.1.2.orig.tar.gz [13:43] Using distribution natty [13:43] bzr: ERROR: Unknown target distribution: natty [13:43] Any idea what's wrong? [13:46] nessita, distribution is ubuntu [13:47] you'll just need to manually change it to natty in debian/changelog [13:47] until you are on natty, then it will default to natty [13:47] kenvandine: but I'm not explicitly setting the distribution anywhere (I've never had) [13:48] I'm just running "bzr merge-upstream --version 1.1.2 ../ubuntu-sso-client_1.1.2.orig.tar.gz" [13:48] oh... weird [13:48] i have always added a --distribution ubuntu [13:48] because it had complained to me about not having that [13:48] kenvandine: for maverick packages, the exact same command always said "distribution maverick" [13:49] nessita, you are on natty? [13:49] maybe it just doesn't know about natty yet [13:49] seb128: nopes [13:49] ok, the maverick version probably doesn't know about natty [13:49] ah! [13:49] * kenvandine moved to natty yesterday, went smoothly [13:49] james_w or didrocks might know what you need to tweak to teach it [13:50] but now i fear upgrading every day :) [13:50] ;-) [13:50] seb128: thanks, I'll ask [13:50] kenvandine: you, brave man! [13:50] james_w: ping [13:50] kenvandine, hey [13:50] kenvandine, bug #655252 [13:50] Launchpad bug 655252 in indicator-me (Ubuntu Maverick) (and 2 other projects) "Hint not always hidden when the broadcast field is in use (affects: 22) (dups: 6) (heat: 84)" [Low,Triaged] https://launchpad.net/bugs/655252 [13:50] what's going on with this one? [13:51] seems it has been fixed in trunk? is there any release planned for natty or sru? [13:51] sigh... i don't know, dbarth_ has a fix that works for him [13:51] but not me [13:51] and his fixed worked sometimes for bratsche [13:51] but we couldn't figure out why! [13:51] dbarth_, ping ^^ === dbarth_ is now known as dbarth [13:53] kenvandine: yep? [13:53] oh, the hint issue is still there? [13:53] dbarth, can you look at that bug again? [13:53] yeah... your fix never worked for me [13:53] and only worked for cody sometimes [13:53] but we couldn't figure out why [13:53] i also tested in a pristine, fresh install of maverick [13:53] nessita: it's written in debchange script [13:54] nessita: /usr/bin/debchange [13:54] nessita: add "natty" to unless ($opt_D =~ /^((dapper|hardy|jaunty|karmic|lucid|maverick) [13:54] kenvandine: i remember, the fix only worked with indicator-loader, but there was more of the same grab issue when running on the panel [13:54] also $DISTRIBUTION = 'natty' [13:54] and finally $distribution = $opt_D || "natty"; [13:55] didrocks: awesome, thanks! [13:55] dbarth, yeah, but it didn't even work for me in the loader [13:55] well, look for maverick, you will see what to change :) [13:55] nessita: yw [13:55] or just use --distribution ubuntu [13:55] or copy a natty debchange version on your system [13:55] seb128: it will apply "maverick" in maverick [13:55] kenvandine: ok, i'll have another try with bratsche [13:55] thx [13:55] didrocks, well then you can edit it by hand ;-) [13:56] dbarth, there was an assert too that we weren't sure if it was related [13:56] dbarth, kenvandine: thanks [13:56] seb128: sure, but lazyness is sometimes good :) [13:56] "# In Ubuntu uploads should go to maverick" <- wasn't changed in natty, not sure it worth an upload :) [13:58] didrocks: I don't think that's the issue since in /usr/bin/debchange I have natty already. And the error starts with bzr: [13:58] bzr: ERROR: Unknown target distribution: natty [13:58] nessita, https://bugs.launchpad.net/ubuntu/+source/bzr-builddeb/+bug/668764 [13:58] Launchpad bug 668764 in bzr-builddeb (Ubuntu) (and 1 other project) "Add Natty to the list of known distros (affects: 1) (heat: 6)" [Low,In progress] [13:59] Low?!?!?! [13:59] :-) [13:59] nessita: it's not "bzr warning: Recognised distributions are"… ok, then it's not debchange (dch use "$program to fake it's the software which speaks to you :)) [13:59] nessita, edit /usr/share/pyshared/bzrlib/plugins/builddeb/util.py [14:00] nessita, try adding natty to UBUNTU_RELEASES [14:00] right [14:00] awesome, works [14:00] I'm puzzled why we have it there as well and not only in dch, that will be a question for james_w :) [14:01] nessita, great ;-) [14:01] (also having that list just once in /etc will be nice, instead of multiple copies and own list in ~/.pbuilderrc as well) [14:03] please file a bug :-) [14:05] hey james_w [14:06] hi seb128 [14:06] how are you? [14:06] kenvandine, bug #652771, do you know if that's still an issue? [14:06] Launchpad bug 652771 in light-themes (Ubuntu) (and 3 other projects) ""Post message..." text in MeMenu is unreadable with default Ambiance theme (affects: 6) (dups: 2) (heat: 46)" [Undecided,Confirmed] https://launchpad.net/bugs/652771 [14:07] Cimi, ^ [14:07] pedro_, hey === al-maisan is now known as almaisan-away [14:07] hello seb128! [14:07] pedro_, how are you? [14:07] seb128, imo it is still a problem [14:07] grumpf [14:07] seb128, good thanks, how are you? [14:08] it hasn't gotten any better, but from what i hear it is how design wants it [14:08] james_w, I'm fine thanks ;-) [14:08] james_w, nice to be back without ubuflu this time [14:08] seb128, better now, recovering from the darn ubuflu :-/. how are you? [14:08] seb128, it is supposed to be insensitive, but in ambiance that is really hard to see [14:08] pedro_, I'm fine thanks [14:08] in radiance it looks fine [14:08] kenvandine, it's hard to read it seems [14:08] yeah [14:09] Cimi, any more insight? I was told that was on purpose [14:10] it's just with the dark theme, insensitive is nearly impossible to read [14:18] * kenvandine wonders why people actually subscribe to my identi.ca test account.... [14:19] do they really enjoy reading "testing" "test 1 2 3" [14:23] kenvandine: we might want to change it === zyga is now known as zyga-coffee [14:33] kenvandine, hey, have you thought of creating a test that the QA team could automatically run daily? [14:34] a set of daily tests to make sure Gwibber is still working? [14:34] could ensure that libgwibber keeps working too [14:34] hey seb128 [14:35] hello jcastro [14:35] mark says "Jorge, I believe the current plan is that the GNOME 2 session (panel etc) would always be installed on every system anyway, so will be an option at first login and not require a special trip via the Software Center to get it " [14:35] I just want to double confirm. :) [14:35] rickspencer3, have thought about it, but haven't figured out how to automate it [14:35] confirmed [14:35] ta [14:35] jcastro, ^ [14:35] rickspencer3, i am also thinking about trying to use dbus-test-runner [14:36] jcastro, it will be used as a 2d session anyway [14:36] kenvandine, well, the QA team is going to run tests daily, automatically, using mago [14:36] seb128: thanks [14:36] so you can drive Gwibber through the UI, and ensure that if it breaks, you find out right away [14:36] the hard part of testing something like gwibber, will be the authentication bits [14:36] and don't have to worry about it [14:37] rickspencer3, i would like to find a way to run tests with auth and real data from the services [14:37] dobey, well, mago should be able to automated the sign on and such [14:37] I think webkit is sufficiently accessible at this point [14:37] actually i hadn't really thought about mago [14:37] rickspencer3: i don't think you can do much with webkit with mago? [14:37] ara ^ [14:38] rickspencer3, afaik, it isn't completely not a11y [14:38] one of the reasons we are trying to get away from webkit [14:38] kenvandine, I think it might be sufficiently, so [14:38] they've done a lot of work on it recently [14:38] speaking of webkit [14:38] TheMuso, there? [14:38] anyway, it's an HTML DOM, so you can just inject whatever you want, anyway, with a little work [14:38] but has it made it down to pywebkitgtk [14:38] TheMuso, you said webkit accessibility was still an issue for the GNOME documentation? [14:39] kenvandine: a11y being there has nothing to do with the bindings [14:39] knowing right away that auth broke for twitter and/or facebook would be really handy [14:39] rickspencer3, indeed! [14:39] and... [14:39] if the API changes [14:39] kenvandine: what matters is finding the form buttons in the a11y tree, which may difficult as some sites do some crazy stuff for that [14:39] right, that would be part of it breaking, they break us ;) [14:39] yes, I don't think webkit can be automated using a11y, but maybe with a combination of a11y for the gtk parts, and some other (dbus api?) for the rest [14:40] ara, do you think you can automated signing into a twitter account with gwibber? [14:40] rickspencer3, ara: also... all the bits of the UI that we would be driving is webkit currently :/ [14:41] kenvandine, I have no doubt that this can be automated [14:41] rickspencer3, mmm, my first thought is that it is going to be complicated, but we can always try something out [14:41] I'm not willing to accept that it's not possible [14:41] it could be "work", yes, but not impossible [14:41] it's software, nothing is impossible [14:41] it's just a matter of how much tedium it is [14:42] rickspencer3, yeah... question is finding the time to do it :/ [14:42] it's also html in a browser, which is inherently easy to get control of [14:42] rickspencer3, it will get much easier soon, i think [14:42] kenvandine, well, automated testing is the QA team's biggest priority this release [14:42] excellent :) [14:42] i will take any help i can get :) [14:42] did I not make this clear at UDS? [14:42] yes... you did :) [14:42] rickspencer3: well, as soon as you alter the html, you end up with a higher probability that an breakage is actually you, and not the site you're trying to interact with [14:43] Unity, 2d Experience, Software Center, *Testing*, Contributions [14:43] i have talked to developers from other twitter clients... amazingly none of them have unit tests! [14:43] dobey, you don't have to alter it, just get control of the widgets and inject your strings into textboxes and click the buttons [14:44] c'mon, you can't tell me that it's rocket science to automate driving a web page, people do this all the time [14:44] rickspencer3: right, and we should really require the a11y framework to do that. becuase if the a11y framework can't do it, it's a bug we should be gettinf xied [14:44] i am hoping in the next couple of weeks we can string together a minimally functional client which is pure gtk [14:44] rather than writing some JS to inspect the dom and insert text and submit forms [14:45] dobey, right ... we always wait to start testing and ensure quality until some other condition is met [14:45] that's bs [14:45] no [14:46] that's not what i said [14:46] I'm just saying, we could write a test now that would detect breakage right away, we shouldn't wait until we have a perfectly testable platform [14:46] rickspencer3, so i would rather start testing the backend, independant of the client [14:47] using the JS method as a crutch is fine, but it should be a fallback for when the a11y is failing, and we should report that the a11y is failing [14:47] kenvandine, interesting discussion there in the testing community [14:47] some people think you should always test the GUI, because that drives the backend, and you get testing for both in one go [14:47] before spending a bunch of time creating tests for piece of the UI that is very likely going to be replaced very soon [14:47] rickspencer3, i agree completely... [14:47] kenvandine, well, if there are tests in place for the GUI, then when you change the GUI, you change the tests at the same time [14:48] but there are cases where you can't, especially with gwibber [14:48] if you always wait until the GUI is "done" you never write those tests [14:48] well testing the GUI is nice [14:48] i wonder how much even basic stuff gwibber isn't doing [14:48] rickspencer3, in theory... but if the new GUI has now webkit... [14:48] but it's somewhat harder so usually people start by testing the backends [14:48] like, using pylint/pep8 [14:48] dobey, oh god, i don't want to even know :) [14:48] haha [14:49] in any case, Gwibber is core to the desktop [14:49] we should be testing it daily [14:49] it integrates all over the place [14:49] i know it will bitch like crazy over the indenting :) [14:49] rickspencer3, yes... i agree [14:49] dobey, do you need to be pep8 to work with testing tools? [14:49] you really need to separate integration/acceptance/unit/etc... tests properly too [14:49] no [14:49] seb128: no, you can write totally shit code and have passing tests if you want === zyga-coffee is now known as zyga [14:50] well the number of spaces you use doesn't really reflect code quality [14:50] seb128: but better code == better software, and using the lintian tools helps ensure better code quality [14:50] right [14:50] they are both important [14:50] if you care about your code lasting, anyway [14:50] rickspencer3, my point is if the amount of effort to get automated GUI tests with the current webkit stuff is high, better to make the new UI with real a11y a higher priority so the testing is easier... right? [14:51] kenvandine, I don't believe it is that high [14:51] instead of investing a bunch of work and throw it away [14:51] but I am skeptical that the "new GUI" is going to be ready any time soon [14:51] which is why we're working on making all the u1 python code pass pylint and pep8 cleanly [14:51] you always "throw tests away" when the thing that you are testing changes, or goes away [14:51] rickspencer3, i was until UDS... but it seems to have traction now [14:51] and why we're building with -Wall -Werror when landing code now [14:52] rickspencer3, of course... [14:52] also, it would only be the code that drives the UI that changes [14:52] all the code for loading the fixtures, checking for results, etc... would all remain in place [14:52] and gwibber is not the only thing that uses webkit, so knowing how to test it would be generally good, anyway [14:53] kenvandine: gwibber would probably benefit a lot from some of the stuff in ubuntuone-dev-tools [14:53] i don't know much about js and manipulating the DOM, but from what ryan and others have said it is nearly impossible with our current python-mako/python-webkitgtk stuff [14:53]