#instantbird log on 07 21 2014

All times are UTC.

00:04:07 --> mconley has joined #instantbird
00:10:16 <AlexanderSalas> https://testconnectivity.microsoft.com/	
00:10:17 <AlexanderSalas> Microsoft Lync Tests
00:10:17 <AlexanderSalas> - Lync Server Remote Connectivity Test
00:10:17 <AlexanderSalas> - Lync Autodiscover Web Service Remote Connectivity Test
00:10:17 <AlexanderSalas> Microsoft Office Communications Server Tests
00:10:17 <AlexanderSalas> - Office Communications Server Remote Connectivity Test 
00:46:51 <-- mconley has quit (Input/output error)
00:47:18 --> mconley has joined #instantbird
00:49:12 <-- mconley has quit (Ping timeout)
00:54:06 --> mconley has joined #instantbird
00:55:18 <-- mconley has quit (Input/output error)
01:06:23 <-- mpmc has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com)
01:17:54 <clokep> AlexanderSalas: What's your point?
01:52:18 <-- GeekShadow has quit (Ping timeout)
01:52:35 --> GeekShadow has joined #instantbird
01:58:11 <-- clokep has quit (Ping timeout)
02:01:48 <AlexanderSalas> clokep: I want to make the prpl for Lync easy to config
02:02:06 <AlexanderSalas> And for detect issues
02:02:17 <AlexanderSalas> http://technet.microsoft.com/en-us/library/hh690030%28v=ocs.14%29.aspx
02:02:47 <AlexanderSalas> Where is the bug about the prpl for  Microsoft Communicator?
02:17:59 --> mconley has joined #instantbird
02:21:13 <-- Hadi1 has quit (Ping timeout)
02:43:39 <instant-buildbot> build #2278 of macosx-nightly-default is complete: Failure [4failed hg_1]  Build details are at http://buildbot.instantbird.org/builders/macosx-nightly-default/builds/2278
02:56:54 --> CAKCy has joined #instantbird
03:26:31 <-- mconley has quit (Input/output error)
03:26:59 --> mconley has joined #instantbird
03:28:51 <-- mconley has quit (Ping timeout)
03:29:37 <-- Rym has quit (Ping timeout)
04:02:37 <-- AlexanderSalas has quit (Ping timeout)
04:02:55 --> AlexanderSalas has joined #instantbird
04:06:20 <-- EionRobb has quit (Ping timeout)
04:07:16 <instant-buildbot> build #1454 of win32-nightly-default is complete: Success [3build successful]  Build details are at http://buildbot.instantbird.org/builders/win32-nightly-default/builds/1454
04:07:19 --> EionRobb has joined #instantbird
04:08:37 <-- AlexanderSalas has quit (Ping timeout)
04:10:42 --> AlexanderSalas has joined #instantbird
04:25:12 <-- AlexanderSalas has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com)
05:13:59 <-- EionRobb has quit (Quit: Leaving.)
06:10:17 --> mpmc has joined #instantbird
07:16:05 --> EionRobb has joined #instantbird
07:53:16 --> Armada has joined #instantbird
07:59:10 --> gerard-majax_ has joined #instantbird
09:04:23 --> Bollebib has joined #instantbird
09:46:41 --> chrisccoulson has joined #instantbird
10:00:12 --> flo-retina has joined #instantbird
10:00:12 * ChanServ sets mode +qo flo-retina flo-retina 
10:01:21 <flo-retina> http://buildbot.instantbird.org/builders/macosx-nightly-default/builds/2278/steps/hg_1/logs/stdio is really annoying :(
10:01:41 <flo-retina> why does buildbot think it could be a good idea to rm -rf the mozilla-central folder if a pull failed because of a network interrupt? :(
10:07:54 <flo-retina> bah, I have a patch that was r+'ed with comments
10:08:02 <flo-retina> I don't even remember what I was trying to fix :-/
10:08:50 --> mayanktg has joined #instantbird
10:11:25 <-- mayanktg has quit (Ping timeout)
10:12:46 --> mayanktg has joined #instantbird
10:17:21 <flo-retina> of course it no longer applies cleanly
10:20:03 --> clokep has joined #instantbird
10:20:03 * ChanServ sets mode +o clokep 
10:35:12 --> BWMerlin has joined #instantbird
10:38:37 --> aleth has joined #instantbird
10:38:37 * ChanServ sets mode +o aleth 
10:56:23 <-- clokep has quit (Ping timeout)
10:57:10 <-- EionRobb has quit (Quit: Leaving.)
11:19:59 <-- Tonnes has quit (Quit: ChatZilla [Firefox 30.0/20140605174243])
11:30:48 <nhnt11> Hello!
11:32:31 <nhnt11> aleth: https://etherpad.mozilla.org/infinite-scroll-checklist
11:33:23 <aleth> Thanks
11:35:37 <-- nhnt11 has quit (Ping timeout)
11:35:41 --> nhnt11 has joined #instantbird
11:37:36 <nhnt11> I'm enthusiastic about landing log searching soon
11:37:57 <nhnt11> Meanwhile I'm testing a way to get grouped messages working with prepending
11:38:10 <aleth> It's looking good to me - just waiting for the requested feedback there.
11:39:22 <nhnt11> Btw out of curiosity, what's "ireflow" here? https://mxr.mozilla.org/comm-central/source/chat/content/convbrowser.xml#537
11:39:50 <nhnt11> Something to do with text reflow when the window size changes? If I were to guess
11:41:56 <aleth> nhnt11: I think it's OK to break grouped messages if the group becomes huge (larger than the number of messages you are prepending) if that dramatically simplifies things
11:42:05 <aleth> nhnt11: ireflow = interruptible reflow
11:42:30 <aleth> I don't know exactly what bug that is preventing, but it's likely painful...
11:44:38 <aleth> flo-retina would know, he wrote that line ;)
11:44:57 <nhnt11> aleth: The idea I'm testing is, get the html for both the "next" message case and the not-next message case. Store the "next" message html, and prepend the html for the not-next message case. When we want to prepend another message, replace the first one with the "next" case html that we stored.
11:45:03 <nhnt11> Similar to the unread ruler
11:45:15 <nhnt11> So if that works then grouped messages won't be a problem I think
11:45:19 <-- mayanktg has quit (Ping timeout)
11:45:38 --> mayanktg has joined #instantbird
11:45:39 <nhnt11> The isNextMessage method will still work if we want to split gropus
11:45:42 <nhnt11> groups*
11:45:54 <nhnt11> Let's see though.
11:46:09 <aleth> That should work.
11:48:09 <aleth> It's more from a UX pov, we don't want the user to see a bubble growing at the top. If this always happens off-screen it's not a problem though
11:48:16 <nhnt11> Btw, bug 1035060 might be of interest
11:48:25 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1035060 nor, --, ---, xyuan, ASSI, Implement AbortablePromise
11:49:10 --> clokep_work has joined #instantbird
11:49:10 * ChanServ sets mode +o clokep_work 
11:49:19 <nhnt11> Hmm, that's something I didn't think of.
11:49:30 <nhnt11> Right, it should always happen off-screen.
11:49:50 <nhnt11> BUT, once we start loading stuff from logs, that might not be possible...
11:49:54 <-- mayanktg has quit (Ping timeout)
11:50:08 <nhnt11> Because there /may/ be a delay between the user scrolling all the way up and the log file being read
11:50:24 <aleth> Right.
11:50:28 <nhnt11> Since there's file I/O involved. If we already have the messages cached, though, that shouldn't be a problem
11:50:28 --> mayanktg has joined #instantbird
11:50:38 <nhnt11> (We can just add messages when the user is /nearly/ at the top)
11:51:14 --> BillBinkley has joined #instantbird
11:52:14 <aleth> Yes, at the point (later) when messages have to be fetched asynchronically, you'll need a throbber of some sort too just in case.
11:52:36 <nhnt11> Yeah.
11:53:53 * Fallen|away is now known as Fallen
11:55:35 <-- mayanktg has quit (Ping timeout)
11:56:39 --> mayanktg has joined #instantbird
12:01:26 --> mib_a24q8i has joined #instantbird
12:02:17 <nhnt11> Btw, I think this has been mentioned before but I don't think we should support prepending of unread messages. I think we should wait for messages to be read before removing them from DOM. Thoughts?
12:03:08 <aleth> If you open a conv from hold with 1500 unread messages, you do want to avoid having to add all 1500 messages to the DOM at once
12:03:24 <aleth> This is a really common use case.
12:03:34 <nhnt11> In that case we'll want to /append/ messages while scrolling down though
12:03:50 <nhnt11> Scrollbars would get really messed up in that case though
12:04:00 <aleth> We currently show the /last/ new message on opening from hold, not the first.
12:04:16 <aleth> So that means prepending.
12:04:24 <nhnt11> Hmm okay.
12:04:27 <nhnt11> No big deal I guess.
12:05:00 <aleth> The deal is if message 1 pings you but you are only displaying message 50-100, to make sure the ping flag is still set.
12:06:06 <nhnt11> Well, conversations on hold can already tell if you've been pinged, so there must be a way.
12:06:35 <aleth> Sure, there is a way, just something to keep in mind ;)
12:06:51 <aleth> I think for now we shouldn't touch the adding of new incoming messages to the bottom of the conv.
12:07:00 <-- BWMerlin has quit (Quit: BWMerlin)
12:07:51 <-- nhnt11 has quit (Ping timeout)
12:07:59 <aleth> Removing messages *from the bottom* is a slightly different story to removing them from the top.
12:08:38 <-- mayanktg has quit (Ping timeout)
12:09:21 <aleth> So lets leave that for later ;)
12:09:26 --> nhnt11 has joined #instantbird
12:09:33 --> mayanktg has joined #instantbird
12:09:43 <nhnt11> Right.
12:10:17 <clokep_work> All this talk of DOM manipulations makes me sick. :P
12:10:55 <aleth> clokep_work: Abandom all hope ye who enter here? :P
12:10:56 <nhnt11> brb
12:11:16 <-- mayanktg has quit (Ping timeout)
12:11:19 --> mayanktg has joined #instantbird
12:12:57 <clokep_work> aleth: Something like that, yes. :)
12:15:58 <aleth> mayanktg: Can you tell me what goes wrong when you remove those toString()s from your patch?
12:16:49 <aleth> What's the type before the forced conversion?
12:17:18 <-- mayanktg has quit (Ping timeout)
12:18:10 --> mayanktg has joined #instantbird
12:22:39 <flo-retina> bah, the damn ireflow bugs :-/
12:22:55 <aleth> mayanktg: ^^
12:23:55 <mayanktg> aleth: Hi! For fixing the bug 1027779 I need to set _targetResource (http://mxr.mozilla.org/comm-central/source/chat/protocols/xmpp/xmpp.jsm#236) when the presence stanza containing <c/> node is received. Right?
12:23:57 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1027779 nor, --, ---, mayanktg, NEW, Inability to send call request if no messages have been exchanged before.
12:24:23 <aleth> mayanktg: Have you checked if the presence stanza contain the target resource?
12:24:24 <flo-retina> nhnt11, aleth: I think the ireflow bug that was working around is bug 492760
12:24:27 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=492760 nor, --, ---, bzbarsky, RESO FIXED, element.scrollIntoView sometimes scrolls at the top of the document
12:24:40 <flo-retina> mayanktg: no
12:24:55 <flo-retina> mayanktg: err, depends what you mean by "when"
12:25:12 <aleth> mayanktg: also http://log.bezut.info/instantbird/140721#m133
12:26:21 <flo-retina> nhnt11: "- autoscroll (probably not a problem)" I'm not so sure about that "probably not a problem".
12:26:31 <mayanktg> aleth: No. I haven't checked when the targetResource whether presence stanza already contains the target Resource.
12:26:34 <flo-retina> nhnt11: typically anything that caused a change of the scrollbar size caused auto-scroll issues.
12:27:10 <mayanktg> aleth: Wait. I'm answering the toString() question too.
12:27:53 <aleth> mayanktg: If you haven't checked, then you don't know if it can possibly work, right?
12:30:32 <mayanktg> Yes, Right. So I should first check whether stanza's from attribute contains a target resource and if it's present I should assign _targetResource to it.
12:31:55 <aleth> mayanktg: Look at the *existing* code in onPresenceStanza that deals with resources too.
12:32:19 <aleth> Understand the problem before you try fixing it ;)
12:34:11 <mayanktg> aleth: When I remove the toString() from the lines in the sdp2xml() I get an error that: <object>.split is not a function.
12:35:04 <-- mpmc has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com)
12:35:38 <aleth> mayanktg: What is the object? If you JSON.stringify it, what does it look like?
12:35:40 * clokep_work wonders what's being returned that it isn't a string.
12:36:53 * aleth also wonders
12:36:55 <mayanktg> clokep_work: Yes. |match()| isn't returning a string.
12:37:04 <aleth> .match returns an array
12:37:36 <aleth> The question is what match()[0] is if not a string ;)
12:38:03 <mayanktg> Aha..Wait :)
12:39:26 <clokep_work> My guess is that you forgot the [0]?
12:39:49 <mayanktg> Exactly! I didn't use the [0]
12:41:29 --> mpmc has joined #instantbird
12:42:20 <clokep_work> mayanktg: Do you understand why it needs to be there?
12:43:20 <-- mib_a24q8i has quit (Quit: http://www.mibbit.com ajax IRC Client)
12:44:23 <mayanktg> clokep_work: Yes I understood it now.Match() returns an array of strings. So using match()[0] would return a string and it won't be needed to use toString() any longer. :)
12:45:02 <clokep_work> mayanktg: Yes, and the 0 corresponds to which group is being matched.
12:46:03 <mayanktg> Yes.
12:47:28 <clokep_work> :) Good.
12:54:29 <flo-retina> .toString probably worked by accident, because on an array that does .join(","), which will be equivalent to [0] on an array with a single item.
12:54:39 <-- mayanktg has quit (Ping timeout)
12:55:00 --> mayanktg has joined #instantbird
13:21:18 <clokep_work> sawrubh: ping
13:23:19 <-- mayanktg has quit (Ping timeout)
13:24:11 --> mayanktg has joined #instantbird
13:29:20 <-- mayanktg has quit (Ping timeout)
13:31:18 --> mayanktg has joined #instantbird
13:31:34 <-- mpmc has quit (Ping timeout)
13:32:02 --> mpmc has joined #instantbird
13:39:59 <-- mayanktg has quit (Ping timeout)
13:42:15 --> mayanktg has joined #instantbird
13:43:56 <-- mayanktg has quit (Ping timeout)
13:44:52 --> mayanktg has joined #instantbird
13:47:53 --> mconley has joined #instantbird
13:48:15 <-- mayanktg has quit (Ping timeout)
13:49:08 --> mayanktg has joined #instantbird
13:51:46 <-- mayanktg has quit (Ping timeout)
13:52:36 --> mayanktg has joined #instantbird
13:54:26 <-- mayanktg has quit (Ping timeout)
13:55:15 --> mayanktg has joined #instantbird
13:57:23 <-- aleth has quit (Ping timeout)
14:01:06 <sawrubh> clokep_work: pong
14:02:31 <-- clokep_work has quit (Ping timeout)
14:05:12 --> aleth has joined #instantbird
14:05:12 * ChanServ sets mode +o aleth 
14:09:27 <aleth> nhnt11: Btw you've probably noticed this already, but when prepending messages, you'll have to get around the problem of not having more than one insert node in a document, and around the way time bubbles currently does its time calculations.
14:09:59 <nhnt11> aleth: Why would I need extra insert nodes
14:10:07 <nhnt11> I mean, the current setup is fine
14:10:24 <nhnt11> I don't need to add anything, because prepending always uses parent.firstChild
14:10:36 <nhnt11> (Until we have support for inserting messages arbitrarily)
14:10:40 <aleth> The insert nodes are in the message style, and optional.
14:11:05 <aleth> You will break stuff if there is more than one in a document, with the current code at least.
14:11:21 <nhnt11> Right, so my question is, why would there be more than one?
14:11:40 <-- mayanktg has quit (Ping timeout)
14:11:44 <aleth> If there is one at the end of a document, and one in html you are inserting at the top.
14:13:04 <aleth> For the second, you're either going to have to rewrite a fair bit of time bubbles code (in the message styles), or do something clever with documentfragments
14:18:58 * nhnt11 is looking around
14:19:01 <nhnt11> (at code)
14:30:55 --> clokep_work has joined #instantbird
14:30:55 * ChanServ sets mode +o clokep_work 
14:31:54 --> iamjayakumars has joined #instantbird
14:34:00 <clokep_work> sawrubh: Sorry, lost internet.
14:38:41 <clokep_work> sawrubh: Please let me know when you're back.
15:29:17 <sawrubh> clokep_work: sorry had gone for dinner, back
15:29:38 <sawrubh> clokep_work: sorry I missed those review comments, must have gotten off my minds (there are quite a few comments)
15:29:54 <sawrubh> *mind
15:30:55 --> mayanktg has joined #instantbird
15:34:16 <-- flo-retina has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com)
15:34:22 <-- mayanktg has quit (Ping timeout)
15:36:03 <-- chrisccoulson has quit (Quit: OSError: [Errno 130] Owner died)
15:41:55 <-- gerard-majax_ has quit (Ping timeout)
15:45:41 <-- clokep_work has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com)
15:47:33 --> mayanktg has joined #instantbird
15:49:19 <-- mayanktg has quit (Ping timeout)
15:49:36 <-- aleth has quit (Ping timeout)
15:49:41 --> mayanktg has joined #instantbird
15:51:33 --> aleth has joined #instantbird
15:51:33 * ChanServ sets mode +o aleth 
15:51:54 <aleth> mayanktg: Do you understand how resources work now?
15:56:09 <mayanktg> aleth: I guess yes. When an incoming message is received the resource is extracted from the from attribute using |(this._account._parseJID(aStanza.attributes["from"])).resource| and is assigned to _targetResource. Similarly when we delete the targetresource if the presence stanza has changed.
15:56:42 <aleth> Do you understand what all the resource code in onPresenceStanza is for?
15:57:33 <aleth> I'm wondering why, if you've understood all this, you haven't fixed the bug. Or if you have not understood it, why you're not asking questions ;)
15:58:44 <-- mayanktg has quit (Ping timeout)
15:58:57 <aleth> "we delete the targetresource if the presence stanza has changed." is not exactly right. It's not the presence stanza changing that does it.
15:59:16 --> flo-retina has joined #instantbird
15:59:17 * ChanServ sets mode +qo flo-retina flo-retina 
16:01:41 --> mayanktg has joined #instantbird
16:02:31 <mayanktg> aleth: Sorry for my internet connection :-/ . I'm unable to get how to call the _targetResource of XMPPConversationPrototype from XMPPAccountPrototype.
16:02:52 <mayanktg> aleth:  You mean the resource here? http://mxr.mozilla.org/comm-central/source/chat/protocols/xmpp/xmpp.jsm#536
16:03:25 <aleth> Yes, and everything following that.
16:04:11 <aleth> What's it for? Do you know? If not, why are you not asking?
16:04:31 <aleth> "how to call the _targetResource of XMPPConversationPrototype from XMPPAccountPrototyp" does not sound like something you should be doing 
16:06:55 <mayanktg> aleth: Sorry but I don't understand what should be done here. I mean how should I use this._resources to set the _targetResource.
16:07:19 <aleth> mayanktg: Let's start at the beginning. What are XMPP resources for?
16:07:54 <aleth> I'm sorry to ask so many questions, but I really don't understand what you're not understanding here.
16:08:21 <mayanktg> XMPP resources tells what's the source of the account. For eg. its an Android, Instantbird, Jitsi etc..
16:09:01 <aleth> Not really. It's more that you can have multiple devices or clients connected with the same XMPP id at the same time.
16:09:24 <aleth> Each one is identified by a resource. You could have two IB instantbird instances for example (maybe on two computers)
16:09:39 <aleth> Or a mobile client and IB on your desktop.
16:10:03 <mayanktg> Yes.
16:10:19 <aleth> So when you want to send a message, or start a video, the id is not enough - you need the specific resource.
16:10:23 <-- iamjayakumars has quit (Client exited)
16:10:42 <mayanktg> And it tells to which account the message should be sent. We need a full ID.
16:10:44 <aleth> On the other hand, presence will give you information on the state of all the resources.
16:10:59 <mayanktg> Ok
16:11:03 <aleth> It's *not* an account. If you use that word, it's super confusing.
16:11:24 <aleth> But you're right a full JID is one including the resource.
16:13:22 --> iamjayakumars has joined #instantbird
16:13:57 <aleth> So if there is a XMPP buddy in your contact list, we need its status. If that buddy has multiple resources, what happens?
16:16:55 <mayanktg> Yes. When the buddy has multiple resources it would receive presence stanza from each of the resource.
16:17:18 <aleth> Right. But how do we figure out what to show in the contact list?
16:17:31 <aleth> What does the code do?
16:18:22 <aleth> Hint: The contact list doesn't care about resources, because the user doesn't. He just cares about how available his friend is ;)
16:18:27 <mayanktg> Just a min..let me look at the code.
16:20:07 <aleth> Sure... that's what I've been trying to get you to do since http://log.bezut.info/instantbird/140721#m153 ;)
16:21:54 <-- mayanktg has quit (Ping timeout)
16:22:12 --> mayanktg has joined #instantbird
16:23:51 <mayanktg> The user should set the message to the resource that is more available? i.e.  set the status for the most available resource.?
16:24:44 <aleth> Is that what the code does? Can you show me the line where it does that?
16:27:28 <-- iamjayakumars has quit (Ping timeout)
16:28:48 <aleth> It's not hard... :-/
16:31:06 <mayanktg> aleth: Sorry my net is not working.  http://mxr.mozilla.org/comm-central/source/chat/protocols/xmpp/xmpp.jsm#558 ?
16:31:32 <aleth> Yes.
16:32:07 <aleth> Where does it store the resource it's currently using for the buddy status?
16:33:36 --> iamjayakumars has joined #instantbird
16:34:10 <-- iamjayakumars has quit (Client exited)
16:34:11 <mayanktg> The _resource is stored at  http://mxr.mozilla.org/comm-central/source/chat/protocols/xmpp/xmpp.jsm#478
16:34:37 <mayanktg> * _resources
16:34:45 <aleth> That's an object that contains the current data for *all* the resources (see line 538), so no.
16:36:26 <mayanktg> Ohh...Ok ok.
16:38:09 <-- mayanktg has quit (Ping timeout)
16:38:30 --> mayanktg has joined #instantbird
16:40:09 * aleth wonders what's so hard to understand about the 30 or so lines of code in onPresenceStanza that do all this
16:40:45 <aleth> This would be a lot easier if I was being asked the specific questions...
16:40:56 <mayanktg> Is it at http://mxr.mozilla.org/comm-central/source/chat/protocols/xmpp/xmpp.jsm#489?
16:41:01 <mayanktg> Sorry :( .
16:41:46 <mayanktg> What I'm unable to understand is when and how to set the targetResource for the buddy?
16:42:23 <aleth> The target resource has nothing at all to do with what we are talking about (yet). You won't understand what to do about that bug until you understand how resources are handled and why.
16:42:49 <aleth> The line you are pointing at just sets a temporary variable, it doesn't store anything.
16:43:00 --> goofy has joined #instantbird
16:43:12 <mayanktg> Ok.
16:44:26 <goofy> hello guys, this is a (minor) feature request: I realize I would appreciate to have a "pin this tab" feature similar to firefox one
16:46:03 <aleth> mayanktg: what I mean by "specific questions" is: If you are having trouble understanding the existing code, ask about specific parts of it. "What is this line for",  "I don't understand the JS in this line", etc...
16:47:43 <sawrubh> clokep_work: I'm not sure what's the use of a NO_ERROR flag, since if there's no error I simply won't have called notifyObservers (which would have called fileTransferError), also not initializing `error` member of prplIFileTransfer to NO_ERROR doesn't have any effect
16:48:11 <aleth> goofy: Could you file a bug for that please? We use bugs for feature requests too
16:49:47 <goofy> no problem, please just tell me your bugzilla url
16:50:59 <sawrubh> clokep_work: I added those two XMPP specific comments (even though recommended not to) because I wasn't sure how to explain ERROR_NOT_SUPPORTED in a better fashion than I what I done previously (`File transfer not supported by receiver.`) without touching any XMPP specific comments
16:51:01 <aleth> goofy: bugzilla.mozilla.org
16:51:11 <goofy> aaah :) 
16:51:41 <sawrubh> clokep_work: I would like to discuss how to better word them, which suits what you want
16:52:54 --> Mook_as has joined #instantbird
16:54:55 <sawrubh> clokep_work: I formatted that last comment like that because currently it's going till 73, had I include the `initiate` from the second line, it would have gone till 82, I preferred keeping it below 80 rather than overshooting it
16:55:31 <sawrubh> clokep_work: I'm looking at what other errors and previous comments I've not addressed
16:55:42 <aleth> mayanktg: what are you looking at? Where are you stuck?
16:56:04 --> chrisccoulson has joined #instantbird
16:57:20 <mayanktg> aleth:  I'm re-reading and understanding the onPresenceStanza() . I was looking where is the resource stored from where the buddy status is fetched.
16:57:53 <aleth> mayanktg: One way to do this is to work backwards from the end, where setStatus is called.
17:00:30 <sawrubh> clokep_work: re your next patch review, I kept the comment as "Please ask the receiver to send you a message." as you suggested in the previous review, also what's XMPP specific in it? also not possible and unsupported cases make sense in my opinion because one  is probably a bug in xmpp and with IB (something we might fix soon) and another is lack of
17:00:30 <sawrubh> implementation of the xmpp implementation
17:00:43 <-- mayanktg has quit (Ping timeout)
17:01:06 --> mayanktg has joined #instantbird
17:01:12 <sawrubh> what might make sense alternatively is that we don't have a localized string for the not possible case (since that might be fixed soon with that _targetResource issue)
17:01:56 <aleth> sawrubh: I don't think it makes sense to add strings for issues that are due to bugs that have to be fixed anyway before this ships.
17:02:28 <aleth> sawrubh: Just throw an error at the appropriate place and add a TODO comment.
17:02:38 <sawrubh> aleth: yeah, I'll remove it as soon as I have confirmation from clokep_work
17:03:23 * sawrubh just wants to land this
17:03:42 <-- mayanktg has quit (Ping timeout)
17:04:13 --> mayanktg has joined #instantbird
17:07:45 <-- mayanktg has quit (Ping timeout)
17:08:32 --> mayanktg has joined #instantbird
17:08:57 <mayanktg> So the resource for the buddy is at |preferred|. If the preferred is not undefined the status is set as the statusText for the given statusType. Right?
17:10:51 <aleth> Yes, but that's a local variable. Where is it stored? How do we figure out if the current preferred is different from the previous preferred resource, so we have to notify observers?
17:11:50 <-- mayanktg has quit (Ping timeout)
17:12:17 --> mayanktg has joined #instantbird
17:17:58 <-- mayanktg has quit (Ping timeout)
17:18:15 --> mayanktg has joined #instantbird
17:28:26 <-- mayanktg has quit (Ping timeout)
17:28:52 --> mayanktg has joined #instantbird
17:32:31 <-- mayanktg has quit (Ping timeout)
17:32:52 --> mayanktg has joined #instantbird
17:36:55 <-- mayanktg has quit (Ping timeout)
17:37:24 --> mayanktg has joined #instantbird
17:40:28 <-- mpmc has quit (Connection reset by peer)
17:41:12 <-- mayanktg has quit (Ping timeout)
17:41:30 --> mayanktg has joined #instantbird
17:42:35 <mayanktg> aleth: The preferred Resource has been set at the this._preferredResource. right?
17:42:45 <aleth> Right.
17:43:53 <flo-retina> goofy: Is bug 1041627 about Thunderbird or Instantbird?
17:43:56 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1041627 nor, --, ---, nobody, NEW, Feature Request : Having a "pin this tab" feature in instant messaging
17:44:51 <aleth> mayanktg: Do you understand line 576-578 now?
17:45:02 <goofy> flo-retina: actually I am using both standalone version and thunderbird embedded one, and I was not able to find "instantbird" as aproduct in bugzilla maze
17:45:39 <flo-retina> goofy: tip: on https://bugzilla.mozilla.org/enter_bug.cgi instead of searching, just start typing in the "find product" box at the top ;)
17:45:52 <goofy> ok noted
17:46:53 <-- mayanktg has quit (Ping timeout)
17:47:17 --> mayanktg has joined #instantbird
17:47:31 <aleth> mayanktg: In particular, do you understand why sometimes it is *wanted* that targetResource isn't set?
17:49:21 <mayanktg> aleth: Yes. The lines delete the targetResource if  _preferredResource and preferred are different &&& the buddy is without a resource.
17:49:43 <mayanktg> The comment contains a FIXME (L575)
17:50:39 <aleth> Yes, but why does it do it? What happens when targetResource isn't set and you send a message in that conversation?
17:52:42 <aleth> The answer is actually in the comment ;)
17:53:04 --> clokep_work has joined #instantbird
17:53:04 * ChanServ sets mode +o clokep_work 
17:53:54 <-- mayanktg has quit (Ping timeout)
17:54:12 --> mayanktg has joined #instantbird
17:54:18 <mayanktg> If I send a message to a buddy for whom s targetResource is not set, the message is sent to all the resources! (That's why a new conversation opens and I receive the message)
17:55:59 <-- mayanktg has quit (Ping timeout)
17:56:06 --> mayanktg has joined #instantbird
17:56:14 <mayanktg> So if I have connected buddy from two resources and the client doesn't know about the targetResource to whom it has to send the message, it sends the message to all the resources. Right?
17:58:47 <aleth> Yup.
17:59:44 <-- mayanktg has quit (Ping timeout)
17:59:44 <aleth> OK, so now you have a reasonable understanding of resources, do you have any ideas for what to do about that bug?
17:59:57 --> mayanktg has joined #instantbird
18:01:40 <-- mayanktg has quit (Ping timeout)
18:02:05 --> mayanktg has joined #instantbird
18:03:50 <sawrubh> clokep_work: http://log.bezut.info/instantbird/140721/#m297
18:04:05 <clokep_work> sawrubh: I'm reading.
18:04:26 <mayanktg> aleth: I think like we are sending message to all the resources iwhen target resource isn't set, we should send the startCall notification too to all the resources?
18:04:35 <mayanktg> *when
18:04:53 <mayanktg> But will that be reasonable :-o
18:06:08 <aleth> It's one possible solution, yes.
18:06:58 <aleth> Since we do that for normal messages too.
18:07:19 <aleth> flo-retina, what do you think of that suggestion?
18:07:27 <clokep_work> sawrubh: I don't understand how you don't see "Please ask the receiver to send you a message." as being XMPP specific.
18:07:36 <clokep_work> that's a bug and an implementation detail of our *XMPP* code.
18:08:11 <aleth> mayanktg: The alternative would be to send it only to the current preferredResource 
18:08:54 <flo-retina> aleth: what's the suggestion?
18:08:55 <sawrubh> clokep_work: ok, it makes sense to just report an error (and not have a localized string for that case since it's anyway a bug and will be fixed) so I'll remove the notSupported string
18:09:00 <mayanktg> Ok.
18:09:33 <aleth> flo-retina, mayanktg: http://log.bezut.info/instantbird/140721/#m370
18:09:37 <clokep_work> sawrubh: OK.
18:09:49 <mayanktg> flo-retina: The suggestion is that if no targetResource has been set the video call notification should be sent to all the resources.
18:09:54 <flo-retina> aleth: that sounds more like the initial problem than like a suggestion
18:10:17 <flo-retina> mayanktg: what do you mean by "call notification should be sent to all the resources"?
18:11:08 <aleth> flo-retina: I take it the idea is that only one of the resources would respond, and from there things proceed as normal.
18:11:47 <flo-retina> aleth: IIRC the spec, the XMPP server will just reject the message
18:12:00 <clokep_work> sawrubh: I think for accounts we check it on disconnect and the same flag is used for a disconnect no matter if there's an error not.
18:12:02 <mayanktg> Sorry I mean that notification should be sent to all the resource if the user is connected to more than one resource.. 
18:12:04 <flo-retina> aleth: messages attempting to start a P2P interaction have to be targeted to a specific resource.
18:12:07 <clokep_work> So yeah , don't worry about adding it.
18:12:15 <flo-retina> they are not regular messages that the server can buffer/duplicate/route
18:12:21 <flo-retina> *re-route
18:12:24 <mayanktg> OK.
18:12:36 <aleth> flo-retina: He means a for loop over the resources stored on the account buddy, sending a startcall message to each full jid in turn.
18:12:55 <flo-retina> aleth: I haven't seen him say that.
18:14:20 <flo-retina> aleth: there's only 2 possible solutions anyway: 1. Find the most available resource that supports the capability you want, and send the call only to that one. 2. Start a _separate call_ with each of the resources supporting the capability you care about, and cancel all the calls but the one that answers as soon as you get an answer
18:14:36 <aleth> mayanktg: You're going to have to tell us if that's what you meant or...
18:15:13 <aleth> flo-retina: sure. I was hoping we were *finally* at the point where we could choose between 1 and 2 ;)
18:15:51 <flo-retina> aleth: it's not yet clear to me if mayanktg understands any of these 2 solutions ;)
18:15:56 <mayanktg> I was trying to say thateach of the resource which are present should be a call notification. and the one which responds should be allowed to continue with the call.
18:15:59 <flo-retina> he still hasn't explains his plan
18:16:52 <mayanktg> Btw identifying the most available resource which supports the capability needed sounds a  better idea.
18:17:14 <flo-retina> why?
18:19:01 <mayanktg> Beacause if we are able to identify the resource which supports the capability the chances would be most likely that the person receives the notification and is able to respond to that.
18:20:33 <mayanktg> Sending the notification to each resource present would rather increase the amount of data we send and there would also be a need to cancel the call at all the other resources which do not support the video call capability.
18:21:17 <mayanktg> I mean. after a call has been answered, other resources should end the call.
18:21:30 <sawrubh> clokep_work: so I'll remove notSupported, not add NO_ERROR, can we discuss what you would like the comments to be
18:22:42 <sawrubh> clokep_work: also are you OK with that formatting of the comment (ending at 72 instead of 82) which you mentioned in your review
18:23:03 <clokep_work> sawrubh: Comments go the full line length and then wrap when they go over 80.
18:23:09 <clokep_work> There's nothing to discuss about that.
18:23:58 <sawrubh> so it's ok to exceed 80, I wasn't sure of that and that's why I took it as far as I could without hitting 80
18:24:03 <aleth> mayanktg: I just sent you some feedback on the entity capabilities patch, I think it is clear now you need to fix that before you take this bug further (with solution 1 or 2).
18:25:32 <flo-retina> "there would also be a need to cancel the call at all the other resources which do not support the video call capability." makes no sense.
18:25:36 <sawrubh> clokep_work: so you mentioned not refer anything XMPP specific, how can I make "File transfer not supported by the receiver." better, I find this comment pretty clear
18:25:48 <clokep_work> sawrubh: NO!
18:25:53 <clokep_work> It's NOT ok to exceed 80!
18:26:05 <flo-retina> if the entity doesn't support webrtc, you wouldn't be starting a call with it, so you would have nothing to cancel
18:27:22 <clokep_work> sawrubh: "due to lack of Stream Initiation or In Band Bytestream implementation"
18:27:27 <clokep_work> That doesn't sound XMPP specific to you? :-S
18:27:46 <sawrubh> yes, that;s why I proposed the comment in my last message
18:27:58 <clokep_work> Where?
18:28:02 <clokep_work> Last message?
18:28:03 <clokep_work> What?
18:28:12 <sawrubh> clokep_work: http://log.bezut.info/instantbird/140721/#m416
18:28:29 <clokep_work> sawrubh: Why does it need to be better? :-S
18:28:39 <clokep_work> Did I say it isn't good enough?
18:28:42 <clokep_work> I have no context.
18:29:01 <mayanktg> aleth: Ok. I'm checking it with multiple clients and then proceeding further as you've suggested.
18:30:57 <sawrubh> clokep_work: in https://bugzilla.mozilla.org/show_bug.cgi?id=1024023#c27 you asked for clarification and I thought you meant a better comment, miscommunication then.
18:31:00 <instantbot> Bug 1024023 nor, --, ---, saurabhanandiit, ASSI, Add File Transfer Support for JS-XMPP
18:32:00 <clokep_work> sawrubh: I don't see a reference to that block...
18:32:31 <clokep_work> I think I was just summarizing.
18:32:50 <sawrubh> it's all clear now
18:32:55 <clokep_work> OK.
18:33:46 --> arlolra has joined #instantbird
18:34:12 <sawrubh> clokep_work: re "This comment is still formatting wrong." so if we're not supposed to exceed 80, I don't see anything wrong with the formatting, currently I end at `is used to` which ends at 73, if I include the `initiate` on the next line, it'll go to 82, am I missing something with regards to formatting
18:35:43 <-- arlolra has quit (Ping timeout)
18:35:56 <clokep_work> sawrubh: https://bugzilla.mozilla.org/page.cgi?id=splinter.html&bug=1024023&attachment=8459154 either that comment or line 873 is formatted very wrong.
18:36:13 <clokep_work> You either have a lot of comments formatting incorrectly or a lot of code that exceeds 80 chars.
18:38:51 <sawrubh> ok, I'll recheck the 80 limit on all the code
18:39:30 <clokep_work> Your editor can probably add a marker to show you.
18:41:15 <mayanktg> aleth: Yes. I'm receiving capabilities node for each of the resource. So I should now store the capabilities separately for each of the resource.
18:41:50 <aleth> mayanktg: Of course, like here for the status http://mxr.mozilla.org/comm-central/source/chat/protocols/xmpp/xmpp.jsm#538 
18:42:36 <aleth> Just add some properties there.
18:43:03 <mayanktg> Yes.
18:43:03 <-- aleth has quit (Quit: exit stage left)
18:47:29 <sawrubh> clokep_work: re "Again...this shouldn't refer to XMPP." I earlier had this: https://pastebin.mozilla.org/5587441 but you commented "This error name implies error while waiting for an acknowledgement. What do you mean by "somewhere in between"? I'm also not positive I understand your TODO."
18:47:40 <sawrubh> so I changed it to https://pastebin.mozilla.org/5587442
18:48:13 <sawrubh> how do I improve the 'somewhere in between' without actually listing the long list of reasons nor linking to the document explaining the reasons
18:49:01 <sawrubh> "Error while sending in either the sender or the receiver's side", something like this works?
18:53:17 <clokep_work> sawrubh: That TODO makes no sense.
18:53:23 <clokep_work> I don't think that was mine.
18:53:37 <clokep_work> That comment doesn't make any sense at all. :-\
18:54:06 <-- mayanktg has quit (Ping timeout)
18:54:10 <clokep_work> sawrubh: Isn't that error just "The remote client failed to acknowledge sent data."?
18:55:13 <sawrubh> no, the error could have been caused "Because a server-to-server link has gone down, the sender's server" hence due to the sender too
18:55:38 --> mayanktg has joined #instantbird
18:56:51 <sawrubh> I mean it could be either a fault at the sender side (the case of connectivity) otherwise the receiver side (case of connectivity, bad session ID, bad seq ID, data not formatted correctly) etc
18:57:53 --> gerard-majax_ has joined #instantbird
18:58:05 <clokep_work> sawrubh: Doesn't that all boil down to the person not acknowledging correctly?
18:58:52 <clokep_work> sawrubh: So here's the deal. I'm pretty sure I've explained this before...but...interfaces need to be protocol agnostic. They should not refer to a specific protocol's implementation.
18:59:50 <sawrubh> yeah you've told me that before, I just get confused sometimes (and it gets off my mind too sometimes) how to word it without using protocol specific things :)
19:03:23 <-- mayanktg has quit (Ping timeout)
19:04:13 --> mayanktg has joined #instantbird
19:06:35 <-- flo-retina has quit (Ping timeout)
19:14:27 <-- mayanktg has quit (Ping timeout)
19:14:50 --> mayanktg has joined #instantbird
19:15:49 * mayanktg has to write his weekly blog post too today.
19:15:50 --> flo-retina has joined #instantbird
19:15:50 * ChanServ sets mode +qo flo-retina flo-retina 
19:16:03 <clokep_work> sawrubh: OK.
19:16:16 * clokep_work is tired of making formatting nits. ;)
19:16:39 <sawrubh> I'll reword that to "The remote client failed to acknowledge sent data."
19:16:57 * sawrubh is tired of nits :P
19:18:23 <-- goofy has quit (Ping timeout)
19:25:11 <-- mayanktg has quit (Ping timeout)
19:25:32 --> mayanktg has joined #instantbird
19:28:13 <-- mayanktg has quit (Ping timeout)
19:28:36 --> mayanktg has joined #instantbird
19:30:32 --> aleth has joined #instantbird
19:30:32 * ChanServ sets mode +o aleth 
19:35:17 <mayanktg> aleth: By capabilities you meant the <c/> node or the value of the capabilities generated from the ver attribute? I'm asking this because I'm setting the this._availabilityDetails also at the onServiceDiscoveryStanza().
19:35:39 <aleth> Won't you have to do service discovery for each resource?
19:36:59 <-- mayanktg has quit (Ping timeout)
19:37:11 --> mayanktg has joined #instantbird
19:38:04 <aleth> Obviously you have to also change the way you set this._availabilityDetails.
19:38:33 <mayanktg> aleth: I will have to do a service discovery request only if I haven't received the same ver attribute before.
19:38:40 <aleth> Sure.
19:38:48 <mayanktg> Ok.
19:38:59 <aleth> But there may be more than one service discovery per buddy.
19:39:29 <-- Bollebib has quit (Ping timeout)
19:40:28 <-- mayanktg has quit (Ping timeout)
19:40:49 <aleth> It seems to me each resource will have its own availabilityDetails after service discovery.
19:41:59 --> mayanktg has joined #instantbird
19:42:41 <mayanktg> Ok.
19:43:12 <mayanktg> I thought _availabilityDetails should be assigned the value only for the preferred resource.
19:43:13 <-- chrisccoulson has quit (Quit: OSError: [Errno 130] Owner died)
19:43:33 --> chrisccoulson has joined #instantbird
19:44:07 <aleth> There's a difference between this._availabilityDetails (which should be that of the preferred resource) and the ones you store for each resource in the resource object.
19:44:23 <aleth> How else are you going to find out easily which resources you can send a startCall to, later? ;)
19:49:31 <mayanktg> Aah! understood. Set a object which contains the availability details for each resource --> get the most suitable resource (one which has the video call capability) --> set this._availabilityDetails assigned with this preferred resource?
19:49:58 <aleth> this._resource is where all the details for each resource go.
19:50:20 <aleth> this._availabilityDetails always has to be for this._preferredResource, yes.
19:50:20 <mayanktg> yes.
19:52:42 <-- CAKCy has quit (Quit: Have a great day everyone!)
19:57:20 <aleth> mayanktg: You'll also want to add to this if clause http://mxr.mozilla.org/comm-central/source/chat/protocols/xmpp/xmpp.jsm#560
19:58:28 <aleth> So we prefer resources with more capabilities if they have the same statustype
19:58:55 <-- mayanktg has quit (Ping timeout)
19:59:23 --> mayanktg has joined #instantbird
20:00:17 <mayanktg> ok
20:12:18 <-- mayanktg has quit (Ping timeout)
20:13:09 --> mayanktg has joined #instantbird
20:13:17 --> PhilDF has joined #instantbird
20:14:51 <-- aleth has quit (Ping timeout)
20:18:40 --> aleth has joined #instantbird
20:18:41 * ChanServ sets mode +o aleth 
20:19:24 <-- mayanktg has quit (Ping timeout)
20:19:47 --> mayanktg has joined #instantbird
20:21:44 <mayanktg> I can't work even connect my XMPP account with such slow internet :( . Sorry, I'll write my blog until then and continue with the patch as soon as my net improves.
20:23:35 <-- BillBinkley has quit (Ping timeout)
20:30:57 <-- mayanktg has quit (Ping timeout)
20:31:30 --> mayanktg has joined #instantbird
20:33:13 --> Rym has joined #instantbird
20:34:53 --> EionRobb has joined #instantbird
20:37:24 <-- clokep_work has quit (Ping timeout)
20:50:12 <-- mayanktg has quit (Connection reset by peer)
20:50:56 --> mayanktg has joined #instantbird
20:52:42 <-- mayanktg has quit (Ping timeout)
20:53:44 --> mayanktg has joined #instantbird
21:01:07 <-- mayanktg has quit (Ping timeout)
21:02:22 --> mayanktg has joined #instantbird
21:04:32 <aleth> mayanktg: there's also this simple followup, http://log.bezut.info/instantbird/140717#m243
21:04:35 <-- mayanktg has quit (Ping timeout)
21:05:00 --> mayanktg has joined #instantbird
21:06:47 <-- mayanktg has quit (Ping timeout)
21:08:40 <-- gerard-majax_ has quit (Ping timeout)
21:11:48 <-- aleth has quit (Ping timeout)
21:13:54 --> aleth has joined #instantbird
21:13:55 * ChanServ sets mode +o aleth 
21:23:03 --> Bollebib has joined #instantbird
21:24:02 <-- flo-retina has quit (Ping timeout)
21:33:29 --> flo-retina has joined #instantbird
21:33:29 * ChanServ sets mode +qo flo-retina flo-retina 
21:33:59 <-- Rym has quit (Ping timeout)
21:37:11 <-- PhilDF has quit (Quit: http://www.mibbit.com ajax IRC Client)
21:48:40 <-- aleth has quit (Ping timeout)
21:50:28 --> aleth has joined #instantbird
21:50:28 * ChanServ sets mode +o aleth 
21:59:49 <-- mconley has quit (Input/output error)
22:09:30 <-- aleth has quit (Ping timeout)
22:09:40 --> aleth has joined #instantbird
22:09:40 * ChanServ sets mode +o aleth 
22:24:23 * Fallen is now known as Fallen|away
22:35:29 <flo-retina> http://mxr.mozilla.org/comm-central/source/build/unix/mozconfig.linux#21 :-D
22:35:44 <aleth> There it is.
22:36:45 <flo-retina> so what do I need to do to be in that "else" case?
22:39:09 <flo-retina> ok, I need http://mxr.mozilla.org/comm-central/source/mail/config/mozconfigs/linux64/nightly#1 in the mozconfig
22:39:32 <aleth> The mail/ Linux mozconfigs all set no_tooltool=1
22:39:54 <aleth> ah, duplication ;)
22:41:52 <flo-retina> now I have the good compiler
22:42:13 <flo-retina> configure fails after 20s, insulting me about the gtk version
22:43:08 <flo-retina> I don't see any gtk package in that repo :-S
22:43:47 <aleth> This is also odd http://mxr.mozilla.org/comm-central/source/build/unix/mozconfig.linux#30 considering "the tooltool toolchain is x86_64 only."
22:43:56 <aleth> Though I didn't think we'd be building against gtk3
22:45:00 <aleth> Maybe you need the gtk from the centos repos?
22:46:36 <flo-retina> yeah
22:46:48 <flo-retina> or maybe the pkg_config_path isn't correct, like the error message suggests
22:46:55 <aleth> ie. update your centos 6.2
22:47:09 <flo-retina> nope, I don't want to update :-P
22:47:38 <aleth> not to 6.3 ;)
22:48:52 <flo-retina> maybe I need sudo yum group mark install "X Software Development"
22:49:06 <aleth> Oh, I thought you'd done that
22:49:41 <flo-retina> hmm, no
22:49:46 <flo-retina> "No such command: group"
22:50:01 <flo-retina> aleth: I haven't because of the comment that says "# 'Development tools' is defunct in Fedora 19 use the following"
22:50:12 <flo-retina> the first line containing 'Development Tools' worked OK
22:50:23 <aleth> Oh
22:50:46 <aleth> gtk would be 'Gnome software development" anyway
22:50:52 <aleth> :-S
22:52:57 * flo-retina runs |yum install gtk2-devel|
22:53:09 <flo-retina> and that's actually installing stuff
22:53:21 <flo-retina> including 2 freetype packages coming from the mozilla repo
22:54:29 <flo-retina> let's see how much that helps (will configure fail after 22s instead this time?)
22:54:35 <flo-retina> ah, no 19s
22:54:46 <flo-retina> complaining about dbus this time
22:55:13 <flo-retina> https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Linux_Prerequisites#RedHat_Enterprise_Linux_%28RHEL%29.2FCentOS.2FFedora seems awfully outdated/useless :(
22:55:49 <aleth> Probably hasn't been updated since mach bootstrap
22:56:36 <aleth> Maybe you should try that? ;)
22:57:34 <flo-retina> yum install dbus-devel
22:57:55 <flo-retina> ah, do you remember where that list is for what bootstrap does?
22:58:35 --> clokep has joined #instantbird
22:58:35 * ChanServ sets mode +o clokep 
22:58:37 <flo-retina> now failing on dbus-glib-1
22:58:56 <aleth> no
22:58:57 --> clokep_work has joined #instantbird
22:58:57 * ChanServ sets mode +o clokep_work 
22:59:06 <aleth> but you'll have a terrible time if you do it one by one
22:59:22 <flo-retina> I'll have a terrible time if I touch centos
22:59:27 <flo-retina> aleth: there aren't that many
22:59:39 <flo-retina> as I've already installed plenty of them from that page
22:59:54 <flo-retina> now complaining about yasm
23:00:07 <aleth> yasm was in your mozilla repo
23:00:24 <flo-retina> |yum install yasm| takes something from the moz repo indeed
23:00:42 <aleth> flo-retina: https://hg.mozilla.org/mozilla-central/file/5b64c42742cd/python/mozboot/mozboot/centos.py
23:00:57 <aleth> should save some time ;)
23:01:06 <clokep> Sounds like you're making progress.
23:01:08 <clokep> !
23:01:24 <flo-retina> reticulating splines!
23:01:45 <flo-retina> aleth: a bit late I'm afraid ;)
23:02:05 <aleth> well, if you've got them all, never mind :)
23:02:13 <flo-retina> aleth: but yeah, that would have saved some time
23:02:19 <flo-retina> it's currently building
23:02:39 * clokep goes to keep reviewing patches.
23:02:46 <flo-retina> clokep: yes, making some centos progress ;)
23:03:21 <flo-retina> aleth: yasm was in the list from MDN :-S
23:03:28 <flo-retina> aleth: maybe I ran that line before setting up the moz repo
23:04:06 * aleth will be surprised if the build finishes without some sort of regression/missing build system change/...
23:04:26 <aleth> Then again, this is m-c you're building ;)
23:04:30 <flo-retina> I haven't checked out purple/
23:04:38 <flo-retina> aleth: it's c-c with --enable-application=im
23:04:46 <aleth> OK, straight for the win!
23:04:59 * clokep goes to make dinner and looks at mayanktg's patch.
23:08:11 <flo-retina> 7 minutes since I started the build, and it hasn't failed yet
23:08:40 <clokep> How long do we expect a build to be?
23:08:41 * flo-retina is curious to see how long builds take on that old hardware
23:08:41 <clokep> 27 minutes?
23:08:50 <flo-retina> clokep: I'm hoping it will be less than an hour
23:08:57 <flo-retina> the machines are old
23:09:21 <flo-retina> but then, there's been huge build speed improvements lately :)
23:12:21 <-- Bollebib has quit (Client exited)
23:17:52 <-- aleth has quit (Ping timeout)
23:22:05 <flo-retina> the exicting thing is that... if we have centos6 builders, we will be able to stop disabling random features in our mozconfigs :)
23:24:17 <clokep> Doesn't that mean more stuff can break?
23:28:00 <flo-retina> can it get more broken than it currently is?
23:28:24 <flo-retina> clokep: what I had in mind was all the gio stuff (link clicking that doesn't work, etc...)
23:29:08 <flo-retina> clokep: http://mxr.mozilla.org/comm-central/source/im/config/mozconfigs/linux/mozconfig#24 we should be able to remove lines 24 to 30.
23:29:11 <clokep> flo-retina: Ah! Yes. :)
23:29:19 <flo-retina> that will bring us closer to the build config used for Firefox and Tb
23:29:31 <flo-retina> so hopefully less likely to have random unnoticed bustage
23:33:12 <-- clokep_work has quit (Ping timeout)
23:36:56 --> aleth has joined #instantbird
23:36:56 * ChanServ sets mode +o aleth 
23:38:41 --> Rym has joined #instantbird
23:39:40 --> clokep_work has joined #instantbird
23:39:40 * ChanServ sets mode +o clokep_work 
23:43:59 * clokep should really debug that password issue some more at some point. :-\
23:44:32 <aleth> Build still hasn't failed?
23:44:42 --> rosonline has joined #instantbird
23:46:39 <flo-retina> already running for 45 minutes
23:46:48 <flo-retina> aleth: nope :)
23:46:59 <flo-retina> it's still in layout/
23:47:14 <flo-retina> maybe "1 hour" was optimistic as a build time estimate :-/
23:47:19 <aleth> might take a bit longer then...
23:47:47 <flo-retina> I'll see the result tomorrow
23:47:50 <flo-retina> Good night