Re: Making a 3.2.2 release

2018-09-11 Thread Roger Leigh

On 11/09/18 17:26, Cantor, Scott wrote:

RC3 is now up. I'll wait a bit for any final checks and then call a vote.


Thanks.  I've tested these with:

Linux (Ubuntu 18.04)

  autotools / make (pass)
  cmake / make (pass)
  cmake / ninja(pass)

Windows (10 x64, VS2017)

  cmake / ninja debug (pass)
  cmake / msbuild release (pass)
  cmake / msbuild debug   (pass)

Where a pass is building and passing all the tests.  Tests also run in 
parallel across the board with no problems.


All GPG signatures are OK as well.

No problems seen on my side, so I think this rc3 is fine.


Regards,
Roger

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Making a 3.2.2 release

2018-09-11 Thread Cantor, Scott
RC3 is now up. I'll wait a bit for any final checks and then call a vote.

-- Scott




Re: Making a 3.2.2 release

2018-09-11 Thread Roger Leigh

On 11/09/18 15:38, Cantor, Scott wrote:

I've uploaded an RC2 build (named appropriately this time) for eval, same spot.


Thanks.  I've given this one a test on Windows, and it's now building 
fine.


I've also now been able to fix XERCESC-2153 which was minor but 
annoying.  If you could possibly make an RC3 with this included, that 
should be the last thing from me for the release, and it should be ready 
to go.


Thanks,
Roger

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] [Closed] (XERCESC-2153) Tests can fail on Windows when run in parallel

2018-09-11 Thread Roger Leigh (JIRA)


 [ 
https://issues.apache.org/jira/browse/XERCESC-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh closed XERCESC-2153.

   Resolution: Fixed
Fix Version/s: 3.2.2

Fixed in SVN r1840586.  Running StdIn tests serially avoids contention with 
other tests sharing the same input files.  All the other tests can be run in 
parallel.

> Tests can fail on Windows when run in parallel
> --
>
> Key: XERCESC-2153
> URL: https://issues.apache.org/jira/browse/XERCESC-2153
> Project: Xerces-C++
>  Issue Type: Wish
>  Components: Samples/Tests
>Affects Versions: 3.2.1
> Environment: Windows 10 x64 with VS2017 x64 build of Xerces-C++ 3.2.2 
> prerelease.
>Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Minor
>  Labels: test-fail, windows
> Fix For: 3.2.2
>
>
> Tests always pass when run serially, so I don't see this as a blocker for 
> 3.2.2 unless it's indicative of a very long-standing problem internally in 
> Xerces rather than that the tests were not originally written with parallel 
> execution in mind.
> When running "ctest -jn" to run tests in parallel, tests can randomly fail.  
> Looks like an interaction between tests when run at the same time.  Some 
> resource contention?
> The following is a reduced testcase, where I've found two tests which 
> interact badly (there may be others).  Both are using personal.xml as input.
> {{D:\xerces-c-3.2.2\b>ctest -C Release -j 4 -R "DOMPrint3|StdInParse2"}}
> {{Test project D:/xerces-c-3.2.2/b}}
> {{ Start 66: DOMPrint3}}
> {{ Start 70: StdInParse2}}
> {{1/2 Test #66: DOMPrint3 ***Failed 0.07 sec}}
> {{2/2 Test #70: StdInParse2 .. Passed 0.08 sec}}{{50% 
> tests passed, 1 tests failed out of 2}}{{Total Test time (real) = 0.11 
> sec}}{{The following tests FAILED:}}
> {{ 66 - DOMPrint3 (Failed)}}
> {{Errors while running CTest}}
> I can't reproduce on Linux, so it may well be Windows-specific due to file 
> locking preventing multiple readers of a file?  Is it due to one process 
> having it held open on stdin while the other tries to open it.  Running 
> multiple StdInParse[123] tests or multiple DOMPrint[123] tests does not 
> result in failure.  But when the two are combined, it's always DOMPrint that 
> fails; is it the open mode being used?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Speakers needed for Apache DC Roadshow

2018-09-11 Thread Rich Bowen
We need your help to make the Apache Washington DC Roadshow on Dec 4th a 
success.


What do we need most? Speakers!

We're bringing a unique DC flavor to this event by mixing Open Source 
Software with talks about Apache projects as well as OSS CyberSecurity, 
OSS in Government and and OSS Career advice.


Please take a look at: http://www.apachecon.com/usroadshow18/

(Note: You are receiving this message because you are subscribed to one 
or more mailing lists at The Apache Software Foundation.)


Rich, for the ApacheCon Planners

--
rbo...@apache.org
http://apachecon.com
@ApacheCon

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Making a 3.2.2 release

2018-09-11 Thread Cantor, Scott
I've uploaded an RC2 build (named appropriately this time) for eval, same spot.

-- Scott




-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] [Updated] (XERCESC-2153) Tests can fail on Windows when run in parallel

2018-09-11 Thread Roger Leigh (JIRA)


 [ 
https://issues.apache.org/jira/browse/XERCESC-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Leigh updated XERCESC-2153:
-
Issue Type: Wish  (was: Improvement)

> Tests can fail on Windows when run in parallel
> --
>
> Key: XERCESC-2153
> URL: https://issues.apache.org/jira/browse/XERCESC-2153
> Project: Xerces-C++
>  Issue Type: Wish
>  Components: Samples/Tests
>Affects Versions: 3.2.1
> Environment: Windows 10 x64 with VS2017 x64 build of Xerces-C++ 3.2.2 
> prerelease.
>Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Minor
>  Labels: test-fail, windows
>
> Tests always pass when run serially, so I don't see this as a blocker for 
> 3.2.2 unless it's indicative of a very long-standing problem internally in 
> Xerces rather than that the tests were not originally written with parallel 
> execution in mind.
> When running "ctest -jn" to run tests in parallel, tests can randomly fail.  
> Looks like an interaction between tests when run at the same time.  Some 
> resource contention?
> The following is a reduced testcase, where I've found two tests which 
> interact badly (there may be others).  Both are using personal.xml as input.
> {{D:\xerces-c-3.2.2\b>ctest -C Release -j 4 -R "DOMPrint3|StdInParse2"}}
> {{Test project D:/xerces-c-3.2.2/b}}
> {{ Start 66: DOMPrint3}}
> {{ Start 70: StdInParse2}}
> {{1/2 Test #66: DOMPrint3 ***Failed 0.07 sec}}
> {{2/2 Test #70: StdInParse2 .. Passed 0.08 sec}}{{50% 
> tests passed, 1 tests failed out of 2}}{{Total Test time (real) = 0.11 
> sec}}{{The following tests FAILED:}}
> {{ 66 - DOMPrint3 (Failed)}}
> {{Errors while running CTest}}
> I can't reproduce on Linux, so it may well be Windows-specific due to file 
> locking preventing multiple readers of a file?  Is it due to one process 
> having it held open on stdin while the other tries to open it.  Running 
> multiple StdInParse[123] tests or multiple DOMPrint[123] tests does not 
> result in failure.  But when the two are combined, it's always DOMPrint that 
> fails; is it the open mode being used?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] [Commented] (XERCESC-2153) Tests can fail on Windows when run in parallel

2018-09-11 Thread Roger Leigh (JIRA)


[ 
https://issues.apache.org/jira/browse/XERCESC-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16610530#comment-16610530
 ] 

Roger Leigh commented on XERCESC-2153:
--

Putting some debug messages in WindowsFileMgr::fileOpen (called from 
BinFileInputStream from LocalFileInputSource), shows that the HRESULT is 
0x80070020 (sharing violation) which meets the hypothesis above.  The input 
file on stdin must be opened without FILE_SHARE_WRITE.  This isn't a bug in 
Xerces-C++, it's due to the way the CMake execute_process function sets up 
pipes for STDIN with read and write access.  I have created a ticket for that 
here which contains more details: 
https://gitlab.kitware.com/cmake/cmake/issues/18359

> Tests can fail on Windows when run in parallel
> --
>
> Key: XERCESC-2153
> URL: https://issues.apache.org/jira/browse/XERCESC-2153
> Project: Xerces-C++
>  Issue Type: Improvement
>  Components: Samples/Tests
>Affects Versions: 3.2.1
> Environment: Windows 10 x64 with VS2017 x64 build of Xerces-C++ 3.2.2 
> prerelease.
>Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Minor
>  Labels: test-fail, windows
>
> Tests always pass when run serially, so I don't see this as a blocker for 
> 3.2.2 unless it's indicative of a very long-standing problem internally in 
> Xerces rather than that the tests were not originally written with parallel 
> execution in mind.
> When running "ctest -jn" to run tests in parallel, tests can randomly fail.  
> Looks like an interaction between tests when run at the same time.  Some 
> resource contention?
> The following is a reduced testcase, where I've found two tests which 
> interact badly (there may be others).  Both are using personal.xml as input.
> {{D:\xerces-c-3.2.2\b>ctest -C Release -j 4 -R "DOMPrint3|StdInParse2"}}
> {{Test project D:/xerces-c-3.2.2/b}}
> {{ Start 66: DOMPrint3}}
> {{ Start 70: StdInParse2}}
> {{1/2 Test #66: DOMPrint3 ***Failed 0.07 sec}}
> {{2/2 Test #70: StdInParse2 .. Passed 0.08 sec}}{{50% 
> tests passed, 1 tests failed out of 2}}{{Total Test time (real) = 0.11 
> sec}}{{The following tests FAILED:}}
> {{ 66 - DOMPrint3 (Failed)}}
> {{Errors while running CTest}}
> I can't reproduce on Linux, so it may well be Windows-specific due to file 
> locking preventing multiple readers of a file?  Is it due to one process 
> having it held open on stdin while the other tries to open it.  Running 
> multiple StdInParse[123] tests or multiple DOMPrint[123] tests does not 
> result in failure.  But when the two are combined, it's always DOMPrint that 
> fails; is it the open mode being used?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Making a 3.2.2 release

2018-09-11 Thread Roger Leigh

On 11/09/18 00:17, Cantor, Scott wrote:

Didn't get to it until tonight.

https://dist.apache.org/repos/dist/dev/xerces/c/3/sources/

If that looks good, I'll call for a vote tomorrow.


I found a missing file which wasn't included in EXTRA_DIST, which broke 
building on Windows from the release zip (version.rc.cmake.in).  I've 
included it, tested locally with VS2017, and commited to SVN.  If you 
could recreate the dev release files, I'll retest again.



Regards,
Roger

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] [Created] (XERCESC-2153) Tests can fail on Windows when run in parallel

2018-09-11 Thread Roger Leigh (JIRA)
Roger Leigh created XERCESC-2153:


 Summary: Tests can fail on Windows when run in parallel
 Key: XERCESC-2153
 URL: https://issues.apache.org/jira/browse/XERCESC-2153
 Project: Xerces-C++
  Issue Type: Improvement
  Components: Samples/Tests
Affects Versions: 3.2.1
 Environment: Windows 10 x64 with VS2017 x64 build of Xerces-C++ 3.2.2 
prerelease.
Reporter: Roger Leigh
Assignee: Roger Leigh


Tests always pass when run serially, so I don't see this as a blocker for 3.2.2 
unless it's indicative of a very long-standing problem internally in Xerces 
rather than that the tests were not originally written with parallel execution 
in mind.

When running "ctest -jn" to run tests in parallel, tests can randomly fail.  
Looks like an interaction between tests when run at the same time.  Some 
resource contention?

The following is a reduced testcase, where I've found two tests which interact 
badly (there may be others).  Both are using personal.xml as input.

{{D:\xerces-c-3.2.2\b>ctest -C Release -j 4 -R "DOMPrint3|StdInParse2"}}
{{Test project D:/xerces-c-3.2.2/b}}
{{ Start 66: DOMPrint3}}
{{ Start 70: StdInParse2}}
{{1/2 Test #66: DOMPrint3 ***Failed 0.07 sec}}
{{2/2 Test #70: StdInParse2 .. Passed 0.08 sec}}{{50% tests 
passed, 1 tests failed out of 2}}{{Total Test time (real) = 0.11 sec}}{{The 
following tests FAILED:}}
{{ 66 - DOMPrint3 (Failed)}}
{{Errors while running CTest}}

I can't reproduce on Linux, so it may well be Windows-specific due to file 
locking preventing multiple readers of a file?  Is it due to one process having 
it held open on stdin while the other tries to open it.  Running multiple 
StdInParse[123] tests or multiple DOMPrint[123] tests does not result in 
failure.  But when the two are combined, it's always DOMPrint that fails; is it 
the open mode being used?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



[jira] [Commented] (XERCESC-2152) Wrong value for XERCES_SIZE_T in XercesIntTypes.cmake

2018-09-11 Thread Volo Zyko (JIRA)


[ 
https://issues.apache.org/jira/browse/XERCESC-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16610182#comment-16610182
 ] 

Volo Zyko commented on XERCESC-2152:


Another note: yesterday I've encountered more legitimate case when I got 
{{XERCES_SIZE_T=unsigned long}}. Again when cross compiling for iOS. If I pass 
to cmake {{"-DCMAKE_CXX_FLAGS=-isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk
 -arch armv7 -arch arm64 -miphoneos-version-min=10.0"}} then {{SIZEOF_SIZE_T}} 
in XercesIntTypes.cmake is {{0}}. I think this happens because on armv7 
{{sizeof(size_t) == 4}} and on arm64 {{sizeof(size_t) == 8}} and cmake gets 
confused.

So, is this really necessary detecting types' sizes (for other types too) at 
build configuration time? Probably more important is to check whether a given 
type is present on the target platform but checking for its size should be done 
at compile time, I think.

> Wrong value for XERCES_SIZE_T in XercesIntTypes.cmake
> -
>
> Key: XERCESC-2152
> URL: https://issues.apache.org/jira/browse/XERCESC-2152
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 3.2.1
>Reporter: Volo Zyko
>Assignee: Roger Leigh
>Priority: Minor
> Fix For: 3.2.2
>
>
> In the line {{set(XERCES_SIZE_T unsigned long)}} the value should be quoted, 
> otherwise cmake incorrectly inserts it as {{#define XERCES_SIZE_T 
> unsigned;long}} to InstalXerces_autoconf_config.hpp



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org