#instantbird log on 07 22 2016

All times are UTC.

01:40:30 <-- DGMurdockIII has quit (Quit: Leaving)
02:16:23 <instant-buildbot> build #3241 of macosx-nightly-default is complete: Failure [4failed compile]  Build details are at http://buildbot.instantbird.org/builders/macosx-nightly-default/builds/3241
02:37:34 <-- bgmCoder has quit (Connection closed)
04:21:44 <instant-buildbot> build #768 of linux64-nightly-default is complete: Failure [4failed shell_6]  Build details are at http://buildbot.instantbird.org/builders/linux64-nightly-default/builds/768
04:44:43 --> Bollebib has joined #instantbird
05:13:39 <-- EionRobb has quit (Quit: Leaving.)
05:28:28 --> bogdan_maris has joined #instantbird
05:44:37 <-- Bollebib has quit (Connection closed)
05:47:00 --> chrisccoulson has joined #instantbird
06:09:52 --> EionRobb has joined #instantbird
07:28:11 --> nhnt11 has joined #instantbird
07:28:11 * ChanServ sets mode +h nhnt11 
08:12:22 --> gerard-majax has joined #instantbird
08:12:59 <-- nhnt11 has quit (Ping timeout: 121 seconds)
08:37:20 --> aleth has joined #instantbird
08:37:20 * ChanServ sets mode +o aleth 
08:37:54 <-- gerard-majax has quit (Ping timeout: 121 seconds)
08:39:22 --> gerard-majax has joined #instantbird
08:45:31 <-- gerard-majax has quit (Ping timeout: 121 seconds)
08:48:27 --> gerard-majax has joined #instantbird
09:10:23 <-- gerard-majax has quit (Ping timeout: 121 seconds)
09:15:45 --> abdelrhman has joined #instantbird
09:26:00 <-- EionRobb has quit (Connection closed)
09:26:45 --> EionRobb has joined #instantbird
09:45:01 --> gerard-majax has joined #instantbird
10:00:42 <-- abdelrhman has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com)
10:10:20 --> BWMerlin has joined #instantbird
10:31:28 --> flo-retina has joined #instantbird
10:31:28 * ChanServ sets mode +qo flo-retina flo-retina 
10:50:18 --> abdelrhman has joined #instantbird
10:51:33 <-- gerard-majax has quit (Ping timeout: 121 seconds)
10:51:35 <abdelrhman> aleth: another test with different client (http://pastebin.instantbird.com/3244760)
10:53:20 <abdelrhman> This seems reasonable.
10:53:24 --> gerard-majax has joined #instantbird
10:53:29 <aleth> abdelrhman: Yes. The best thing to do is probably to go through https://github.com/xsf/registrar/blob/master/disco-features.xml (which is ordered by XEP) and add the ones from there IB supports.
10:54:16 <aleth> That's the official register
10:55:45 <abdelrhman> OK
10:56:05 <-- abdelrhman has quit (Connection closed)
10:56:59 --> abdelrhman has joined #instantbird
11:10:43 <-- abdelrhman has quit (Connection closed)
11:10:44 --> abdelrhman has joined #instantbird
11:17:43 <-- Tonnes has quit (Connection closed)
11:18:56 --> Bollebib has joined #instantbird
11:20:34 <-- BWMerlin has quit (Ping timeout: 121 seconds)
11:38:53 <-- abdelrhman has quit (Ping timeout: 121 seconds)
11:41:41 --> abdelrhman has joined #instantbird
11:47:45 <-- abdelrhman has quit (Ping timeout: 121 seconds)
11:50:16 --> abdelrhman has joined #instantbird
11:53:14 <abdelrhman> aleth: Should we include section "old-style jabber: namespaces"?
11:53:37 <abdelrhman> Line 587
11:54:08 <aleth> yes, where it makes sense
11:54:43 <aleth> note some of the vars in that file don't make sense for clients, they are for muc rooms, servers etc
11:58:38 <abdelrhman> Yeah, I see
12:10:15 <-- abdelrhman has quit (Ping timeout: 121 seconds)
12:10:51 --> abdelrhman has joined #instantbird
12:23:18 <-- flo-retina has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com)
12:29:17 --> clokep_work has joined #instantbird
12:29:17 * ChanServ sets mode +o clokep_work 
13:09:27 <-- abdelrhman has quit (Connection closed)
13:11:09 --> abdelrhman has joined #instantbird
14:05:00 --> flo-retina has joined #instantbird
14:05:00 * ChanServ sets mode +qo flo-retina flo-retina 
14:45:47 <-- bogdan_maris has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com)
15:55:58 <-- gerard-majax has quit (Ping timeout: 121 seconds)
15:56:11 --> arlolra has joined #instantbird
16:08:45 <-- abdelrhman has quit (Connection closed)
16:08:57 --> abdelrhman has joined #instantbird
16:15:13 <-- abdelrhman has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com)
16:17:18 --> abdelrhman has joined #instantbird
16:20:26 <instantbot> ab@abahmed.com changed the Resolution on bug 1142142 from --- to FIXED.
16:20:27 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1142142 nor, --, Instantbird 50, ab, RESO FIXED, Implement service discovery (XEP-0030)
16:22:56 --> gerard-majax has joined #instantbird
16:41:45 <clokep_work> So...what's that do for us? ;)
16:48:25 <flo-retina> clokep_work: I haven't looked, but I would guess it's a large step toward being able to discover MUCs for the awesometab
16:48:28 <abdelrhman> Responds to service discovery queries from other users
16:48:42 <clokep_work> abdelrhman: Yes, but what does 'service' mean in there?
16:49:07 <abdelrhman> Features that we support in the client
16:49:28 <flo-retina> hmm, isn't that feature discovery?
16:49:40 * flo-retina hasn't read XMPP XEPs recently enough apparently :-/
16:50:19 <abdelrhman> Yes
16:50:36 <-- gerard-majax has quit (Ping timeout: 121 seconds)
16:55:04 --> gerard-majax has joined #instantbird
16:58:55 <clokep_work> abdelrhman: I'm asking for examples.
16:58:57 <clokep_work> Sorry I'm not being clear.
17:00:58 <abdelrhman> This (http://pastebin.instantbird.com/3244760) is a real example from another client. It shows what the features that client implement or support (e.g. MUC)
17:01:58 <clokep_work> So what can of features will this help us implement in IB?
17:02:24 <abdelrhman> http://xmpp.org/extensions/xep-0045.html#disco-client
17:07:22 <abdelrhman> An entity might want to discover if one of the entity’s contacts supports the Multi-User Chat protocol (e.g., before attempting to invite the contact to a room).
17:08:07 <abdelrhman> clokep_work: I hope your question is answered as it's not clear to me
17:08:18 <freaktechnik> so it mostly improves the experience for others that have you as XMPP contact
17:09:15 <clokep_work> abdelrhman: I don't understand what supporting that part of the spec gets us.
17:14:40 <abdelrhman> a client may try to discover a feature to make sure the other clients support it before attempting to use it. (e.g. attention, version command), so if we do not respond to their queries of the features that we support, the sender will assume that we do not implement it
17:17:03 <flo-retina> eg. OTR ? ;)
17:18:37 <-- gerard-majax has quit (Ping timeout: 121 seconds)
17:23:16 <abdelrhman> Not sure if it has a namespace, but if it has, the answer is yes
17:23:18 --> gerard-majax has joined #instantbird
17:28:22 <aleth> flo-retina: Discovering XMPP MUCs in the awesometab already landed
17:31:54 <-- abdelrhman has quit (Connection closed)
17:32:34 --> abdelrhman has joined #instantbird
17:40:03 <-- gerard-majax has quit (Ping timeout: 121 seconds)
18:03:35 <clokep_work> aleth, abdelrhman: I got that hang again when I opened the awesometab. ;)
18:28:48 <-- abdelrhman has quit (Ping timeout: 121 seconds)
18:31:57 --> abdelrhman has joined #instantbird
18:38:22 <-- abdelrhman has quit (Ping timeout: 121 seconds)
18:46:55 --> abdelrhman has joined #instantbird
18:48:43 --> Tonnes has joined #instantbird
18:51:50 --> gerard-majax has joined #instantbird
18:59:34 <-- gerard-majax has quit (Ping timeout: 121 seconds)
19:22:04 <-- aleth has quit (Quit: Instantbird 50)
19:47:14 --> mib_e7i20o has joined #instantbird
19:50:18 <-- mib_e7i20o has left #instantbird ()
19:55:21 <arlolra> hmm, one of my autojoins requires me to identified before joining the channel.  shouldn't it wait for the response from nickserv before trying to join
19:57:12 <clokep_work> I'm guessing the server doesn't support SASL?
19:57:31 <clokep_work> We could possibly do that, but I don't think the protocol processes autojoins itself, could be tough to do.
20:08:37 <-- Suiseiseki has quit (Ping timeout: 121 seconds)
20:12:20 --> Suiseiseki has joined #instantbird
20:28:45 <-- clokep_work has quit (Ping timeout: 121 seconds)
20:41:11 <arlolra> the server is oftc
20:55:26 --> clokep_work has joined #instantbird
20:55:26 * ChanServ sets mode +o clokep_work 
20:59:28 <-- clokep_work has quit (Ping timeout: 121 seconds)
21:31:20 --> unghost has joined #instantbird
21:41:35 --> clokep_work has joined #instantbird
21:41:35 * ChanServ sets mode +o clokep_work 
21:45:20 <clokep_work> arlolra: Yeah we could probably fix that.
21:45:23 <clokep_work> They don't support SASL btw.
21:47:24 <arlolra> if you have some ideas on what a fix would look like, let me know.  not a rush but i'll eventually want to scratch my own itch
21:50:12 <clokep_work> So I think what you want to do is add some state to the IRC connection that's "done authenticating" it would be false until we've either successfully authenticated OR finished trying all the possible ways to authenticate. Once we've finished we can then join rooms, etc.
21:50:20 <clokep_work> You'd probably need to queue room joins, etc. until after all that though.
21:50:34 <clokep_work> Since I think thats all async from different notifications.
21:50:36 <clokep_work> Which is annoying. :)
21:51:08 <arlolra> ok, thanks
21:51:19 <arlolra> i'll take a crack at it at some point
21:52:09 <clokep_work> Something like that at least. I think we filed a bug on this a while ago?
21:53:51 <clokep_work> arlolra: So the "retweets are already displayed" patch...are they already displayed because we get them back over the API anyway?
21:54:04 <clokep_work> I guess I'm not 100% sure what the "already" in that sentence means.
21:54:26 <clokep_work> Does it mean "they're displayed because it was someone else's tweet you retweeted" or "they're displayed via some other mechanism, so no reason to do it manually"?
21:54:30 <arlolra> if you're retweeting something, it's already in your timeline
21:54:59 <clokep_work> Right so we don't really care about the success condition of the API call because we get it over our API call for the timeline anyway?
21:55:41 <arlolra> it ends up being a no-op though.  it gets to displayTweet and says hey, that's already in my timeline
21:55:47 <arlolra> end of story
21:56:22 <arlolra> oh, you're agreeing with me
21:56:22 <arlolra> yes
21:56:31 <arlolra> sorry, i read your response wrong
21:57:22 <clokep_work> :) Yeah I was pretty sure we were saying the same thing. :)
21:58:07 <clokep_work> arlolra: OK, so the uninitialized conversation...when can that happen? Is that like if you close the conversation tab during an API call?
22:02:08 <arlolra> yeah, exactly.  in the otr extension we listen for a conversation close to send out a message saying to end the otr session.  since the response from the server is async, the conversation has already been uninit by the time it comes back and then poof
22:02:37 <arlolra> but it's a general problem that the otr extension just exposes
22:24:22 <-- chrisccoulson has quit (Ping timeout: 121 seconds)
22:32:10 <-- clokep_work has quit (Ping timeout: 121 seconds)
22:32:41 <-- abdelrhman has quit (Connection closed)
22:46:21 <-- Bollebib has quit (Ping timeout: 121 seconds)
22:53:57 <-- arlolra has quit (Client exited)
23:57:32 <-- unghost has quit (A TLS packet with unexpected length was received.)