Re: EXTERNAL: Re: Building comphelper

[Herbert Duerr]

Hy Raymond,

On 04.09.2013 18:33, Steele, Raymond wrote:

You are right, I completely missed your post. I am updating my compiler (SolarisStudio 
12.3) now.  As far as I can see now, I do not have isfinite is not a member of std on my 
system. Although, Netbeans allows me to choose C++ Standard C++11. What do you mean by 
" experiment with the different SAL_MATH_FINITE definitions"?


mathconf.h is a C header file, so we need the C definition of isfinite.

According to [1] the "C" isfinite() should be defined in . Maybe 
on your platform there is a bug similar to [2] that undefines it later. 
But we can assume that isfinite() is available in one form or the other 
on your system. Maybe it is called finite(), _finite(), or 
__builtin_isfinite()? Assuming [3] applies here then finite() may be the 
pre-standard equivalent to the isfinite() function that we are looking for.


[1] http://pubs.opengroup.org/onlinepubs/009695399/functions/isfinite.html
[2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14608
[3] https://www.varnish-cache.org/trac/ticket/464

What I meant with "experiment with the different SAL_MATH_FINITE 
definitions" is to check whether one of the above pre-standard 
isfinite() alternatives work. If you found one then add a define for 
SOLARIS only that doesn't break the other platforms.


By the way std::isfinite() should be provided via  for C++11. But 
as the mathconf.h header is a "C" header this C++11 header is not 
available in this context.


Herbert


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

Re: svn commit: r1519953 - in /openoffice/branches/l10n40/main/languages/source: af/ ar/ as/ ast/ be-BY/ bg/ bn/ bo/ br/ brx/ bs/ ca-XV/ ca/ cs/ cy/ da/ de/ dgo/ dz/ el/ en-AU/ en-GB/ en-ZA/ eo/ es/ e

[Herbert Duerr]

Hi Jan,


[...]
I have to ask very clearly; is the opinion of the community, that .po files
is not to be considered a vital/integrated part of our source tree and
should be moved away ?


I believe they are as important as the source code. But they are not 
source code! Also templates, clip art, etc. are just wonderful to have. 
The more the better. They are not source code either. Having them all 
localized would be a big plus though. Having all the localizable stuff 
not being spread out all over the repository would be helpful IMHO.


IIRC all the localized strings were in the source files itself. Then 
they were split off into *.src file, were they were maintained until 
2004. Then the individual localizations were split off again and 
collected in the l10n project. This consolidation of localizations was a 
good cleanup IMHO.


Modern platforms try to split the resources and the binaries. They even 
split the resources in itself, e.g. for different target resolutions. 
And nobody is complaining that e.g. low-DPI targets are discriminated 
against.


But I trust your assessment of the situation. Please consider the points 
I made and do what you think is best.


Herbert

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

Re: about ooo export PDF file?

[Herbert Duerr]

On 05.09.2013 10:43, jianlizhao wrote:

Hello my friend , Who can help me below problem?
OOo export PDF files, how to know the number of the PDF document object?


Please see the source file pdfwriter_impl.cxx [1]. You're probably 
looking for the PDFWriterImpl::emitDocumentMetadata() or the 
PDFWriterImpl::emit() methods there.


[1] 
http://svn.apache.org/viewvc/openoffice/trunk/main/vcl/source/gdi/pdfwriter_impl.cxx?view=markup



When the output PDF file, how to generate catalog object?


Please see the PDFWriterImpl::emitCatalog() method in the same file.


How to generate pages object


Please see the PDFWriterImpl::newPage() method in the same file.

I hope these infos will help you to advance our project.

Herbert

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

Re: EXTERNAL: Re: Building comphelper

[Herbert Duerr]

On 05.09.2013 18:37, Steele, Raymond wrote:

Thanks for the information.  I will give this a try if my current strategy does 
not work.

> Apparently, SolarisStudios 12.3 compiler is not compatible with c++11.

We don't build in C++11 mode for (most of) our target platforms yet.


I  just finished building GCC 4.8.1 so that  I can attempt to build with that.


I'm a bit worried about our UNO bridges when I hear this. This code in 
main/bridges/source/cpp_uno is very sensitive to platform/compiler 
changes. GCC 4.8 is quite new and I'm also afraid that the gcc-solaris 
bridges are not as well exercised as their suncc counterparts.


By the way, are you targeting sparc or x86 CPUs?


Now, I am  having the issue described here: 
http://wiki.openoffice.org/wiki/OpenSolaris_Build_Instructions/Configure_Errors#Error:_GCC_Linker
 because I have CC and CXX pointing to my new gcc and g++.  How can I  point 
these variables to SolarisStudio compilers for linking, but use gcc for 
compiling?


If I understand the error message in the referenced Wiki section 
correctly you'd want to link with GNU ld on Solaris if you built with 
gcc and link with Sun ld if you built with Sun CC, so all should be fine 
with CC and CXX being set.


Herbert

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

Re: Question to all developers and translators: How integrated should translation be ?

[Herbert Duerr]

On 06.09.2013 15:03, Rob Weir wrote:

So maybe just rename "extras" to something else if it is merely the
word that is offensive.   But although translations are essential to
the project, modularity is also important.  For example, we don't put
the website in /main do we, although that is important to the project?


Yes, "main" should be renamed to "source" or "src" as this name is too 
presumptuous and I understand why not being in main is considered 
discriminatory. Having a dedicated "source" directory would also help to 
give our repository a more common structure for an open source project.


In "extras" we could have templates, clip arts, example documents, etc.

And "l10n" deserves its own directory tree.

Herbert

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

Re: bug 107063 (needs update)

[Herbert Duerr]

On 08.09.2013 23:38, Kay Schenk wrote:

On Sun, Sep 8, 2013 at 6:55 AM,  wrote:


Can someone please set the bugs:
26331
20525
as duplicate of:
107063

And change the "Version" of  107063 to 4.0.1.
I tested this on Apache_OpenOffice_4.0.1_Win_x86_install_en-GB.exe on XP
and this bug still occurs.
(tested with frames of images and tables)


Thanks for checking this issue with our latest snapshot! Knowing that a 
bug is still there is an important data point.



I marked the duplicate issues you suggested. Please log in and update the
version on your own if you would. If there is some problem you can't do
this, please let us know.


For re-confirming issues such as 107063 we have the field "latest 
confirmation on". The version field itself should record when a bug 
first appeared.


Also we there is no release of AOO 4.0.1 yet, there are only snapshots 
on the way to 4.0.1 that use "4.0.1" in various strings for technical 
reasons. So recording a bug against a pre-release should only be against 
e.g. AOO401-dev but not against the target version.


Herbert

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

Re: Wrong "vendor" on last dev build

[Herbert Duerr]

On 07.09.2013 10:39, Ricardo Berlasso wrote:

Under Help → About OpenOffice it seems that the build system name is used
as vendor:

AOO401m3(Build:9712)  -  Rev. 1520285
2013-09-05 14:04 - Linux x86_64

Copyright © 2013 aoo_centos5_64.

Este producto fue creado por aoo_centos5_64, basado en Apache OpenOffice


Good point. I'll remove the vendor option for the official builds from 
my configure script.


Herbert

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

Re: EXTERNAL: Re: Building comphelper

[Herbert Duerr]

On 07.09.2013 00:17, Steele, Raymond wrote:

To address the isfinite() issue I added the following to rtl/math.hxx:

#ifdef SOLARIS
#undef SAL_MATH_FINITE
#define SAL_MATH_FINITE(d) finite(d)
#endf

Your links were very helpful. Thanks so much.


Wonderful, so this problem is mostly solved. We just need to get it 
cleanly into the mathconf.h. How about this patch?


--- main/sal/inc/sal/mathconf.h
+++ main/sal/inc/sal/mathconf.h
@@ -55,7 +55,9 @@ extern "C" {


 /* SAL_MATH_FINITE(d): test double d on INFINITY, NaN et al. */
-#if defined(__GNUC__) // workaround gcc bug 14608
+#if defined(OS2) || defined(SOLARIS)
+   #define SAL_MATH_FINITE(d) finite(d)
+#elif defined(__GNUC__) // workaround gcc bug 14608
#if (__GNUC_MINOR__ >= 3) // gcc>=4.3 has a builtin
#define SAL_MATH_FINITE(d) __builtin_isfinite(d)
#else
@@ -67,8 +69,6 @@ extern "C" {
#define SAL_MATH_FINITE(d) isfinite(d)
 #elif defined( WNT)
 #define SAL_MATH_FINITE(d) _finite(d)
-#elif defined OS2
-#define SAL_MATH_FINITE(d) finite(d)
 #elif defined LINUX || defined UNX
 #define SAL_MATH_FINITE(d) finite(d)
 #else /* WNT, LINUX, UNX */


Now onto:

integer_fwd.cpp contains the following on line 136 and 137:

136: template < > 137: struct low_bits_mask_t< ::std::numeric_limits::digits>;


I'm not sure whether you saw my mail from September 2nd 
(http://markmail.org/message/bt7bazzvb6zionee):


https://issues.apache.org/jira/browse/STDCXX-937 might have to do with 
this. It mentions a compiler bug 6703971 but that doesn't seem to be 
available any more. I suggest to update the compiler to its latest patch 
level.


Of course it would also interesting to know what type 
::std::numeric_limits::digits on that platform. The error 
message looks as if this was not an integer but a class. The C++ spec 
requires that the type should be an int. Please check the  
include file.


Herbert

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

Re: EXTERNAL: Re: Building comphelper

[Herbert Duerr]

Hi Raymond,

On 07.09.2013 02:17, Steele, Raymond wrote:

Problem after problem.


So far the problems where quite trivial platform differences. Of course 
the problems only become simple after their root cause is understood ;-)



Now I am getting:

Entering /opt/aoo-4.0.0/main/configmgr/source

Compiling: configmgr/source/partial.cxx
"/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 199: Error: Could not find a match for 
boost::tuples::get(const 
boost::tuples::tuple) needed in 
boost::unordered::detail::construct_from_tuple(configmgr::Partial::Node*, const boost::tuples::tuple&).
"/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 350: Where: While instantiating 
"boost::unordered::detail::construct_from_tuple(configmgr::Partial::Node*, const boost::tuples::tuple&)".
"/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 350: Where: Instantiated from 
boost::unordered::unordered_map, 
_STL::equal_to, _STL::allocator<_STL::pair>>::operator[](const rtl::OUString&).
"/opt/aoo-4.0.0/main/configmgr/source/partial.cxx", line 82: Where: 
Instantiated from non-template code.
1 Error(s) detected.
dmake:  Error code 2, while making '../unxsoli4.pro/slo/partial.obj'


What version of AOO are you building? AOO trunk? AOO400 or AOO401? If 
you're not building AOO trunk I suggest to apply my change from revision 
1515285 to it and recompile configmgr. If it helps then the change is a 
candidate to be merged into the release branch as well.


[1] http://svn.apache.org/viewvc?view=revision&revision=1515285

Herbert

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

Re: Example of spreadsheet formula testing

[Herbert Duerr]

On 09.09.2013 22:03, Andrea Pescetti wrote:

On 03/09/2013 Herbert Duerr wrote:

That's a good idea. Here is a first very rough draft:
https://blogs.apache.org/roller-ui/authoring/preview/OOo/?previewEntry=writing_spreadsheet_test_cases_now


That link is behind an editor password. Here's the public preview link:

https://blogs.apache.org/preview/OOo/?previewEntry=writing_spreadsheet_test_cases_now


And the post is nice too! I would just add something about how people
can help. I assume the best way is to contact the QA list and say that
they could contribute testcases.


Good idea. And thanks for the feedback! I'm afraid I have to postpone 
working on it until we released 4.0.1, though.



Since testcases must be attached anyway, one way to get them could be to
open a specific issue in Bugzilla and attach testcases to is as they
become available.


Yes. And I'm sure that we already have quite a few test documents in 
bugzilla that need just a few tweaks to be usable for automated this 
automated formula testing.


Herbert

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

Re: EXTERNAL: Re: Building comphelper

[Herbert Duerr]

On 09.09.2013 19:59, Steele, Raymond wrote:

I am using trying to build the source code that I pulled from here:

http://www.apache.org/dist/openoffice/4.0.0/source/


Thanks for the info. Now I know better what to patch.


I make the changes to my local copy of the files specified at  
http://svn.apache.org/viewvc?view=revision&revision=1515285

Now, I am receiving the following. Looking into the cause now.
[...]
"/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/stl/_tree.c", line 590: Error: Too many 
arguments in call to "rtl::OUStringHash::operator()(const rtl::OUString&) const".
[...]


The patch in the revision I mentioned was for a newer branch than 
AOO400: To adapt it to your tree please keep the patched partial.hxx and 
revert modifications.hxx to its original.


Herbert

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

Re: EXTERNAL: Re: Building comphelper

[Herbert Duerr]

Hi Raymond,

On 09.09.2013 19:13, Steele, Raymond wrote:

Thanks for the information. I attached the new mathconf.h file with your
patch. I then did a clean build and it compiles without error.


Good. I created an issue ("Adaptions for building AOO 4.0.0 on Solaris") 
for all such adaptions that we'll find. I already attached the patch for 
mathconf.h there.


[1] https://issues.apache.org/ooo/show_bug.cgi?id=123228


   I am
not sure about what you'd like me to provide when you say , " Of course
it would also interesting to know what type
::std::numeric_limits::digits on that platform." Could
you provide more details? Thanks.


In your platform's  include file there are probably 
specializations for numeric_limits template. The symptoms of the error 
message look as if there was no template specialization for 
numeric_limits. Is this so? Please check the  
include file. In case you are using gcc then you could use the "-E" 
option to see the preprocessed source (with the  file included).


Another trick is to create a line
struct Dummy{} dummy = ::std::numeric_limits::digits;
in one of the functions and  when compiling there will be an error 
message about an invalid assignment that hopefully provides enough 
detail about the type of this digits member.



Also,

I've found a couple other things that you may be interested in.


Sure. I suggest to collect these findings in the newly created task 
123228 I referenced above [1].



1. The generated bootstrap script will not execute after configure
because of like 64. I've had to change it like this:

  -  dmake_full_package_name=$(find $TARFILE_LOCATION
-type f -name "*-$dmake_package_name")

  +  dmake_full_package_name=`find $TARFILE_LOCATION
-type f -name "*-$dmake_package_name"`


Good. I attached this patch to issue [1] too. It replaces the bash-ism 
with generic shell code.



2.  I keep receiving the following each time I do a clean build:
[...]
Compiling: basebmp/source/bitmapdevice.cxx
"/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/vigra/mathutil.hxx",
line 801: Error: erf is not a member of _STL.


According to the C99 standard the error function erf() should be 
provided via math.h. If this is not so then vigra could provide the 
function itself if the macro VIGRA_HAS_ERF was not defined. For some 
reason that macro gets defined for Solaris in

/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/vigra/config.hxx
for __sun && !__GNUC__ Vigra's commit message regarding this was
   "added configs for Sun C++ (very incomplete)
which shows that there is room for improvement. I added an experimental 
patch for vigra to the issue [1]. Please try it out.


Herbert

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

Re: EXTERNAL: Re: Building comphelper

[Herbert Duerr]

On 10.09.2013 19:29, Steele, Raymond wrote:

I cannot seem to figure out which  integer_fw.hpp is using on my 
system.  I put the following in scopeguard.cxx and received a

void ScopeGuard::dismiss()
{
 struct Dummy{} dummy = ::std::numeric_limits::digits;
 m_func.clear();
}


Here is the output.
[...]
"/usr/local/include/boost/integer_fwd.hpp", line 138: Error: Illegal value for 
template parameter.
"/usr/local/include/boost/integer_fwd.hpp", line 138: Error: Cannot use class 
specialization with non-classes.
"/opt/aoo-4.0.0/main/comphelper/source/misc/scopeguard.cxx", line 63: Error: 
Cannot use const int to initialize Dummy.


Ah, so this shows that the digits member is a const int as it should be.
Why low_bit_mask_t<> doesn't like the specialization with int is 
strange, because in my boost/integer/integer_mask.hpp only allows 
integer specializations (for std::size_t)!


What is also interesting is the location of the integer_fwd.hpp header 
file: /usr/local/include/boost/
Are you using "--with-system-boost" or "--with-system-headers"? What 
version of boost is installed on your system? AOO's current reference 
implementation of boost is 1.48.



I did a search for all the limits files on my system. Here are the results.:

bash-3.2# find / -name limits
/usr/sfw/include/c++/3.4.3/limits
/usr/include/stdcxx4/limits
/usr/local/include/boost/mpl/limits
/usr/local/include/boost/tr1/tr1/limits
/usr/local/include/boost_52/mpl/limits
/usr/local/include/boost_52/tr1/tr1/limits
/usr/local/gcc-4.8.1/include/c++/4.8.1/limits
/opt/aoo-4.0.0/main/stlport/unxsoli4.pro/inc/stlport/limits
/opt/aoo-4.0.0/main/stlport/unxsoli4.pro/inc/stlport/SC5/limits
/opt/aoo-4.0.0/main/stlport/unxsoli4.pro/misc/build/STLport-4.0/stlport/limits
/opt/aoo-4.0.0/main/stlport/unxsoli4.pro/misc/build/STLport-4.0/stlport/SC5/limits
/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/limits
/opt/aoodeps/perl-5.18.1/cpan/Devel-PPPort/parts/inc/limits
/opt/aoodeps/STLport-5.2.1/stlport/limits
/opt/aoodeps/boost_1_48_0/boost/mpl/limits
/opt/aoodeps/boost_1_48_0/boost/tr1/tr1/limits
/opt/aoodeps/gcc-4.8.1/libstdc++-v3/testsuite/18_support/headers/limits
/opt/aoodeps/gcc-4.8.1/libstdc++-v3/include/std/limits
/opt/solarisstudio12.3/prod/include/CC/Cstd/limits
/opt/solarisstudio12.3/prod/include/CC/stlport4/limits
/boost_1_54_0/boost/mpl/limits
/boost_1_54_0/boost/tr1/tr1/limits
/gcc-4.8.1.OLD/include/c++/4.8.1/limits


Darn, these are a lot of  file. If the compiler picks one that 
is not consistent with the related include files then all kinds of 
troubles are not surprising.


To find out which  file is included you could use the gcc option 
"-E", that tells the compiler to just preprocess a source file and 
output the preprocessed result to the output file specified by "-o".


As an example change into the configmgr directory and
   build verbose=true
there. You'll see the exact command line for the compiler building e.g. 
partial.cxx. Change the "-c" option ("compile") to "-E" ("preprocess 
only") and run this one command line. The resulting partial.o is the 
preprocessed source that will show you which  was included.



Lastly,
The following patch seems to address the erf() issue. I edited 
/opt/aoo-4.0./main/solver/400/unxsoli4.pro/inc/vigra/config.hxx with the 
following and it seems to compile without error.  However, isn't 
/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/vigra/config.hxx generated by 
the build. Should this be modified somewhere else?


When external libraries are built the process is as follows:
1. the tarball of the library is unpacked
2. some patches are applied (for vigra its the file "vigra-1.6.0.patch")
3. the library is built
4. the library is delivered to "solver"

Though modifying the header in solver can temporarily solve a compile 
problem in a dependent module (e.g. basebmp) it is better to do the 
needed modification before the library is built to get a consistent 
state. To get the patch in as early as possible the patch file has to be 
modified. As mentioned yesterday I already attached a patch against 
"vigra-1.6.0.patch" to issue 123228.


By the way, did the modified vigra config.hxx allow basebmp to be built?

Herbert

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

Re: IA2 Branch r1519381 IAccessible2 testing - failed Buildbot

[Herbert Duerr]

On 12.09.2013 05:21, V Stuart Foote wrote:

Look to again have a clean and installable build of the IA2 branch --
r1519381 (wef 2013-09-02)-- to start working against.


The latest builds #232 (forced by Andrew) and #233 (regular nightly 
build) were both successful [1] and built rev 1519381.


[1] http://ci.apache.org/projects/openoffice/

Herbert

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

Re: bug 107063 (needs update)

[Herbert Duerr]

On 12.09.2013 11:34, bugreporte...@hushmail.com wrote:

Can someone please tell me how to change the "Latest Confirmation on:" field in 
a bug report on bugzilla?


You have to be logged in for doing that. There is no userid 
"bugreporter99" and there are no issues mentioning this userid [1]. What 
is your userid in AOO's bugzilla?


[1] http://s.apache.org/bz_bugreporter99


Don't get me wrong but can someone also tell me if Oliver Specht is still 
working on OpenOffice cause the first bug is from 2003?


He isn't active in the AOO community.

Herbert

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

Re: IA2 Branch r1519381 IAccessible2 testing - failed Buildbot

[Herbert Duerr]

Hi Jean-Philippe,

On 12.09.2013 21:02, MENGUAL Jean-Philippe wrote:

Could you tell me if there's a binary of this branch?  I no longer find
any downloadable binary for OOo with IA2.


Please see http://ci.apache.org/projects/openoffice/#w7ia2 for the 
windows install pack of the latest IA2 build. There are two packages 
there: one for the application and one for the SDK. Please install the 
application, not the SDK.


Enjoy!

Herbert


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

Re: EXTERNAL: Re: Building comphelper

[Herbert Duerr]

On 12.09.2013 20:15, Steele, Raymond wrote:

Yes,  the modified vigra config.hxx allowed basebmp to be built. I  am using 
--with-system-boost, however,  I just did a reconfigure after removing it and 
ran into issues during the boost build. I receive the following hundreds of 
times until it fails.


Good, so the vigra erf() problem can be considered as solved.


/usr/sfw/bin/gtar: Archive value 4294967295 is out of gid_t range 
-2147483648..2147483647
[...]

I am not sure why. Looking into it now.


I found [1] ("Whoever created that tar file did so on a platform that 
allows gid_t values of 32bits."), and this probably means the boost 
tarball was packed on a too new system. Or that gtar on your system 
needs to be updated.


[1] http://comments.gmane.org/gmane.comp.gnu.mingw.msys/4816


Also, here is filtered output from the CC -E of partial.cxx.  I grep'd for 
limits, as you can see in the command  I issued.

bash-3.2# /opt/solarisstudio12.3/bin/CC -E -temp=/tmp -xarch=generic -xO3 
-DENABLE_LAYOUT=0 -DENABLE_LAYOUT_EXPERIMENTAL=0   -xldscope=hidden -I. 
-I../unxsoli4.pro/inc/configmgr -I../inc -I../inc/pch -I../inc -I../unx/inc 
-I../unxsoli4.pro/inc -I. -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl 
-I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/external 
-I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc 
-I/opt/aoo-4.0.0/main/solenv/unxsoli4/inc -I/opt/aoo-4.0.0/main/solenv/inc 
-I/opt/aoo-4.0.0/main/res -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl 
-I/opt/solarisstudio12.3/include -I/opt/aoo-4.0.0/main/solenv/inc/Xp31 
-I/usr/jdk/latest/include -I/usr/jdk/latest/include/solaris 
-I/usr/jdk/latest/include/native_threads/include: -I/usr/local/include 
-I/usr/include -I/usr/local/include/boost 
-I/opt/solarisstudio12.3/prod/include/CC/Cstd/ -I/usr/local/include/rasqal: 
-I/usr/local/include -I/usr/include -I/usr/local/include/boost 
-I/usr/local/include/rasqal -I/usr/include/std

cxx4  -I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/offuh -I. -I../res -I. 
-features=no%altspell -library=no%Cstd "-features=rvalueref" +w2 
-erroff=doubunder,identexpected,inllargeuse,inllargeint,notemsource,reftotemp,truncwarn,wnoretvalue,anonnotype
   -KPIC -mt -DSOLARIS -DUNX -DVCL -DC52 -DC52 -DINTEL -D_PTHREADS -DSYSV -DSUN -DSUN4 
-D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DSTLPORT_VERSION=400 -D__DMAKE -DUNIX 
-DCPPU_ENV=sunpro5 -DSUPD=400 -DPRODUCT -DNDEBUG -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DCUI 
-DSOLAR_JAVA   -DSHAREDLIB -D_DLL_-DEXCEPTIONS_ON  -o /tmp/file 
/opt/aoo-4.0.0/main/configmgr/source/partial.cxx|grep -i limit

The compiler option "-library=no%Cstd" could have introduced some 
trouble. In AOO 4.0 we want to use this compiler STL (wrapped with 
boost's TR1 library to fill the missing TR1 pieces and for easier porting).


I see this flag is set in
main/solenv/inc/unxsol*.mk
and in
main/solenv/gbuild/platform/solaris.mk
and suggest to remove it in all places.


#1 "/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/climits.SUNWCCh"


This header shouldn't be there if your configure step used the 
"--without-stlport" option. If you didn't use the option then please 
reconfigure the AOO build using it.


Please see e.g. the Linux configure options in [2] as a reference.

[2] 
https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds


> [other lines matching a grep for "limit"]

These other grepped lines are interesting too, but with the two 
suggestions I made things could change considerably here.


Herbert

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

Re: EXTERNAL: Re: Building comphelper

[Herbert Duerr]

Hi Raymond,

On 16.09.2013 19:40, Steele, Raymond wrote:

I removed the -library=no%Cstd from the two files and performed a clean build, 
but still have the same issues. Also, I am untarring the BOOST package version 
1.48  so I downloaded the zipped version and unzipped it, placed the resulting 
boost directory in /usr/local/include after using --with-system-boost 
configuration. Still no luck.  I also reconfigured with --without-stlport.



It still appears that I it is using 
/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl/climits.SUNWCCh.


This file should and cannot be there if the --without-stlport build was 
clean. For its recipe see main/stlport/makefile.mk. Please retry doing 
the --without-stlport clean build, i.e. main/solver and */unxsoli4.pro 
output directories removed.


Herbert

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

Re: EXTERNAL: Re: Building comphelper

[Herbert Duerr]

Hi Raymond,


I found hash_set in ../main/stlport/systemstl

Is that where it is supposed to be.


Yes.


Once, I added this to my SOLARINC and SOLARINV environment variables, 
everything was okay, but then I received a

"/usr/local/include/boost/tr1/detail/config_all.hpp", line 161: Error: Could not open 
include file<../include/utility>


The  header should come somewhere from your c++ compiler 
includes.  According to [1] it should be there somewhere. If it is not 
found we need to put its path at the end of the include paths.


[1] http://docs.oracle.com/cd/E19205-01/819-5267/bkajw/index.html

Sorry for the late answer. I was busy with AOO401rc3.

Herbert

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

Re: EXTERNAL: Re: Building comphelper

[Herbert Duerr]

Hi Raymond,

On 20.09.2013 19:52, Steele, Raymond wrote:

No problems on the delay. I am very greatful for your assistance!!

Here is my compiler command and below are locations of my utility file. 
Hopefully this may help. I added utility to the include path, but still no luck.

bash-3.2# /opt/solarisstudio12.3/bin/CC  -c -temp=/tmp -xarch=generic -xO3 
-DENABLE_LAYOUT=0 -DENABLE_LAYOUT_EXPERIMENTAL=0   -D_FILE_OFFSET_BITS=64 -I. 
-I../../unxsoli4.pro/inc/oslall -I.. /inc -I../../inc/pch -I../../inc 
-I../../unx/inc -I../../unxsoli4.pro/inc -I. 
-I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/stl 
-I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/externa l 
-I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc 
-I/opt/aoo-4.0.0/main/solenv/unxsoli4/inc -I/opt/aoo-4.0.0/main/solenv/inc 
-I/opt/aoo-4.0.0/main/res -I/opt/aoo-4.0.0/main/solver/400/unx 
soli4.pro/inc/stl -I/opt/solarisstudio12.3/include 
-I/opt/aoo-4.0.0/main/solenv/inc/Xp31 -I/usr/jdk/latest/include 
-I/usr/jdk/latest/include/solaris -I/usr/jdk/latest/include/native_threads 
/include: -I/usr/local/include -I/usr/include -I/usr/local/include/rasqal 
-I/usr/include/stdcxx4 -I/opt/aoo-4.0.0/main/stlport/systemstl/: 
-I/usr/local/include -I/usr/include -I/usr/local/i nclude/rasqal 
-I/usr/include/stdcxx4 -I/opt/a

oo-4.0.0/main/stlport/systemstl/: -I/usr/local/include -I/usr/include 
-I/usr/local/inclue/rasqal -I/opt/aoo-4.0.0/main/stlport/systemstl/ -I/opt 
/solarisstudio12.3/prod/include/CC/Cstd/  
-I/opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/offuh -I. -I../../res -I. 
-features=no%altspell "-features=rvalueref" +w2 -erroff=doubunder,ident 
expected,inllargeuse,inllargeint,notemsource,reftotemp,truncwarn,wnoretvalue,anonnotype   
-KPIC -mt -DSOLARIS -DUNX -DVCL -DC52 -DC52 -DINTEL -D_PTHREADS -DSYSV -DSUN -DSUN4 
-D_REENTRANT -D _POSIX_PTHREAD_SEMANTICS -DSTLPORT_VERSION=400 -D__DMAKE -DUNIX 
-DCPPU_ENV=sunpro5 -DSUPD=400 -DPRODUCT -DNDEBUG -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DCUI 
-DSOLAR_JAVA  -DEXCEPTIONS_ON  -o . ./../unxsoli4.pro/obj/debugbase.o 
/opt/aoo-4.0.0/main/sal/osl/all/debugbase.cxx

"/usr/local/include/boost/tr1/detail/config_all.hpp", line 161: Error: Could not open 
include file<../include/utility>.

[...]
/usr/include/stdcxx4/utility
[...]
/opt/solarisstudio12.3/prod/include/CC/Cstd/utility


I think one of these two header files is the one we are looking for.
Boost is using the "relative include path" trick with its 
BOOST_TR1_STD_HEADER() macro because the neat "include_next" extension 
is not supported in the solaris compiler.


One of the BOOST_TR1_STD_HEADER defines in config_all.hpp is looking for 
the stdcxx4 path. I wonder why it isn't picked up. Either
1. one of the defines is wrong (__SUNPRO_CC,__STD_RWCOMPILER_H, 
___RWSTD_VER) or boost erroneously doesn't pick it up
2. the -I/opt/solarisstudio12.3/prod/include/CC/Cstd/ part of the 
compile options should be changed to find /usr/include/stdcxx4/ instead

3. the BOOST_TR1_STD_HEADER define should be changed to "../Cstd/"

Which of the alternatives 2. or 3. is better depends on which of both 
STL header sets better implements C++'s std templates as defined in TR1. 
From the name I'd guess the Cstd one is better.



/opt/solarisstudio12.3/prod/include/CC/stlport4/utility

I found this about Solaris 11, but the fix appears to be included in boost 
version 1_48 (Mine is attached).

https://svn.boost.org/trac/boost/ticket/5111


Interesting. Maybe the above and this are related.

Hope that helps. Have a nice weekend!

Herbert
(about to upload AOO401rc3 to the snapshot page)


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

Re: [RELEASE]: propose a further RC3 for AOO 4.0.1

[Herbert Duerr]

Hi Yuzhen,

On 22.09.2013 10:47, Yuzhen Fan wrote:

For RC3, could you please share a little bit more on the impact to the
functions of the AOO, from testing perspective? QE have been doing RC build
acceptance test on RC1 and RC2 from last week, we'd like to know then
evaluate what level test we need to consider for RC3. Thanks!


Thanks for asking. I created the detailed list of changes and issues 
fixed by RC3: http://people.apache.org/~hdu/izlist_aoo401_rc2_vs_rc3.htm


In short the relevant changes were fixes for the AOO's SDK on Windows, 
which is only developer-testable and it doesn't impact end users. 
Another important update in the respin was that the just finished 
Turkish translation was integrated for RC3, even though it was way past 
the original l10n deadline.


So from an end-user perspective RC2 and RC3 are identical except that 
now there is a Turkish localization. All testing results can be reused.


Herbert

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

Re: [RELEASE]: propose a further RC3 for AOO 4.0.1

[Herbert Duerr]

Hi Yuzhen,

On 22.09.2013 10:47, Yuzhen Fan wrote:

For RC3, could you please share a little bit more on the impact to the
functions of the AOO, from testing perspective? QE have been doing RC build
acceptance test on RC1 and RC2 from last week, we'd like to know then
evaluate what level test we need to consider for RC3. Thanks!


Thanks for asking. I created the detailed list of changes and issues 
fixed by RC3: http://people.apache.org/~hdu/izlist_aoo401_rc2_vs_rc3.htm


In short the relevant changes were fixes for the AOO's SDK on Windows, 
which is only developer-testable and it doesn't impact end users. 
Another important update in the respin was that the just finished 
Turkish translation was integrated for RC3, even though it was way past 
the original l10n deadline.


So from an end-user perspective RC2 and RC3 are identical except that 
now there is a Turkish localization. All testing results can be reused.


Herbert

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

Re: [VOTE]: Release Apache OpenOffice 4.0.1 (RC3)

[Herbert Duerr]

this is a call for vote on releasing the RC3 release candidate as
Apache OpenOffice 4.0.1. This will be an important update release for
Apache OpenOffice 4.0 to fix some serious regressions and to introduce
some new languages (Basque, Khmer, Lithuaian, Polish, Serbian Cyrillic,
Swedish, Turkish, Vietnamese and Chinese Traditional). It is a further
key milestone to continue the success of OpenOffice.
[...]
The RC is based on the release branch AOO401, revision 1524958!

Please vote on releasing this package as Apache OpenOffice 4.0.1.
[...]
[ ] +1 Release this package as Apache OpenOffice 4.0.1
[ ]  0 Don't care
[ ] -1 Do not release this package because...


+1 : release AOO401rc3 (a.k.a. r1524958) as Apache OpenOffice 4.0.1

Herbert


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

[RESULT][VOTE] Release Apache OpenOffice 4.0.1 (RC3)

[Herbert Duerr]

Tallying the answers to the release vote [1] resulted in ten binding +1, 
four non-binding +1 and one non-binding -1 votes. No other votes were cast.


[1] 
http://mail-archives.apache.org/mod_mbox/openoffice-dev/201309.mbox/%3C523EA4EB.8080608%40gmail.com%3E


The one negative vote has a lot of merit, especially as the issues 
mentioned were brought to our attention by our very experienced and 
highly respected community member Yu Zhen. On the other hand the 
problems raised were already in AOO 4.0.0 and didn't block the release 
then. They were also not reported, suggested or discussed as release 
blockers ever since until today. They deserve attention but the vote 
result indicates that they shouldn't block the release of Apache 
OpenOffice 4.0.1.


So the vote result is: Apache OpenOffice r1524958 shall be released as 
Apache OpenOffice.


Here is the detailed vote tally, sorted by voter choice and name.

-1:

Yuzhen Fan

+1:

Andrea Pescetti (binding)
Armin Le Grand (binding)
Bonnie Kim
Dirk Groskamp
Herbert Dürr (binding)
Jan Iverson (binding)
Kay Schenk (binding)
Kazunari Hirano (binding)
Marcus Lange (binding)
Michal Hriň
Oliver-Rainer Wittmann (binding)
Regina Henschel (binding)
Ricardo Berlasso (binding)
Vladislav Stevanovic

I'll create the AOO401 revision tag from revision 1524958. The official 
release announcement will follow in the near future.


Herbert

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

Re: [RELEASE] finishing release notes

[Herbert Duerr]

Hereby I request everybody to have a look at the current draft release
notes for AOO 4.0.1 [1] in order to complete and 'tuned' them.

[1]
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0.1+Release+Notes


Also having more translations is encouraged.


P.S.: Personally, I am currently not sure about mentioning in the
release notes that the performance of the saving .xls files had been
improved.


Many users complained about the XLS file saving performance. For them 
the considerable performance increase of 4.0.1 relative to 4.0.0 is 
quite noteworthy. Whether such a change is a fix, a boost, an 
enhancement, an improvement or just a task done is a point that could 
fill a whole dissertation. Whether these distinct terms overlap or not 
or how much opens another research topic for linguists. But I think we 
can agree that it is noteworthy.


Herbert

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

Re: Reminder: Time to update your entry in the Directory of Volunteers

[Herbert Duerr]

Николай Нинков wrote:
> Because the translation of Bulgarian is almost ready, please do for me a dev
> snapshot with the Bulgarian translation to carry out the necessary tests.
> I do not want to promise but I will try to handle the tests so that you  turn
> the Bulgarian translation in the new Release 4.0.1.

I have to admit that I don't know how get a *sdf file out of pootle. But
if someone can provide me with the latest *sdf file for Bulgarian I'd
volunteer to do a snapshot build for it. I extend that offer also for
Danish as that just got ready.

The builds would be quite similar to the soon to be expected AOO 4.0.1,
but only similar because the revision number approved for the official
4.0.1 release would not have the latest *sdf files.

I look forward to the near future when we'll be able to skip the SDF
step and use the pootle files directly.

> Wish me success.

I wish you a lot of success! ;-)

Herbert

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

Re: Building for MAC OS, gcc 4.0

[Herbert Duerr]

Hi Tal,

On 26.09.2013 22:21, Tal Daniel wrote:

Following the Building guide for MAC, I need help.
My gcc version is 4.2, and the configure script outputs a warning that it
needs 4.0.
Is it a blocker? Do I need to install another gcc?


...


checking the GNU gcc compiler version... configure: error: You need to use

the gcc-4.0 compiler (gcc 4.2.1 won't work with the MacOSX10.4u.sdk) - set
CC accordingly


GCC 4.2 on Mac means that you are probably using XCode4. Building our 
official releases still requires XCode3 with its gcc4.0. If installing 
the older XCode3 with the OSX10.4 SDK is possible for you then this 
would be the fastest solution to get a build.


We/Me are working on supporting newer MacOSX build environments. If you 
are adventurous you might want to try out my "rejuventate01" branch [1]. 
As you saw the build requirements for our current OSX release are so 
ancient that there are very few developers left with such an old 
environment. The rejuvenation of the OSX platform support is really 
needed. Be warned: The branch is experimental, unfinished and has some 
rough edges. It already produces quite usable binaries [2]. Having other 
developers work on the branch too would be great. I hope I'll find the 
time to get back into it again soon.


[1] http://svn.apache.org/repos/asf/openoffice/branches/rejuvenate01/
[2] http:http://people.apache.org/~hdu/AOO_Mac64_rejuv.dmg

If you're interested I suggest to check this branch out, set the 
environment variables

CC=`xcrun -f clang` -arch x86_64
CXX=`xcrun -f clang++` -arch x86_64
and then continue with [3]

[3] 
http://wiki.openoffice.org/wiki/Documentation/Building_Guide/Building_on_MacOSX#Build_environment_with_enabled_category-b_dependencies



Guide I'm following step-by-step:
http://wiki.openoffice.org/wiki/Documentation/Building_Guide/Building_on_MacOSX


I'd be glad if someone can be a guide on the build process, because I'm a
bit lost from the autoconf step onwards.


The building guide is good. I updated it to make the XCode3/SDK10.4 
requirement more prominent.


Herbert


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

New localizations (was: Reminder: Time to update your entry in the Directory of Volunteers)

[Herbert Duerr]

Hi Jan,

On 27.09.2013 10:27, janI wrote:

On 27 September 2013 08:32, Herbert Duerr  wrote:


Николай Нинков wrote:

Because the translation of Bulgarian is almost ready, please do for me a

dev

snapshot with the Bulgarian translation to carry out the necessary tests.
I do not want to promise but I will try to handle the tests so that you

  turn

the Bulgarian translation in the new Release 4.0.1.


I have to admit that I don't know how get a *sdf file out of pootle. But
if someone can provide me with the latest *sdf file for Bulgarian I'd
volunteer to do a snapshot build for it. I extend that offer also for
Danish as that just got ready.



I think only 2 people know that, which is why I wrote a docu about a year
ago. juergen is the real guru.

I nobody beats me to it, I will give it a shoot during the weekend (I have
already done for it danish, but not committed it).


Wonderful, thanks for the offer!


Can I commit it to trunk ?


Yes. please do.

Having it on trunk would have the additional benefit that we add them to 
the schedule of our regular buildbots. New localizations benefiting from 
a few rounds of polishing wouldn't be surprising. AFAIK trunk and the 
AOO401 branch are still 100% compatible from a localization perspective.


Herbert


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

Re: Building for MAC OS, gcc 4.0

[Herbert Duerr]

On 27.09.2013 13:39, Tal Daniel wrote:

Thank you Herbert, I'm using Xcode 3.2.6, with gcc 4.2, so I'll wait with
your branch.


Oh, if you already XCode 3 then you're probably almost all set: Please check
ls -l /usr/bin/gcc*
AFAIK on a typical XCode3 system there should be gcc-4.0 and gcc-4.2. I 
can't remember whether there was an install option to install the older 
version.


If I read the configure script correctly it tries to find this gcc-4.0 
version and would use it if it was there.


Regarding the 10.4 SDK I'm quite sure it was optional with XCode3's 
package installer. That one defaults to only install SDK 10.5 and 10.6. 
I you'll have 10.4 you are probably only two hours away from your own 
AOO build! :-)



Thanks for the invite.
Today I've managed to install & switch to gcc 4.0 using MacPorts


I'm not sure if the MacPorts gcc 4.0 will work. Better check whether the 
older compiler version was an optional part of XCode3 and use that if 
possible.



(I'll update the Guide, when I'm done).


Wonderful, thanks in advance!

Herbert

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

Re: [Mac] [Build] python headers not found

[Herbert Duerr]

On 27.09.2013 13:51, Tal Daniel wrote:

Hi, I'm trying to follow the Building Guide for Mac,
and not I'm struggling with Python: the configuration shell script can't
find the Pyhon header files (python.h, ...).


Jürgen recently [1][2] updated the python baseline to Python 2.7

[1] https://issues.apache.org/ooo/show_bug.cgi?id=122010
[2] 
http://svn.apache.org/viewvc/openoffice/trunk/main/configure.in?r1=1485654&r2=1485653&pathrev=1485654



I installed [mac]port python33


I'm not sure whether a build against Python 3.3 is already possible


, and switched to it, and I know where its
headers folder is located.
I tried to change configure file, but it keeps reseting so I can't change
anything there (e.g. the PYTHON_CFLAG var).


Change the "configure.in" file, not the "configure" file! Then run 
autoconf to get the new and shiny and patched configure script ;-)


Hope that helps,
Herbert

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

Re: [Accessibility] Calc and Impress got complete ia2 support -- (aoo-w7ia2) Buildbot currently failing

[Herbert Duerr]

On 27.09.2013 15:44, V Stuart Foote wrote:

Great news!  Once we have a useable build...

I just checked and the current r1526782 based ia2 branch is failing snapshot
Buildbot for "svn under cygwin"

So the (aoo-w7ia2) Buildbot for the ia2 branch again needs some attention.


bb-win7 says:

svn: E155004: Working copy '/cygdrive/e/slave14/aoo-w7ia2/build_svn' locked.
svn: E155004: '/cygdrive/e/slave14/aoo-w7ia2/build_svn' is already locked.
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)

Andrew, can you help us out here? AFAIK you're the only one of us who 
has direct access to the machine in question (bb-win7).


Herbert

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

Re: [Mac] [Build] python headers not found

[Herbert Duerr]

Hi Tal,

On 28.09.2013 11:14, Tal Daniel wrote:

Herbert, thank you updating me on the SVN update, which updated Python
definitions in configure.in; it makes things much more easier now, since
Jürgen points now to the current version of Python.

Would you share with us how do you track SVN updates? do you use Eclipse,
or other tool? cmd-line?


Yes, I use the command-line of plain svn and I'd do it for all work with 
the repository if there wasn't git-svn which is much more convenient for 
my preferred workflow.


To get things going I'd suggest to start with plain svn though. Getting 
to know one version control system first is easier than learning two at 
the same time and dealing with their interactions.


I'd also recommend iterm2 which makes working on the command line on Mac 
more convenient.



For now, I've decided to sync & build AOO401 tag, which is more stable, I
guess.


Yes, that's a good approach.

Herbert


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

Re: [MAC][Build] Error at soltools mkdepend

[Herbert Duerr]

On 28.09.2013 12:40, Tal Daniel wrote:

Hi, I get an error while building (below).
Can anyone guide me how to check its source, and how can I get a more
detailed error report? or... how to try to compile only this part in Xcode
3.2.6?
[...]

1 module(s):
soltools
need(s) to be rebuilt


Changing into the directory in question i.e.
cd ../soltools
then running
build verbose=1
there and checking its output should provide all details known about the 
build problem.


Herbert


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

Re: AOO 4 unusable under Linux64?

[Herbert Duerr]

On 29.09.2013 21:12, Edwin Sharp wrote:

[...]
Not sure what is meant by Crash bug, but here is relevant information:
Current distribution I use: http://www.aptosid.com/


A great distribution, I use that too!


AOO was installed from arc file of the Buildbots.


Ah, that's the reason. Linux has a different development philosophy than 
most other platforms. On other platforms you tell the compiler to target 
a specific baseline (e.g. OSX 10.4 or Windows XP). On Linux the 
philosophy used to be "just recompile if any of the libraries changed 
its APIs" or "update from your system's specific package repository 
where one of the maintainers did that for you". Things have gotten much 
better since but selecting a target API is still not easily possible.


So to solve this for our releases we use the "greatest common 
denominator" approach on Linux: Linux nowadays tries not to break older 
binaries, so we're using a very old system for building the packages. A 
system old enough that most current systems can work with it.


These ancient systems are how we build our releases and release snapshots.

Now the Linux64 buildbot uses Ubuntu 10.4 and the Linux32 buildbot runs 
on Ubuntu 12.4. These systems are quite new and their new compilers are 
much better than what is provided by the "greatest common denominator " 
systems, which enables them to find and report important bugs. The 
drawback is that unless your system is a descendant of these newer Linux 
systems the builds they create are unusable for you.


I suggest to check the official release candidate snapshots if we're in 
the release phase. They have the maximum binary compatibility.


If you want to check the latest experimental trunk releases created by 
buildbots running new distributions I suggest to install that same 
distribution or one of its descendants.


Herbert

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

Re: svn commit: r1526917 - /openoffice/trunk/extras/l10n/source/bg/localize.sdf

[Herbert Duerr]

On 27.09.2013 16:59, janI wrote:

Please make these changes in pootle instead, otherwise we loose them
next time someone generates the sdf file, like I just did.


I just wanted to give buildbots a chance to actually build them 
independent when their SDF file gets recreated. Also my chinese, 
bulgarian or danish language skills are not nearly good enough so that 
I'm very hesitant to make translation suggestions for them. I just 
wanted to get the build going ASAP, so sorry for not going the full 
circle on a Friday evening.


The builds stumbled over other problems too anyway, so these 
translations will take more time to fix. I'm trying to solve them and 
when I find solutions I'll update pootle and svn's sdf. Please check both.


Herbert

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

Re: svn commit: r1526917 - /openoffice/trunk/extras/l10n/source/bg/localize.sdf

[Herbert Duerr]

On 30.09.2013 13:40, janI wrote:

Danish also had a problem in helpcontent2, but I solved that and committed
a new sdf file.


Thanks!


Somewhere in the future, we should find a way to avoid tags in text, and
only give translators what should be translated.


Absolutely, these tags seem to be the main source of errors. On the 
other hand the tag checking is so local and looks so simple that maybe 
we could do it directly when a translation suggestion gets made by 
pootle itself or an extension to it.


Herbert

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

Re: AOO 4 unusable under Linux64?

[Herbert Duerr]

On 29.09.2013 07:30, Rainer Bielefeld wrote:

Edwin Sharp and some other users found several bugs [1] under Linux64,
in summary the conclusion seems to be that AOO currently is more or less
unusable with Linux 64.


Please see the thread on the QA list where things start to look as if 
buildbot nightly builds where tested that were not compatible (and not 
intended to be compatible) with the system where they were tested.



Can some developers please have a look?
[...]



Most of the issues look platform independent. They seem to be reported 
against Linux64 just because this was the system the testers used and 
not because they were isolated to be Linux64 specific. So it would be 
interesting for testers on other platforms to check them too. I suggest 
that if an issue is confirmed on two or more different platforms that 
this field gets set to "ALL".


Herbert

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

Re: New localizations for testing (Danish and Bulgarian)

[Herbert Duerr]

Many thanks to Jan for providing the *sdf files and for completing the 
danish translation. I fixed the remaining tag imbalances in the 
Bulgarian translation in both Pootle and SVN.


The first test builds are available now for Bulgarian [1] and Danish 
[2]. For now only the Mac builds, Linux 64bit is uploading, Linux 32bit 
and Windows will probably become available tomorrow.


[1] http://people.apache.org/~hdu/developer-snapshots/snapshot/extra/bg/
[2] http://people.apache.org/~hdu/developer-snapshots/snapshot/extra/da/

Herbert

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

Re: New localizations for testing (Danish and Bulgarian)

[Herbert Duerr]

On 30.09.2013 21:56, Andrea Pescetti wrote:

On 30/09/2013 Herbert Duerr wrote:

The first test builds are available now for Bulgarian [1] and Danish
[2].


Now all the Bulgarian [1] and Danish [2] packages for Mac, Linux i686 
and Linux amd64 as RPM and DEB are created and uploaded. Their Windows 
counterparts will hopefully make it tomorrow.


[1] http://people.apache.org/~hdu/developer-snapshots/snapshot/extra/bg/
[2] http://people.apache.org/~hdu/developer-snapshots/snapshot/extra/da/


Thank you! It would still be helpful for translators to have the keyid
("kid") builds available too. I can't find valid reasons not to build
them: the "kid" SDF file on trunk is up-to-date, the one for 4.0.1 is at
http://people.apache.org/~pescetti/tmp/2013-09-keyid/ since 4.0.1 was
open for blockers only.


A good idea. I created language packs for the keyid pseudo-localization 
for Mac, Linux i686 and Linux amd64 as RPM and and DEB packages and put 
them next to the new languages [3]. Their Windows counterparts will 
hopefully make it tomorrow.


[3] http://people.apache.org/~hdu/developer-snapshots/snapshot/extra/kid

Seeing all the manual effort that is needed to build these localizations 
I respectfully request that translators interested in having their 
language supported do it before the localization deadline.


Herbert


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

Re: Skills, Resources and Mentors

[Herbert Duerr]

On 01.10.2013 07:14, Rainer Bielefeld wrote:

Tal Daniel schrieb:

But I couldn't edit the wiki page (I'm logged in to as Talchu).


Hi,

I can confirm that problem. I am not familiar with with cwiki, but I
added myself to "Directory of volunteers", where I currently also can't
find a way how to edit that page.

It seems currently cwiki only can be edited by very few persons?


I cannot edit pages in the cwiki either. I was able to do it last week, 
but this week I can't, because the edit-page option is missing. Is this 
lock-out a collateral damage of the release notes being protected?


Herbert

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

Re: Skills, Resources and Mentors

[Herbert Duerr]

On 01.10.2013 14:03, Rob Weir wrote:

On Tue, Oct 1, 2013 at 7:24 AM, Herbert Duerr  wrote:

On 01.10.2013 07:14, Rainer Bielefeld wrote:


Tal Daniel schrieb:


But I couldn't edit the wiki page (I'm logged in to as Talchu).



Hi,

I can confirm that problem. I am not familiar with with cwiki, but I
added myself to "Directory of volunteers", where I currently also can't
find a way how to edit that page.

It seems currently cwiki only can be edited by very few persons?



I cannot edit pages in the cwiki either. I was able to do it last week, but
this week I can't, because the edit-page option is missing. Is this lock-out
a collateral damage of the release notes being protected?



The web page says: "No edit restrictions are defined for this page".
This is under Tools/Restrictions menu item.  Do you see something
differenent?


I'm logged in and that Restrictions page says that:
No view restrictions are defined for this page
No edit restrictions are defined for this page

But the "Edit" link that used to be on the page (left to the "Share" 
link) is missing. That edit link is still visible on a page that I 
haven't refreshed since last week. I'm sure it will be gone there too if 
I reload the page. Also the "Add" link, which used to be between the 
"Share" and the "Tools" link is missing.



I was able to edit it (of course).  It looks like Andrea was as well.


Do you happen to have the admin role in our CWikis?

Herbert

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

Re: Automating Error-prone Manual Release-related Files By Using Centralized Release Artifact Metadata

[Herbert Duerr]

Rob Weir wrote:
> Every time we release we need to generate quite a few files related to
> the release.
> 
> Here's the list I know of:
> 
> 1) The ASC/SHA/MD5 hashes and signature files, one for every released file

We're using scripts for these of course. With the more than 400 packages
we're providing everything else would be insane. The checksums should
and are created on the machines they are built on to help protect the
gigabytes of data as early as possible.

> 2) A CWiki page listing all the built files with hyperlinks to hashes, etc.
> 
> https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOOSnapshot
> 
> This is used when voting on a Release Candidate.

Jürgen uses a self written script for that. AFAIK it is not publically
available yet. If needed it can be rewritten with a few lines of a
script language.

> 3) release_matrix.js, used by the download page's logic to decide what
> file to recommend based on user's locale:
> [...]
> 7) The XML files used by the upgrade notification server, one XML file
> per release:

Don't know about these. It would be stupid to do all of it manually. I
suggest the owners of these tasks share their scripts, e.g. in the
http://svn.apache.org/repos/asf/openoffice/devtools/scripts/ directory.

> How close are we to this?  Is any part of this automated already today?

The parts I'm aware of are automated.

Herbert

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

Re: [CWiki] new default access rights active

[Herbert Duerr]

On 02.10.2013 09:30, Andrea Pescetti wrote:

Oliver-Rainer Wittmann wrote:

We have already everything to whitelist CWiki users for our CWiki space
ooousers and ooodev. Members of ooo-admins group are able to whitelist.


Unfortunately, yes. So I whitelisted orw and rgb-es. Who needs
whitelisting too? Your CWiki username please (and 24 hours of patience!).


I'd like to have edit-rights (again): h...@apache.org

Herbert

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

Re: EXTERNAL: Re: Building comphelper

[Herbert Duerr]

Hi Raymond,

On 02.10.2013 17:26, Steele, Raymond wrote:

I have hit a stop work on the Solaris 10 port for now. We are in the process of 
moving over to Solaris 11. I will probably need to port OpenOffice to Solaris 
11 soon.


Thanks for the update! With the newer build environment there things 
should be easier... Hope springs eternal ;-)


Herbert

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

Re: [Mac] [Build] Successful Configuration, Example

[Herbert Duerr]

Hi Tal,

Tal Daniel wrote:
> Finally, I've managed to build AOO401 on MAC OSX 10.6.8!

Congratulations! That's an important step in joining AOO development.

> I'm publishing the steps needed, with configuration, for any comments.
> Later on, I plan to edit the Mac Building Guide wiki page, accordingly, so
> other Mac developers, please comment:
> 
> Created a folder for Apache OpenOffice code
> 
> SVN sync to tags/AOO401 (more stable code)

I'd merge these two into
svn co https://svn.apache.org/repos/asf/openoffice/tags/AOO401 myAOO401

> Created initial configuration script (build.sh), which contains:
> [...] 
>  echo "### checking for moz prebuild libs ... "
> [...]
> --disable-mozilla \
> 
>  --disable-build-mozilla \

Currently when mozilla is disabled password protection etc. doesn't
work. I suggest to remove the --disable-mozilla line when the mozilla
prebuilt libs are available.

BTW: there is work in progress to remove the insane dependency of AOO's
crypto requirements to the ancient mozilla binaries (branch Remove_MOZ)

> --enable-minimizer --enable-presenter-console

These options are no longer needed. The very popular extensions
Presenter Console and Presentation Minimizer have been merged into AOO's
core. Kudos to Ariel for that.

> build –all -P2 --html --html_path /Users/$USER/Sites/
> 
>  Build time: started ~14:15 – 00:00 = ~10

Depending on how powerful your Mac is you could try e.g.
   build --all -P3 -- -P3 ...
(three modules at once, the files at once, i.e. work for nine processors)

>  When the build is complete, opened DMG package present at
> cd unxmacxi.pro/Apache_OpenOffice_SDK/dmg/install/en-US/
> and installed into a folder of my choice. Works.

Wonderful :-) I look forward to work with you!

Herbert

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

Re: [MAC][Build] Error at soltools mkdepend

[Herbert Duerr]

Hi Tal,

Tal Daniel wrote:
> Thank you Herbert, that helped me to solve the issue.
> 
> ccache gcc was looking for Mac OSX 10.4u SDK, so ... instead of installing
> 10.4u SDK (xcode already installed), I created a symbolic link to 10.5.
> Guess what, it works!

A nice idea! And a lucky one because the 10.4 and 10.5 SDKs are not that
much different from the perspective of the AOO code base.

By the way, I'm working on upgrading the baseline of our Mac build to
64bit/SDK 10.6 and up. For more details please see [1] and [2].

[1] http://markmail.org/thread/tedxuouu327ottxq
[2] http://markmail.org/thread/g5ol64sv4oghjqor

Herbert

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

Re: AOO 4 unusable under Linux64?

[Herbert Duerr]

On 02.10.2013 15:57, Oliver-Rainer Wittmann wrote:

Hi,

On 30.09.2013 17:17, Oliver-Rainer Wittmann wrote:

Hi,

On 29.09.2013 07:30, Rainer Bielefeld wrote:

Hi all,

Edwin Sharp and some other users found several bugs [1] under Linux64,
in summary the conclusion seems to be that AOO currently is more or less
unusable with Linux 64.

Can some developers please have a look?



I will have a closer look at these issues in my Ubuntu 64bit 10.04 VM.
On this VM I have snapshots with different OpenOffice versions - namely
OOo 3.3.0, AOO 3.4.0 and AOO401RC2. Thus, I can check, if the defects
are newly introduced or already present in a former version.

I will also check on my Windows 7 64bit, if the defects are also
reproducible on this platform.



My intermediate report.
I had a look at about half of the initial 28 reported issues. Due to my
investigations the below given buglist now only shows 22 issues.
- 121322 - not my area of expertise - no investigations from my side
- 121694 - platform-independent and most likely not a bug
- 122278 - duplicate of 122279 which is platform-independent
- 122281 - platform-independent, broken since OOo 3.4Beta
- 122333 - still unclear and unconfirmed
- 122480 - until now not reproducible - it is still unconfirmed
- 122715 - still unconfirmed and reporter's feedback pending
- 122726 - still under investigation by others --> no investigation from
my side
- 123348 - already known and depending other software installed on the
system; also reporter answers pending
- 121290 - related to build environment - users are not affected;
workaround available
- 121312 - not my area of expertise - no investigations from my side
- 122014 - seems to be fixed in AOO 4.0.1
- 122737 - platform-independent


So this initial assessments shows that there is no Linux64 specific 
badness, it just proves the assumption that the platform field was set 
to "Linux64" not because the issues were analyzed to be Linux64 
specific. They were just reported for that popular platform because it 
has many power users of Apache OpenOffice.


And it shows that an issue's Operating-System field is somewhat 
ambiguous. For the reporter the field means the operating system where 
the problem occurs. As was seen in the original mail of this thread it 
can also get interpreted differently: to evaluate the quality of AOO's 
support for a platform. This would only work if the field was more reliable.


To make it more reliable I suggest that the field gets adjusted when the 
issue gets confirmed or when the platform impact of a problem is better 
known. E.g. when users report the issue on different platforms or when 
the issue has been analyzed and the root cause is understood to be 
platform independent.


Herbert


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

Re: [Mac] Development environment

[Herbert Duerr]

Hi Tal,

Tal Daniel wrote:
> I'm desperate for some mentoring regarding setting up the dev environment.
> on the Mac. Herbert, can you direct me at the right direction, such as
> which IDE, what project settings,

The AOO build system is unfortunately not yet ready for a full IDE
integration. On this list there were already some good ideas on how to
improve the build system and we'll hopefully find time to work on it
again. As I personally work on multiple platforms their common
denominator, the command line, is my favorite IDE ;-)

With the rejuvente01 branch I started using XCode again, also because of
its debugger interface that uses LLDB in the backend. I wrote a helper
script to make AOO debugging with LLDB more convenient. Please see
   main/solenv/inc/lldb4aoo.py

To use it run lldb and enter
command script import path-to-script/lldb4aoo.py
or add that line to lldb's configuration file
~/.lldbinit
It mostly helps to view AOO's strings. As the ecosystem of OOo's string
classes was not one of its strong points this helper is quite useful.

> do you build a module externally, etc.

I'm not sure I understand the question. Do you mean how to build a
third-party module such as main/icu?

> Notes:
> I'm used to Eclipse; does Xcode have any benefits?

XCode integrates with LLDB and has some additional tools, e.g. for
profiling. But maybe there are extensions for Eclipse to do this too.

> Currently I'm oriented towards fixing BiDi parts (/sw?
> com.core.suncom.sun.star.text.XText? ... started reading the dev guide),

This is an API from the UNO framework. From a BiDi perspective it just
exposes the functionality provided by ICU's BiDi algorithm [1]. In AOO's
core BiDi is used in Writer (main/sw/source/core/text), EditEngine
(main/editeng/source/editeng/) and Vcl (mostly
main/vcl/source/gdi/outdev3.cxx 's OutputDevice::ImplLayout method), so
if there are BiDi problems you'll probably find the answer in their code.

[1] http://userguide.icu-project.org/transforms/bidi

> but maybe later I could help with the Mac OSX10.6 branch too.

As you see our nice project has plenty of work/fun opportunities all
over the place.

Before I forget it: For AOO set the tab-space to four (although I
personally would prefer ts=8 indentation, but the existing AOO codebase
assumes ts=4).

Herbert

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

Re: [Mac] Development environment

[Herbert Duerr]

Hi Tal,

On 05.10.2013 18:46, Tal Daniel wrote:

On Sat, Oct 5, 2013 at 10:41 AM, Herbert Duerr  wrote:

[...]
I'm not sure I understand the question. Do you mean how to build a
third-party module such as main/icu?


Yes, e.g, when you're done editing a cxx file, you enter the folder of that
module, build it, then back to instsetoo_native, and build --all?


For the edit/debug cycle better copy the resulting *dylib file into the 
OpenOffice installation. E.g. if you are in main/editeng and your AOO 
installation is in /Applications/OpenOffice then run

cp -r ../solver/*/unxmacxi.pro/lib/libediteng.dylib \
/Applications/OpenOffice.app/Contents/MacOS/
to replace the existing libediteng.dylib there. You probably have to run
chmod +w /Applications/OpenOffice.app/Contents/MacOS/*dylib*
first.

Please note that AOO still uses two different build systems. The older 
"dmake" system and the newer "gnumake" system. Consolidating them is 
another field with plenty of work opportunities. The dylib results of 
the "gnumake" system are in solver whereas the unstripped results of the 
"dmake" system are in the modules themselves. E.g. the libraries for the 
Calc application (in the main/sd folder) are created as

main/sd/unxmacxi.pro/lib/lib*dylib
To get them into the application copy them over as above.

For debugging I suggest to build with the "debug=1" flag.


[...]
Wow, nice references... thanks! I've tried to edit some code today, in
editeng/source/editeng/impedit2.cxx, but nothing had an effect on the final
app, after I installed it. Strange. I'll try the other locations you
referred me to, later on this week.


Please see my answer above: You need to copy the changed libraries into 
the application directory.



BTW, do files with different indexes target different OS/platforms? i.e.
impedit.cxx, impedit[2-4].cxx


No. In the long heritage of the AOO/OOo codebase there was a time, when 
editors with >64 KByte or >32 KLines support were apparently not that 
common, so big source files had to be split up. Splitting these huge 
files wasn't a bad idea anyway so they are still split. This is also 
good when one looks up a files history in the revision control systems.


By the way, in AOO/OOo's codebase the file names following the 8.3 
naming convention often have a history of more than 20 years.


Have fun,
Herbert

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

Re: File needed, Kid for 4.0.1 (trunk)

[Herbert Duerr]

On 05.10.2013 23:36, Andrea Pescetti wrote:

On 28/09/2013 janI wrote:

I have btw changed xx_XX to xx-XX in branch l10n40, so we dont have a mix
of _ and -.


A good idea, thanks!


main/i18npool/source/localedata/data consistently uses underscores. On
the other hand, the old "extras/l10n/source" consistently uses dashes...
so I don't know which one is best here. If there's a way to adopt a
common convention, very good.


Following the RFC3066 [1] convention should be best. It uses the hyphen 
to separate the language tag from the subtag. Of course for naming 
variables in the source code the underscore counterpart is a good fallback.


[1] http://www.ietf.org/rfc/rfc3066.txt

Herbert


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

Re: [Bugzilla] Vote and issue

[Herbert Duerr]

On 07.10.2013 16:20, FR web forum wrote:

Some issue seems to be without possibility of vote.
Like: https://issues.apache.org/ooo/show_bug.cgi?id=99429
Why?


I guess this has to do with the product specific settings. For the "App 
Dev" product the "Maximum votes per person" has been set to zero. I 
don't know whether the creator of that product category intended it that 
way or whether it was an oversight.


Almost all other products categories allow 5 votes per person and a 
maximum of two per bug in that category. Other products with no votes 
allowed are "Native-Lang", "qa" and "marketing". I guess for all of them 
voting should be enabled. Unless someone disagrees I'll assume lazy 
consensus in 72h.


Herbert

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

Re: [Bugzilla] Vote and issue

[Herbert Duerr]

On 07.10.2013 16:56, Rob Weir wrote:

[...]
1) Does auto-confirm make any sense for us?  Remember, marking
something as "confirmed" takes it off the radar for QA.  But if
something is in the unconfirmed state and many users are voting for
it, shouldn't that mean that QA should give more attention to it, to
try to confirm it?  If we skip over QA entirely then we miss the
opportunity they have to do additional testing of other versions,
uploading sample documents, etc.   So I'd be in favor of disabling the
auto-confirmation entirely.  We shouldn't skip over QA.


Agreed, issue votes shouldn't auto-confirm. Confirming an issue should 
mean that someone we can trust vouches that the issue status has a 
reasonable quality.



2) What values should we set of the max number of votes per product
and per bug?   In one sense it doesn't really matter, since we don't
really have a view of what the top vote issues are.  But if the goal
is for users to express their preferences, why not set it to 10/10/0?
In other words, let them express the fact that a single bug matters to
them most of all if they want.


10 votes per product makes sense, but it devalues the existing votes a bit.

Limiting the number of votes a user can give to an issue to 1 or 2 would 
have important benefits: it encourages the voter to take a broader view 
of the situation and discourages radical positions.


If there were situations where an issue was so important that working on 
anything else would be a waste of time then voting wouldn't cut it 
anyway. Such a problem should then become the main focus on the 
development list.


Herbert

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

Re: Help Needed: Redo the /porting/mac page

[Herbert Duerr]

On 08.10.2013 22:33, Andrea Pescetti wrote:

janI wrote:

http://www.openoffice.org/porting/mac/ ...
So my first question is
- what does a MAC page have to do here. MAC is a supported platform, not
third party ?
- why does the porting page not have a link to the mac page ?


The Mac version used to be a port (you can still find outdated
information around, with the name "Aqua Port"), but it has been a fully
supported version since 3.0.0 or around.


Yes, OOo 3.0 was our first version with Mac as fully supported platform.


So the porting page does not link to it since it's not a port. And the
URL is... well, historical, but I wouldn't oppose to move it outside
porting/ if we can setup redirects that won't break search engines.


+1 for just redirecting to our download page.

Herbert

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

Re: New record download day

[Herbert Duerr]

On 09.10.2013 01:32, Vladislav Stevanovic wrote:

Is there any chance to improve options of getting data about downloads?
For example, I want to know  (for example) how much copies were downloaded
for AOO 4.0.1 Serbian pack , in some (from - to) period? And how meny
downloads (Serbian pack) are done from Serbia and other countries. Serbian
nation lives in several countries, so  analysing of this downloads data can
be more accurate for me.  It would be great to have somehow advance options
from data analysing stored on AOO web page.


Please see the statistics on the right of [1] or the location specific 
results in [2].


[1] 
http://sourceforge.net/projects/openofficeorg.mirror/files/4.0.1/binaries/sr/
[2] 
http://sourceforge.net/projects/openofficeorg.mirror/files/4.0.1/binaries/sr/Apache_OpenOffice_4.0.1_Win_x86_install_sr.exe/stats/map



One criteria for inuput would be version of AOO or all version.
Next filter for data analysing would be for which language pack or all
packeges
Next: for which platform or for all platforms
Next: date (from - to); for better and faster entering of this criterion,
it needs to be available release date for every version of AOO
Next option: from where are downloads done (option for selecting a
particular country; or option for all countries - in that case we will get
list of countries and number of downloads for that count )

If we have this it means to have liberty to get all sort of data analysing
about downloads in any time for all of us.
Also, why are not automatically processed the current way of presenting
data that is now appearing on the AOO site (about downloads) every week, it
would be easier and for person who now has to prepare and publish this
data  manually


You might want to check out SourceForge's REST API [3] to get such data

[3] http://sourceforge.net/p/forge/documentation/Download%20Stats%20API/

Herbert

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

Re: Opensource and security

[Herbert Duerr]

Hi Guy,

On 09.10.2013 09:32, Guy Waterval wrote:

A little off topic perhaps, for this list, but perhaps also a frequent
question to which it could be nice to have some answers.
An opensource sofware has the advantage, in security terms, to grant that
there are no spyware in it, that's OK. But is there no danger, as the code
is public, to facilitate the creation of virus. It's always a problem for
me to answer to this kind of question, it's unclear for me. So, If somebody
could bring some arguments understandable for end users about this issue,
It would be great.


The are some good arguments in the Wikipedia article on that topic [1].

[1] http://en.wikipedia.org/wiki/Open-source_software_security

Another discussion-worthy point is that "Security by Obscurity" [2] 
software is considered not to be not much safer than their binary-only 
counterparts: "System security should not depend on the secrecy of the 
implementation or its components."


[2] http://en.wikipedia.org/wiki/Security_by_obscurity


The same could be applicable to the ODF, what are the advantages, in terms
of security, to work with an open format.


"Trust is good, control/validation is better": An open format allows 
inspection and validation.


Herbert

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

Re: AOO Security Features without Mozilla

[Herbert Duerr]

Hi Pedro,


Really nice to see nss being split soon. I hope we can use an external
nss too as the one we include internally is somewhat outdated and
potentially insecure.


Absolutely. For the same reason the internal NSS should be updated. 
Would you be interested in doing it? You did a great job of updating 
some other AOO-external libs.



While on the subject of replacing mozilla addressbook, just thought I'd
remind about the analysis done by Andre while we were working on IP
clearance [1].

Back then I also found the Mulberry vCard library [2] that is under an
Apache License. Interfacing it with AOO is a completely different
matter though :-(.


Thanks for the link to mulberry. But as can seen in the scripts [2][3] 
linked to in my original mail, accessing the interesting address sources 
is by far the least problem. Delivering this info properly into AOO is 
much more work.


[2] 
https://bug241438.bugzilla.mozilla.org/attachment.cgi?id=175024&action=view
[3] 
http://stackoverflow.com/questions/11538550/retrieving-outlook-contacts-via-python


Herbert

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

Re: AOO Security Features without Mozilla

[Herbert Duerr]

Hi Andrew,

On 22.10.2013 20:00, Andrew Rist wrote:

On 10/22/2013 7:15 AM, Herbert Dürr wrote:

[...]
With these new insights I suggest to remove both the enable-mozilla
and its eventual replacement enable-mozab-module before losing much
more time on that topic. The sooner the better.

+1

This should simplify the configure options.  All the mozilla stuff will
be gone and there will be no more enable/disable mozilla/mozab options -
right?


IMHO that's the best course of action. I'll pursue it unless someone 
objects with good reasons.


Herbert

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

Re: AOO Security Features without Mozilla

[Herbert Duerr]

On 23.10.2013 14:05, janI wrote:

On 23 October 2013 13:57, Herbert Duerr  wrote:
[..]

  Really nice to see nss being split soon. I hope we can use an external

nss too as the one we include internally is somewhat outdated and
potentially insecure.



Absolutely. For the same reason the internal NSS should be updated. Would
you be interested in doing it? You did a great job of updating some other
AOO-external libs.



When / if we do this update, should we not do like other packages do, have
the lib as a preinstallation requirement, and not something we download ?


If we want to get back into individual linux repositories then using 
system libraries and dependencies to them is the way to go. For our 
"greatest common denominator" build works on almost every Linux target 
this is unfortunately not possible. I'd be happy to be proven wrong.


For our Windows build there is no central repository e.g. from Microsoft 
where we could say we'd depend on e.g. the latest NSS so that the 
MSI-Installer automatically fetches them. For our Windows platform 
target this is unfortunately not yet possible. Maybe it will work one 
day in the Windows app store? That's certainly an interesting topic and 
maybe we'll find volunteers for it.


Also Mac doesn't provide NSS in its system. It also doesn't provide the 
concept of external dependencies that the system installer would take 
care of. Maybe this is something they'll do in the future in their app 
store. That's another interesting topic and volunteers may find worth 
investigating?


Summary: there are good reasons why we are still bringing our own nss. 
For cases where we can rely on external facilities to provide our 
dependencies we should go for it. Volunteers are welcome.



I have had pretty the same thought for all external libs (ext_libraries)
and to a part also (ext_sources).

But maybe I am completely wrong.


Not at all. IF we can depend on stuff being there then we should depend 
on it being there. In such cases installing/using our own libs would be 
counterproductive. The problem is that the IF is currently too often on 
the wrong side so we for now do the "better safe than sorry" solution.


Herbert

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

Re: AOO Security Features without Mozilla

[Herbert Duerr]

On 22.10.2013 22:33, Andrea Pescetti wrote:

Herbert Dürr wrote:

[1] https://issues.apache.org/ooo/show_bug.cgi?id=85356
[2] https://issues.apache.org/ooo/show_bug.cgi?id=63270
[3] https://issues.apache.org/ooo/show_bug.cgi?id=91079
This is an interesting reality check and I'm afraid the project lost
users that depended on that functionality long ago. On the other hand
these facts enable us to kick this non-functioning and unmaintainable
crap out without a serious negative impact.


Count me among those who are very happy to see a large, unmaintained,
outdated, problematic part of our codebase being removed, and thanks for
doing so!

But we need to be quite clear in telling users what we will drop by
extending the "Mozilla removal" from the initial idea of replacing just
the crypto support to this idea of dropping the Address Book
functionality too.

The above issues show that functionality had been (and still is)
crippled, but not that it is 100% broken. Would it be possible to
extract some short bullet points, or use cases, of what is lost by
dropping Mozilla at this stage? We could put it early in the draft
Release Notes and give proper notice to the (hopefully few) users who
may still depend on it.


I'd say there are two noteworthy cases:

- Windows XP users will have the same experience as Windows Vista, 
Windows 7 and Windows 8 users now already have with AOO: trying to add 
the Windows Address Book as an AOO database won't work


- Thunderbird users will not see direct TB address book support in AOO's 
address book wizard, but AOO's support for Csv-Text can replace it for 
now. They can get use TB's Tool->Export->AsCsv functionality to get 
their address book as comma separated text.


Another interesting question is the LDAP support:

The AOO codebase already seems to have support for mozilla-less openldap 
which could be enabled using --with-openldap but AFAIK that hasn't been 
used in mainstream OOo or AOO yet. So bugzilla cannot help to assess its 
status. It might be possible that it is much better than the 
seamonkey-ldap, especially when access control is enable which is 
probably the default in professional environments, as the non-anonymous 
bin to LDAP fails with the seamonkey version. I'd like to invite 
volunteer help for this question. Especially current power users of 
AOO's address book functionality via LDAP are encouraged to try the 
--with-openldap option on their favorite platform.


Herbert

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

Re: ratscan

[Herbert Duerr]

On 03.11.2013 20:29, janI wrote:

it sure looks like it, thx for correcting me.


[...]
Besides, build-bot openoffice-linux64-rat runs the target weekly:
http://ci.apache.org/projects/openoffice/



that runs on trunk, and not on the branches.


Yes, I noticed that too. So I committed r879545/r879849 and 
r869036/r869204/r870734 in the buildbot configuration file 
openofficeorg.conf during the release phase to switch it temporarily to 
the release branch. There is no need to worry: the last releases were 
covered.


Herbert

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

Re: ratscan

[Herbert Duerr]

On 04.11.2013 15:30, Andre Fischer wrote:

On 04.11.2013 10:36, janI wrote:

[...]
But my original question is still not answered, do we use the build
system
to do ratscan, or is the ratscan target an old relict ?


I think that I have added the ext_libraries/ratscan/ module.   It is
built and started when the --with-rat-scan option is given to configure.
But I don't know if that is used on our build servers.  If you see a
--with-rat-scan option in their configuration files then it is,
otherwise it is not.


Looking through the buildbot configuration shows that it doesn't uses 
ant (like almost all other projects in the ASF buildbot infrastructure) 
and not the configure option.


Herbert

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

Re: ia2 Buildbot needs attention

[Herbert Duerr]

On 04.11.2013 14:44, V Stuart Foote wrote:

The ia2 branch buildbot hung on initial build of the rev 1538382 build
today---"Failed build.pl --all"

It needs some attention.


The error was
"ia2_api_all.idl' not found, and can't be made"
but Steve already committed http://svn.apache.org/r1538506
"Add ia2_api_all.idl"
so there is a good chance that the next build will have this problem 
resolved.


Herbert

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

Re: ratscan

[Herbert Duerr]

On 04.11.2013 15:41, Herbert Duerr wrote:

On 04.11.2013 15:30, Andre Fischer wrote:

On 04.11.2013 10:36, janI wrote:

[...]
But my original question is still not answered, do we use the build
system
to do ratscan, or is the ratscan target an old relict ?


I think that I have added the ext_libraries/ratscan/ module.   It is
built and started when the --with-rat-scan option is given to configure.
But I don't know if that is used on our build servers.  If you see a
--with-rat-scan option in their configuration files then it is,
otherwise it is not.


Looking through the buildbot configuration shows that it doesn't uses
ant (like almost all other projects in the ASF buildbot infrastructure)
and not the configure option.


Typo fix: it uses plain ant and none of AOO's binaries

Herbert


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

Re: BUGZILLA/FAQ

[Herbert Duerr]

Hi Rainer,

On 07.11.2013 09:23, Rainer Bielefeld wrote:

it would be great if some volunteers would help to replace the question
marks on  by useful
contents.


I updated the topics
- good sample docs
- the bug status "confirmed"
- bug summary in general
and split the "pseudo tags in summaries" topic into two:
- bracketed branch names
- deprecated pseudo tags

I hope you like the changes.

Herbert

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

Re: does something still depend on poppler?

[Herbert Duerr]

Hi Pedro, hi Armin,

On 08.11.2013 10:06, Armin Le Grand wrote:

On 07.11.2013 20:04, Pedro Giffuni wrote:

I just noticed on FreeBSD port we have a dependency on poppler-glib.
Opengrok reports it is detected in configure but it doesn't seem
to be used elsewhere.

The poppler license is cat-x so it was probably removed before
graduation. Is it still useful at all?


OpenGrok only gives trunk/main/configure.in and there is something like
--with-system-poppler. I have not found a reaction on that flag, but I
am no configure expert, so someone knowing that better (hdu?) should
have a look...


Looking through the history the --with-system-poppler and 
--enable-pdf-import configure options seem to be remainders of the XPDF 
removal in the IP-Clearance phase that was done before our first 
release. https://issues.apache.org/ooo/show_bug.cgi?id=118592 has more 
details on that removal.


The developers that worked on XPDF removal (Andre and Jürgen) know 
probably better whether these options are still needed?


Herbert

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

the Seamonkey has left the building

[Herbert Duerr]

As discussed in the thread "AOO Security Features without Mozilla" I 
removed the dependency on the ancient Seamonkey-1.1 binaries and use the 
NSS libraries ("Network Security Services") instead. This major rework 
has been integrated into trunk now.


If you are working on trunk you'll notice that the moz module and the 
configure switch named --disable-mozilla is gone. This switch was 
sometimes used to build Apache OpenOffice without security services. If 
you want to continue building without security services please use the 
--disable-nss-module instead. Whether such an insecure AOO build is 
something to aim for is dubious though, especially since the biggest 
hurdles to enable this functionality have been removed which were:

- building the Seamonkey-1.1 using special old compiler versions
- providing zip-archives of such prebuilt Seamonkey-1.1 binaries
are no longer needed. Good riddance.

If you are working on Windows then you'll notice that the
--with-mozilla-build option is still there as NSS being part of the 
Mozilla project needs the Mozilla build environment. If you object to 
install the Mozilla build environment then you couldn't build the 
moz+nss modules on Windows then and cannot build nss on Windows now. 
Please use the --disable-nss-module or the --disable-category-B switches 
if providing the Mozilla build environment for NSS is out of the question.


As shown in the earlier thread on this topic the address books provided 
via the old Seamonkey binaries were quite bit-rotten and often didn't 
work on modern systems. There is a good chance that their successors 
will be ready for AOO 4.1 and solve most current problems. Volunteers 
who'd like to dive right into AOO's SDBC subsytem and write drivers for 
Mork, LDAP or MAB address book formats are welcome. Especially power 
users of the older implementations who suffered their shortcomings may 
find this chance interesting.


With the Seamonkey-1.1 compatibility requirement removed it was now also 
possible to do an overdue update of the security critical NSS libraries 
to their latest released version. Thanks to Pedro for his initial patch 
on the platform-independent part of the library update.


Herbert

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

Re: the Seamonkey has left the building

[Herbert Duerr]

On 08.11.2013 13:39, Armin Le Grand wrote:

On 08.11.2013 13:18, Herbert Duerr wrote:

[...]
If you are working on Windows then you'll notice that the
--with-mozilla-build option is still there as NSS being part of the
Mozilla project needs the Mozilla build environment. If you object to
install the Mozilla build environment then you couldn't build the
moz+nss modules on Windows then and cannot build nss on Windows now.
Please use the --disable-nss-module or the --disable-category-B
switches if providing the Mozilla build environment for NSS is out of
the question.


Is there a way to get around this...? Maybe nss can be 'replaced'
somehow...?


There are several libraries that could be alternatives, please see [1] 
for an overview. Evaluating the viability of them for replacing the 
individual aspects of NSS that are used in AOO could be an interesting 
task for volunteers.


[1] http://en.wikipedia.org/wiki/Comparison_of_TLS_implementations

Regarding the requirement of having the mozilla build environment for 
building NSS on Windows: I don't think NSS needs much of that tooling. 
They require this MingW based environment like we depend on our Cygwin 
based environment. NSS could certainly be rewritten to use cygwin too. 
But is it worth the trouble? Downloading MozBuildSetup [2] and running 
it is not much of an effort and it has the great benefit that we can 
then consume the source releases of NSS almost directly. The alternative 
of rewriting NSS for our cygwin environment would be much more intrusive 
than what is recommended for a category-B licensed library.


[2] http://ftp.mozilla.org/pub/mozilla.org/mozilla/libraries/win32

Herbert

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

Re: Compile Openoffice/pyuno with UCS-4 support

[Herbert Duerr]

Hi Marcin,

Marcin Tustin wrote:
> Hi All,
> 
> When openoffice builds python and pyuno, it builds with UCS-2 support,
> which is the default for python. HOWEVER, python as shipped by fedora is
> built with UCS-4 support. I'd like to be able to use the various pyuno bits
> with my system python, and so I'd like to get it compiled with UCS-4
> support.
> 
> Unfortunately, having unzipped the source tarball, I can't even see a
> python source tree to hack manually. Any pointers on how to do this would
> be much appreciated.

After the configure step some external tarballs (such as python) are
downloaded during the "bootstrap" step. When building AOO these tarballs
get unpacked, eventually patched, compiled and "delivered". The case you
are interested in is in the main/python module.

You'll find the unpacked and patched python source code be in
main/python/*/misc/build/Python-2.7.5
The python module interacts mostly with the main/pyuno module. Once you
changed main/python to build with UCS4 the pyuno module probably needs
similar adjustments.

More details on how to work with these external source tarballs is
available in [1].

[1]
https://wiki.openoffice.org/wiki/Build_Environment_Effort/External_source_tarballs

Hope this helps!

Herbert

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

Re: the Seamonkey has left the building

[Herbert Duerr]

On 10.11.2013 17:59, Andrea Pescetti wrote:

On 08/11/2013 Herbert Duerr wrote:

As discussed in the thread "AOO Security Features without Mozilla" I
removed the dependency on the ancient Seamonkey-1.1 binaries and use the
NSS libraries ("Network Security Services") instead. This major rework
has been integrated into trunk now.


Thank you! This makes two pending blog posts from you, right? Just
joking... but it would be nice that the innovation coming in OpenOffice
gets appropriate coverage.


It certainly was important work. Like the work of a rodent control 
specialist who solves the problem of rats gnawing people's flesh of 
their bones while they sleep. Advertising that there even was the need 
for such a solution is not a good idea IMHO. The sooner that abomination 
is forgotten the better...


I respect the former colleagues that introduced it very much but I never 
liked that particular approach which was probably a result of "a 
steamroller is really good for cracking nuts" and "the grass is always 
greener on the other side of the fence".



By the way, I incorporated your notes from that thread into
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Notes


Thanks!


If you are working on trunk you'll notice that the moz module and the
configure switch named --disable-mozilla is gone.


Yes, but the build is now broken on the Fedora 19 machine that I use for
building trunk from time to time. Note that this does not necessarily
depend on your changes, but maybe some conflict is triggered. I did a
completely clean build.

The nss module is built cleanly (warnings aside).

Then I see warnings/errors like:

Making:idlc ...
/lib64/libcrypt.so.1: undefined reference to
`NSSLOWHASH_End@NSSRAWHASH_3.12.3'


Darn. Major reworks always require some polishing. Maybe adapting the 
change [1] the Mozilla guys did to make it work on Fedora helps us too?


[1] https://bugzilla.mozilla.org/attachment.cgi?id=589009&action=diff

Please try this patch and rebuild from nss:

--- main/nss/makefile.mk
+++ main/nss/makefile.mk
@@ -88,7 +88,7 @@ BUILD_DIR=mozilla$/security$/nss
 BUILD_ACTION= $(GNUMAKE) nss_build_all
 #See #i105566# && moz#513024#
 .IF "$(OS)"=="LINUX"
-BUILD_ACTION+=FREEBL_NO_DEPEND=1
+BUILD_ACTION+=FREEBL_NO_DEPEND=1 FREEBL_LOWHASH=1
 PATCH_FILES+=nss_linux.patch
 .ENDIF

Herbert

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

Re: the Seamonkey has left the building

[Herbert Duerr]

A followup to my earlier mail:


Please try this patch and rebuild from nss:

--- main/nss/makefile.mk
+++ main/nss/makefile.mk
@@ -88,7 +88,7 @@ BUILD_DIR=mozilla$/security$/nss
  BUILD_ACTION= $(GNUMAKE) nss_build_all
  #See #i105566# && moz#513024#
  .IF "$(OS)"=="LINUX"
-BUILD_ACTION+=FREEBL_NO_DEPEND=1
+BUILD_ACTION+=FREEBL_NO_DEPEND=1 FREEBL_LOWHASH=1
  PATCH_FILES+=nss_linux.patch
  .ENDIF


On a virtual test system the problem could be reproduced and the patch I 
suggested works. I already committed it as r1540693 so trunk should 
build now also on such systems.


Herbert


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

Re: Failure with system NSS

[Herbert Duerr]

Hi Pedro,

On 09.11.2013 01:58, Pedro Giffuni wrote:

I tried the new  --with-system-nss configure option but it failed
in the libxmlsec module:


checking for libxslt libraries >= 1.0.20... no
checking for openssl libraries >= 0.9.6... no
checking for nspr libraries >= 4.0... no
checking for nss libraries >= 3.2... no
checking for gnutls libraries >= 0.8.1... no
checking for mscrypto libraries... none
checking for crypto library... configure: error: At least one crypto
library should exist for xmlsec1
yes
checking whether byte ordering is bigendian...
dmake:  Error code 1, while making
'./unxfbsdx.pro/misc/build/so_configured_so_xmlsec1'


libxmlsec needs the nss development headers and libs. Are they available 
too?


We could use new checks for configure for that scenario...


[..]

But it appears that nspr is not found either:


Maybe the nspr development headers and libs are needed too for building, 
depending on how the system nss was provided.



While here, I suspect that if libxmlsec could find openssl,
it would seriously help progress in the direction of not
depending on nss.


That may be an interesting topic after AOO 4.1.


Finally, both openssl and libxmlsec could get an update.
libxmlsec is probably not easy to update, but for openssl
I uploaded a newer version to apache-extras.


Absolutely. Security critical libraries need to stay up to date.


JIC someone is looking for a good excuse to contribute ;).


Just contribute, no excuses needed ;-)

Herbert


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

Re: Failure with system NSS

[Herbert Duerr]

Following up to myself:


libxmlsec needs the nss development headers and libs. Are they available
too?


I just committed r1540735 to enable pkgconfig when system-nss is active. 
This should solve the config-problem on most systems.



We could use new checks for configure for that scenario...


Autoconf experts are invited to implement a nss>=3.2 and nspr>=4.0 in 
our configure.in template.


Herbert

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

Re: [OS2] gcc 4.7.3, CPPULIB now required for some modules

[Herbert Duerr]

On 11.11.2013 20:52, Yuri Dario wrote:

Hi,

I moved building of AOO on OS/2 from gcc 4.4.6 to gcc 4.7.3.
Everything seems of except for a minor issue: on some modules, UNO
constructors from CPPULIB are now required to link dlls. I'm getting
this errror

Error! E2028: _uno_any_construct is an undefined reference
Error! E2028: _uno_type_any_construct is an undefined reference
Error! E2028: _uno_any_destruct is an undefined reference
Error! E2028: _uno_type_any_assign is an undefined reference

mainly in filter graphicfilter dlls and in
i18npool/source/textconversion/data/. Adding CPPULIB satisfies the
linker.

do you have any ideas what could be wrong?


Did you change the linker too? When linux distributions switched from 
the "bfd" to the "gold" linker there where problems that libraries that 
were only linked indirectly had to be mentioned directly [1].


[1] 
https://wiki.debian.org/ToolChain/DSOLinking#Not_resolving_symbols_in_indirect_dependent_shared_libraries


Herbert

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

Re: ia2 Buildbot needs attention

[Herbert Duerr]

On 11.11.2013 11:12, Steve Yin wrote:

Based on Herbert suggestion, I will synchronize the branch with the latest
trunk. And the build issue will go away. :)


Thanks for synchronizing with trunk! That solved the problem, the ia2 
builds are successful again and the install packages are available [1].


[1] http://ci.apache.org/projects/openoffice/#w7ia2

Herbert

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

Re: [OS2] gcc 4.7.3, CPPULIB now required for some modules

[Herbert Duerr]

Hi Yuri,

On 12.11.2013 12:37, Yuri Dario wrote:

Did you change the linker too? When linux distributions switched from
the "bfd" to the "gold" linker there where problems that libraries that
were only linked indirectly had to be mentioned directly [1]


OS/2 does not use ld to link object files. But this seems not the
problem I see.

I'm thinking that these functions were inlined in previous gcc
releases or that now code generates some new kind of reference to
them, thus requiring the linker to satisfy the dependancy.


I had thought about that too, but seeing that the missing functions are 
declared in main/cppu/source/uno/any.cxx and not in an exported header 
file convinced me that this cannot happen.


But maybe there really are new uses of cssu::Any in the modules you 
mentioned. Do the error messages say which object files need these 
methods that were missing without the CPPULIB dependency?



OS/2
linkers needs to resolve all symbols like Windows, we do not have lazy
loading enabled by default.


The direct/indirect linking (in the build phase) I referred to is 
orthogonal to eager/lazy loading (in the run phase).


Herbert

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

Re: XML files are binary?

[Herbert Duerr]

On 12.11.2013 14:59, Andre Fischer wrote:

I just checked in some files for creating Windows patches (no, the work
is not yet finished) and saw that the .xml files are flagged as binary.
Checking their properties revealed that their mime type is correctly set
to application/xml.  Does anybody know why they are still flagged as
binary?

By the way, what became of our attempt to replace SVN with GIT? [...]

> Can we please change to GIT? Life would be so much easier.

Please see the closed JIRA issue [1] and my mail in [2] where I 
suggested to reopen it when we have consensus on
"[...] whether we want to have a read-only git-mirror of our svn 
repository or to whether we want to fully switch to git (read-write)."


I'm for a read-only git-mirror for a start.

[1] https://issues.apache.org/jira/browse/INFRA-5590
[2] http://markmail.org/message/5cx4yyb5z5qb6sdz

Herbert

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

Re: [proposal] GIT mirror

[Herbert Duerr]

On 12.11.2013 16:48, janI wrote:

based on the discussion in thread "XML files are binary" and herberts
comments I had a chat with jfarrell (the infra git specialist).

We can have a GIT Read/Only mirror very easy (standard)

We cannot have a GIT Read/write mirror (restriction from infra)

We can switch completely to GIT (which I for one would be against).

I recommend to reopen ticket 5590 with a comment asking for a read/only
mirror. Jfarrell is right now (this week) working through git issues, so if
we can reopen the ticket fast, I can help jfarrell make this happen fast.


Thanks for this interesting info. This makes it clear that we should act 
ASAP.



@herbert, if nobody objects will you reopen the ticket, or should I ?


I have reopened the JIRA issue and requested a read-only mirror for now.

Herbert


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

Re: [proposal] GIT mirror

[Herbert Duerr]

On 12.11.2013 20:08, Andrea Pescetti wrote:

Herbert Duerr wrote:

On 12.11.2013 16:48, janI wrote:

@herbert, if nobody objects will you reopen the ticket, or should I ?

I have reopened the JIRA issue and requested a read-only mirror for now.


And what would be the advantage for real contributors in having a
read-only GIT mirror? The complaints I've seen so far are mostly in the
other direction (i.e., committing or applying patches). I'm not talking
about generic advantages of GIT: everybody here can be assumed to have a
good working knowledge of both SVN and GIT. What concrete problems does
a read-only GIT mirror solve in our case?


A git mirror is needed as a first step also when we do the full switch. 
The read-only mirror can start immediately without any disruption and we 
can switch to full git at a convenient time.


And there are other goodies too:
- A R/O mirror gives a reference point. As individual git-svn clones of 
the asf-repo are often different because of "svn propedit" having an 
official git-mirror would be nice.

- It gives time to rewrite our buildbot recipes.
- It gives time to rewrite our repo2bz service.
- It gives time to rewrite the svnlog2info script.
- It gives time to rewrite our building guides.


I'm not at all against it, but I'd just like to make sure that a
read-only GIT mirror brings enough concrete advantages, since many GIT
niceties (local commits, proper attribution, quick application of
patches) are still left out or significantly limited with this approach.


Local branches, local commits, interactive rebasing, etc. are all 
available directly.


When every service we like now has been converted to run with the 
git-mirror we can switch to full git conventiently.



By the way, you can find discussions about GIT everywhere at Apache,
there's even a Github account https://github.com/apache and lots of
suggestions like adopting the newly-released Apache Allura (Incubating)
GIT (and more) hosting environment. As far as I know, there have been
very significant updates in the GIT support at Apache in the last few
weeks and I hope that this is soon summarized in a blog post at
http://blogs.apache.org/infra/ or reflected in the documentation at
http://www.apache.org/dev/git.html . So this is a good moment to start
considering GIT again.


Absolutely. I'm a big git fan and used it in my daily work since 2005! 
Then I ran git in my CVS checkout, later in the SVN checkout, then the 
git-svn bridge, then the hg-git bridge and finally the git-svn bridge again.


Even when tracking other projects (e.g. to see when boost fixed a 
particular problem) I always look for its git-mirror first. Thats why I 
know how powerful even a read-only git-mirror is.


Herbert


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

Re: [OS2] gcc 4.7.3, CPPULIB now required for some modules

[Herbert Duerr]

Hi Yuri,

On 13.11.2013 11:04, Yuri Dario wrote:

But maybe there really are new uses of cssu::Any in the modules you
mentioned. Do the error messages say which object files need these
methods that were missing without the CPPULIB dependency?


yes, I see the module name. e.g. for graphicfilter it is the only .cxx
file present in the directory. Preprocessor shows that functions are
referenced because any2.h is included.


Graphicfilter [1] has quite more that one source file. Some of its 
subdirectories already use CPPULIB directly. If there is a new 
subdirectory where its needed nowadays I suggest to just add the CPPULIB 
line to the makefile. I don't think there is any more reason to worry.


[1] 
http://svn.apache.org/repos/asf/openoffice/trunk/main/filter/source/graphicfilter/


Herbert

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

Re: Build braker in rejuvenate01 cppu

[Herbert Duerr]

Just a small status update to my mail from Tuesday:

On 12.11.2013 10:17, Herbert Dürr wrote:

On 11.11.2013 10:47, Raphael Bircher wrote:

I run in a build breaker in the rejuvenate01 branche

dmake:  Error: -- `uno_purpenvhelpers5abi.map' not found, and can't be
made


I just committed r1540968 to add the missing file by renaming its older
cousin.


Has someone a idea what happend here, and what's wrong?

[...]
Thanks for looking into the "rejuvenate01" branch. With the renaming and
the recent major update from trunk it has become a "construction site"
though. After the RmMoz work I can now focus on getting the branch round
again and make it a viable port. So stay tuned, in a few days it will
build+run out of the box again and it will have gained an important
feature it missed so far: support for password protected documents!


The rejuvenate01 branch should build out of the box again. Note the 
working support for password protected documents and the latest goodies 
we got by resyncing to trunk.


Herbert

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

Re: Apache OpenOffice 4.1 to Bring Enhanced Accessibility Support

[Herbert Duerr]

On 15.11.2013 17:06, V Stuart Foote wrote:

Rob,

Great news! Great blog post--subtle ;-)

On a side bar, I see that Herbert and Oliver are hard at work correcting
build issues for Steve's rev 1541847 integration done yesterday, getting the
new IAccessible2 bridge to build cleanly on trunk is obviously now the
priority.   But when someone gets a chance there are several source files
from the merge that will need to have ALv2 headers inserted--don't want the
down stream folks to complain too loudly...


Good point, thanks for finding it!

I fixed the license headers to the ALv2 as intended and moved the 
SNAPSHOT tag to the new revision. The next SNAPSHOT build is expected to 
be ready for downloading and testing next Monday evening.


Have a great weekend and have fun with the next SNAPSHOT build!

Herbert

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

Re: Nepali or Hindi or Sanskrit using Devanagari Script

[Herbert Duerr]

On 17.11.2013 08:32, taruntap...@gmail.com wrote:

Sir those languages must be more developed for it.


A great idea, thanks! What is mostly needed for this are translation 
volunteers. Can you help with that? Please see [1] for a start.


[1] 
https://cwiki.apache.org/confluence/display/OOOUSERS/Native+Language+Projects


The Nepali translation [2] of Apache OpenOffice is only at 7% so a lot 
more strings need to be translated before we can think of distributing 
binaries for this language.


[2] https://translate.apache.org/ne/

The Hindi translation [3] is already at 88% for the UI but only 12% done 
for the help files.


[3] https://translate.apache.org/hi/

Herbert


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

Re: Build braker in rejuvenate01 cppu

[Herbert Duerr]

Hi Raphael,

On 16.11.2013 06:23, Raphael Bircher wrote:

Am 15.11.13 17:17, schrieb Herbert Duerr:

Just a small status update to my mail from Tuesday:
[...]
The rejuvenate01 branch should build out of the box again. Note the
working support for password protected documents and the latest
goodies we got by resyncing to trunk.

No, at me it does not working it stops at "testtools" as far I can see.
[snipped output from the build of the xml-module]


The good thing about doing parallel builds is that the resources are 
better utilized and the build is way faster.


The bad thing about parallel builds is that the output of the individual 
build processes get intermingled. This intermingled output is incredibly 
hard to analyze.


E.g. the output of the xml module is not related to the eventual 
problems in the testtools module. So providing the output of the xml 
build does not help in any way to analyze a build problem in the 
testtools module.


To get relevant output for analyzing an eventual testtools problem I 
suggest to change into the testtools directory and run

rm -rf unxmaccx* && build 2>&1 | tee build.out | grep -i error:
there. Please note that no "-P" option should be used to prevent the 
intermingling of output.


A source of trouble could be if you are compiling using the XCode3 
compiler. Are you using

export CC=`xcrun -f clang` -arch x86_64
export CXX=`xcrun -f clang++` -arch x86_64 -std=c++11
before running configure? If in doubt please use a new shell and a clean 
checkout of the code base.


Herbert


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

Re: many many stlport issues...can anyone help

[Herbert Duerr]

On 20.11.2013 02:00, Kay Schenk wrote:

I installed the stlport provided by opensuse for my version -- it is 4.6.2,
whereas the latest one at Sourceforge is 5.2.1.


Yes. Stlport 4.6.2 was getting a bit old. As the latest maintenance 
version of the stlport4 series it was released in 2004. So Stlport 4 has 
been unmaintained for almost ten years now.


Since AOO 4 we are using the compiler/system provided STL and not 
stlport 4. We are lucky that the STL variants have been standardized 
with [1], so we can rely on them. Stlport 5.x follows this standard too, 
but Stlport 4 didn't, so it was no longer maintained. With AOO 4 we have 
abandoned it too.


Please use the --without-stlport configure switch. Stlport 4 was great 
for its time. OOo and AOO 3.x still used it many years after its last 
maintenance version which is a reverence to stlport4. But with AOO 4 it 
was overdue that we finally let it rest in peace. This gives AOO the 
chance to become more compliant with the rest of the C++ world.


[1] http://en.wikipedia.org/wiki/C++_Technical_Report_1

A lot more work is needed to change all the many parts of the source 
code that use pre-standard STL constructs to their standard compliant 
counterparts. But the heavy lifting is already done and the individual 
adaptions can be done automatically by some scripting.



Should I install the newer version --  with gcc 4.7.2 in use.


You don't need stlport4 any longer. Please use the --without-stlport 
configure switch. The gcc provided libstdc++ library, boost/tr1 [2] and 
our stl wrappers will replace it just fine.


[2] http://www.boost.org/doc/libs/1_54_0/doc/html/boost_tr1.html


Also, I see this page:
http://www.stlport.org/doc/vendor_interface.html

and since I seem to be getting a LOT of redefinition errors from what I'm
seeing, is this a namespace problem on my system? I also have C stdlib
installed.


Yes, the stdlib and the stdc++ libs are the standard libraries available 
on almost all Unixes nowadays. That's why we prefer using these 
libraries to provide the STL functionality we need. Having such native 
libs is much better than us shipping some an old stlport4 binary that is 
based on long unmaintained versions of a non-standard compliant library.



Finally, in order to do anything, I had to muck with the include (-I)
definitions since stlport was not in the generated includes. Maybe we need
to fix this since it's no longer provided locally?

All was more or less fine with my setup until this change -- now things are
not happy.


Please use the --without-stlport configure switch.

This option is the new default. Thanks to Jan for fixing configure.in. 
But you'd need to update to the newest trunk version to benefit from 
Jan's fix.


Herbert


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

Re: many many stlport issues...can anyone help

[Herbert Duerr]

On 20.11.2013 09:20, Andre Fischer wrote:

On 20.11.2013 08:33, Herbert Duerr wrote:


Please use the --without-stlport configure switch.

This option is the new default. Thanks to Jan for fixing configure.in.
But you'd need to update to the newest trunk version to benefit from
Jan's fix.



Is there any reason why we still need this option (be it default or
not)?


If there is a choice between step-wise evolution and a big-bang change 
I'd always prefer the step-wise evolution.


We don't NEED this option. We don't NEED individual commits either, all 
we NEED is a good next release. But a big-bang commit that would update 
AOO 4.0.1 to AOO 4.1.0 wouldn't be really helpful.


Most users couldn't care less but from the standpoint of a professional 
developer individual bi-sectable commits that address the different 
aspects of a problem are orders of magnitude better than their big-bang 
alternatives.



 Is there any scenario where we would need that switch to turn on
support for stlport?


A developer reusing the latest recipes from our snapshots page would 
fail with the latest trunk if the --without-stlport option was no longer 
recognized.


Also code bisection [1] is a very valuable tool in software engineering. 
When bisecting it is good when one doesn't have too many knobs to turn 
for each bisection step (such as if revdifferent option).


[1] http://en.wikipedia.org/wiki/Code_Bisection

Please learn about this powerful concept. It is another good reason to 
switch to git because it supports this facility wonderfully.


So the AOO evolution of the configure option was/is:
1) encourage the use of --without-stlport
2) identify and solve all issues on all target platforms
3) make --without-stlport the default
4) remove obsoleted code parts
5) remove --without-stlport being tolerated after it has become the 
default and it stopped being useful


The current trunk is now after step 4, but as described above tolerating 
the --without-stlport option is still useful.


Herbert

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

Re: trunk build failure: ld: library not found for -lc++ in comphelper

[Herbert Duerr]

Hi Pavel,

> current trunk on unxmacxi:


Pavel-Janiks-MacBook-Pro:comphelper pavel$ make
[ build LNK ] Library/libcomphelpgcc3.dylib
R=/Users/pavel/BUILD/BuildDir && S=$R/ooo_trunk_src && O=$S/solver/410/unxmacxi.pro && W=$O/workdir &&  
mkdir -p $W/LinkTarget/Library/ && DYLIB_FILE=`/usr/bin/mktemp -t gbuild.` && /usr/bin/perl 
$S/solenv/bin/macosx-dylib-link-list.pl  -dynamiclib -single_module -install_name 
'@__OOO/libcomphelpgcc3.dylib' -Wl,-syslibroot,/Developer/SDKs/MacOSX10.5.sdk  -L$O/lib 
-L/usr/lib  -luno_sal -luno_cppuhelpergcc3 -luno_cppu -lucbhelper4gcc3 -lvos3gcc3 -lc++  > ${DYLIB_FILE} && ccache 
/usr/bin/g++-4.0  -dynamiclib -single_module -install_name '@__OOO/libcomphelpgcc3.dylib' 
-Wl,-syslibroot,/Developer/SDKs/MacOSX10.5.sdk  -L$O/lib -L/usr/lib  -luno_sal -luno_cppuhelpergcc3 -luno_cppu -lucbhelper4gcc3 -lvos3gcc3 
-lc++   $W/CxxObject/comphelper/source/compare/AnyCompareFactory.o 
$W/CxxObject/comphelper/source/container/IndexedPropertyValuesContainer.o $W/CxxObject/comphelper/source/container/NamedPr

opertyValuesContainer.o ... $W/CxxObject/comphelper/source/xml/attributelist.o 
$W/CxxObject/comphelper/source/xml/ofopxmlhelper.o-o $W/LinkTarget/Library/libcomphelpgcc3.dylib 
`cat ${DYLIB_FILE}` &&  /usr/bin/perl $S/solenv/bin/macosx-change-install-names.pl Library OOO 
$W/LinkTarget/Library/libcomphelpgcc3.dylib && ln -sf 
$W/LinkTarget/Library/libcomphelpgcc3.dylib $W/LinkTarget/Library/libcomphelpgcc3.jnilib && rm 
-f ${DYLIB_FILE}

ld: library not found for -lc++
collect2: ld returned 1 exit status
make: *** 
[/Users/pavel/BUILD/BuildDir/ooo_trunk_src/solver/410/unxmacxi.pro/workdir/LinkTarget/Library/libcomphelpgcc3.dylib]
 Error 1
Pavel-Janiks-MacBook-Pro:comphelper pavel$



Please update your trunk checkout (r1543407 or newer) and restart doing 
a clean build.


Herbert

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

Re: many many stlport issues...can anyone help

[Herbert Duerr]

On 20.11.2013 09:54, Herbert Duerr wrote:

[...]

So the AOO evolution of the configure option was/is:
1) encourage the use of --without-stlport
2) identify and solve all issues on all target platforms
3) make --without-stlport the default
4) remove obsoleted code parts
5) remove --without-stlport being tolerated after it has become the
default and it stopped being useful


Some important steps were missing in my previous mail. Here is a better 
description of the stepwise evolution:


1) implement --without-stlport support also for non-Linux platforms
2) encourage the use of --without-stlport for all platforms
3) identify and solve all issues on all target platforms
4) make --without-stlport the default
5) disallow the --with-stlport option and warn about it in configure
6) remove code parts obsoleted by the dropped stlport4 support
7) remove --without-stlport being tolerated after it has become the 
default and it stopped being useful


The current trunk has now passed step 6.

Herbert

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

Re: many many stlport issues...can anyone help

[Herbert Duerr]

On 21.11.2013 01:27, Kay Schenk wrote:

[...]
short update...in building  xml2cmp/source/finder

the reference to

#  include BOOST_TR1_STD_HEADER(utility) in

../boost/tr1/detail/config_all.hpp

fails for me either from the externally installed boost or my local
install.


BOOST_TR1_STD_HEADER(utility) should find a C++ header named utility 
[1]. Since we are using boost/tr1 it should be found from 
solver/*/*/inc/boost/tr1/tr1/utility


[1] http://www.cplusplus.com/reference/utility/


I have no idea why this never happened before the stlport removal
but there you have it. I guess to make this work, I will need to define
BOOST_TR1_STD_HEADER properly at least.


Do you happen to have set a HAVE_STL_INCLUDE_PATH manually? This could 
interfere with boost finding its own headers. So please undefine it.


Herbert

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

Re: trunk build failure: ld: library not found for -lc++ in comphelper

[Herbert Duerr]

On 22.11.2013 08:17, Pavel Janík wrote:

 From where is -lc++ generated?

I forgot to mention that I do not use 4u sdk, but MacOSX10.5.sdk only.


The same issue later in module unoxml.

Looks like something somewhere is doing s/-lstdc++/-lc++/ ie. removing the 
string std from the lib name. Hints?


Ah, now that you mention it:
Such a replacement is done if MACOSX_DEPLOYMENT_TARGET!=10.4. The 
unxmacx.* target is for the 10.4 SDK, but the newer mac targets for more 
recent SDKs use libc++ as their native STL.


So if you adjusted the check in main/RepositoryFixes.mk:50 to your use 
of the 10.5 SDK instead of the intended 10.4 SDK then everything should 
work again in your environment.


Hope that helps!

Herbert

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

Re: trunk build failure: ld: library not found for -lc++ in comphelper

[Herbert Duerr]

On 22.11.2013 09:14, Pavel Janík wrote:

Ah, now that you mention it:
Such a replacement is done if MACOSX_DEPLOYMENT_TARGET!=10.4. The unxmacx.* 
target is for the 10.4 SDK, but the newer mac targets for more recent SDKs use 
libc++ as their native STL.

So if you adjusted the check in main/RepositoryFixes.mk:50 to your use of the 
10.5 SDK instead of the intended 10.4 SDK then everything should work again in 
your environment.


Looks like this is it, thanks!


A better test would have checked for less-than 10.6 SDK, but gnu make 
only supports the equal/not-equal check. Since the 10.4 SDK was listed 
as build requirement for the original mac build it was the only version 
checked for.


Even better tests would have been possible, e.g. make it dependent on 
the XCode>=4 clang environment, etc. but if an ifeq check suffices for 
normal build environments then putting too much thought into it to cover 
all eventual corner cases would be a bit of overkill.



/me should have mentioned his strange build env ;-)


We figured it out and learned from it.

It's great that we/our community build in so many different 
environments. It's inevitable that problems show up then. If we solve 
them and it helps to make our code base better then its worth it.


Herbert

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

Re: EXTERNAL: Re: Building comphelper

[Herbert Duerr]

Hi Raymond,

On 21.11.2013 22:27, Steele, Raymond wrote:

Forget about my last report. We started over and figured out that an 
environment variable was causing the dmake issues.  Once we cleared the 
environment of variables related to our other projects, the build took off. We 
will have to figure out what it was later.


Thanks for debugging and solving that problem!

The current way of configure writing a file for setting environments 
variables is too fragile. As can be seen in your example if configure is 
run in an environment that is already "contaminated" with such env vars 
then unnecessary causes of troubles exist.


IMHO build and config settings should be done via e.g. Makefile.config 
that should be created by configure. This config result should then be 
included by the other Makefiles.


So if in doubt better use a fresh shell before running configure.

Herbert

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

Re: trunk: error: "STR_STYLE_ELEMTLIST" redefined

[Herbert Duerr]

Hi Pavel,

On 22.11.2013 12:03, Pavel Janík wrote:

Good afternoon,

current trunk:

[ build CXX ] sfx2/source/dialog/templdlg
In file included from 
/Users/pavel/BUILD/BuildDir/ooo_trunk_src/sfx2/source/dialog/templdlg.cxx:64:
/Users/pavel/BUILD/BuildDir/ooo_trunk_src/sfx2/source/dialog/dialog.hrc:77:1: error: 
"STR_STYLE_ELEMTLIST" redefined
In file included from 
/Users/pavel/BUILD/BuildDir/ooo_trunk_src/sfx2/source/dialog/templdlg.cxx:62:
/Users/pavel/BUILD/BuildDir/ooo_trunk_src/sfx2/source/dialog/templdlg.hrc:49:1: 
error: this is the location of the previous definition

Pavel-Janiks-MacBook-Pro:dialog pavel$ grep "define STR_STYLE_ELEMTLIST" *
dialog.hrc:#define STR_STYLE_ELEMTLIST  ( 
RC_DIALOG_BEGIN + 125 )
templdlg.hrc:#define STR_STYLE_ELEMTLIST18
Pavel-Janiks-MacBook-Pro:dialog pavel$


Good catch! Looking at Mattias's commit [1] from two years ago the 
STR_STYLE_ELEMTLIST seems to be the right one. I'm cc'ing the expert.


[1] http://svn.apache.org/viewvc?view=revision&revision=1172343

Herbert


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

Re: trunk: error: "STR_STYLE_ELEMTLIST" redefined

[Herbert Duerr]

A follow up to my previous mail:

On 22.11.2013 13:20, Herbert Duerr wrote:

[...]
Good catch! Looking at Mattias's commit [1] from two years ago the
STR_STYLE_ELEMTLIST seems to be the right one. I'm cc'ing the expert.

[1] http://svn.apache.org/viewvc?view=revision&revision=1172343


To clarify main/sfx2/source/dialog/dialog.hrc seems to be the right one 
because it was intentionally moved there (from [2] to [3]) in the 
resource error fix by Matthias.


[2] 
http://svn.apache.org/viewvc/incubator/ooo/trunk/main/sfx2/source/dialog/templdlg.hrc?r1=1172343&r2=1172342&pathrev=1172343
[3] 
http://svn.apache.org/viewvc/incubator/ooo/trunk/main/sfx2/source/dialog/dialog.hrc?r1=1172343&r2=1172342&pathrev=1172343


Herbert

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

Re: Join the open office project

[Herbert Duerr]

Hi Andrea,

> Still my build does not complete successfully, since it breaks in VCL.
> The error I get is:
> 
> [ build CXX ] vcl/unx/generic/gdi/salgdi3
> .../main/vcl/unx/generic/gdi/salgdi3.cxx: In member function 'virtual
> void PspKernInfo::Initialize() const':
> [...]
> Has someone else already seen/solved that?

Please update your trunk checkout (to revision r1545947 or newer).

Herbert

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

Re: soltools need(s) to be rebuilt

[Herbert Duerr]

On 28.11.2013 18:31, Απόστολος Συρόπουλος wrote:

[...]
I am proceeding slowly now since many things fail and I have to do them
manually. For example,  the following fails

configure: configuring in CoinUtils
configure: running /bin/sh './configure' 
--prefix=/extra/sources/OpenOffice/aoo-4.0.1/ext_libraries/coinmp/unxsoli4.pro/misc/build/CoinMP-1.6.0
  '--disable-pkg-config' '--disable-bzlib' '--disable-zlib' 'CC=/usr/bin/cc 
"-features=rvalueref"' 'CXX=/usr/bin/CC "-features=rvalueref"' 
--cache-file=/dev/null --srcdir=.

simply because 'CC=/usr/bin/cc "-features=rvalueref"' 'CXX=/usr/bin/CC 
"-features=rvalueref"'  should be
'CC=/usr/bin/cc -features=rvalueref' 'CXX=/usr/bin/CC -features=rvalueref'

I cross my fingers and I proceed.


The quoted -features=rvalueref compiler option is probably caused by the 
ARCH_FLAGS define in main/solenv/inc/unxsoli4.mk
I suggest to unquote it. But why did it work for others? Did dmake 
unquote automatically at one time?


Herbert

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

Re: soltools need(s) to be rebuilt

[Herbert Duerr]

On 01.12.2013 20:26, Απόστολος Συρόπουλος wrote:

After reading the reply by  jan I. I decided to try again with GCC.
Now, compilation proceeds with no stupid problems as before.
BTW, main/soltools/adjustvisibility/adjustvisibility.c does not
compile with g++ but it compiles with CC so this is the only
thing I had to do manually. However, now compilation stops
as follows:
[...]
: ERROR: ld.so.1: checkdll: fatal: relocation error: file 
../unxsogi.pro/lib/check_libuno_sal.so.3: symbol osl_isSingleCPU: referenced 
symbol not found
[...]
I see that file interlck_x86.s is old... but I have no idea why linking fails. 
Any ideas and/or suggestions?


I suggest to look into main/sal/osl/unx/util.c. The check for a 
__SUNPRO_C define in line 316 looks suspicious. Is this define still 
active in newer compilers for your platform? If not please change the 
check so that this part of the code becomes active.


You also said you switched compilers. Please make sure that there are no 
object files around that were build for the other compiler.


Herbert

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

Re: Improvements of OUString

[Herbert Duerr]

On 03.12.2013 09:13, Andre Fischer wrote:

A developer who apparently wants to remain anonymous has added the
function isEmpty() to the rtl::OUString class.  See
main/sal/inc/rtl/ustring.hxx for not much more information.


Sorry for being too short. The full semantic for isEmpty() is:

"The method isEmpty() returns true if the string is empty. If the length 
of the string is one or two or three or any number bigger than zero then 
isEmpty() returns false."


I added isEmpty() to make it possible to cleanly express the check for 
an empty string. In our codebase there were quite a few constructs such as

if( aString) {}
which were intended to mean
if( aString.isEmpty()) {}
What's funny is that the old construct compiled but it did the wrong 
thing: The string was implicitly converted to a pointer to its elements 
and that pointer was then compared against NULL. For our OUString that 
pointer was always non-NULL though.


Please see issue 123068 for further problems caused by the implicit 
conversion of the OUString to a pointer to its elements. This dangerous 
conversion is now disabled. By making the method private all such 
problems will be found and prevented by the compiler. When we're 
confident that all has been found the operator can be removed completely.



This in itself may not yet be very exciting but I hope that it is the
first of several improvements to one of our most frequently used
classes.  Sadly, we missed the opportunity to make some more substantial
but incompatible changes for the 4.0 release. However, some changes that
make OUString more accessible to new (and old) developers might include:

- Make construction from string literal more straightforward.  At the
moment you have to write
 ::rtl::OUString("text", sizeof("text"), RTL_TEXTENCODING_ASCII_US)
   or slightly shorter and safer
 ::rtl::OUString::createFromAscii("text")


Allocating heap space, transcoding a literal string to this memory and 
deallocating it later when the string is deleted are quite wasteful 
operations. Especially when considering that the literal string is 
already there. It would be great if constructs such

OUString( L"hello")
used the pointer to the UTF-16 literal directly instead of copying its 
contents around. The same applies for the OString(). The 'L' prefix is a 
Windows convention but C++11 has even more possibilities with its 
support for unicode string literals.


Also we shouldn't bother our main string classes with non-unicode 
support. Having external tooling for converting from/to other encodings 
is still needed though.


Looking over our string processing I'm confident that we could get along 
great with UTF-8 strings. Only when interfacing with other APIs an 
eventual conversion to UTF-16 would be needed.


And if we were using UTF-8 byte strings we could base them directly on 
the standard std::string.



- Conversion back to char* is not much better
 ::rtl::OUStringToOString(sOUStringVariable,
RTL_TEXTENCODING_ASCII_US).getStr()


This awful construct could be made much simpler if our strings were 
always unicode (UTF-8/UTF-16/UTF-32).



Do you have more ideas?


Using ideas from languages such as Python/Perl/Java for convenient and 
powerful string processing to replace the awkward string handling that 
is too often seen in our code base. E.g. having regexp enabled match() 
or search() methods would be a great start.


Herbert


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

Re: EXTERNAL: Re: Building comphelper

[Herbert Duerr]

A small correction for my patch suggestion:

On 03.12.2013 11:36, Herbert Duerr wrote:

[...]
+DEBUGBASE_ENSURE( !bOK, "### insertion failed!?" );


The condition there was inverted. It should have been
DEBUGBASE_ENSURE( bOK, "### insertion failed!?" );

Herbert


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

Re: EXTERNAL: Re: Building comphelper

[Herbert Duerr]

Hi Raymond,

On 02.12.2013 23:34, Steele, Raymond wrote:

Let me know if you did not get the attachment.


Attachments usually get stripped on the mailing list, but I got it 
because was on CC. As the PDF only contained scanned text a simple 
copy+paste of that text would have been better.



We are having trouble interpreting the boost preprocessor macros. We are 
receiving the following output when compiling sal/osl/all.  I've attached the 
output as a pdf.


Line 133 of main/sal/osl/all/debugbase.cxx had a problem with a 
hand-crafted map::value_type and const correctness. Please try

this patch to make the construct more digestible:

--- main/sal/osl/all/debugbase.cxx
+++ main/sal/osl/all/debugbase.cxx
@@ -129,10 +129,9 @@ void SAL_CALL osl_detail_ObjectRegistry_registerObject(
 {
 if (rData.m_bStoreAddresses) {
 osl::MutexGuard const guard( 
osl_detail_ObjectRegistry_getMutex() );
-std::pair const 
insertion(

-rData.m_addresses.insert(pObj) );
-DEBUGBASE_ENSURE( insertion.second, "### insertion failed!?" );
-static_cast(insertion);
+const bool bOK = rData.m_addresses.insert(pObj).second;
+DEBUGBASE_ENSURE( !bOK, "### insertion failed!?" );
+(void)bOK; // unused for non-debug
 }
 else {
 osl_incrementInterlockedCount(&rData.m_nCount);


Please report whether this helps, I'll commit the change then.

Herbert


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

Re: Improvements of OUString

[Herbert Duerr]

On 03.12.2013 13:02, Andre Fischer wrote:

On 03.12.2013 10:35, Herbert Duerr wrote:

On 03.12.2013 09:13, Andre Fischer wrote:
[...]
"The method isEmpty() returns true if the string is empty. If the
length of the string is one or two or three or any number bigger than
zero then isEmpty() returns false."


Additionally to this almost correct statement one could mention that
isEmpty() is preferred over getLength()>0 and why.


Yes, it is preferred for checking the emptiness because it directly 
expresses what it checks.


In general it is a good idea to check for emptiness instead of counting 
the elements and then comparing against zero. Its the old "interface vs. 
implementation detail" question. The result will be the same from a 
mathematical standpoint but the effort to get this result may be 
different. From an algorithmic complexity standpoint an emptiness check 
is always equal or better. Maybe a mathematician can provide some 
insights from the set theory on this question?


By the way: the String class of Java>=6 got its isEmpty() method for the 
same reasons.



Can you tell me what happens when an OUString is created for "\0". Is
that handled as end-of-string or as just one additional character?


What happens during the string construction is unchanged. So if you were 
using the

OString( "\0")
it did and does create a zero-length OUString. If you were using the 
constructor with length argument

OString( "\0", 1)
then the length was and is 1, because 1 was provided as length argument.

Only a string without any elements is empty. A string with one or more 
elements is considered non-empty even if all its elements are zero. So 
if you used a test like aString.getLength()==0 before you can use 
aString.isEmpty() directly.



[...]
Also we shouldn't bother our main string classes with non-unicode
support. Having external tooling for converting from/to other
encodings is still needed though.


We should drop our support for ASCII?


UTF-8 contains ASCII. This was one of its most important design goals 
and IMHO is a key factor that made this encoding such a big success.


Speaking of UTF-8 vs. ASCII I suggest to change the O*String methods 
such as createFromAscii() to createFromUtf8().



[...]
 ::rtl::OUStringToOString(sOUStringVariable,
RTL_TEXTENCODING_ASCII_US).getStr()


This awful construct could be made much simpler if our strings were
always unicode (UTF-8/UTF-16/UTF-32).


I thought that OUString is UTF-16 and that that where the cause, not the
solution of the conversion problems.


The complexity of the awful construct comes from the use of the general 
purpose machinery for an N:1 conversion (with N being the number of 
supported byte encodings). A 1:1 conversion (UTF-8 <-> UTF-16) is much 
simpler.


As I wrote I'd even like to go full UTF-8 inside AOO. Most of the back 
and forth transcodings between UTF-8 and UTF-16 inside AOO are just 
wasteful.


Herbert


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