[01:36] <kieppie> !applet ?applet
[01:36] <ubot4> Factoid 'applet ?applet' not found
[01:36] <kieppie> ubot4: !applet
[01:36] <ubot4> Factoid 'applet' not found
[01:37] <kieppie> hey guys. what's the deal with the applet? how can I explicitly force a sync & see the sync status?
[01:37] <kieppie> !indicator
[01:37] <ubot4> Factoid 'indicator' not found
[01:51] <kieppie> anyone online?
[02:28] <kieppie> anyone online yet?
[03:32] <jamesh> kieppie: you can see the status of the daemon by running "u1sdtool --status" in a terminal
[03:33] <jamesh> kieppie: alternatively, you can run "u1sdtool -w" to wait until things become quiescent
[06:05] <_vaibhav_> how to unshare folders and files synced with ubuntu one??
[06:06] <_vaibhav_> mistakenly I said sync wrong folder, I dont want it to be sync..
[08:14] <duanedesign> morning all
[08:14] <duanedesign> _vaibhav_: hello
[08:14] <duanedesign> _vaibhav_: get your folder unsynced?
[08:21] <rye> ATTENTION: At 8:00 UTC we will start updating the servers, database and related service that will cause up to 4 hours downtime for web ui, syncdaemon, public files, music store, music streaming, couchdb replication and contacts syncing
[08:22] <rye> ^ well, 8:00 was 21 minutes ago
[08:22] <Tm_T> rye: that's 10 hours from now, or _now_ ?
[08:22] <rye> Tm_T, that's 08:00 AM, which is 22 minutes ago
[08:22] <Tm_T> rogery (:
[08:22] <duanedesign> thanks rye for the heads up
[08:23] <rye> duanedesign, it was on facebook, identi.ca, twitter, status page and i will add this to the subject now
[08:56] <_vaibhav_> duanedesign: yes, Thanks.. :)
[08:58] <duanedesign> _vaibhav_: you might of already seen this. This is a good reference for operating the client from the command line. Also has some info at the bottom for removing accidentaly synced folders. https://wiki.ubuntu.com/RomanYepishev/UbuntuOne/ClientControl
[09:02] <_vaibhav_> duanedesign: thanks a lot, It will speedup my work..
[12:18] <tola> Any news on the UbuntuOne maintenance? I was expecting it to be up by now?
[12:19] <tola> Oh, just seen the tweet. Another two hours? Ugh.
[12:19] <rye> We have had to extend the downtime for additional 2 hours. We estimate services to be brought back by 1400 UTC. Sorry for the inconvenience.
[12:19] <rye> tola, yes, that is not really a great thing
[12:20] <duanedesign> rye: I also put a sticky up on the Forums
[12:20] <tola> rye: OK, thanks for letting me know. It is a bit inconvenient (I need to get to some files for work) but I'm sure the engineers are doing their best.
[12:21] <duanedesign> new Natty kernel is not working so well. At least the WiFi
[12:28] <ralsina> good morning!
[12:28] <duanedesign> hello rye
[12:28] <duanedesign> oops
[12:28] <duanedesign> hello ralsina
[12:29] <ralsina> Hello duanedesign
[12:29] <rye> duanedesign, hello duanedesign (since i did not react on the original message), thanks for putting the info on the forums
[12:50] <ralsina> rye: want a review for https://code.launchpad.net/~rye/ubuntuone-client/lucid-backport-work-lp657195/+merge/47231 ?
[12:52] <rye> ralsina, well, it is for dobey's lucid backport branch, don't know what's the policy for such branches
[12:52] <ralsina> rye: me neither, so I'll wait for dobey ;-)
[12:55] <alecu> hello #ubuntuone! good morning all!
[12:57] <nessita> hi alecu
[12:58] <ralsina> hola alecu!
[12:58] <alecu> hola jefes!
[12:58] <ralsina> alecu: +1 the disable zeitgeist branch
[12:58] <alecu> ralsina, were you able to review my branch on lucid?
[12:58] <ralsina> alecu: yes, but only wth nightlies
[12:58] <ralsina> alecu: which was maybe not the smartest thing
[12:59] <alecu> ralsina, well, I think that's the way to build the client on lucid... with the nightlies.
[12:59] <alecu> ralsina, so it should be ok. thanks!
[12:59] <ralsina> alecu: about the "when to show notifications" thread. Are you aware of XSMP?
[13:00] <ralsina> alecu: well, it worked ok then ;-)
[13:00] <alecu> ralsina, no, let me find out more.
[13:00] <ralsina> basically, you can interact with the user on event of session closing/suspension
[13:01] <ralsina> I think that would remove one of your annoying cases and give you more freedom about when to show stuff
[13:02] <alecu> ralsina, right, I knew there was some way to do that, I didn't know the name.
[13:02] <alecu> ralsina, "X Session Management Protocol", right?
[13:02] <ralsina> alecu: no idea what's the API from gtk for it though
[13:02] <ralsina> alecu: right
[13:02] <alecu> ralsina, it seems it does a bit more than what we need
[13:02] <ralsina> I am not actually sure if it handles suspension, though
[13:03] <ralsina> alecu: yes, it's also intended to persist state over sessions, but we want the part of "the session id closing, need anything?" :-)
[13:03] <alecu> ralsina, great. The thing is, we do not have an X connection on syncdaemon, only dbus.
[13:03] <ralsina> alecu: well, that sure sucks ;-)
[13:04] <alecu> ralsina, so we may need to do this on the gsd-plugin. Or some other place.
[13:04] <ralsina> Yep.
[13:04] <alecu> ralsina, anyway, I wanted to discuss a little bit more on this.
[13:04] <ralsina> There is session management over dbus!
[13:05] <alecu> ralsina, no, not session managemente
[13:05] <alecu> ralsina, I want to discuss notifications
[13:05] <ralsina> alecu: sure
[13:05] <alecu> ralsina, I was very "moved" by the comparison to clippy
[13:05] <alecu> ralsina, there's a lot of truth there
[13:05] <ralsina> hahaha
[13:05] <ralsina> yes, a bit
[13:05] <alecu> ralsina, so I'm truly trying to find out how much we should be actively bothering the user
[13:06] <ralsina> But I don't expect the bubbles to be our primary mechanism of interaction with the user
[13:06] <alecu> ralsina, then we will have to tone it down, a lot.
[13:06] <ralsina> For example, progress will be moved to the unity progressbar
[13:06] <ralsina> Warnings about things not finishing will have to be moved to the session somehow
[13:06] <ralsina> Out-of-space and other alerts will go to the unity icon overlay, whatever it's calle
[13:07] <ralsina> Other things go to the messaging menu
[13:07] <ralsina> So... I don't see there being much left for the bubbles themselves
[13:07] <alecu> yes, I agree with that
[13:07] <alecu> ralsina, my idea was to turn this around
[13:08] <alecu> ralsina, instead of calling a dbus method to show the bubbles, we should be be firing a dbus signal
[13:08] <alecu> ralsina, and interested apps can read the status. (for instance, the control panel)
[13:08] <ralsina> alecu: makes sense
[13:08] <ralsina> alecu: of course it means there is no notifications by default
[13:09] <ralsina> alecu: or am I misunderstanding?
[13:09] <alecu> ralsina, exactly. Now I also believe "no notifications" should be the default.
[13:09] <ralsina> alecu: I agree until we have the means for less annoying notifications.
[13:10] <ralsina> For example, I think that adding shares to the messaging menu is useful
[13:10] <ralsina> shares I meant "received shares"
[13:10] <alecu> sure. both received shares and available udfs for subscription
[13:11] <ralsina> We can also implement the warning about not syncing using GNomeSession over DBUS: http://live.gnome.org/SessionManagement/GnomeSession
[13:11] <ralsina> I think that covers both "important" notifications
[13:12] <ralsina> So I agree. It was important to try it, and see how it worked. Too bad basically we didn't like it so much, but live and learn.
[13:15] <alecu> ralsina, I'm playing with D-Feet, and I see that there are a lot of apps registered in org.gnome.SessionManager
[13:15] <ralsina> alecu: basically every gnome app will register automatically, I think
[13:16] <alecu> ralsina, automatically? nice!
[13:16] <alecu> ralsina, but we don't have X nor gtk on syncdaemon
[13:16] <ralsina> alecu: but we can register over dbus
[13:16] <ralsina> And then we get the QueryEndSession signal, I think
[13:17] <alecu> ralsina, right... I was thinking of using the gnome libraries that do that dbus talking... but right, we will have to do that by hand.
[13:18] <ralsina> You can always read the GNOME sources to see how it's done I suppose
[13:20] <ralsina> Doesn't look terrbly hard though
[13:20] <ralsina> http://people.gnome.org/~mccann/gnome-session/docs/gnome-session.html#org.gnome.SessionManager
[13:20] <ralsina> You can even just inhibit and uninhibit when you are busy :-)
[13:20] <alecu> ralsina, Inhibit
[13:21] <ralsina> If you just call Inhibit then when the user tries to logout he will be told he can't because ubuntuone is not ready, and he can ask to logout anyway
[13:21] <ralsina> Not very friendly
[13:21] <ralsina> But you can set a reason using the Inhibitor interface, it seems
[13:22] <alecu> ralsina, Inhibit also has a "reason"
[13:22] <alecu> 1 (logging out) + 4 (suspending)...
[13:22] <ralsina> Oh, right, Inhibitor is to query the inhibitions
[13:22] <ralsina> alecu, cool, so it's just three dbus calls, maybe
[13:24] <alecu> ralsina, so, I've just called Inhibit
[13:24] <alecu> ralsina, and tried to log out
[13:24] <alecu> ralsina, I was shown the dialog to log out, I clicked on "log out"
[13:24] <alecu> ralsina, and *after* that, I'm presented with another window
[13:25] <alecu> "A program is still running"
[13:25] <alecu> "Ubuntu One"
[13:25] <alecu> "the reason I set"
[13:25] <alecu> and three options:
[13:25] <ralsina> You didn't even register? Neat!
[13:25] <alecu> "lock screen", "cancel", "logout anyway"
[13:25] <ralsina> I love when the platform does our job;-)
[13:25] <alecu> ralsina,  :-)
[13:26] <alecu> now I'll call uninhibit, and I'll let you know after I log back in...
[13:26] <ralsina> testing this is a pain :-D
[13:27] <alecu> ralsina, no need. I'm calling "IsInhibited", and it returns the right flags.
[13:27] <alecu> ralsina, I don't see how this handles "crashing".
[13:28] <ralsina> well, crashing is out of spec
[13:28] <alecu> :-)
[13:28] <ralsina> Just like running out of battery or meteorite impact
[13:29] <ralsina> It won't run the tests on fake dbus session because you don't have gnome session running...
[13:30] <alecu> ralsina, for that we fake a "server" SessionManager object that implements these exact dbus methods.
[13:30] <alecu> ralsina, that's what we do for the keyring manager.
[13:30] <ralsina> alecu: and then we start an upload and check if it reports inhibition?
[13:31] <alecu> ralsina, right. We tell it to inhibit, and check that it was successfully inhibited.
[13:31] <ralsina> ok
[13:34] <alecu> ralsina, ok, I'll prepare a new mail, telling that we won't be doing notification bubbles at all, and telling about the new world order.
[13:34] <ralsina> great
[13:53] <ralsina> alecu dobey CardinalFang nessita thisfred cds standup in 8'
[13:53] <thisfred> ackthx
[13:54] <mandel> ralsina: im a included?
[13:54] <ralsina> mandel: sorry, didn't see you!
[13:55] <mandel> ralsina: not that i have much to report
[13:55] <ralsina> mandel: start typing head :-)
[13:55] <ralsina> report on your doctor's visit and how much it hurts/itches
[13:55] <ralsina> s/head/ahead/
[14:01] <vds> me?
[14:01] <mandel> me
[14:01] <nessita> me
[14:01] <alecu> me
[14:01] <CardinalFang> me
[14:02] <ralsina> me
[14:02] <nessita> thisfred, dobey?
[14:02] <thisfred> me
[14:03] <dobey> me
[14:03] <nessita> vds: go!
[14:03] <vds> DONE: seventh branch for #701029 landed eight, started
[14:03] <vds> TODO: continuing with the views, but not for too long, shortly (tomorrow) it's going to be url testing
[14:03] <vds> BLOCKED: nope, but I will need DAL to support uploading of files soon
[14:03] <vds> mandel: prego
[14:03] <mandel> DONE: doctor appointment, cast will have to be there for 6 weeks and i have to take drugs the first week. After that I should be able to get back to coding (although i'll be very slow).
[14:03] <mandel> TODO: take drugs, rest. Mumble after this on how to re-organize work
[14:03] <mandel> BLOCK: yes, no coding 'til next week
[14:03] <mandel> nessita, please go ahead
[14:03] <nessita> DONE: follow up on releases of ussoc and u1cp (all done!). More coding for bug #708335. I tried to started the IRL testing but syncdaemon was extremely slow (caused by storage servers being extremely slow). Made some reviews, bug triage.
[14:03] <nessita> TODO: ussoc questions/concerns from aquarius/rye/Chipaca. shares-subscription IRL testing. Maybe do the expenses claim from platform rally?
[14:03] <nessita> BLOCKED: ubuntu one service being down (should be back at 14 UTC)
[14:03] <nessita> LOVE: morning mate with tostadas and cheese
[14:03] <nessita> NEXT: alecu
[14:03] <ubot4> Launchpad bug 708335 in ubuntuone-client "Add subscription capabilities to shares (affects: 1) (heat: 119)" [High,In progress] https://launchpad.net/bugs/708335
[14:03] <alecu> DONE: fixed a few server bugs when running the client integration tests. Worked on the notifications branch, more discussion, lots of thoughts on it, arrived at the right solution: discard notifications
[14:03] <alecu> TODO: finish mail explaining new world order, work on branch to show new folders events in messaging menu (bug #702075 and bug #702144)
[14:03] <alecu> BLOCKED: no, thanks!
[14:03] <alecu> LOVE & HATE: that we will not be showing notifications
[14:03] <alecu> NEXT: CardinalFang
[14:03] <ubot4> Launchpad bug 702075 in ubuntuone-client (Ubuntu) (and 1 other project) "Syncdaemon needs to add an entry to the messaging menu when a new UDF is available for subscription (affects: 1) (heat: 230)" [Medium,Triaged] https://launchpad.net/bugs/702075
[14:03] <ubot4> Launchpad bug 702144 in ubuntuone-client (Ubuntu) (and 1 other project) "Syncdaemon needs to add an entry to the messaging menu when a new share offer comes in (affects: 1) (heat: 230)" [Medium,Triaged] https://launchpad.net/bugs/702144
[14:04] <CardinalFang> DONE: landed fixes for two bugs in desktopcouch replication.  landed fix for missing-sd-card UI complaint in ubuntuone-android-music.  Failed to find some way to cause exception that I thought I avoided last week, so removed Exception-exception from a branch nessita reviewed.
[14:04] <CardinalFang> TODO: test replication more.
[14:04] <CardinalFang> BLOCKING: None.
[14:04] <CardinalFang> ralsina, svp
[14:04] <ralsina> DONE: reviews, did my canonicaladmin work, researched for sprint, desktop integration call, read code.
[14:04] <ralsina> TODO: reviews, management stuff, sprint planning, someday actual coding ;-)
[14:04] <ralsina> BLOCKED: no
[14:04] <ralsina> LOVE: D-Bus
[14:04] <ralsina> HATES: Nothing today
[14:04] <ralsina> thisfred!
[14:05] <thisfred> DONE: branch that allows message counts and updating notfications
[14:05] <thisfred> TODO: get branch approved and landed
[14:05] <thisfred> BLOCKED: no
[14:05] <thisfred> LOVED: http://tinysong.com/nUwx
[14:05] <thisfred> dobey!
[14:05] <dobey> λ DONE: bug 591340, discussed external contacts in picker, vapigen research
[14:05] <dobey> λ TODO: finish bug 673012, evaluate SRUs for maverick, vapi for libsd
[14:05] <dobey> λ BLCK: None.
[14:05] <ubot4> Launchpad bug 591340 in ubuntuone-client "tests.test_preferences.PreferencesTests should not depend on the system Dbus service (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/591340
[14:05] <ubot4> Launchpad bug 673012 in desktopcouch (Ubuntu) (and 1 other project) "Async monitoring of _changes (affects: 1) (heat: 39)" [Undecided,Confirmed] https://launchpad.net/bugs/673012
[14:05] <ralsina> ok, comments? We will have to mumble after this for 5 minutes
[14:05] <nessita> CardinalFang: I reported bug #711208 and I approved your branch
[14:05] <ubot4> Launchpad bug 711208 in desktopcouch "desktopcouch-service is failing with IncompleteRead(2356 bytes read, 6 more expected) (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/711208
[14:06] <nessita> ralsina: I have comments! I want notifs
[14:06] <nessita> I agree to add more delay and stuff, but I want them
[14:06] <ralsina> nessita: we will have. Just no bubbles :-)
[14:06] <nessita> I want bubbles!
[14:06] <nessita> I agree to add more delay and stuff, but I want them
[14:06] <alecu> nessita, we won't have them
[14:07] <ralsina> nessita alecu: we can talk about it a bit more, of course. But alecu and I don't like them much anymore.
[14:07] <alecu> nessita, please wait for a few minutes while I finish the mail explaining why not
[14:07] <nessita> alecu: why not?
[14:07] <alecu> nessita,  and then you'll be able to complain.
[14:07] <dobey> ralsina: "we will have to mumble" ? you, or all of us?
[14:07] <ralsina> dobey: you me and mandel at least
[14:07] <nessita> alecu: ok, please do not land any bubble-removing branch until we agree on this
[14:07] <ralsina> dobey: so we can talk about shotwell, since mandel can't type
[14:08] <dobey> ralsina: ok. and apparently i can't speak (stupid sound drivers/pulseaudio)
[14:08] <mandel> hahaha
[14:08] <ralsina> dobey: you type, mandel speaks :-)
[14:08] <dobey> yeah
[14:08] <ralsina> Ok, sprint news
[14:09] <dobey> alecu, nessita, ralsina: perhaps i should help with the bubble discussion, since i've been down this road before? :)
[14:09] <ralsina> Based on Canonical policy, it should be done in the city where more of us lives
[14:09] <ralsina> Bending the rules a bit, that meant either London, Orlando or Buenos Aires
[14:10] <ralsina> London is very expensive, and only qualified because of the two UX contractors
[14:10] <mandel> how is in london?
[14:10] <nessita> ralsina: from us, who lives in Orlando?
[14:10] <ralsina> nessita: noone, that's why it's bending the rules ;-)
[14:10] <dobey> ralsina: chad does
[14:10] <ralsina> dobey: oh, right!
[14:10] <CardinalFang> Yes, just me from this team.
[14:10] <nessita> right, chad
[14:10] <nessita> I forgot, sorry
[14:11] <ralsina> And two others have easy access to Orlando, so I counted 3
[14:11] <ralsina> Buenos Aires has 2, but I counted nessita too
[14:11] <ralsina> And London has chipaca + 2 UX contractors
[14:11] <alecu> so it's a tie!
[14:11] <nessita> buenos aires is cheaper!
[14:11] <nessita> :-P
[14:11] <ralsina> Based on airfare and hotel costs, Buenos Aires is *much* cheaper
[14:11] <Chipaca> contractors wouldn't come to the sprint
[14:11] <Chipaca> I think
[14:12] <ralsina> For example, London<->Orlando is 30% more expensive than London<->Buenos Aires
[14:12] <ralsina> And the hotel is 2/3 the cost
[14:12] <Chipaca> (i don't think flying around the globe is part of the standard contract)
[14:12] <ralsina> Chipaca: I thought you said they would?
[14:13] <Chipaca> ralsina: I said we'd have people from design, I pretty sure I didn't say contractors
[14:13] <mandel> ralsina: but from italy and spain surely is more expensive to argentina than to usa, right?
[14:13] <ralsina> Oh, I just assumed it was the new contractors. Ok.
[14:13] <ralsina> mandel: not from spain, actually.
[14:13] <ralsina> Let me get the numbers
[14:13] <ralsina> From italy it's expensive yes
[14:13] <mandel> he, i though it wouldm funny
[14:14] <mandel> that m is a ,
[14:14] <ralsina> Barcelona <-> Argentina == $1174
[14:14] <Chipaca> mandel: I guess the rape-o-rama cost needs to be paid by somebody
[14:15] <ralsina> Barcelona <-> Orlando == $908
[14:15] <ralsina> So yes, a bit more expensive
[14:15] <Chipaca> 30% is not "a bit" :)
[14:16] <ralsina> Chipaca: compensated by the cost for the london contingent :-)
[14:16] <mandel> I though so, athough for me you can assume im going from madrid since if i book the train on time is just 60 eur return
[14:16] <ralsina> Delta costs $555 + 385 taxes! WTF?
[14:16] <ralsina> Ok, then
[14:16] <Chipaca> ralsina: have fun with the spreadsheet :)
[14:17] <vds> ralsina, do we already have a date? if so I missed it, sorry
[14:17] <dobey> ralsina: depending on where you look at prices, they get calculated really weirdly
[14:17] <ralsina> I will be preparing a document with both targets and then I will submit it to marianna who will help me from then on
[14:17] <dobey> vds: week of Apr 04
[14:17] <ralsina> vds: april 4th
[14:17] <nessita> vds: fom April 4th to April 8th
[14:17] <tola> Any update on UbuntuOne maintenance?
[14:17] <CardinalFang> No travel sites have an API, where we could use itertools.combinations()?
[14:17] <nessita> vds: closed interval
[14:17] <dobey> CardinalFang: no
[14:17] <Chipaca> CardinalFang: man, I wish they would
[14:17] <vds> ralsina, Chipaca no chance for a trivirtual sprint again?
[14:18] <Chipaca> vds: I don't think it was effective, no
[14:18] <dobey> CardinalFang: travel sites are really big on you having to use *their* site for everything :-/
[14:18] <mandel> vds: when did we do that?
[14:19] <vds> mandel, not sure you joined already
[14:19] <ralsina> dobey: of course, that's the only reason they have to exist. Airlines should provide the APIs instead.
[14:19] <mandel> CardinalFang: best option is to find a way to connected to amadeus to retrieve the data sinc is what those webs use
[14:19] <mandel> ralsina: ^
[14:20] <dobey> mandel: i thought you couldn't type
[14:20] <mandel> dobey: Ive been typing that for the last minute, which is bloody titing :P
[14:21] <mandel> tiring*
[14:21] <ralsina> mandel: there is no public access to amadeus, IIRC
[14:21] <ralsina> But I may be completely wrong, of course
[14:21] <dobey> all the travel sites don't use the same info
[14:21] <ralsina> Ok, I have team leads call in 9'
[14:21] <ralsina> eom?
[14:21] <mandel> dobey: i should be typing with my left hand for the next 4 weeks so i might as well start practicing now
[14:22] <mandel> ralsina: mumble?
[14:22] <dobey> most of the ones in the us use travelocity or that MS one
[14:22] <ralsina> mandel dobey, mumble quickly
[14:22] <CardinalFang> So, did we decide on Orlando?
[14:22] <dobey> mandel: surely you've already got plenty practice
[14:22] <ralsina> CardinalFang: probably not, wait for spreadsheet
[14:22] <CardinalFang> Right.
[14:23] <mandel> dobey: yes, but not with only the left hand
[14:23]  * CardinalFang thinks he should change his address to a post-office box in Las Vegas for a week or so.
[14:23] <nessita> eom!
[14:23] <dobey> BA or Orlando are the only viable options anyway
[14:23] <nessita> wasn't Orlando all booked? :-D
[14:24]  * nessita begs for BA
[14:24] <CardinalFang> Okay.  I'm moving locations.  AFK for a bit.
[14:25]  * CardinalFang away
[14:25] <mandel> dobey: got it, good one :)
[14:26] <dobey> :)
[14:35] <snap-l> Just read the update, and answered my question. Thanks. :)
[14:37] <thisfred> alecu, lucio, facundobatista, nessita: new u1-client branch  https://code.launchpad.net/~thisfred/ubuntuone-client/science-fiction-double-feature/+merge/48169
[14:38] <alecu> thisfred, I hope you don't kill me
[14:38] <thisfred> I just saw your mail :)
[14:39] <alecu> thisfred, I'm reviewing it :-)
[14:39] <thisfred> alecu: no, it's fine, notification hasn't been that much work, the messaging, was the bulk of it, which we will still use
[14:39] <alecu> thisfred, cool :-)
[14:39] <thisfred> alecu: and I agree completely. I liked Clynt's analysis a lot
[14:40] <thisfred> Clint that is
[14:40] <thisfred> alecu: I vote we leave the notification infrastructure in for now. I think we may still want to notify in case of massive failures
[14:41] <dobey> nessita: you proposed your add-subscribed-to-shares branch twice it looks like
[14:41] <alecu> thisfred, absolutely, let's keep that.
[14:41] <thisfred> alecu: If we don't use it before the next release we should take it out again
[14:41] <nessita> dobey: I superseed it. Have a link?
[14:41] <nessita> alecu, thisfred: please don't remove any bubble logic yet
[14:41] <dobey> oh ok
[14:42] <alecu> nessita, supersemilla?
[14:42] <thisfred> nessita: we're not :)
[14:42] <nessita> dobey: I forgot to set a prerequisite...
[14:42] <nessita> :-)
[14:43] <dobey> thisfred: clint makes some good points, and a lot of egregious ones
[14:44] <thisfred> egregious?
[14:44] <thisfred> exceptionally bad?
[14:45] <alecu> e·gre·gious/iˈgrējəs/Adjective 1. Outstandingly bad; shocking. 2. Remarkably good.
[14:45] <alecu> dobey, 1 or 2?
[14:45] <dobey> not 2
[14:46] <alecu> dobey, what are the good points in clint's email?
[14:46] <thisfred> That's gonna be my new rap name. E.-Gregious
[14:46] <dobey> the party analagy is quite bad, because it just ignores lots of things about what u1 is/does
[14:46] <alecu> thisfred, that sounds like a greek rapper!
[14:47] <dobey> alecu: that would be sigma
[14:47] <thisfred> E-gregious στο σπίτι!
[14:49] <dobey> alecu: well the good points were that we are doing it wrong and annoyingly right now
[14:50] <alecu> dobey, ok. But do you think u1 should be doing any notification at all?
[14:51] <dobey> yes
[14:51] <alecu> dobey, which notifications?
[14:51] <ralsina> alecu: you said flash the taskbar in non-unity. If there's no window visible, how would we do that?
[14:52] <alecu> ralsina, there's a dialog shown when you ran out of space. That one!
[14:52] <ralsina> alecu: ok
[14:52] <ralsina> alecu: so the only missing part is what replaces the unity progressbar in non-unity
[14:52] <ralsina> And there we may need to do configurable bubbles
[14:53] <alecu> ralsina, I propose to expose that progress as dbus signals, and non-unity folks can do whatever they want with them.
[14:54] <ralsina> alecu: we would have to provide SOMETHING for the users. A tray icon app?
[14:54] <dobey> alecu: i'm not entirely sure exactly
[14:55] <nessita> alecu, thisfred, ralsina: bubble thread answered. Summary: I think bubbles are annoying for technical users, but needed (with much bigger delay than now) for non-technical sers
[14:55] <nessita> users*
[14:55] <ralsina> nessita: even in unity?
[14:56] <nessita> ralsina: we may turn them off in unity 3d, but surely we need a config setting to let users turn them on
[14:56] <nessita> and if we get tons of people asking how to turn it on, we turn it on by default
[14:56] <CardinalFang> ubuntuone-syncd, 95% CPU.  Hrm.
[14:56] <dobey> i don't think the answer to the frequency problems is more delay
[14:56] <thisfred> nessita: I disagree, I think between progress bars and messages we can solve all communication needs
[14:56] <ralsina> thisfred: there is no progress bar outside unity (or in unity right now, for that matter)
[14:57] <nessita> thisfred: that  is *if* we finally get the progress bar API, and *only* on unity 3d
[14:57] <dobey> thisfred: <design> "the messaging menu is for messages from people, not the system"
[14:57] <nessita> ralsina: and it will be only on unity 3d
[14:57] <dobey> and it will only be if you have a launcher for u1
[14:57] <thisfred> ralsina: right, so we may want to fall back to showing a bubble when everything is 100% done, or when it somehow failed
[14:57] <dobey> if you remove the launcher, you won't get a progress bar there
[14:57] <thisfred> although that merits a message I guess
[14:58] <ralsina> thisfred: imagine bubble at 100% done when you are coding inside Ubuntu One folder :-)
[14:58] <nessita> thisfred: nopes, messaging should not be notifications such as all compelted
[14:58] <nessita> or error ocurred
[14:58] <thisfred> dobey: sure, but presumably you don't really care in that case
[14:58] <alecu> thisfred, the problem with showing a message on 100% is when you have an app doing autosave every 5 minutes.
[14:58] <alecu> ralsina, exactly
[14:58] <ralsina> alecu: or running make that changes one file every 10 seconds?
[14:58] <dobey> thisfred: you probably do, but you don't open the control panel all the time, because it serves no common purpose for you
[14:58] <thisfred> ralsina: well that use case doesn't work very well anyway, as I understand it. You'll get a lot of conflicts
[14:59] <nessita> alecu: that particular user can disable bubbles, right? let's agree is not the common case for non tehcnical users
[14:59] <nessita> technical*
[14:59] <ralsina> thisfred: well, it would work bad *and* show bubbles all the time. Not fun.
[14:59] <thisfred> true :)
[14:59] <alecu> nessita, an app doing autosave every 5 minutes? that's the most common case with openoffice
[15:00] <nessita> alecu: but people is not using it inside U1, I mean
[15:00] <thisfred> but showing annoyingly many bubbles may discourage the non-working use case :D
[15:00] <alecu> nessita, and also that's the use case ivanka mentioned while using gedit on a folder on u1.
[15:00] <ralsina> nessita: yes, autosave is a very common use case here. People use U1 to share documents.
[15:00] <alecu> nessita, yes, they expect to use it inside u1.
[15:00] <dobey> mp3s aren't documents
[15:00] <dobey> :)
[15:01] <nessita> alecu, ralsina: well, in that case, our aggregator may use the threshold to show a sync 100% completed every 10 minutes (or a number we agree on)
[15:01] <thisfred> dobey: I edit my mp3 more often than my documents ;)
[15:01] <nessita> I don't think that is an argument to remove bubbles (we do need to tune when we're showing them)
[15:01] <ralsina> nessita: that is confusing. Some times the user gets told uploads are finished, sometimes he doesn't :-(
[15:01] <thisfred> And I am *so* the typical user
[15:01] <alecu> nessita, anyway: "notifications bubbles are used when somebody is talking to you"
[15:02] <nessita> alecu: I disagree with that
[15:02] <nessita> bubbles are bubbles, 'You have 10 new updates'
[15:02] <alecu> nessita, notification bubbles interrupt your work.
[15:02] <nessita> I agree messaging stuff should be from 'people'
[15:02] <ralsina> nessita: I think bubbles make more sense for downloads than for uploads
[15:02] <dobey> me changing the volume or brightness is not "someone talking to me"
[15:02] <ralsina> "You are getting 10 new files"
[15:02] <nessita> alecu: I agree, let's show them less frequantly
[15:02] <alecu> nessita, and yes: 'You have 10 new updates' happens only once per day.
[15:03] <nessita> alecu: once per boot
[15:03] <dobey> me pressing "next track" is not "someone talking to me"
[15:03] <ralsina> Uploads are user-initiated, so it makes less sense to bubble about them.
[15:03] <nessita> alecu: you get bubbles when changing the volume or brightness, like dobey said
[15:03] <ralsina> And the case of "the user needs to know if uploads are finished" should be handled differently, I think.
[15:03] <dobey> people posting on twitter are not people talking to *me*
[15:04] <ralsina> Because it's not really about notifications.
[15:04] <nessita> ralsina: maybe we should focus bubbles differently, like emphasizing syncs coming up from other devices. I still think that we should not get rid of them.
[15:04] <alecu> ralsina, "Uploads are user-initiated" -> not true when doing autosave.
[15:04] <thisfred> dobey: well I get bubbles from gwibber only when people do
[15:04] <thisfred> dobey: or libnotify just plain can't keep up
[15:04] <ralsina> alecu: well, they are! He just doesn't know it ;-) Ok, a grey area
[15:04] <dobey> thisfred: well maybe that was fixed, or you changed the setting from the default then
[15:05] <nessita> alecu, ralsina: I insist: bubbles are not user oriented. Messages are.
[15:05] <thisfred> dobey: Yeah I think I changed it.
[15:05] <ralsina> And remember, we should not notigy the user "things are ok" every X minutes, either.
[15:05] <ralsina> nessita: I am not sure I understand that.
[15:05] <thisfred> nessita: perhaps it's a good idea to notify (haha) design of this discussion, and get a reading from them?
[15:05] <dobey> "Oh your leg is off. It'll grow back in no time." "Thanks for the reassurance doc!"
[15:06] <nessita> ralsina: I mean notifications (bubbles) are not exclusive of 'people talking to you'. Messages from the messaging menu are.
[15:06] <ralsina> nessita: yes, agree on that.
[15:07] <ralsina> nessita: however, doing a bubble about what the user did himself makes no sense. That's why I don't like them for uploads.
[15:07] <nessita> thisfred: I agree. I also want 'regular' user input, such as cparrino, who happens to also be our product owner and because of that role he should be giving his opinion
[15:07] <dobey> ralsina: it depends
[15:07] <alecu> dobey, nessita: well, you have a point there. For updating the brightness or volume, notifications are used as a means to show "how much" the volume/brightness was changed.
[15:07] <alecu> for changing a track, to show what track was changed to.
[15:07] <ralsina> nessita: we have the problem of cparrino being unavailable for a bit
[15:07] <nessita> ralsina: I agree we should not notify about 'Upload started'. I think the user may wnat to know about 'Upload finished'. A lot of time can pass in between.
[15:08] <alecu> but I believe that automatic track change (when a track ends) should not pop up a notification.
[15:08] <alecu> that's just visual noise.
[15:08] <ralsina> nessita: why does the user needs to know uploads are finished?
[15:08] <alecu> and I believe the default on music players is not to show that.
[15:08] <dobey> it's not that bad
[15:08] <alecu> So let me rephrase it:
[15:08] <alecu> "automatic actions should not show bubbles"
[15:09] <alecu> only "somebody trying to talk to you."
[15:09] <dobey> i disagree
[15:09] <dobey> volume change is not "someoene trying to talk to you"
[15:10] <dobey> it is "confirmation that you pressed a button"
[15:10] <ralsina> dobey: is feedback on your action
[15:10] <nessita> ralsina: think like and end user. You have this important doc you need in your cloud, but is big. You add it to U1, the file will start uploading. so, the upload start will be (in the common case) pretty immediate. But you have no clue when it will be done, and you'd like to know that. Is very important for you. For the autosave case, I would recommend an aggregation: 'VeryImportantFile.txt was uploaded and 5 more'
[15:10] <ralsina> dobey: pressing the button doesn't tell you how the volume changed, thus you need feedback.
[15:10] <dobey> ralsina: so is "we uploaded this file you requested be uploaded"
[15:10] <dobey> ralsina: my speakers tell me how the volume changed
[15:10] <nessita> alecu: so, you would remove all the twitter bubbles? nobody is trying to talk to you
[15:11] <thisfred> ralsina: right, and I think this has sort of been shoe horned into a notifications because there is nothing else to do it, I don't think it's the best fit
[15:11] <ralsina> dobey: not really unless you listen to constant tones instead of music ;-)
[15:11] <dobey> ralsina: yes really.
[15:12] <nessita> ralsina: use that same argument for tons of files: you added for syncing tons of files, so adding them doesn' tell you how the synched chaned, thus you need feedback
[15:12] <dobey> i'm pretty sure i know what my ears tell me
[15:12] <ralsina> nessita: so, maybe a bubble shown every 10 minutes if any files have been uploaded. Optionally disabled. I can live with that.
[15:12] <thisfred> ralsina: the problem with that is, it has *no* relation anymore to when things actually happen
[15:12] <ralsina> dobey: suppose the song is on a quiet moment. Well, you have no feedback about volume. It doesn't work that way.
[15:12] <nessita> ralsina: what I'm pushing for right now is do not get rid of bubbles. Let's tune it.
[15:13] <thisfred> ralsina: for people using autosave, they will have an annoying pop-up *every* 10 minutes
[15:13] <nessita> thisfred: I don't understand that
[15:13] <dobey> ralsina: it's a song, so it's not going to stay silent long enough to hinder that
[15:13] <ralsina> thisfred: how about "when uploads are finished, if the last bubble was 10 minutes ago"
[15:13] <nessita> thisfred: why you think is annoying? I see it as comforting
[15:13] <dobey> ralsina: and users change volume by multiple steps, not one step at a time
[15:13] <ralsina> dobey: ok, for mumble, hen you are waiting for the call to start. Good enough?
[15:13] <nessita> thisfred: it generates a sensation of security to know that your important work is already in your cloud
[15:13] <thisfred> nessita: If it happens every ten minutes, people will just start ignoring the bubbles more
[15:14] <ralsina> nessita: that's the whole problem. annoying/comforting balance is hard.
[15:14] <nessita> let's discuss about that balance then :-)
[15:14] <thisfred> nessita: and they won't notice when they're not there, which is actually information that is a LOT more interesting
[15:14] <ralsina> nessita: the user should ASSUME it's uploaded.
[15:14] <nessita> removing them altogether is dropping comfort altogether
[15:14] <dobey> ralsina: mostly i never have a need to change the volume. and if i/when i do, it is not necessary to show me a progress bar of it
[15:14] <thisfred> nessita: not if we alert them when something goes wrong
[15:15] <thisfred> which we should anyway
[15:15] <ralsina> dobey: ok, may I mention that none of us is an average user? ;-) I have never seen anyone complain about the volume feedback...
[15:15] <thisfred> nessita: THAT is what users have been asking for, for a long time, even if they didn't phrase it exactly that way
[15:15] <nessita> thisfred: the absence of bubble would be ambiguous: is it that the upload haven't finished and I should wait for an error bubble or is it finished already?
[15:16] <nessita> thisfred: how can you tell if the error buble didn't show up because there was no error or the error didn't happen yet?
[15:16] <ralsina> nessita: and that's why it's a problem that we don't have any UI at all times :-(
[15:16] <thisfred> nessita: who cares whether the upload has finished, unless you're about to shutdown? And then we should just pop-up the dialog saying "sync still in progress"
[15:16] <dobey> ralsina: i'm not complaining about it. i'm making a point with it, and how it works, with regards to how we work
[15:17] <thisfred> nessita: the only reason people would care (and do care) is because it goes wrong every so often
[15:17] <ralsina> dobey: ok, for regular users the volume feedback is nice, they like it and see it as useful.
[15:17] <thisfred> nessita: and then they'd wanna be notified about that
[15:17] <alecu> thisfred, "because it goes wrong every so often". exactly.
[15:17] <thisfred> nessita: I never heard anyone asking for notification bubbles for dropbox
[15:17] <dobey> ralsina: i'm not sure that's verifiable
[15:17] <dobey> ralsina: i think "not complaining" and "like it" are wildly different things
[15:17] <ralsina> dobey: well, it's proven by the lack of cranky reports about it ;-)
[15:18] <ralsina> dobey: with enough users they are the same thing, I think.
[15:18] <ralsina> thisfred: dropbox has a tray icon
[15:18] <nessita> alecu, thisfred: have you read/seen how people loved rye's notification thingy?
[15:18] <ralsina> thisfred: so, if you want to know the status, you hover it and see.
[15:18] <alecu> ralsina, does the box rotate?
[15:18] <dobey> ralsina: i don't complain all the time about Yugos, but I don't like them either.
[15:18] <thisfred> ralsina: yeah, which would be awesome if we could
[15:19] <ralsina> dobey: I am sure you can find complaints about Yugos, whatever they are if you look for them. No such thing about volume feedback, AFAIK.
[15:19] <alecu> nessita, yes. People that were having issues with the service :-)
[15:19] <thisfred> ralsina: even better, the icon changes according to status
[15:19] <ralsina> thisfred: IF we provide dbus signals? I can do it in 5'
[15:19] <nessita> alecu, thisfred: about 'because it goes wrong every so often' -> let's make a pact that we can remove bubbles when the service is impecable
[15:19] <thisfred> ralsina: which we can do with the U1 launcher
[15:19] <ralsina> So we could show an optional "U1 notification icon" :-)
[15:19] <thisfred> ralsina: but not outside of unity
[15:19] <ralsina> thisfred: yes, I was thinking bout the not-unity case
[15:20] <nessita> right now, if the service is not impeccable, let's try to make the experience more pleasant
[15:20] <ralsina> So what do you guys think about an optional tray icon app?
[15:20] <thisfred> ralsina: yeah, we can do it technically, the issue is, we're not allowed an icon up there in ubuntu
[15:20] <nessita> ralsina: -10
[15:20] <ralsina> hahaha I expected that :-)
[15:20] <nessita> :-)
[15:20] <thisfred> ralsina: I would like it, but it's not going to happen
[15:20] <alecu> nessita, that's what we are aiming for. "make the experience more pleasant".
[15:20] <dobey> ralsina: just because i haven't been complaining about it, doesn't mean there isn't something to complain about. just ask Chipaca. he will tell you i am very good at complaining about things :)
[15:20] <nessita> ralsina: system tray icon will eventually dissapear
[15:20] <ralsina> But this is the textbook case FOR tray apps. Oh, well.
[15:21] <ralsina> dobey: duly noted ;-)
[15:21] <ralsina> Ok, so.
[15:21] <nessita> alecu: we agree on that, then. From my POV, removing the bubbles for natty is not helping in that direction. Sparsing them and fine tunning them, is needed, yes.
[15:21] <ralsina> Let me try to make sense of the discussion, wait 2' and then give me feedback.
[15:21] <thisfred> nessita: bubbles are not pleasant, especially if they tell you about stuff that the only response to is: "uh, ok, thanks"
[15:21] <nessita> ralsina: one tiny thing before that
[15:22] <ralsina> nessita: ure
[15:22] <ralsina> s/ure/sure
[15:22] <dobey> and my point was that trying to say that bubbles are only for "somebody talking to you" is grossly wrong
[15:22] <ralsina> dobey: ok, noted too.
[15:22] <nessita> do we have a setting to turn them on/off?
[15:22] <ralsina> nessita: we don't YET
[15:22] <thisfred> we will
[15:22] <dobey> i don't think we should
[15:22] <ralsina> I don't think we should, but I think we will.
[15:23] <thisfred> I think we should, and we will :)
[15:23] <nessita> ok, if we have that, we can have (MAYBE) it False by default. But let's no remove altogether the chance of having them
[15:23] <ralsina> Because we need user feedback, and the switch is useful for that.
[15:23] <dobey> adding settings to hide bugs is not the way to fix bugs
[15:23] <nessita> dobey: luckely this is not a bug ;-)
[15:23] <ralsina> dobey: this is not a bug, it's a dubious feature.
[15:23] <thisfred> dobey: we won't hide bubbles for when problems arise
[15:23] <dobey> having a setting won't give us user feedback
[15:23] <ralsina> the switch is for "normal operations" bubbles.
[15:23] <dobey> it is a bug
[15:24] <dobey> "the software works poorly"
[15:24] <ralsina> dobey: bug #? ;-)
[15:24] <dobey> sounds like a bug to me
[15:24] <nessita> ok, let's give ralsina time to summarize
[15:24] <nessita> (and also, I think we should have this disussion in the thread)
[15:24] <dobey> if there isn't a bug #, then why are we discussing it? there's no bug task to work on for progress tracking. :)
[15:24] <ralsina> On upload bubbles: I don't like them, nessita does. I think the imporant case is covered by the shutdown inhibition.
[15:25] <thisfred> +1
[15:25] <dobey> nessita: i don't think so. if we want user feedback we should have it somewhere that's not a private user list
[15:25] <ralsina> On download bubbles: I like them, but not so often.
[15:25] <dobey> nessita: perhaps on the u1-users list instaed of our private list
[15:25] <ralsina> dobey: shut up one minute please ;-)
[15:25]  * ralsina is trying to summarize
[15:25] <ralsina> On "problem" bubbles, we all like them.
[15:26] <ralsina> All that is only for non-unity cases
[15:26] <nessita> ralsina: non-unity-3d
[15:26] <ralsina> I think that's the only interesting stuff to discuss.
[15:26] <nessita> (is important)
[15:26] <ralsina> because I think on unity-3d (thx nessita) we have the important stuff covered better.
[15:26] <ralsina> Does that summary sound fair?
[15:27] <nessita> it does. You can extend:
[15:27] <nessita> On download bubbles: we like them, but not so often. (not sure how many we)
[15:28] <ralsina> nessita: yes, assume all bubbles except problem bubbles will be every X minutes with X>10
[15:29] <alecu> ralsina, what would be "problem bubbles"? out of space, disconnection... any other?
[15:29] <ralsina> alecu: you tell me :-)
[15:30] <dobey> out of space should so not be a bubble
[15:30] <nessita> ok. I know cristian is on QBR but I will run this by him, at least thru email. He is the product manager, so he has a big part in the decision of how we present/show the product, and how the product behaves
[15:30] <alecu> dobey, absolutely
[15:30] <ralsina> nessita: sure
[15:31] <alecu> nessita, right, but this is much more about User Experience than product.
[15:31] <alecu> nessita, I believe we should be running this thru u1 design and the Unity folks.
[15:32] <nessita> alecu: product involves user experience. +1 to add UX people
[15:34] <ralsina> On other topic: any of us knows about the notes server side?
[15:34] <ralsina> Because there are a ton of oopses
[15:34] <dobey> ralsina: rodrigo would
[15:34] <dobey> rye might know a little
[15:34] <ralsina> dobey: thx
[15:35] <nessita> ralsina: I emailed you about that... did you get my email from last Friday?
[15:35] <nessita> thisfred: kenvandine just told me that
[15:35] <nessita> (11:42:08 AM) kenvandine: nessita, i have to run to an appointment... the problem seems to be that messaging.py isn't included in the ubuntuone-client package
[15:35] <nessita> (11:42:11 AM) kenvandine: so it isn't installed
[15:35] <ralsina> nessita: yes I did, but it slipped my mind. My mind is getting slippery lately :-(
[15:36] <dobey> messaging.py?
[15:36] <nessita> ralsina: basicaly we are short of people to assign to work on that, which sucks
[15:36] <ralsina> nessita: figured as much
[15:36] <thisfred> nessita: doh! I'll add it on this branch
[15:36] <ralsina> nessita: so I'll just keep it in mind until we do :-(
[15:37]  * ralsina looks for the mind stapler so it doesn't slip again
[15:37] <nessita> ralsina: you may wanna beg for some time to rodrigo, maybe
[15:37] <thisfred> nessita: huh
[15:37] <nessita> ralsina: to seeif he can point us to the fix and that way avoid researching time
[15:37] <ralsina> nessita: ok, will pong him when he's around
[15:37] <thisfred> nessita: it adds the /status directory, I don't think the individual files have to be mentioned in the makefiel
[15:38] <thisfred> makefile
[15:38] <nessita> right, can you please ask kenvandine what he meant? I'll give you more context now
[15:38] <dobey> status/ is in the package
[15:38] <nessita> thisfred: so, we have this bug
[15:38] <thisfred> right
[15:38] <thisfred> and messaging is in status
[15:39] <rye> dobey, know what?
[15:39] <nessita> bug #711260
[15:39] <ubot4> Launchpad bug 711260 in ubuntuone-control-panel (Ubuntu) (and 1 other project) "the indicator messages entry should indicate that the service is running (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/711260
[15:39] <dobey> rye: about notes server side stuff
[15:39] <nessita> thisfred: and kenvandine was trying to work on solving it
[15:39] <rye> ralsina, notes! THey BUG!
[15:39] <ralsina> rye: yes, they do
[15:39] <nessita> thisfred: and then he said:
[15:39] <ralsina> It's a 503 so it's a not-logged in problem or similar, right?
[15:39] <nessita> (11:33:29 AM) kenvandine: nessita, i think i have it, testing then will propose a branch :)
[15:39] <nessita> (11:42:08 AM) kenvandine: nessita, i have to run to an appointment... the problem seems to be that messaging.py isn't included in the ubuntuone-client package
[15:39] <nessita> (11:42:11 AM) kenvandine: so it isn't installed
[15:40] <dobey> lies
[15:40] <thisfred> right. that's pretty strange though
[15:40] <nessita> thisfred: so, if you could ask him what is needed, we will be able to behave properly in the messaging menu
[15:40] <dobey> or he's got an old package installed
[15:40] <nessita> maybe
[15:40] <thisfred> I did not yet do anything to change the running status in the menu. I did not even know about it
[15:40] <nessita> dobey: can you ask him, when he comes back, please?
[15:40] <dobey> oh
[15:40] <thisfred> we'll do that
[15:40] <nessita> I need to run a quick errand
[15:41] <rye> ralsina, basically rodrigo has never got around creating recursive parser for incoming HTML that could create 100% replica of the layout leading to tomboy oopsing, however that's not the thing why /notes/ fail. And I was not able to reproduce "Unknown" exeption :-/
[15:41] <ralsina> rye: ok
[15:41] <dobey> uhm
[15:42] <ralsina> rye: so basically we can't do anything until rodrigo is available again?
[15:42] <dobey> there is no ubuntuone/status/messaging.py in trunk
[15:43] <dobey> oh it is in trunk now, but it wasn't yesterday
[15:45] <dobey> thisfred, nessitaway: so ken just doesn't have the new nightlies package it seems
[15:52] <thisfred> dobey: yeah probably, but in that case, why is it showing up in the menu at all? The messaging menu entry is more recent than me adding the status/ directory...
[15:52] <kenvandine> dobey, i have what is in natty
[15:53] <kenvandine> thisfred, it is showing up because the indicators file pointing to the desktop file is installed
[15:53] <kenvandine> i think you need to move the self.server.show() up to where the server is created though
[15:53] <thisfred> kenvandine: right, but that was added *after* we fixed the problem with the missing directory in the makefile
[15:53] <dobey> thisfred: the messaaging.py was only added in the last 24 hours though
[15:53] <thisfred> really?
[15:54] <thisfred> oh right, because the branch hadn't landed for all that time
[15:54] <thisfred> nm me
[15:54] <dobey> yes, i made a branch from trunk yesterday which didn't have it, and now it is in trunk
[15:55] <thisfred> kenvandine: that's quite possible. I moved stuff around a lot until it finally stopped not working. It's kind of programming in the dark ;)
[15:55] <dobey> kenvandine: so if you want to test nessita's thing, you'll need the u1-client packages from ppa:ubuntuone/nightlies i guess
[15:56] <thisfred> kenvandine: and that will show the '>
[15:56] <thisfred> '
[15:56] <thisfred> ?
[15:56] <thisfred> or we need to do something else at startup
[15:57] <thisfred> kenvandine: while I have your attention: one thing I really don't get is how the indicators find the right server. Is that by using the right subtype property?
[15:59] <kenvandine> thisfred, you need to ask tedg, he could explain it
[16:00] <thisfred> kenvandine: will do
[16:00] <kenvandine> it is like magic :)
[16:00] <thisfred> kenvandine: Yeah :)
[16:00] <kenvandine> there is some sort of registration, and it matches based on process, connection, etc
[16:00] <kenvandine> something like that
[16:00] <kenvandine> sometimes running from a source checkout won't match it for example
[16:01] <thisfred> right, I noticed some problems testing
[16:01] <thisfred> explicit > implicit :)
[16:02] <alecu> thisfred, ping
[16:02] <thisfred> alecu pong
[16:02] <alecu> thisfred, I'm reviewing the messaging branch, and I like it.
[16:03] <thisfred> and the bad news? :D
[16:03] <alecu> thisfred, one question though: is there some way to unittest the "Notification" class and the "Messaging" classes
[16:03] <alecu> ?
[16:03] <alecu> thisfred, for instance, by making a "fake_pynotify" or something like that.
[16:04] <alecu> and a fake_indicate...
[16:04] <thisfred> alecu:  right, I've thought about this, and I don't see easy way, that's still worth the effort. Our layer is so thin, that it's basically API translation. We do have fake implementations of both messaging and notification, so that higher level tests can use them.
[16:04] <thisfred> an easy way
[16:06] <thisfred> alecu: and I don't know if integration tests are possible, if the client tests have to be runnable from within the server code.
[16:06] <ralsina> Sprint change: it may be orlando because suddenly a lot of cheap US Airlines flights appeared.
[16:07] <alecu> thisfred, well, the thing is that we only end up testing the code paths in the code that uses those fake implementations of notifications and messaging
[16:07] <alecu> thisfred, but the code paths in Messaging and Notifications do not get run till runtime
[16:08] <alecu> thisfred, and a typo there will not show up till later... (insert ness-ita speech here)
[16:08] <thisfred> alecu: right, so maybe we should mock pynotify and indicate then
[16:08] <thisfred> I'll start a new branch for that, and I'll ask for help. I haven't done too much mock testing yet
[16:09] <alecu> thisfred, ok, cool. I'm approving this branch then.
[16:09] <thisfred> thx!
[16:09] <alecu> thisfred, and let me know if I can be of help on that... let me find some samples.
[16:10] <thisfred> that would be awesome. I'll look around, I know we use it in desktopcouch as well.
[16:11] <ralsina> dobey: you really need to update your data in directory.canonical.com
[16:12] <alecu> thisfred, I believe you will be able to do it with twisted.trial.unittest.TestCase.patch(), just like in tests/status/test_aggregator.py
[16:12] <thisfred> alecu: awesome thx!
[16:13] <alecu> thisfred, and from the test patching the "indicate" module with a fake instance
[16:13] <thisfred> cool
[16:13] <alecu> thisfred, so, for instance: "self.patch(messaging, "indicate", FakeIndicate())
[16:14] <dobey> ralsina: huh?
[16:14] <ralsina> dobey: it says you work in ops and report to philip
[16:15] <ralsina> dobey: it looks like it doesn't actually use the company's data at all, but is done manually.
[16:15] <dobey> yeah it's manual
[16:15] <pfibiger> ralsina: that was from the rotation, you probably still have rick.
[16:15] <pfibiger> they each did a six month swap
[16:16] <dobey> manual in the sense of how the Vogons operate
[16:16] <ralsina> pfibiger: yes I do :-)
[16:16] <dobey> ralsina: the whole online services team is out of whack in the directory :-/
[16:17] <ralsina> Acrtually our group is ok, except the name of the group is wrong :-)
[16:17] <ralsina> We are listed as "Desktop" which is of course a problem there being a whole other Desktop group
[16:18] <dobey> ralsina: well, it says you are Desktop
[16:18] <dobey> ralsina: it says the rest of us are Online Services - Desktop
[16:18] <ralsina> dobey: ok, I will fix me :-)
[16:22] <nessitaway> dobey: I don't think that ken uses nightlies, no
[16:22] <nessitaway> and I'm not sure if he should...
[16:22]  * nessitaway is back
[16:23]  * dobey thinks everyone at canonical should use nightlies
[16:23] <nessita> ralsina: orlando? noooooooooooooooooo! you break my heart :-P
[16:23] <dobey> yay!
[16:24] <ralsina> nessita: there is still the hotel costs...
[16:24] <ralsina> So this is not a final decision. Besides, this morning it was $1500 cheaper for Buenos Aires
[16:25] <ralsina> I am surprised it's cheaper to go to Orlando from Cordoba thanfrom Buenos Aires, though.
[16:25] <nessita> ralsina: using which airline?
[16:25] <dobey> ralsina: well the cost of my flight to orlando just went down :)
[16:25] <ralsina> nessita: using something and then TACA
[16:25] <nessita> ralsina: that is pretty bad
[16:25] <ralsina> dobey: the cost of LHR<->ORL went down $400 in 4 hours
[16:25] <nessita> and take into account that a few weeks ago the trip panama -> cordoba landed with emergency
[16:26] <nessita> nothing bad happened in the end, but there were a group firemen and all waiting for the landing
[16:26] <ralsina> And... this is not how the tickets are bought, so it's only a lead
[16:27] <dobey> nessita: when i went to dallas for UDS, we had to land in Waco for a bit to refuel, because of a "storm" around DFW
[16:27] <ralsina> nessita:  the TACA flight is no more. Now you get LAN for 1214 too.
[16:28] <ralsina> nessita: happier? ;-)
[16:28] <nessita> hehehe
[16:28] <ralsina> Actually LAN to miami, then united to Orlando
[16:28] <dobey> ralsina: no, but the prices are going to be the same, with the added fee of going through a travel agency
[16:28] <ralsina> via Chile
[16:29] <ralsina> dobey:  most of these prices are available for only two or three seats, and only for this week. Next week the numbers are going to be completely different again.
[16:29] <dobey> LAN isn't too bad. i had to fly on LAN from Santiago to BA
[16:29] <nessita> ralsina: lan states US$ 1.499 for that flight. Wierd.
[16:29] <ralsina> nessita: april 2, flight 951
[16:29] <ralsina> and then 5502
[16:29] <dobey> ralsina: as we get closer, prices will go down, until a point when they skyrocket, and then go way down again for last minute sales
[16:30] <dobey> flight prices literally follow a roller coaster graph line
[16:30] <ralsina> dobey: yes, but they don't go down at the same speed for all destinations, which makes it harder :-)
[16:30] <dobey> yeah
[16:30] <ralsina> nessita: copa is available for 1236
[16:30] <nessita> ralsina: don't worry. I will go wherever the sprint is :-). I know you know I prefer BA, so I'll know you made your best for the whole team
[16:31] <nessita> yes, copa was the one with the landing emergency ;-)
[16:31] <ralsina> nessita: I know I would like to take my kid to Disney, but I also know it's easier for me not to travel, so I am impartial ;-)
[16:31] <nessita> it shoudl be cheap for a couple of weeks
[16:32] <dobey> if only we could travel at light speed
[16:33] <ralsina> So, that's the current status. I will keep you posted as things develop.
[16:33] <dobey> ralsina: there's also the fact that everyone isn't going too book flights at the exact same time, so the prices are really only a guideline for genearating averages, when planning like this
[16:34] <ralsina> dobey: exactly
[16:34] <ralsina> It's mostly because I need to provide a rationale for choosing one place or the other, and this one is the easiest.
[16:34] <ralsina> If we hired a couple more people in Orlando or Buenos Aires, it would be much simpler.
[16:34] <karni> hi guys :)
[16:34] <ralsina> hi karni!
[16:35] <karni> I read we're having quite an interesting disccussion today ;)
[16:35] <karni> hello ralsina  :)
[16:35] <karni> It's about next sprint I presume?
[16:35] <ralsina> karni: right
[16:36] <ralsina> karni: basically, nobody wants to travel too far, and most of us will :-)
[16:36] <dobey> ralsina: i'm sure we can find someone in florida to hire
[16:36] <nessita> ralsina: we definitely need chicharra people around. That adds 4 more to BA :-D
[16:36] <karni> ralsina: I see
[16:36] <ralsina> nessita: tricky! I like i! ;-)
[16:36] <nessita> ralsina: seriously, do we need chicharra people around?
[16:37] <ralsina> nessita: probably going to bother them, but I am not sure about having them. They are not being considered AFAIK.
[16:38] <nessita> right. I know I could use some face to face interaction for this sharing stuff I'm dealing with, is not easy, I know I will have bugs. But yes, probably mumble and/or IRC will do the trick
[16:38] <ralsina> nessita: maybe you can come for a few days pre-sprint
[16:38] <ralsina> And we do a mini-sprint with them. Just thinking about it.
[16:39] <nessita> that can work, specially if my teaching class is Mon or Tue (I may travel to BA Wed and internationally in the weekend with you and alecu)
[16:40] <nessita> of course after that I may get the divorce requested to me, but that is another story (just kidding)
[16:40] <dobey> ok, must get food
[16:40] <ralsina> nessita: something like that. Bring you worse half and go to the teather or something :-)
[16:42]  * karni hops back on U1F work
[16:48]  * alecu will have something to eat
[16:50] <nessita> lunch time!
[17:17]  * nessita is back
[17:30] <dobey> so cold
[17:32] <karni> dobey: how cold is it?
[17:33] <dobey> 37F right now
[17:33] <ralsina> dobey: come on, that's above freezing point! ;-)
[17:33] <dobey> grr, i wish people would learn to use AC_ARG_{WITH,ENABLE} correctly
[17:34] <karni> dobey: ~3C. it's -4C here ^^
[17:34] <ralsina> Today it's an ideal 23C here :-)
[17:34] <karni> ralsina: good for you! :)
[17:34] <ralsina> Of course it will be 37C in two days ;-)
[17:35] <dobey> :(
[17:35]  * dobey wishes it was 30C here
[17:35] <karni> yeah, I also wish it was warmer here.
[17:35] <dobey> then i could fix my car AND drive it with the top out
[17:38] <ralsina> dobey: I sometimes wish I had a car. Then I remember I don't know how to drive.
[17:38] <dobey> heh
[17:39]  * karni chuckles
[17:39] <dobey> well having two fun/project cars and one daily driver, is nice
[17:39] <ralsina> I live in a city where driving is not all that practical.
[17:40] <ralsina> At least for me.
[17:40] <dobey> yeah, i've been in a car there
[17:40] <ralsina> My wife is probably going to need a car this year though.
[17:40] <dobey> crazy
[17:44] <nessita> thisfred: did you talk with kenvandine?
[17:44] <thisfred> nessita: yeah, a little: the branch that has all the messaging is not that old, so he did not have it yet
[17:53] <dobey> nessita: that's why i said he needs the nightlies
[17:53] <nessita> kenvandine: would upgrading to ubuntuone nightlies fix the issue you were having?
[17:54] <kenvandine> nessita, don't know, i assume it would work then
[17:54] <dobey> it has the messaging.py which is not in the 1.5.3 tarball, yes
[17:54] <kenvandine> dobey, think we can get a release uploaded with it?
[17:55] <nessita> kenvandine: not with the little time interval to update bubbles (users may feel flooded with notifications)
[17:55] <nessita> alecu: is the threshould and timeout already increased in nightlies?
[17:56] <dobey> kenvandine: well a2 freeze was last night, right?
[17:56] <kenvandine> soft freeze
[17:57] <alecu> nessita, no
[17:57] <kenvandine> it would be nice to get a fix like that in... but not if it will annoy users
[17:57] <dobey> i thought 1.5.3 had notifications already, but maybe not
[17:57] <ralsina> kenvandine: too risky, too. We could push it today or even tomorrow (it's a soft freeze after all) but...
[17:57] <dobey> kenvandine: i'd also like to get the branch i'm working on in first
[17:57] <ralsina> dobey: no it doesn't
[17:57] <alecu> ralsina, let's buy two cars, maybe we can get a better price
[17:58]  * alecu needs to learn to drive, too
[17:58] <nessita> alecu: can we set those values to a high value to consider making an official release?
[17:58] <ralsina> alecu: I don't think it works that way :-)
[17:58] <alecu> nessita, ack
[17:58] <kenvandine> lets just wait then
[17:58] <nessita> alecu: I was actually asking 'can' as in possibility :-D
[17:58] <nessita> not as a request
[17:59] <alecu> nessita, ack :-)
[17:59] <nessita> alecu: is that yes or no?
[17:59] <alecu> nessita, running the client tests spews a lot of ubuntuone.credentials debugging info.
[17:59] <nessita> yes
[17:59] <alecu> nessita, it's a "yes"! :-)
[17:59] <dobey> kenvandine: i'm adding a .vapi generation setup for libsyncdaemon :)
[17:59] <karni> dobey: what's that? .vapi
[18:00] <dobey> karni: for vala
[18:00] <nessita> kenvandine: so, if you need another release we should tune a few setting first. Let us know if you want us to do that :-)
[18:01] <karni> aha
[18:03] <dobey> doh. make
[18:04] <ralsina> dobey: you are adding that .vapi... couldn't you use the DBUS apis thisfred and chad were doing?
[18:04] <ralsina> Just curious here
[18:06] <dobey> ralsina: dbus apis for what?
[18:07] <ralsina> dobey: 3rd party APIs
[18:07] <ralsina> dobey: remember the big spreadsheet?
[18:08] <dobey> ralsina: we already have a GObject style library for using the syncdaemon from C/GTK+ apps. for things using vala that want to interact with syncdaemon, we should provide a .vapi
[18:08] <dobey> ralsina: similar to how we provide a .gir file for it, and mono bindings
[18:08] <ralsina> dobey: yes, but are we promising to keep that API stable?
[18:08] <ralsina> As I said, just curious.
[18:08] <dobey> well, as stable as the dbus API
[18:09] <ralsina> dobey: ok then good enough for me.
[18:09] <ralsina> my main concern was ending with yet another thing to maintain in the API front
[18:10] <ralsina> But if you say it's cool, it's cool
[18:12] <dobey> no, the .vapi will be generated automatically for the most part
[18:13] <ralsina> dobey: even better
[18:14] <ralsina> thisfred: do you need a review for https://code.launchpad.net/~thisfred/ubuntuone-client/science-fiction-double-feature/+merge/48169 ?
[18:15] <thisfred> ralsina: I do, though ideally by one of the chicharrachos
[18:15] <ralsina> thisfred: cool. Let me know if you can't get one of those :-)
[18:15] <thisfred> will do!
[18:44] <ralsina> My ubuntuone bubbles are stuck in 0 done (total 4) since yesterday.
[18:49] <nessita> ralsina: since yesterday what time?
[18:49] <ralsina> nessita: can't say I remember the time
[18:49] <nessita> we've been updating the databases for hours now, before you (maybe) woke up
[18:49] <ralsina> Oh, could be
[18:50] <nessita> ralsina: and eysteday the storage servers were really, really slow
[18:50] <nessita> yesterday*
[18:50] <ralsina> So, one more thing to think about for notifications. Should we pop the same status when it's just not moving? I don't know :-)
[18:51] <nessita> not very often, for sure
[18:51] <nessita> from time to time, I'd say yes. In cases like today, where the service is down for an usual amount of time, it may be relevant, IMHO
[18:52] <ralsina> nessita: yes, but that's not what the bubble says. It just says it's stuck. Maybe we should fetch a service status update somewhere?
[18:52] <ralsina> That way when the service is dead, we could do nothing.
[18:52] <nessita> ralsina: good idea, I don't see it very plausible for this cycle, though :-(
[18:52] <ralsina> And maybe even notify the user
[18:53] <nessita> at least in the clean way
[18:53] <ralsina> nessita: it should be pretty trivial to do, just fetch one URL
[18:53] <nessita> but if we're down, which URL would you fetch?
[18:53] <ralsina> Of course someone in ops would have to generate that URL
[18:53] <joshuahoover> nessita: ping
[18:53] <ralsina> nessita: not a URL from the service, an independent status URL
[18:53] <nessita> joshuahoover: pong
[18:53] <nessita> ralsina: ah, could be
[18:54] <joshuahoover> nessita: the user yesterday who signed up for u1 but didn't input the confirmation code the first time around wasn't prompted for a confirmation code when trying to login again via sso gui
[18:55] <nessita> joshuahoover: what version is he running? early versions in maverick don't do that
[18:55] <joshuahoover> the user is allowed to login but can't connect (i'm guessing auth failed, don't have logs)...he connects then gets disconnected almost immediately
[18:56] <nessita> joshuahoover: latest does (was added thru SRU)
[18:56] <joshuahoover> nessita: hmmm...i don't have that info...i'll suggest he updates
[18:56] <alecu> thisfred, btw: I would really like if the Notification object would keep the return value of send_notification and use it for update_notification
[18:56] <nessita> joshuahoover: well, right now the service is down so no one is connecting, but you know that, so I guess this is from where the service was alive?
[18:56] <joshuahoover> nessita: right
[18:56] <nessita> joshuahoover: please suggest an update and sso logs, I can help you more with that
[18:56] <nessita> logs are locates at:
[18:56] <nessita> located:
[18:57] <nessita> ~/cache/sso
[18:57] <joshuahoover> nessita: ok, thanks!
[18:57] <nessita> prego!
[18:57] <thisfred> alecu: sure, I thought about that, it would be more consistent with the way the messaging works
[18:57] <thisfred> alecu: I'll change that on my mocking branch, after I have working tests, so that I can do it TDD, and test the tests :)
[18:58] <alecu> cool
[19:04] <ralsina> nessita: it turns out there is a planned status URL feature, it's blocked on losa availability. I think this would be a great small feature to add.
[19:05] <nessita> indeed
[19:05] <nessita> do we have a bug # for that?
[19:05] <ralsina> I don't think so
[19:05] <ralsina> But let's check!
[19:05] <nessita> file it if not! :-)
[19:39] <dobey> almost got it...
[20:02] <dobey> rock.
[20:12] <nessita> dobey: ping
[20:16] <nessita> dobey: u1trial is not working properly in syncdaemon tests. Seems like, somehow, the session bus is being used instead of the test bus. You can see this by yourself by modifying tests/syncdaemon/tets_dbus.py:test_get_shares and add a d.addCallback(check) right before the 'return d' sentence, and then run:  PYTHONPATH=. u1trial -t test_get_shares$ tests/platform/linux/test_dbus.py
[20:16] <nessita> You will see how it fails saying that the number of shares is not 1, like it's supposed to be since the test adds only one share (instead it will take into account all your real shares)
[20:17] <nessita> dobey: please let me know when you see this, is blocking me in a considerably way. I've been debugging a test for an hour now :-/ (it turned out that the real SD was being used)
[20:20] <dobey> oh crap
[20:20] <dobey> ok, will fix quickly
[20:20] <dobey> nessita: is there a bug # for it?
[20:20] <nessita> dobey: thanks. Did you manage to reproduce?
[20:20]  * nessita fills the bug
[20:21] <dobey> nessita: no, but i'm pretty sure i know what the issue is
[20:21] <nessita> ok, the steps I listed should enable you to reproduce
[20:23] <nessita> dobey: bug #711470
[20:23] <ubot4> Launchpad bug 711470 in ubuntuone-client "u1trial is (somehow) using the real SD DBus service (affects: 1) (heat: 6)" [Critical,New] https://launchpad.net/bugs/711470
[20:36] <dobey> nessita: https://code.launchpad.net/~dobey/ubuntuone-client/fix-dbus-testing/+merge/48239
[20:36]  * nessita reviews
[20:38] <karni> EOD for me. I should be still around for a while if anybody needs me.
[20:40] <karni> beuno: last hardcore chunk of syncdaemon left. I'm so looking forward to have it working.
[20:41] <karni> beuno: I've sent an update from today.
[20:41] <beuno> karni, wooooooooooooooooooooooooooooooooooooooo
[20:41] <beuno> I saw
[20:41] <beuno> great progress!
[20:41] <karni> Thank you :)
[20:41] <karni> beuno: I should be having more and more time in following days for U1F
[20:42] <karni> Okay. I'll be updating you guys! I'm still around for a bit.
[20:52] <nessita> dobey: does DBusTestCase.setUp return a deferred?
[20:52] <nessita> if so, you need to yield on it
[20:55] <ralsina> EOD for me
[20:55] <ralsina> have a nice evening everyone!
[20:55] <dobey> nessita: no, but tearDown does
[20:55] <nessita> ack
[21:23] <nessita> dobey: I'm getting http://pastebin.ubuntu.com/561143/ with your branch
[21:24] <dobey> huh
[21:25] <nessita> dobey: I guess you need to remove     155         d = self.cleanup_signal_receivers(self.signal_receivers)          from the tearDown in test_dbus.py
[21:25] <dobey> nessita: i wonder if that is related to bug 689677
[21:25] <ubot4> Launchpad bug 689677 in ubuntuone-client "DBusException when running tests (affects: 1) (heat: 15)" [High,Confirmed] https://launchpad.net/bugs/689677
[21:26] <dobey> oh, maybe
[21:26] <nessita> self.cleanup_signal_receivers is being called twice
[21:26] <nessita> can be related, hopefully we fix 2 things
[21:27] <dobey> hrmm
[21:28] <nessita> also,
[21:28] <nessita>      165         self.bus.flush()
[21:28] <nessita>     166         self.bus.close()
[21:28] <nessita> is called twice
[21:28] <nessita> (in DBusTwistedTestCase and DBusTestCase)
[21:31] <dobey> yeah but that might be ok
[21:31] <dobey> am testing a fix
[21:33] <dobey> crap, my machine was a gig into swap :(
[21:34] <dobey> i really need to get this company to approve my rma and send me a new stick of ram
[21:40] <dobey> firefox was using almost 700M, and so was a runaway u1trial running under tarmac :(
[21:41] <thisfred> dobey: is that the reason tarmac is failing on my branch?
[21:42] <thisfred> or the result of it?
[21:42] <dobey> thisfred: please don't set it to approved until my fix is
[21:42] <thisfred> dobey: ok, I won't
[21:42] <dobey> thisfred: probably, because i killed u1trial
[21:42] <thisfred> dobey: I noticed the u1-client tests starting to take a loooooong time recently, and I don't think it's my branch
[21:43] <thisfred> locally on my supercomputer that is
[21:44] <nessita> thisfred: recently as in hours, days or weeks?
[21:45] <dobey> thisfred: just slow, or insane RAM usage?
[21:45] <dobey> afaik, they've been hella slow forever
[21:46] <thisfred> nessita:  dobey, oh ok, maybe it was just the first time I was waiting for them, rather than having them run in the background while doing something else
[21:46] <thisfred> dobey: I noticed no exceptional RAM usage, but then I have 8GB
[21:47] <nessita> right
[21:47] <nessita> I've noticed the slowness from the u1devtools migration
[21:47] <dobey> nessita: where exactly did you see the error in the pastebin?
[21:47] <dobey> nessita: did it cause a failed test?
[21:48] <nessita> running a particular test that I'm adding. No, the test finish but tearDown won't complete
[21:48] <nessita> dobey: I have a print right before my tests ends
[21:48] <dobey> nessita: does it happen with other tests?
[21:48] <nessita> it should, let me try
[21:49] <nessita> yes, any test that connects to a dbus signal, such as:
[21:49] <nessita> PYTHONPATH=. u1trial -t tests.platform.linux.test_dbus.ShareTests.test_delete_share$ tests/platform/linux/test_dbus.py
[21:49] <dobey> ie the test_shreas in teh bug
[21:49] <nessita> no, test_get_shares will not fail, since is not connecting to any signal
[21:49] <dobey> shares
[21:49] <dobey> oh ok
[21:50] <thisfred> dobey: could you ping me when it's ok to approve the branch again?
[21:50] <dobey> nessita: ok, i'm not seeing it with my fix then
[21:50] <dobey> i'll commit/push
[21:50] <nessita> let's see
[21:51] <nessita> dobey: did you get the failure without your last fix?
[21:52] <dobey> i didn't run the tests to see it, but i see in the code why it happened
[21:53] <dobey> i really wish we had more time to spend on cleaning up our test suites
[21:53] <nessita> is it pushed?
[21:53] <dobey> yes, r830
[21:55] <nessita> dobey: you added a ;
[21:55] <nessita> -.-
[21:56] <dobey> eh?
[21:56] <nessita> dobey: you, added, a, ';'
[21:56] <dobey> haha
[21:56] <dobey> sorry, have been poking vala most of the day :P
[21:57] <dobey> removed it
[21:59] <nessita> :-)
[22:01] <nessita> dobey: running tests now
[22:16] <nessita> dobey: approved
[22:17] <nessita> I'm gone now
[22:17] <nessita> bye all!
[22:31] <dobey> later all
[22:41] <thisfred> hasta luego todos
[22:48] <jderose> aquarius: what package do i need to install to get `from gi.repository import WebKit` to work?  is that not packaged yet?  running natty, btw.  and found your questions here - http://rottyforge.yi.org/irclogs/gnome/%23python/2010-10-21/
[22:48] <aquarius> jderose, it'll be gir(something)-webkit(something)
[22:48] <aquarius> sudo apt-get install gir*-webkit* should do it :)
[22:49] <jderose> aquarius: ah, got it  thanks!
[22:50] <aquarius> jderose, we're in a weird interregnum right now, where the GI stuff isn't quite finished yet, but the static bindings ("import webkit") are Not The Way You're Meant To Do It any more
[22:51] <jderose> aquarius: plus the static bindings "aren't able to do the useful things you want" :)
[22:51] <aquarius> soon, the GI stuff will completely work. But it's really bleeding edge; in natty, it should all be OK, but in maverick some of it doesn't exist. I was told to not use GI in maverick.
[22:51] <aquarius> this makes your life quite shit, I admit :)
[22:51] <aquarius> what are you up to with header stuff in webkit? Is this talking to DC?
[22:52] <jderose> aquarius: aside from gi, is there anyway around the immutable SoupMessageHeaders problem?
[22:52] <jderose> aquarius: i *only* talk to DC!  :P
[22:52] <aquarius> not as far as I'm aware; the static bindings just don't cope with it
[22:52] <aquarius> and the static bindings aren't being improved because GI is the new black
[22:52] <jderose> hehe
[22:52] <aquarius> so you get to be all GI all the time if you want new stuff.
[22:53] <jderose> well, i'm more concerned with "working" than working on maverick, so supporting just natty+ is fine
[22:53] <aquarius> being in the interregnum is not helping, I know. You have my apologies, not that I have any influence over this stuff :)
[22:54] <jderose> aquarius: i wont hold you personally responsible :) thanks for the tips
[22:54] <aquarius> jderose, no problem, pal :)
[22:54] <jderose> aquarius: jeff and i miss drinking beer with you  :(
[22:55] <aquarius> jderose, well, if you're ever in the UK I'm happy to nominate a pub; I do occasionally drop by the US (where are you guys?)
[22:56] <jderose> in colorado... were you at the texas sprint?
[22:57] <aquarius> no. I don't go to platform rallies, because I don't spend enough time working on the platform; most of what I do is tied up with future Ubuntu One stuff
[22:58]  * aquarius looks at a map to find out where Colorado is
[22:58] <aquarius> hm. Not all that close to San Francisco, which is where I normally end up when I'm in the US
[22:59] <aquarius> 1,200 miles. Ouch. I forget about distances in the States when I'm not there.
[23:00] <aquarius> Truly it is said that we have history and you have geography.
[23:06] <jderose> hehe
[23:06] <jderose> aquarius: well, when you're going out to sf next, let us know... we go there occasionally.  that's where jeff was living before novacut madness started
[23:07] <aquarius> jderose, I might be there in August
[23:07] <jderose> cool
[23:07] <jderose> aquarius: will you be at UDS-O?
[23:08] <aquarius> I almost certainly will, yes
[23:08] <aquarius> so some opportunity for discussion and a pint may happen there :)
[23:09] <jderose> aquarius: sweet. okay, tech question: is there a place where i can see the exact request headers CouchDB is getting, like in a dc log file or something?
[23:11] <aquarius> ya. You need to turn on couchdb debug mode in ~/Applications/Settings/desktop-couch/couchdb.ini
[23:11] <aquarius> (that is, under [log], set level=debug)
[23:11] <aquarius> er, in .config/desktop-couch/couchdb.ini, sorry -- I've got friendlier config folders on my machine :)
[23:12] <jderose> ah, gotcha... i was scratching my head there
[23:13] <jderose> aquarius: and then restart dc i take it?
[23:13] <aquarius> then in ~/Applications/Cache/desktop-couch you have all the logs you could ever dream of.
[23:13] <aquarius> er, ~/.cache/desktop-couch. Sorry.
[23:13] <jderose> heeh
[23:13] <aquarius> ya, you'll want to killall beam.smp (or killall beam if you're not on a multicore machine) and then re-connect to DC to make it start up again
[23:14] <aquarius> must remember to translate my sensible folders into Ubuntu's default crappy .whatever folders :-)
[23:15] <jderose> i re-iterate my request for a simple way to start/stop/restart dc :)
[23:15] <aquarius> killall beam.smp is a pretty simple way to stop it :)
[23:17] <aquarius> the problem there is that there's 30 years of experience in stopping and starting system-level services (sudo service stop apache, and so on). There's almost no experience in starting and stopping services run for a user, because the very concept of such a thig is new-ish
[23:18] <jderose> true, but it would still be nice
[23:19] <aquarius> I agree entirely, but since no such thing exists, that leaves us with: (1) invent a DC-specific thing, (2) push for a general thing and then tie into it.
[23:20] <jderose> aquarius: so there isn't an existing mechanism to shutdown a dbus service?
[23:20] <aquarius> (1) basically *is* "killall beam/smp" (and I hope you're not running rabbitmq as your user); (2) means waiting for ages whiel it exists. I'd like to talk to keybuk about upstart and user-level services.
[23:20] <aquarius> the d-bus service isn't the problem; we can kill the d-bus service, but that won't kill and restart the couchdb service itself.
[23:21] <jderose> ah, gotcha... didn't realize that
[23:22] <aquarius> yeah; they're not the same thing. the d-bus service is desktopcouch. DC starts up couchdb with specific parameters and mediates access to it; killing the DC D-Bus service will not stop the underlying couchdb process.
[23:27] <aquarius> right, time for bed, I feel.