#instantbird log on 07 09 2014

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! :)