Re: [Allseen-core] Segmentation fault

I’m guessing, but just calling DebugControl::Init may not be enough, especially because I see both Thread and Event in the stack trace, and each of those have some structures that need to be set up. I recommend calling qcc::Init() and qcc::Shutdown(). From:

Re: [Allseen-core] Branch for iOS changes

I see Jorge has pushed a lot of commits to Gerrit for the new branch. Jorge, did you author all of these? And if so, have they been through any sort of internal review? If not, can you ask someone who’s knowledgeable about iOS to review before merging? From: Lioy, Marcello

Re: [Allseen-core] Scons help

Hi Glenn, That GitHub mirror looks like it's several months out of date. I've added Ry Jones, who may have some insight on who controls that mirror, and if it can be updated. Meanwhile, you can look at this wiki page to see where our live repositories live:

Re: [Allseen-core] Branch for iOS changes

I also approve. From: Daniel Mihai Sent: Tuesday, July 12, 2016 3:30 PM To: Lioy, Marcello ; Josh Spain ; Way Vadhanasin ; Kevin Kane ; Greg Zaverucha Cc: Ry Jones

Re: [Allseen-core] Branch for iOS changes

Committers will still be on the path in a branch. Gerrit’s workflow lends itself to changes being examined when they’re merged into the branch, and not to doing one massive review when the branch merges back into the parent. Speaking only for myself, I prefer it to one massive review at the

Re: [Allseen-core] Removing non-XML-based public C++ APIs

Does this mean we shouldn’t merge all of these open changes in Gerrit for ObjC and Java, but just leave them abandoned for future reference? From: allseen-core-boun...@lists.allseenalliance.org [mailto:allseen-core-boun...@lists.allseenalliance.org] On Behalf Of Lioy, Marcello Sent: Thursday,

Re: [Allseen-core] Removing non-XML-based public C++ APIs

I suggest abandoning, since a) leaving open implies there should be action on the change and it will keep appearing on our incoming reviews list, and b) when abandoning, one can leave a convenient note stating this. From: Lioy, Marcello [mailto:ml...@qce.qualcomm.com] Sent: Friday, August 19,

Re: [Allseen-core] 16.10 ready for early testing?

Changes for IPv6 for the SCL also only recently went into code review, and are not yet merged. All IPv6-related changes are also going into the feature branch “feature/ipv6” for both SCL and TCL. Is there a plan to test these changes in the feature branche so we can gain confidence in them,

Re: [Allseen-core] Publishing XSD

Correct address is: allseen-helpd...@rt.linuxfoundation.org From: allseen-core-boun...@lists.allseenalliance.org [mailto:allseen-core-boun...@lists.allseenalliance.org] On Behalf Of Pawel Winogrodzki via Allseen-core Sent: Tuesday, September 20,

Re: [Allseen-core] featureiOS_updates branch?

Looks like the branch was merged into RB16.04 on August 1st. RB16.04 was then merged into master on the 3rd. https://git.allseenalliance.org/gerrit/#/c/851f7/ https://git.allseenalliance.org/gerrit/#/c/8541/ For the particular commit you referenced, it's in all the branches:

Re: [Allseen-core] Debug vs. Release build testing - 16.10

Probably not. If you find an issue in release, the best course at that point is for someone to start triaging the issue, which may then lead to re-running the failing test cases with trace logging enabled and/or using a debug build. I don't expect re-running the test case on a debug build will

Re: [Allseen-core] API change

I’d go back to the trace log, particularly from the PERMISSION_MGMT source. At its most verbose setting it is pretty in-depth about going through each access control check, and should say where something is happening to cause permission denied. From: George Tang [mailto:gt...@affinegy.com]

Re: [Allseen-core] API change

nManifest() usable in java-binding might mean loss of some use cases / capability? Thanks, Paul On Oct 25, 2016, at 10:29 AM, Kevin Kane via Allseen-core <allseen-core@lists.allseenalliance.org<mailto:allseen-core@lists.allseenalliance.org>> wrote: It should be possible to call

Re: [Allseen-core] Release note ASACORE-3464

This looks like a real bug. The "Old application state/New application state" output is from the security manager. I'm not as familiar with this code but I'm guessing it's changing its internal database that tracks the work it has to do, but when it attempts to actually claim the door provider,

Re: [Allseen-core] Ubuntu/Eclipse + Cross Compile + Basicclient & Service

No, adding this header into all the AllJoyn/qcc header files is definitely cumbersome, and not normal. That’s not what I’m suggesting. But you might be able to unblock yourself quickly by #include’ing the standard header file in your app code before your app code #include’s AllJoyn’s header