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 0.9.90.1 [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