All times are UTC.
00:10:33 <-- Armada has quit (Ping timeout) 00:10:56 --> Armada has joined #instantbird 00:12:07 --> wnayes has joined #instantbird 00:18:24 --> chrisccoulson has joined #instantbird 00:42:42 <-- mpmc has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 00:55:36 --> wnayes1 has joined #instantbird 00:55:42 <-- wnayes1 has quit (Quit: wnayes1) 01:04:05 <-- Armada has quit (Connection reset by peer) 01:17:12 <-- Mook_as has quit (Quit: Mook_as) 01:31:34 <-- wnayes has quit (Ping timeout) 01:54:59 --> wnayes has joined #instantbird 02:32:54 <-- EionRobb has quit (Ping timeout) 02:34:16 --> EionRobb has joined #instantbird 02:47:26 --> mconley has joined #instantbird 02:55:17 <-- wnayes has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 04:07:32 <-- mconley has quit (Input/output error) 04:25:13 --> Mook has joined #instantbird 04:31:37 --> mayanktg has joined #instantbird 04:41:15 --> qheaden has joined #instantbird 04:42:45 <-- mayanktg has quit (Ping timeout) 04:43:18 --> mayanktg has joined #instantbird 05:07:13 <-- Rym has quit (Ping timeout) 05:08:33 <-- Mook has quit (Quit: Mook) 05:34:10 <-- mayanktg has quit (Ping timeout) 05:34:33 --> mayanktg has joined #instantbird 05:43:49 <-- EionRobb has quit (Quit: Leaving.) 05:53:50 <-- mayanktg has quit (Ping timeout) 05:58:18 --> gerard-majax_ has joined #instantbird 06:04:10 --> mayanktg has joined #instantbird 06:06:47 <-- mayanktg has quit (Ping timeout) 06:06:58 --> mayanktg has joined #instantbird 06:17:12 <-- mayanktg has quit (Ping timeout) 06:17:32 --> mayanktg has joined #instantbird 06:19:47 * Fallen|away is now known as Fallen 06:22:10 <-- gerard-majax_ has quit (Ping timeout) 06:38:09 --> gerard-majax_ has joined #instantbird 06:49:41 <-- gerard-majax_ has quit (Ping timeout) 06:56:20 * Fallen is now known as Fallen|away 07:29:24 --> jb has joined #instantbird 07:37:21 <-- mayanktg has quit (Ping timeout) 08:02:13 --> gerard-majax_ has joined #instantbird 08:13:43 <-- qheaden has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 08:21:16 --> aleth has joined #instantbird 08:21:16 * ChanServ sets mode +o aleth 08:27:37 --> mpmc has joined #instantbird 08:32:23 --> nhnt11 has joined #instantbird 08:36:33 <-- jb has quit (Ping timeout) 08:42:40 --> mayanktg-ph has joined #instantbird 08:47:07 --> jb has joined #instantbird 08:51:44 * Fallen|away is now known as Fallen 08:54:19 <-- chrisccoulson has quit (Quit: OSError: [Errno 130] Owner died) 08:55:07 --> chrisccoulson has joined #instantbird 09:02:54 --> Rym has joined #instantbird 09:05:30 <-- flo-retina has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 09:06:55 <-- mpmc has quit (Ping timeout) 09:07:32 --> mpmc has joined #instantbird 09:15:22 <-- mpmc has quit (Ping timeout) 09:15:41 --> mpmc has joined #instantbird 09:31:56 --> flo-retina has joined #instantbird 09:31:56 * ChanServ sets mode +qo flo-retina flo-retina 09:32:42 <flo-retina> Failed Windows nightly, and offline mac slave... really? :( 09:33:59 <flo-retina> the Windows failure says "mozbuild.base.ObjdirMismatchException: Objdir mismatch: d:\bb-slave\win32\obj-instantbird\mozilla != d:\bb-slave\win32\obj-instantbird" :-/ 09:34:51 <aleth> bah, not /another/ one of those :( 09:35:29 <flo-retina> "Hi Florian, It looks like someone logged into "XMPP Password Login"" Is Facebook really going to email me each time I connect to the XMPP gateway with a different IP? 09:35:37 <flo-retina> are they trying to scare everybody away from it? :( 09:36:17 <nhnt11> Well it's going to be discontinued soon, right? 09:36:29 <flo-retina> "soon" is sometimes in 2015 09:53:48 <aleth> purple is broken too :( 09:54:37 <aleth> Looks like bug 1028588 09:54:40 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1028588 nor, --, mozilla33, bjacob, RESO FIXED, Add dangerous public destructor detection to much of the rest of nsISupportsImpl.h (still not coveri 09:55:26 <aleth> purplexpcom/src/purpleDebug.cpp:32:1: error: static_assert failed "Reference-counted class purpleDebug should not have a public destructor. Try to make this class's destructor non-public. If that is really not possible, you can whitelist this class by providing a HasDangerousPublicDestructor specialization for it." 09:55:31 --> Armada has joined #instantbird 09:56:23 <aleth> At least that's not totally mysterious like the universal build thing... 10:04:35 <flo-retina> aleth: I'm not too worried about that error, it likely just needs fixing :) 10:04:44 <flo-retina> is this the only broken file, or are there more? 10:04:49 <flo-retina> (you can make -k in the purplexpcom/src folder) 10:07:09 <aleth> Looks like the only on 10:08:03 <-- jb has quit (Ping timeout) 10:08:34 --> BWMerlin has joined #instantbird 10:19:31 <-- mpmc has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 10:32:21 --> arlolra has joined #instantbird 10:49:21 <-- Rym has quit (Ping timeout) 10:57:50 <aleth> Ah, once you fix one, all the others show up :) 10:58:14 <flo-retina> have you tried |make -k|? 11:00:34 <aleth> Yes 11:04:53 <-- aleth has quit (Ping timeout) 11:09:26 --> aleth has joined #instantbird 11:09:27 * ChanServ sets mode +o aleth 11:20:18 * Fallen is now known as Fallen|away 11:22:46 <-- gerard-majax_ has quit (Client exited) 11:27:26 --> gerard-majax has joined #instantbird 11:42:42 <instantbot> New Chat Core - General bug 1036367 filed by aleth@instantbird.org. 11:42:43 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1036367 nor, --, ---, aleth, ASSI, Fix dangerous public destructors in purple/ 11:44:39 <-- gerard-majax has quit (Ping timeout) 11:52:52 <-- mayanktg-ph has quit (Quit: Connection closed for inactivity) 12:04:49 * Fallen|away is now known as Fallen 12:05:35 <-- BWMerlin has quit (Quit: BWMerlin) 12:07:58 --> mayanktg-ph has joined #instantbird 12:10:01 --> Rym has joined #instantbird 12:16:56 --> mayanktg has joined #instantbird 12:20:17 --> gerard-majax has joined #instantbird 12:36:14 <-- arlolra has quit (Quit: arlolra) 12:38:57 <mayanktg> aleth: Hello. I have a stupid question. How can I change the value of availabilityDetails inside the xmpp.jsm file? I'm using http://pastebin.instantbird.com/748322 Line 11 to change the integer but when I dump |this._conv.buddy.availabilityDetails| in the conversation binding it gives the output "0". I know this isn't the correct way :-/ 12:42:51 <-- Armada has quit (Connection reset by peer) 12:43:48 <aleth> Line 11 makes no sense. 12:44:00 <aleth> You don't want to change the prototype for all accountbuddies ;) 12:44:05 --> Armada has joined #instantbird 12:44:22 <aleth> You want to set it for that particular buddy. 12:45:20 <mayanktg> Yepp...How can I set it for a particular buddy? :-o 12:45:22 <aleth> I don't understand line 10, isn't this.to a string? 12:45:41 <aleth> What's entitiesNode.buddy? 12:47:35 <mayanktg> I'm storing fullJID and bitmask in the _buddyEntities and when the conversation binding asks for the entity list it checks for the availability of the entities for that particular buddy. 12:48:16 <aleth> mayanktg: Do you know where the account buddies for an account are stored? 12:48:47 <mayanktg> No. Let me find out. 12:48:52 <aleth> If you don't understand how account buddies work, your *really* should ask much more questions before trying to write any code. 12:48:55 <flo-retina> mayanktg: This pastebin really lacks context; please provide a diff instead next time. 12:49:19 <aleth> How do you expect to be able to write code that works if you don't understand where the buddies are? 12:49:29 --> jb has joined #instantbird 12:50:34 <aleth> You have to understand how the existing code around accountbuddies works before you add to it... 12:50:40 <mayanktg> flo-retina: I'm sharing the complete diff. Wait a min. 13:02:07 <mayanktg> Here is the complete diff http://pastebin.instantbird.com/748345 . How should I store the availabilityDetails for a particular buddy? I won't be needing buddyEntities then. 13:04:49 <aleth> You store them in the availabilityDetails property of the account buddy. 13:05:22 <aleth> That's what you're accessing with this._conv.buddy.availabilityDetails, after all. 13:06:09 <aleth> You're right, you don't need that buddyEntities. 13:07:34 * Fallen is now known as Fallen|away 13:08:21 <mayanktg> Ok. And How will I be able to edit the availabilityDetails property for the particular buddy? I'll have to do it inside the onIQStanza() i.e. at Line 364 of the diff. 13:08:41 * mayanktg takes a look again over availabilityDetails... 13:09:05 <aleth> What you need to look at is how account buddies work! 13:10:38 <aleth> You get presence information for each roster item, right? 13:10:49 <mayanktg> Right. 13:10:55 <aleth> And each roster item corresponds to an accountbuddy. 13:11:26 <mayanktg> Yepp! 13:11:38 <aleth> So look at the code that passes the presence info to the accountbuddy. 13:11:55 <aleth> Understand how that works before you do any more coding. 13:12:17 <aleth> You can ask questions about the existing code you know, what it does, how it works... ;) 13:12:26 <aleth> Just use mxr to point at lines. 13:12:53 <mayanktg> aleth: Ok. I'm looking at it ..Yes, I'll ask if I have doubts. :) 13:14:37 <aleth> Once you understand that, then you can use http://mxr.mozilla.org/comm-central/source/chat/modules/jsProtoHelper.jsm#352 13:17:57 <-- mayanktg has quit (Ping timeout) 13:19:01 --> mayanktg has joined #instantbird 13:22:30 <-- mayanktg has quit (Ping timeout) 13:23:18 --> mayanktg has joined #instantbird 13:26:08 --> arlolra has joined #instantbird 13:37:21 --> clokep_work has joined #instantbird 13:37:21 * ChanServ sets mode +o clokep_work 13:38:59 <-- mayanktg has quit (Ping timeout) 13:39:10 --> mayanktg has joined #instantbird 13:41:39 <-- aleth has quit (Ping timeout) 13:41:49 --> aleth has joined #instantbird 13:41:49 * ChanServ sets mode +o aleth 13:46:41 <clokep_work> aleth: Thanks for taking a look at that. 14:03:27 <-- Rym has quit (Ping timeout) 14:06:00 --> mconley has joined #instantbird 14:06:43 <-- clokep_work has quit (Ping timeout) 14:07:21 --> Rym has joined #instantbird 14:15:36 <-- aleth has quit (Ping timeout) 14:32:15 <-- mayanktg has quit (Ping timeout) 14:35:32 --> aleth has joined #instantbird 14:35:33 * ChanServ sets mode +o aleth 14:39:26 <-- flo-retina has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 14:55:38 --> iamjayakumars has joined #instantbird 14:59:17 <-- arlolra has quit (Quit: arlolra) 15:01:47 --> flo-retina has joined #instantbird 15:01:47 * ChanServ sets mode +qo flo-retina flo-retina 15:04:57 --> mayanktg has joined #instantbird 15:07:46 <-- mayanktg-ph has quit (Quit: ) 15:10:04 <aleth> mayanktg: How's it going? 15:15:17 <mayanktg> aleth: I just returned from dinner. Until then I have seen that on receiving a presence stanza different attributes like statusType, statusText, priority etc are retrieved and then stored in the this._resource. http://mxr.mozilla.org/comm-central/source/chat/protocols/xmpp/xmpp.jsm#481 15:16:18 <aleth> Did you see how that function of the buddy is called? 15:18:50 <mayanktg> You mean using |this._buddies[jid].onPresenceStanza(aStanza)| http://mxr.mozilla.org/comm-central/source/chat/protocols/xmpp/xmpp.jsm#849 ?? 15:18:54 <aleth> Yes 15:19:44 <aleth> So do you understand better what to do now? 15:21:30 <aleth> And where to put your capabilities code? 15:22:15 <mayanktg> Oh! Yes.I will need to move my capabilitues code to http://mxr.mozilla.org/comm-central/source/chat/protocols/xmpp/xmpp.jsm#831 15:22:54 <mayanktg> *capabilities 15:23:44 <aleth> Why? Isn't capabilities info received only for buddies? 15:25:21 <mayanktg> Whenever I receive a presence stanza of the buddy which contains the <c/> node the capabilities code is evaluated. 15:25:34 <aleth> Then you should handle it in accountbuddy methods, not account methods. 15:25:35 --> flo-thinkpad has joined #instantbird 15:26:08 <mayanktg> Ok. 15:26:19 <aleth> http://mxr.mozilla.org/comm-central/source/chat/protocols/xmpp/xmpp.jsm#480 15:26:51 <mayanktg> That's where I was using the capability code earlier. 15:27:01 <aleth> OK, then it's in the right place. 15:27:38 <aleth> But then it's already a method of the account buddy, so why did you have a problem with getting the buddy? It's just 'this' 15:28:48 --> rosonline has joined #instantbird 15:29:04 <aleth> I'm not sure what you're confused about, you're going to have to tell us ;) 15:29:17 <mayanktg> Wait.. 15:29:36 <-- jb has quit (Ping timeout) 15:31:29 <mayanktg> No. The availabilityDetails is used at the function onIqStanza() http://mxr.mozilla.org/comm-central/source/chat/protocols/xmpp/xmpp.jsm#806 because at this place I receive the service discovery IQ Query Stanza for the buddy. http://pastebin.instantbird.com/748345 Line 337. 15:31:44 <mayanktg> And its in XMPPAccountPrototype :-/ 15:33:30 <aleth> So you will have to do something like the account onPresenceStanza method, and call an onIQStanza method on the right account buddy http://mxr.mozilla.org/comm-central/source/chat/protocols/xmpp/xmpp.jsm#848 15:34:00 <aleth> And then you can handle it on the buddy. 15:35:42 <aleth> Oh wait. 15:35:44 <mayanktg> Ok. I'm trying it out. 15:35:52 <aleth> Isn't the IQ stanza something you receive on demand? 15:36:40 <mayanktg> Yes, I receive it when I send a service dicovery request IQ Stanza. 15:37:24 <aleth> But when you send the request, you include an unique id, right? 15:37:47 <aleth> So when the response arrives, it should be handled here I think http://mxr.mozilla.org/comm-central/source/chat/protocols/xmpp/xmpp-session.jsm#500 15:38:33 <aleth> i.e. when you send the stanza, *you include a callback which is automatically called when the response arrives* 15:38:52 <aleth> Didn't you read the comment here? exec 15:39:11 <aleth> http://mxr.mozilla.org/comm-central/source/chat/protocols/xmpp/xmpp-session.jsm#104 15:40:07 <mayanktg> Ok. The unique id is automatically generated i.e. its 6,7,8.. 15:40:11 <aleth> So just pass a method of the accountbuddy as the callback. 15:40:51 <aleth> You can see that the callback is added as a handler here http://mxr.mozilla.org/comm-central/source/chat/protocols/xmpp/xmpp-session.jsm#111 and then execHandler calls it when the stanza is received 15:43:26 <mayanktg> Yepp... So after adding the callback the onIQStanza would be automatically called and then I can easily get the buddy and set the availabilityDetails. Right? 15:44:14 <aleth> It's the callback that gets called by the existing onIQStanza code, but yeah. 15:45:09 <aleth> The whole point of the callback mechanism is that it's easy that way to get the response passed to the right buddy, since it's the buddy that sends the request! 15:51:11 <-- nhnt11 has quit (Ping timeout) 15:51:23 --> nhnt11 has joined #instantbird 15:51:30 <mayanktg> Could you summarize what steps I will need to perform.? 15:51:30 <mayanktg> As far as I understand I will need to change it like this: Send service discovery request stanza alongwith callback as onIQStanza() --> Evaluate the received query stanza --> store the availabilityDetails for the particular buddy. 15:51:54 <aleth> what do you mean by "as onIQStanza"? 15:52:33 <aleth> Do you mean that that's going to be the name of your callback? 15:54:16 <mayanktg> No. I was wrong there. I will need to move the http://pastebin.instantbird.com/748345 Line 337 to a separate function and then use it as a callback. Right? 15:55:09 <aleth> Yes. You need to use the second and third argument of http://mxr.mozilla.org/comm-central/source/chat/protocols/xmpp/xmpp-session.jsm#104 to do that. 15:56:02 <aleth> The function should be a method of the buddy, obviously (maybe call it onCapabilityStanza or something like that) 15:56:57 <mayanktg> Ok. What should be the third argument here i.e aObject? 15:57:31 <-- nhnt11 has quit (Ping timeout) 15:57:33 <aleth> It should be the buddy object 15:57:52 <aleth> That makes sure that "this" is set correctly when the callback is called. 15:58:32 <mayanktg> Ok. got it :) 15:58:32 <mayanktg> I'm making the changes then.. 15:58:36 --> nhnt11 has joined #instantbird 15:59:49 --> arlolra has joined #instantbird 16:04:19 <-- gerard-majax has quit (Ping timeout) 16:08:49 <-- Rym has quit (Ping timeout) 16:24:28 --> Rym has joined #instantbird 16:34:57 <flo-retina> aleth: how confident are you in that nsCOMArray change? 16:35:16 <flo-retina> (by code inspection it looks fine, but I'm wondering if you have verified that the purpleTimer destructor is actually called when we expect) 16:36:12 <-- aleth has quit (Ping timeout) 16:41:06 <-- rosonline has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com) 16:43:18 --> ianes has joined #instantbird 16:44:07 <ianes> hello, I was wondering if anyone can tell me where exactly I can acces the Log Viewer in Instantbird 16:47:48 --> Mook_as has joined #instantbird 16:53:29 --> aleth has joined #instantbird 16:53:29 * ChanServ sets mode +o aleth 16:54:31 <aleth> flo-retina: I've not verified it, I'm only "it builds and it doesn't look insane" confident. 16:54:52 <flo-retina> would be nice to check that you can connect an account, and then shutdown without crash 16:55:00 --> mpmc has joined #instantbird 16:55:04 <flo-retina> I meant a libpurple account of course 16:56:15 <aleth> ianes: Previous conversations are listed to the right of the conversation in TB, you can click on them to view the log. Alternatively, use the search function to search your logs 16:58:28 <aleth> flo-retina: That does work. 16:58:42 <ianes> Ah, I just noticed you can right-click on a tab and there's "Show Logs" option 16:59:05 <-- ianes has quit (Quit: http://www.mibbit.com ajax IRC Client) 16:59:19 <aleth> ianes: Oh sorry, I thought you were asking about Thunderbird for some strange reason 16:59:19 <arlolra> flo-retina: I'm around if you want me to clarify anything about what I'm trying to say. 16:59:45 <flo-retina> I have a meeting starting nowish 17:00:19 <arlolra> no problem 17:00:28 <-- iamjayakumars has quit (Quit: ) 17:00:59 <arlolra> I'll be here for a while 17:15:30 <-- Rym has quit (Ping timeout) 17:15:54 <-- aleth has quit (Ping timeout) 17:25:47 --> jb has joined #instantbird 17:37:10 <-- Tonnes has quit (Input/output error) 17:45:52 <mayanktg> aleth: What should be the buddy object? :'( What's wrong in Line 241 http://pastebin.instantbird.com/748399 :-| 17:51:36 * Fallen|away is now known as Fallen 18:10:55 <flo-retina> mayanktg: what's your question exactly? 18:11:25 <flo-retina> I see nothing related to a "buddy" near line 241 18:12:28 <mayanktg> flo-retina: I'm sending a stanza alongwith a callback. I need to know what should be the third argument in the line 241. 18:12:32 <mayanktg> ... 18:12:47 <flo-retina> ok. What's your plan to decide that? :) 18:14:44 <mayanktg> flo-retina: aleth said I would need a buddy object as the third argument so that "this" is set correctly when callback is called. I'm unable to figure out how should I create that buddy object :( 18:15:16 <flo-retina> ok, what have you tried to "figure out how should I create that buddy object"? 18:16:43 <-- jb has quit (Ping timeout) 18:16:45 <mayanktg> In http://mxr.mozilla.org/comm-central/source/chat/protocols/xmpp/xmpp.jsm#1059 a buddy is created but I'm not sure if this is the thing I would be needing here. I tried using "this" as the third argument. No help :-/ 18:17:57 <flo-retina> does it look like "this" is a buddy? O_o 18:18:26 <mayanktg> Thre are other places where such sendStanza are used, for example http://mxr.mozilla.org/comm-central/source/chat/protocols/xmpp/xmpp.jsm#1101 but they are in the XMPPAccountPrototype and are using this._connection.... 18:18:28 <mayanktg> No. 18:24:23 * mayanktg tries to find out more about creating a buddy object... 18:25:25 --> aleth has joined #instantbird 18:25:25 * ChanServ sets mode +o aleth 18:26:11 <aleth> mayanktg: Why do you want to create a buddy object? The buddies already exist. 18:27:24 <aleth> Line 241 in your pastebin looks right to me. 18:27:24 <mayanktg> aleth: Then? Why isn't the this.onServiceDiscoveryStanza() getting evaluated? :-| 18:28:14 <aleth> Is your stanza being sent? 18:28:21 <mayanktg> Then there must be something wrong in my onServiceDiscovery() :-/ 18:28:53 <mayanktg> Yes. And I'm also receiving the response stanza from the buddy 18:29:31 <aleth> So just add dump()s to onIQStanza and the functions it calls to see where things don't do what you expect. 18:30:09 <aleth> Or are there any errors in the error console? 18:31:00 <mayanktg> There were no error in the error console... I've added dumps in the onServiceDsiconveryStanza() ...wait I'm checking for onIQStanza too. 18:34:49 <aleth> You want to find out why it's not getting called. 18:34:59 <aleth> (your callback, that is) 18:37:15 <instantbot> aleth@instantbird.org changed the Resolution on bug 1036367 from --- to FIXED. 18:37:17 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1036367 nor, --, ---, aleth, RESO FIXED, Fix dangerous public destructors in purple/ 18:38:54 <mayanktg> On adding dumps I see that the stanza is received at the onIQStanza() but the callback isn't called. 18:40:24 <aleth> If you put a dump() in execHandler, does it get called for the id of the sent message? 18:42:05 <aleth> There's no way to figure this out other than to dig into the details of what actually happens until it becomes obvious ;) 18:42:57 <mayanktg> I added dump at http://mxr.mozilla.org/comm-central/source/chat/protocols/xmpp/xmpp-session.jsm#125 and it is being called for the given id. 18:43:42 <aleth> So what happens in line 128 where the handler is called? 18:44:51 <aleth> You could dump(this._handlers[aId]) to see if it's a function etc. 18:49:21 <aleth> flo-retina: What's the difference between the comm-aurora and release-comm-aurora bundles here http://ftp.mozilla.org/pub/mozilla.org/thunderbird/bundles/? I thought there wasn't a hg.mozilla.org/comm-aurora, and releases/comm-aurora *was* the aurora repo? 18:50:09 <flo-retina> aleth: look at the modification date of these files 18:50:32 <aleth> aha! thanks! :D 18:52:41 <mayanktg> aleth: Ohhh...On adding Cu.reportError(aId) just below the this._handlers[aID](aStanza) line should return the ID of the service discovery stanza received. Well I'm not receiving one. It means execHandler returns false! 18:53:21 <aleth> mayanktg: See... that's progress! 18:53:28 --> clokep_work has joined #instantbird 18:53:28 * ChanServ sets mode +o clokep_work 18:54:10 <aleth> Put some dumps in sendStanza and addHandler to see what id is actually set and where. 18:54:30 <mayanktg> Ok. 18:55:19 <aleth> flo-retina: I take it there's no better way to uplift than to export the patch from c-c and import it into c-a and then pushing? 18:55:42 <flo-retina> that's what I do 18:56:03 <flo-retina> I've heard there's an |hg transplant| mercurial extension that's helpful for that 18:56:22 <flo-retina> but just importing the patch isn't too bad 18:56:54 <aleth> But what happens on the next merge when the same patch exists in the merge changeset? 18:57:10 <aleth> Uh, sorry, ignore that 18:57:25 <clokep_work> Doesn't Mark usually do those checkins himself? 18:57:46 <aleth> clokep_work: Idk, but he didn't in this case 18:58:00 * clokep_work wonders if the tree is open. . . 18:59:18 <clokep_work> sawrubh: ping 19:00:27 <aleth> clokep_work: Did you have any luck yesterday with the mac universal builds? 19:00:35 <clokep_work> aleth: No. 19:00:40 <clokep_work> I didn't try too hard though. 19:01:16 --> Tonnes has joined #instantbird 19:02:22 <flo-retina> no commit link in that purplexpcom bug? :-/ 19:03:30 <aleth> umm... oh, I see why I forgot. hg push didn't provide one 19:10:02 <-- chrisccoulson has quit (Quit: OSError: [Errno 130] Owner died) 19:12:56 <aleth> mayanktg: what did you discover? 19:13:22 --> chrisccoulson has joined #instantbird 19:14:37 * clokep_work has to read that OTR bug. 19:14:53 <mayanktg> The sendStanza is not taking the callback as the second argument. The callback is evaluated for vCard and others but not for the onServiceDiscoveryStanza :-| 19:14:58 <mayanktg> aleth: ^ 19:16:22 <aleth> When you say "it's not taking the argument", what does that mean exactly? Your sendstanza call has a second argument, so you can dump it in sendStanza and see what happens to it. 19:24:29 <aleth> mayanktg: Which function are you looking at? 19:24:40 <mayanktg> See. I got the onServiceDiscoveryStanza() on adding |this._account.sendStanza(s, Cu.reportError(this.onServiceDiscoveryStanza), this);| but on the sendStanza part I'm unable to get the aCallback argument. 19:24:56 <mayanktg> aleth: http://mxr.mozilla.org/comm-central/source/chat/protocols/xmpp/xmpp-session.jsm#108 19:25:02 <aleth> Show me the code for this._account.sendStanza 19:25:10 <mayanktg> Ok. 19:25:22 <aleth> It's got to be a method on the account, not a method in xmpp-session ;) 19:25:30 <aleth> Since you use this._account... 19:27:30 <aleth> flo-retina: Why is the target milestone 33 if it's going to be in 31? 19:27:34 <mayanktg> Ehh... 19:27:45 <mayanktg> http://pastebin.instantbird.com/748424 Here's the diff btw. 19:28:09 <aleth> mayanktg: I didn't mean the diff, I meant on mxr. 19:28:35 <clokep_work> aleth: "target milestone" is where it lands on c-c. 19:28:45 <aleth> clokep_work: aha, thanks. 19:29:36 <aleth> mayanktg: Where are *all* the methods of this._account? 19:33:18 <aleth> mayanktg: This shouldn't be difficult. 19:33:25 <mayanktg> aleth: Hmm..They are in the XMPPAccountPrototype. 19:33:31 <aleth> Yes! 19:33:44 <aleth> So show me the sendStanza method you are actually calling. 19:34:12 <mayanktg> http://mxr.mozilla.org/comm-central/source/chat/protocols/xmpp/xmpp.jsm#1138 19:34:33 <aleth> The methods are in the XMPPAccountPrototype because when you make a new account object with let account = new XMPPAccount(...) it inherits from the prototype. 19:35:23 <aleth> mayanktg: OK, so it looks like after all this debugging you've found the origin of the problem, right? 19:36:29 <aleth> That function is not passing on the second and third argument. 19:37:50 <mayanktg> aleth: Yes. because the sendStanza only takes one argument i.e. aStanza :-( 19:38:03 <aleth> Yes, so you will have to fix that bug ;) 19:38:26 <mayanktg> Yes! 19:38:53 <aleth> That took a bit of digging to discover, but I hope you've learnt a bit about how to diagnose such problems along the way ;) 19:39:08 <clokep_work> aleth: Thanks for the review. 19:39:29 <aleth> clokep_work: What did I review? 19:39:39 <clokep_work> aleth: bug 1018771 19:39:42 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1018771 min, --, ---, clokep, ASSI, Use Maps and Sets in XMPP code 19:40:13 <aleth> Oh right! 19:40:51 <clokep_work> aleth: What do you mean by "I think you should also set muc.left = true here, *or better, override the left = false default value from jsProtoHelper* ."? 19:42:11 <aleth> I mean you could do this http://mxr.mozilla.org/comm-central/source/chat/protocols/irc/irc.js#278 19:43:02 <clokep_work> aleth: OK. :) 19:43:09 * clokep_work wonders if that should just be false in jsProtoHelper? 19:44:08 <aleth> false is correct for the "default behaviour" of only creating the MUC object after joining is complete 19:44:22 <mayanktg> aleth: Yes exactly! Done! :) Thanks a ton :) :) 19:44:37 <clokep_work> aleth: True. :) 19:44:55 <mayanktg> Now I need to set the availabilityDetails... 19:44:57 <aleth> mayanktg: Does it work now then? :) 19:45:31 <clokep_work> What's the plan for htis availabilityDetails stuff btw? 19:45:47 <mayanktg> aleth: Yes. The ver attribute is getting created and bitmask is also generated :) 19:46:51 <aleth> mayanktg: Then it's easy, just look at what's already there for availabilityDetails in jsProtohelper and use that 19:48:40 <aleth> Don't forget to send a notification too ("account-buddy-availability-changed") 19:49:10 <mayanktg> clokep_work: We are using availabilityDetails http://mxr.mozilla.org/comm-central/source/chat/components/public/imIStatusInfo.idl#41 to set a bitmask of the available entities. Thus when availabilityDetails is when called at conversation binding we can then use it to generate and object of the supported entity. 19:49:40 --> Rym has joined #instantbird 19:49:43 <clokep_work> mayanktg: "Thus when availabilityDetails is when called at conversation binding we can then use it to generate and object of the supported entity." doesn't make sense to me. 19:50:31 <aleth> Looks like some typos crept in ;) 19:50:33 <mayanktg> *generate an object 19:50:54 <mayanktg> yepp.. 19:51:54 <clokep_work> mayanktg: That wasn't the part of the sentence I didn't understand 19:52:00 <clokep_work> "is when called at conversation binding"? 19:52:54 <clokep_work> aleth: "Not sure what the muc.left test is trying to do here? Needs a better comment at least." I don't know what the muc.left check is for. I assume that if you're in the room and get an error something else happened. 19:53:17 <-- Rym has quit (Ping timeout) 19:53:32 <aleth> I guess so, I jsut thought you might know more. 19:53:42 <aleth> Never mind then 19:54:02 <clokep_work> I don't, sorry. :-\ 19:54:15 <clokep_work> aleth: Would you like me to add a comment saying that or? 19:54:17 <mayanktg> We are using in the converation binding as |this._conv.buddy.availabilityDetails| 19:54:49 <clokep_work> You're using the conversation binding as that? I'm afraid that makes no sense to em. :-\ 19:54:50 <clokep_work> me 19:55:10 <clokep_work> If you're doing a bitmask though, please make sure to define constants. 19:57:10 <mayanktg> Ok. I'll take care of that. :) 19:57:45 --> Rym has joined #instantbird 19:59:32 <aleth> clokep_work: No, just leave it without a comment then 19:59:50 <clokep_work> aleth: Thanks. Let me test this stuff. :) 20:00:36 <flo-retina> nhnt11: hey, what's up? :) 20:00:47 <nhnt11> flo-retina: Hello 20:00:49 <-- Rym has quit (Connection reset by peer) 20:00:59 <nhnt11> I'm working on the indexing stuff 20:01:02 <nhnt11> Log sets! 20:01:13 <flo-retina> ah! 20:01:18 * flo-retina pretends to remember what that is 20:01:23 <flo-retina> (I have a vague idea though :)) 20:01:56 <flo-retina> everything going as you expect there? 20:01:59 --> Rym has joined #instantbird 20:02:21 <nhnt11> Yeah, I'll likely have a few questions soon but all is well at the moment 20:04:47 <-- aleth has quit (Ping timeout) 20:05:35 <-- Rym has quit (Ping timeout) 20:06:20 --> aleth has joined #instantbird 20:06:20 * ChanServ sets mode +o aleth 20:12:40 <aleth> I don't understand what could have broken the Windows nightlies since yesterday :-/ 20:12:59 --> EionRobb has joined #instantbird 20:14:57 <-- EionRobb has quit (Connection reset by peer) 20:15:40 --> EionRobb has joined #instantbird 20:32:43 <clokep_work> aleth: https://bugzilla.mozilla.org/attachment.cgi?id=8453304&action=edit 20:33:41 <flo-retina> clokep_work: I r+'ed it 20:33:47 <clokep_work> Thanks. :) 20:34:09 <aleth> Thanks! I wonder why that one didn't show up for me 20:34:26 <flo-retina> clokep_work: it's _dynamic_ prpls that you fixed though ;) 20:34:33 <clokep_work> Oops. 20:34:35 <clokep_work> You're right. :) 20:34:46 <flo-retina> aleth: you are not building a debug build 20:34:57 <aleth> duh, right. 20:36:04 <clokep_work> :) 20:36:08 <aleth> Ah, got it! 20:36:41 <aleth> Bug 1035099 is likely what broke the Windows nightly today 20:36:44 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1035099 nor, --, mozilla33, mh+mozilla, RESO FIXED, Remove the comm-central workarounds from MozbuildObject.from_environment 20:37:25 <aleth> At least it's the only thing that looks related. 20:38:21 <flo-retina> so you all are betting on mach? 20:39:04 <aleth> flo-retina: http://buildbot.instantbird.org/builders/win32-nightly-default/builds/1432/steps/compile/logs/stdio pretty much points at that change 20:40:28 <flo-retina> so do you all think we should try using mach on buildbot? 20:41:22 <aleth> For Mac maybe (if universal builds work with mach as clokep_work seemed to say) 20:41:30 <aleth> For Windows idk if it would help 20:42:39 <flo-retina> there's | command=[bssh.WithProperties('%(python)s'), './mozilla/mach', 'build'], | commented out in the buildbot config file 20:42:42 <flo-retina> I wonder why :-S 20:42:48 <flo-retina> have we tried that before and failed? 20:42:55 <clokep_work> aleth: It works as far as I know. But obviously my set up isn't identical. 20:43:19 <flo-retina> clokep_work: well, could you reproduce the bug when using gmake? 20:43:38 <clokep_work> I didn't try, unfortunately. :-\ 20:43:39 <aleth> mayanktg: How's it going? 20:44:44 --> instant-buildbot has joined #instantbird 20:44:44 * ChanServ sets mode +v instant-buildbot 20:44:56 <flo-retina> ah, at least restarting buildbot gave us the bot back! :-D 20:45:04 <aleth> :D 20:45:29 * flo-retina forced a nightly on each of these 2 OSes 20:46:36 <-- Tonnes has quit (Connection reset by peer) 20:46:40 <mayanktg> aleth: Not good :-/ I'm unable to figure out even how to set the value to availabilityDetails. 20:47:02 <instant-buildbot> build #1433 of win32-nightly-default is complete: Failure [4failed compile] Build details are at http://buildbot.instantbird.org/builders/win32-nightly-default/builds/1433 20:47:11 <aleth> well, that didn't take long :P 20:47:29 <aleth> mayanktg: http://mxr.mozilla.org/comm-central/source/chat/modules/jsProtoHelper.jsm#352 20:47:57 <mayanktg> aleth: Yes I've seen that. 20:48:07 <aleth> mayanktg: So what's the problem? 20:48:48 <aleth> Do you know what the get there means? 20:49:47 <mayanktg> No. I don't know. 20:50:01 <aleth> Why don't you ask then? :-S 20:50:02 <flo-retina> " 0:05.05 --with-unify-dist=../x86_64/dist" 20:50:05 <flo-retina> clearly, mach didn't help :( 20:51:39 <aleth> mayanktg: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Working_with_Objects#Defining_getters_and_setters 20:51:42 <mayanktg> aleth: Sorry. I looked at other implementations like statusType etc but couldn't figure it out. I should have asked. :-| 20:52:01 <aleth> availabilityDetails is defined as read-only in the interface. So there is only a getter for it here, and no setter. 20:52:03 <-- instant-buildbot has quit (Input/output error) 20:52:04 --> instant-buildbot has joined #instantbird 20:52:04 * ChanServ sets mode +v instant-buildbot 20:52:30 <aleth> Look at that page to understand how they work. 20:54:47 --> nhnt11-testing has joined #instantbird 20:54:56 <-- nhnt11-testing has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 20:55:33 <flo-retina> aleth: do you think the mac problem could be because we are exporting MOZ_OBJDIR rather than setting it in the mozconfig? 20:55:51 <clokep_work> Is https://bugzilla.mozilla.org/show_bug.cgi?id=1036619 going to bust us too? 20:55:54 <instantbot> Bug 1036619 nor, --, ---, nobody, NEW, Implement 1035394 - Add dangerous public destructor detection to _INHERITED refcounting macros in co 20:56:00 <aleth> clokep_work: no, fixed already. 20:56:01 --> nhnt11-testing has joined #instantbird 20:57:07 <-- nhnt11-testing has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 20:57:27 <instant-buildbot> build #2243 of macosx-nightly-default is complete: Failure [4failed compile] Build details are at http://buildbot.instantbird.org/builders/macosx-nightly-default/builds/2243 20:57:42 <clokep_work> aleth: Alright. Just to be clear that /is/ a different bug. ;) 20:58:03 <aleth> Yes, but I checked for it too. 20:58:07 <aleth> Thanks anyway 20:58:44 <aleth> flo-retina: Is that something we do that TB doesn't do? 20:59:39 <flo-retina> maybe 20:59:54 <flo-retina> I'm just trying to think about what could be different on buildbot compared to clokep's local build 21:05:29 <aleth> mayanktg: are things clearer now? 21:05:47 <aleth> Do you understand how the code in jsprotohelper I pointed to works? 21:06:04 <flo-retina> clokep_work: I don't see anything enabling ccache in our mac mozconfig 21:06:38 <clokep_work> flo-retina: http://dxr.mozilla.org/comm-central/source/build/mozconfig.cache gets included at some point. 21:07:35 <flo-retina> hmm 21:09:10 <flo-retina> bah, locally I get --with-unify-dist=../x86_64/mozilla/dist 21:09:19 <flo-retina> and that's with the exact mozconfig used for buildbot 21:09:24 <flo-retina> and with the objdir exported 21:09:59 <aleth> I wonder if the Windows build would work locally as well. 21:10:10 <aleth> Similar path issue, after all. 21:11:02 <clokep_work> I unfortunately can't test Windows right now. :-\ 21:11:20 <mayanktg> aleth: Yes. The code gets the value of availabilityDetails in the availabilityDetails() . But since it is a readonly integer I'm unable to get how can I modify its value. 21:12:18 <aleth> mayanktg: Well, where does the getter get the value from in http://mxr.mozilla.org/comm-central/source/chat/modules/jsProtoHelper.jsm#353? 21:13:27 <mayanktg> Just the line above it |_availabilityDetails: 0| ? 21:14:34 <aleth> mayanktg: Right, and that's just a normal property, isn't it? 21:14:49 <aleth> 0 is just a default value. 21:15:01 <aleth> So you can set it to whatever you like :P 21:15:17 <mayanktg> Yes. So I can change its value using a setter.! 21:15:30 <aleth> noooo 21:15:43 <flo-retina> any idea for what I should try next? 21:15:53 <aleth> flo-retina: It's a *normal property*, you don't need a setter to set them, do you? 21:15:57 <flo-retina> my local test in the exact same conditions as the mac builder work :( 21:16:06 <aleth> ah, that was for mayanktg ^^ 21:16:25 <aleth> flo-retina: Dump the environment maybe? 21:16:33 <flo-retina> the local one? 21:16:39 <aleth> Both 21:16:49 <aleth> Something somewhere must be different :-S 21:16:49 <flo-retina> the buildbot one is visible in the logs 21:17:32 <mayanktg> aleth: Ahhh..Just set the _availabitlityDetails to the value of the entities. 21:17:51 <aleth> mayanktg: :) 21:25:15 <clokep_work> flo-retina: I can't think of other things to try. :-\ 21:25:27 <mayanktg> aleth: This is what I was doing earlier :'( I was using |GenericAccountBuddyPrototype.availabilityDeetails = entities| which changed the availabilityDetails. But when I called the |this._conv.buddy.availabilityDetails| at the "initConversationUI" method of the binding the value was again 0. :-| 21:26:12 <aleth> mayanktg: Changing the prototype would definitely not help you at all, apart from being instant r- ;) 21:27:37 <aleth> mayanktg: So does it work now? 21:27:58 <flo-retina> aleth: my local environment is http://pastebin.instantbird.com/748457 21:28:19 <flo-retina> the buildbot one is visible at http://buildbot.instantbird.org/builders/macosx-nightly-default/builds/2243/steps/compile/logs/stdio 21:29:04 <-- arlolra has quit (Quit: arlolra) 21:32:49 <clokep_work> flo-retina: How did you use the proper mozconfig? 21:35:13 <mayanktg> aleth: So I'm simply using |this.availabilityDetails = video | audio | fileTransfer| but I still receive a 0 at the binding :-/ 21:35:50 <aleth> There's a missing _ :P 21:37:04 <mayanktg> Not good day to code today :-/ ... It worked btw! :D 21:38:17 <aleth> Well, you're getting there :) 21:38:22 <aleth> Don't forget to send a notification too and listen for it in the conversation binding, in case the value changes. 21:38:31 <mayanktg> Adding a notifyobserver for the account-buddy-availability-changed. 21:38:43 <aleth> Yup. 21:40:31 <flo-retina> cp im/config/mozconfigs/macosx/mozconfig mozconfig-nightly 21:40:31 <flo-retina> MOZCONFIG=$(pwd)/mozconfig-nightly MOZ_OBJDIR=$(pwd)/nightly-obj make -f client.mk configure 21:40:40 <clokep_work> aleth: Thanks. 21:41:01 <flo-retina> wow! 21:41:04 <flo-retina> I found the issue 21:41:30 <clokep_work> Bleh copying that directly to my terminal exploded things since I had lots of dates, etc. I wonder if that's a use case we care to support... 21:41:31 <flo-retina> If I set the objdir to $(pwd)/../nightly-obj instead of $(pwd)/nightly-obj I can reproduce the bug 21:41:33 <clokep_work> flo-retina: !!! What is it? 21:41:38 <aleth> really? :) 21:41:46 <clokep_work> Oh! 21:41:48 <clokep_work> Wait... 21:42:00 <flo-retina> that doesn't give me a fix though :-S 21:42:01 <clokep_work> I don't think you can build outside of the srcdir anymore, I think it *HAS* to be a sub-folder? 21:42:15 <flo-retina> clokep_work: why? 21:42:30 <flo-retina> clokep_work: it works fine for non-universal builds 21:42:40 <clokep_work> Oh hm....maybe I lied... I thought I saw that at some point. 21:42:48 <nhnt11> Fwiw my objdir is always c-c/../obj-foo 21:43:02 <flo-retina> nhnt11: but you aren't doing universal builds, right? 21:43:06 <nhnt11> nope 21:43:18 * nhnt11 typed that before the bit about universal builds 21:43:38 * clokep_work asks Joshua. 21:44:04 <aleth> flo-retina: I think I know why it breaks things 21:44:24 <aleth> Well, not "know", but I have a guess... 21:45:20 <aleth> There's this code in base.py that adds/subtracts parts of the path and then compares paths, it might not realise when two paths are == if they contain ,, 21:45:25 <aleth> s/,,/.. 21:45:57 <aleth> nhnt11: Didn't you say your build was broken? :P 21:45:57 <flo-retina> could this also explain the Windows failure? 21:46:04 <aleth> nhnt11: This might also explain that problem 21:46:07 <aleth> flo-retina: Yes 21:46:16 <flo-retina> note: we've used this path since we started using buildbot back in 2008... 21:46:34 <aleth> flo-retina: Yes, but in the last few days quite a lot of changes around that have landed 21:46:44 <nhnt11> aleth: Why? My problem is that TB gets built instead of IB, which is super weird. The correct objdir is used (c-c/../obj-instantbird) 21:46:44 <flo-retina> aleth: sure sure 21:46:54 * nhnt11 hasn't tried to further debug his build issues 21:46:57 <aleth> nhnt11: well, give it a try with a different objdir ;) 21:47:10 <aleth> nhnt11: It would be interesting to see if it made a difference. Pull first of course. 21:47:12 <nhnt11> Was there a very recent change related to this stuff? :S 21:47:15 <nhnt11> okay. 21:47:16 <flo-retina> aleth: well, if that really was the problem, we would see it on buildbot too, right? 21:47:20 <flo-retina> afaik buildbot isn't building TB 21:47:41 <flo-retina> s/the problem/nhnt11's problem/ 21:47:56 <aleth> flo-retina: Different things could go wrong for similar reasons, but yeah, it's a bit of a long shot 21:48:19 <flo-retina> aleth: I'm more inclined to suspect nhnt11's lizard friend ;) 21:48:38 <nhnt11> flo-retina: Lol. I wonder if he's still crawling around my dorm room 21:48:41 <aleth> nhnt11: Building TB instead is indeed weird. 21:48:44 <clokep_work> flo-retina: What about trying a fully resolved path that doesn't have the .. in it? 21:49:05 <aleth> clokep_work: I second that suggestion 21:49:37 <flo-retina> you mean that doesn't contain the .. in the string, but that's still outside the srcdir? 21:49:52 <aleth> Yes 21:50:31 <flo-retina> clokep_work, aleth: broken too 21:50:34 <flo-retina> so .. is not the problem 21:50:43 <aleth> So much for my wild guess then :-/ 21:51:29 <aleth> Must be the lizard after all, though you'd think he'd like gecko. 21:52:12 <flo-retina> maybe he prefers TB's gecko? 21:53:04 <nhnt11> Um, I think I've been misleading you by saying "c-c/../obj-instantbird". That is indeed the location of my objdir but it's defined in my mozconfig as an absolute path ("/Users/nhnt11/Dev/obj-instantbird") 21:53:18 <nhnt11> My bad if that led you to think my issue might be related. 21:53:39 <-- flo-thinkpad has quit (Connection reset by peer) 21:53:41 --> flo-thinkpad has joined #instantbird 21:53:58 <flo-retina> nhnt11: don't worry we are just confused by all the bustages ;) 21:54:13 <aleth> Maybe when we fix them we'll discover we're all building TB... 21:54:36 * nhnt11 hopes not^ 21:54:49 <aleth> My local build works, anyway :) 21:55:10 <aleth> Not that thats' much help to anyone. 21:55:36 <clokep_work> Should we try just putting it under the srcdir and see if it works? ;) 21:55:39 <aleth> We really want to land mayanktg's webcam patch, sawrubh's Filelink, etc... 21:56:00 <flo-retina> clokep_work: that's what I'm considering 21:56:06 <flo-retina> clokep_work: how much bustage would that change cause 21:56:09 <aleth> clokep_work: I guess we would see in a minute whether the configure works then, right? 21:56:18 <clokep_work> flo-retina: Is there any huge benefit to not having it under it? 21:56:53 <flo-retina> I don't remember 21:57:19 <flo-retina> there was a reason, but without remembering what the reason was, it's difficult to decide if the reason is still relevant :-| 21:57:42 <flo-retina> the only one I can come up with ATM is not seeing plenty of unknown files when running hg commands 21:57:49 <flo-retina> (ie a pretty weak reason) 21:58:17 <aleth> You shouldn't see those anyway 21:58:39 <aleth> (with a decent .hgignore) 22:01:11 <flo-retina> there are plenty of references to the obj dir in the buildbot config :( 22:02:18 <nhnt11> :S 22:02:45 <nhnt11> I just qpop'd all my patches, did a checkout, removed everything from my mozconfig but hte "essentials" and ran a mach configure 22:02:59 <nhnt11> I now have ldap, mail, mailnews, and chat directories in my objdir 22:03:01 <-- mconley has quit (Input/output error) 22:03:04 <-- instant-buildbot has quit (Input/output error) 22:03:06 --> instant-buildbot has joined #instantbird 22:03:06 * ChanServ sets mode +v instant-buildbot 22:03:07 <nhnt11> What's surprising me is mailnews 22:03:14 <nhnt11> I don't remember if that was showing up before too.. :( 22:03:21 <flo-retina> let's start new nightlies and see how long it takes for them to fail :) 22:03:27 <clokep_work> nhnt11: It shouldn't be there. 22:03:31 <clokep_work> What's your .mozconfig? 22:03:32 <aleth> nhnt11: You're building seamonkey too now?! 22:03:39 * nhnt11 is really really confused 22:03:44 <aleth> Gotta build 'em all! 22:03:46 <clokep_work> nhnt11: mailnews is part of TB. 22:03:55 <nhnt11> Right 22:04:04 <aleth> Ah yeah, suite would be seamonkey. 22:04:11 <nhnt11> Yeah it was probably there before 22:04:25 <flo-retina> I remember not so long ago I didn't dare touching anything in the strange magic that the buildbot config is, and asked Even to do any change there. 22:04:31 <nhnt11> clokep_work: This is my mozconfig: http://pastebin.instantbird.com/748478 22:04:31 <aleth> It's still really strange, what you're seeing. 22:04:35 <nhnt11> I don't have a .mozconfig 22:04:44 <flo-retina> good thing I'm not "happily" adding even more mess in there :-| 22:04:48 <flo-retina> s/not/now/ 22:04:58 <aleth> nhnt11: Try dropping the MOZ_OBJDIR 22:05:05 <clokep_work> nhnt11: Are you positive it's using that mozconfig? It should tell you when you run configure 22:05:22 <flo-retina> --with-unify-dist=../x86_64/mozilla/dist 22:05:25 <flo-retina> \o/ 22:05:26 <flo-retina> !!! 22:05:41 <aleth> \o/ 22:05:56 <flo-retina> so, let's see how soon it fails ;) 22:05:59 <aleth> nhnt11: Definitely try changing that objdir ;) 22:06:06 <flo-retina> maybe in |make distribute| this time? :-D 22:06:49 <aleth> maybe something just landed on m-c :D 22:07:09 <flo-retina> yeah, just what we would need 22:07:17 <flo-retina> aleth: would be awesome if the same change fixed Windows too 22:07:29 <nhnt11> Okay, mach configure doesn't say anything about my mozconfig 22:07:32 <aleth> flo-retina: yup 22:07:47 <nhnt11> mach build, on the other hand, does. 22:08:10 <aleth> nhnt11: look for "Adding client.mk options" 22:08:15 <aleth> Ah, you found it. 22:08:29 <instant-buildbot> build #2244 of macosx-nightly-default is complete: Failure [4failed compile] Build details are at http://buildbot.instantbird.org/builders/macosx-nightly-default/builds/2244 22:08:37 <nhnt11> Definitely not happening in the configure step 22:08:52 <aleth> nhnt11: Right, it's on mach build. 22:09:00 <clokep_work> :-S 22:09:02 <clokep_work> Really? 22:09:09 <clokep_work> It has to read that file in order to know where the objdir is, etc. 22:09:22 <nhnt11> clokep_work: Yeah, it's using the right objdir, but doesn't say anything about it 22:10:08 <clokep_work> Well that failed fast. :) 22:10:48 <nhnt11> aleth: I just removed the objdir from my mozconfig 22:10:49 <nhnt11> And 22:10:53 <nhnt11> Instantbird is building 22:11:00 <instant-buildbot> build #1434 of win32-nightly-default is complete: Failure [4failed compile] Build details are at http://buildbot.instantbird.org/builders/win32-nightly-default/builds/1434 22:11:23 * nhnt11 is really really confused why this is suddenly broken 22:11:25 <aleth> nhnt11: So I think we've confirmed from this and the buildbot that you have to put the objdir in a subdir... 22:11:29 <flo-retina> ah, for good measure the second failed too! 22:11:35 <aleth> Or crazyness results. 22:11:38 <clokep_work> :( 22:12:16 <aleth> flo-retina: So we're left with the new Windows failure, on Mac as well now. 22:12:45 <flo-retina> is it the exact same, 22:12:46 <flo-retina> ? 22:13:08 <flo-retina> yes it is, you are right 22:13:12 <flo-retina> aleth: is that good news? 22:13:27 <aleth> It could be... one problem instead of two :D 22:14:09 <aleth> So at least the universal build issue is gone, hopefully. 22:14:11 <aleth> I linked the patch that changed that code today earlier. 22:15:01 <flo-retina> "the issue is gone"... "hopefully" :-D 22:16:41 <aleth> flo-retina: It didn't get to make distribute, did it ;) 22:17:07 <nhnt11> aleth, flo-retina: Exporting MOZCONFIG=$(pwd)/mozconfig before building also solves my issue 22:17:28 <flo-retina> aleth: ... ;) 22:17:55 <nhnt11> So I'm guessing that my mozconfig isn't detected after mach cd's into my objdir 22:18:19 <aleth> nhnt11: Do you still need that export if you remove your custom objdir setting? 22:18:30 <nhnt11> aleth: No. 22:19:37 <aleth> nhnt11: Sounds like at least locally, that problem is solved one way or another then :) 22:19:54 <aleth> The buildbot is another story 22:20:38 * nhnt11 tries to figure out the best way to automate this 22:21:02 <nhnt11> Possibly export the mozconfig from the mozconfig ;) 22:22:16 <nhnt11> That doesn't work apparently.. 22:22:25 <-- mayanktg has quit (Client exited) 22:22:27 --> mayanktg has joined #instantbird 22:25:02 <-- mayanktg has quit (Ping timeout) 22:25:07 <aleth> nhnt11: With your export trick, does your build complete? 22:25:12 <aleth> Or do you get the same error as the buildbot? 22:25:19 <aleth> (assuming you pulled today) 22:25:52 --> mayanktg has joined #instantbird 22:25:54 <nhnt11> aleth: Running a build, I'll let you know 22:26:32 <aleth> flo-retina: I wonder if this goes wrong for an exported MOZCONFIG http://mxr.mozilla.org/comm-central/source/mozilla/python/mozbuild/mozbuild/base.py#159 22:26:50 <nhnt11> aleth: Same failure 22:27:05 <aleth> the "line 181" one? 22:27:53 <nhnt11> File "/Users/nhnt11/Dev/comm-central/mozilla/python/mozbuild/mozbuild/base.py", line 181, in from_environment 22:28:08 <nhnt11> Aha... 22:28:10 <aleth> nhnt11,flo-retina : That means we now can reproduce the problem locally, at least. :) 22:29:07 <aleth> I wonder how we could do without the export MOZCONFIG on buildbot. 22:29:48 <nhnt11> aleth: Fwiw I am very inclined to say this is similar to the old issue with the dist dir 22:29:56 * Fallen is now known as Fallen|away 22:30:03 <nhnt11> i.e. it thought that the dist dir was objdir/dist, whereas it was actually objdir/mozilla/dist 22:30:31 <nhnt11> Here it's an objdir/mozilla vs objdir mismatch.. 22:30:38 <aleth> nhnt11: It's a new failure, only happened today following bug 1035099. But yeah, the underlying reason is the hack of putting m-c under c-c 22:30:40 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1035099 nor, --, mozilla33, mh+mozilla, RESO FIXED, Remove the comm-central workarounds from MozbuildObject.from_environment 22:31:10 * nhnt11 feels like he's always catching up on these build issues 22:31:11 <flo-retina> aleth: http://pastebin.instantbird.com/748479 22:32:34 <nhnt11> "you can create a .mozconfig that sources the mozconfig you want" 22:32:39 * nhnt11 tries that 22:33:04 <flo-retina> so, back to the buildbot hackery 22:33:49 <nhnt11> "Multiple default mozconfig files present. Remove all but one. /Users/nhnt11/Dev/comm-central/.mozconfig, /Users/nhnt11/Dev/comm-central/mozconfig" 22:34:43 <nhnt11> Renaming mozconfig to mozconfig2 and sourcing it in .mozconfig didn't help 22:34:47 <nhnt11> It's back to building TB 22:35:13 <aleth> nhnt11: Put your mozconfig in a different directory 22:35:32 <nhnt11> aleth: Does that matter? 22:35:42 <aleth> Try a .mozconfig containing only |. path-to-mozconfig| 22:35:43 <nhnt11> The problem seems to be that configure isn't picking up the mozconfig in c-c at all 22:36:03 <nhnt11> s/mozconfig/(.)mozconfig 22:36:07 <aleth> I thought it was picking up both and giving you a multiple mozconfigs error? 22:36:21 <nhnt11> No, that was because I had both c-c/mozconfig and c-c/.mozconfig 22:36:31 <-- instant-buildbot has quit (Input/output error) 22:36:38 <aleth> Yeah, that's what I was responding to 22:37:01 --> instant-buildbot has joined #instantbird 22:37:02 * ChanServ sets mode +v instant-buildbot 22:37:11 <nhnt11> This is the output of mach build: pastebin.instantbird.com/748482 22:37:15 <nhnt11> http://pastebin.instantbird.com/748482 sorry 22:37:29 * flo-retina wonders why the mac slave takes so long to recoonect 22:37:33 <nhnt11> It picks up the mozconfig, sets the objdir, cd's to it, and forgets the mozconfig 22:37:48 <flo-retina> I'm tempted to just kick it, it's within reach of my right hand :-P 22:38:48 <instant-buildbot> build #1435 of win32-nightly-default is complete: Failure [4failed compile] Build details are at http://buildbot.instantbird.org/builders/win32-nightly-default/builds/1435 22:38:59 <-- instant-buildbot has quit (Input/output error) 22:39:01 --> instant-buildbot has joined #instantbird 22:39:01 * ChanServ sets mode +v instant-buildbot 22:39:31 <-- mayanktg has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 22:39:35 <aleth> Did you use a relative path? 22:39:44 <flo-retina> I forgot to remove the environment variable ;) 22:40:02 <instant-buildbot> build #2246 of macosx-nightly-default is complete: Failure [4failed compile] Build details are at http://buildbot.instantbird.org/builders/macosx-nightly-default/builds/2246 22:41:37 <-- instant-buildbot has quit (Input/output error) 22:42:15 --> instant-buildbot has joined #instantbird 22:42:15 * ChanServ sets mode +v instant-buildbot 22:42:59 <instant-buildbot> build #1436 of win32-nightly-default is complete: Failure [4failed compile] Build details are at http://buildbot.instantbird.org/builders/win32-nightly-default/builds/1436 22:43:01 <instant-buildbot> build #2247 of macosx-nightly-default is complete: Failure [4failed compile] Build details are at http://buildbot.instantbird.org/builders/macosx-nightly-default/builds/2247 22:43:13 <aleth> what, again? :( 22:44:07 <flo-retina> aleth: it's pretty obvious that http://buildbot.instantbird.org/builders/macosx-nightly-default/builds/2247/steps/shell_4/logs/stdio doesn't do what I intend 22:44:20 <aleth> yeah... 22:46:54 <aleth> How are you picking up the mozconfig now? 22:48:03 <flo-retina> I guess if I just use a cp instead of the echo, that should work in the same way 22:48:51 <-- instant-buildbot has quit (Input/output error) 22:49:36 <aleth> Why the s after (buildDir)? 22:49:50 --> instant-buildbot has joined #instantbird 22:49:50 * ChanServ sets mode +v instant-buildbot 22:50:51 <flo-retina> aleth: just saying it's a string 22:51:07 <aleth> ah, I always forget that part of the syntax. 22:51:15 <flo-retina> looks like a better start this time 22:51:20 <flo-retina> how long before it fails? :) 22:52:23 <aleth> Looking good so far 22:53:14 <aleth> bah. 22:53:58 <aleth> Annoying when you autocomplete the wrong command... 22:54:40 <flo-retina> do we know how long it took for the previous "real" builds to fail? 22:54:59 <nhnt11> flo-retina: What was the workaround for the buildbot? 22:55:09 <flo-retina> 200s on mac, 400 on Windows 22:55:35 <flo-retina> nhnt11: instead of setting the MOZCONFIG environment variable, I just copied the correct mozconfig to the root of the srcdir 22:55:53 <nhnt11> flo-retina: Is the objdir a subdir of the srcdir? 22:55:59 <flo-retina> yes 22:56:03 <nhnt11> Okay :( 22:56:05 <aleth> flo-retina: looks like they are both past the point of previous failure at least 22:56:16 <flo-retina> nhnt11: only to fix universal builds though ;) 22:56:58 <nhnt11> flo-retina: Putting my objdir outside of the srcdir causes configure to ignore my mozconfig and build TB :-/ 22:57:03 <nhnt11> (for a non-universal build) 22:57:08 * nhnt11 can't figure it out 22:57:25 <nhnt11> exporting MOZCONFIG makes configure pick it up but that causes failure.. 22:57:38 <aleth> "build TB" is what happens when you don't have a mozconfig 22:58:01 <nhnt11> Right, configure is ignoring the mozconfig in my srcdir 23:01:00 <aleth> nhnt11: Why do you prefer the objdir outside the srcdi? 23:02:12 <nhnt11> aleth: I have some aliases set up that I now need to change 23:02:23 <aleth> Oh, OK. 23:02:40 <nhnt11> luckily I have a couple of environment variables for the objdir that the aliases use so it shouldn't be a big deal I guess 23:02:53 <-- clokep_work has quit (Ping timeout) 23:03:08 <flo-retina> aleth: so, are we betting on a new |make distribute| failure? ;) 23:03:21 <aleth> flo-retina: Not really. I am optimistic :D 23:03:42 <aleth> On the other hand, I haven't tried make package since yesterday :P 23:03:59 --> wnayes has joined #instantbird 23:04:00 * nhnt11 thinks he's all set 23:04:05 <flo-retina> "I haven't tried make package since yesterday" ahah 23:04:20 <flo-retina> aleth: make package is only a small subset of the possible distribution bustages 23:04:34 <flo-retina> there's also the mar packaging, the build symbols, etc... 23:05:24 <-- mpmc has quit (Ping timeout) 23:05:35 --> mpmc has joined #instantbird 23:06:02 <aleth> Don't jinx it! 23:06:34 * nhnt11 's build is humming happily 23:11:41 <-- mpmc has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 23:14:07 <-- flo-thinkpad has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 23:18:59 <-- aleth has quit (Quit: exit stage left) 23:20:56 <nhnt11> :O 23:21:05 <nhnt11> My build completed in 13:22.56 23:21:11 <nhnt11> Usually takes >18 minutes 23:21:43 * nhnt11 wonders if it's to do with having the objdir inside srcdir, or some recent build optimizations 23:22:24 <-- Armada has quit (Connection reset by peer) 23:22:57 <flo-retina> nhnt11: debug build? 23:23:02 <nhnt11> flo-retina: optimized 23:23:13 <flo-retina> ccache? 23:23:22 <flo-retina> apparently clokep says it's now enabled by default 23:23:35 <nhnt11> Interesting. I haven't changed any settings 23:24:42 <nhnt11> flo-retina: Doesn't ccache work for /re/builds though? 23:24:46 <nhnt11> (This was a clobber) 23:25:00 <flo-retina> ccache works for files you built before 23:25:06 <flo-retina> doesn't even have to be in the same source tree 23:25:12 <nhnt11> Nice 23:25:13 <flo-retina> as long as the preprocessed C++ code is the same 23:25:15 <instantbot> c++ is evil 23:25:22 * flo-retina pats instantbot 23:25:23 * instantbot beams 23:26:10 <flo-retina> the mac build is almost done compiling 23:27:35 <nhnt11> fwiw, there's no mention of ccache in my build log (though that may not indicate anything) 23:30:25 <flo-retina> it was mentioned in configure for me 23:30:50 <nhnt11> Nothing here 23:32:55 <flo-retina> The mac build is in the distribute step! 23:33:15 <nhnt11> :) 23:43:42 <flo-retina> update packaging 23:46:07 <flo-retina> strange line: remove "Contents/MacOS/d3dx9_43.dll" 23:46:26 <nhnt11> indeed 23:57:00 <flo-retina> it's uploading! :)