Re: Heard you guys could use a hand

2016-09-05 Thread Patricia Shanahan 

On 9/5/2016 3:23 PM, lhicks wrote:


Hi there,
My name is Logan Hicks, President of Eduarmor Inc.
I heard you guys were struggling with OpenOffice, and we might have a solution.
We currently run a program called PANDA, which stands for platform 
accessibility and development acceleration, and is targeted towards rapid 
development and accessibility to open source developers and open source 
projects.
We are a major champion of open source projects, and pour resources into 
sustaining open source projects that are struggling.
We understand you have a personnel deficiency for your project,  and we have 
access to over 14,000 people who could easily fill that gap.
Who should we talk to to discuss this further?
As a user of OpenOffice myself, I would hate to see if fade, gracefully or 
otherwise.
Respectfully,
Logan Hicks, aka Fallenour

Sent from my Verizon, Samsung Galaxy smartphone



I believe the main need is for individual volunteer developers. We now 
have a mailing list, recruitm...@openoffice.apache.org, for volunteers 
to join to introduce themselves and get help finding where they fit in. 
Please pass that on to anyone in your network who might be interested.


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

Re: Help needed: Build error in bean and vcl

2016-09-05 Thread Marcus 

Am 09/06/2016 12:25 AM, schrieb Don Lewis:

On  6 Sep, Marcus wrote:

Am 09/05/2016 11:00 PM, schrieb Don Lewis:

On  5 Sep, Marcus wrote:

Am 09/05/2016 10:39 PM, schrieb Don Lewis:

On  5 Sep, Marcus wrote:

Am 09/05/2016 09:33 PM, schrieb Don Lewis:

On  5 Sep, Marcus wrote:

Am 09/05/2016 05:39 AM, schrieb Don Lewis:

On  4 Sep, Don Lewis wrote:

On  4 Sep, Marcus wrote:

Thanks a lot. "libXt-devel" was indeed not installed.

But now it's breaking in svx:

[...]

=
Building module svx
=

Entering /share/linux2/aoo/trunk/main/svx/prj

cd ..&&  make -s -r -j1&&  make -s -r deliverlog
[ build LNK ] Library/libsvxcore.so
/share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/CxxObject/svx/source/fmcomp/fmgridif.o:
In function
`FmXGridControl::createPeer(com::sun::star::uno::Reference
const&, com::sun::star::uno::Reference
const&)':
fmgridif.cxx:(.text+0x68b2): undefined reference to `non-virtual thunk to
WindowListenerMultiplexer::acquire()'
/usr/bin/ld:
/share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/CxxObject/svx/source/fmcomp/fmgridif.o:
relocation R_X86_64_PC32 against undefined symbol
`_ZThn48_N25WindowListenerMultiplexer7acquireEv' can not be used when
making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
/share/linux2/aoo/trunk/main/solenv/gbuild/LinkTarget.mk:248: recipe for
target
'/share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/LinkTarget/Library/libsvxcore.so'
failed
make: ***
[/share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/LinkTarget/Library/libsvxcore.so]
Error 1
dmake:  Error code 2, while making 'all'

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


That looks very familiar.  What compiler version are you using?


gcc 4.9.2


Yup, it's gcc 4.9 bug.  This is what I did for the FreeBSD port to work
around this problem:


Unfortunately $(CCNUMVER) isn't available to gbuild so we can't disable
optimization of the affected file only for gcc 4.9.


I'm sorry but the error has not changed. I've compared the patched
"Library_svxcore.mk" file with the original one and only these changes
were made.

In your patch a "dbaccess/source/ui/uno/makefile.mk" file is mentioned
which I don't have. Is this related to the "--disable-odk" configure
flag I've used and therefore is OK?


Hmn, that's strange.  That makefile is still present in recent trunk.
It' doesn't have any relationship to --disable-odk.


Yesterday I've done my very first checkout and a "svn update" a second
ago in the directory doesn't got anything new. SWo, it's indeed strange.


Is there any other way than to downgrade gcc?


For the FreeBSD port, I'm not using that patch due to the lack of
$(CCNUMVER) on the gbuild side of thigs.  If we had that, then I would
have upstreamed the patch.  Instead, I'm still using the workaround in
the third to last paragraph.  The Makefile for the FreeBSD port does
this on-the-fly patch:

.if ${COMPILER_TYPE} == gcc
# g++49 -Os sometimes leaves inline class methods undefined,
# affects fmgridif.cxx and ColumnControl.cxx
# See:
if [ ${CXX} = g++49  ]; then \
${REINPLACE_CMD} -e "s/ := -Os/ := -Os -fno-devirtualize 
-fno-de
virtualize-speculatively/" ${WRKSRC}/solenv/gbuild/platform/freebsd.mk; \
${REINPLACE_CMD} -e "s/=-Os /=-Os -fno-devirtualize 
-fno-devirtu
alize-speculatively /" ${WRKSRC}/solenv/inc/unxfbsdi.mk; \
fi


For Linux you would have to patch main/solenv/gbuild/platform/linux.mk
(and main/solenv/inc/unxlng*.mk for non-x86_64 platforms).


I've add the following to line 152, beside to the COMPILERNOOPTSFLAFS

gb_COMPILEROPTFLAGS := O0

I hope that this correct. If so, then unfortunately it doesn't make a
change. Stil lthe same error.


On x86_64, the Library_svxcore.mk patch should have done the trick
though.  The problem is triggered by using -Os optimization and with
that change to Library_svxcore.mk, fmgridif.cxx should be getting
compiled with -O0.  Can you check the log file to see if that is the
case?  You'll probably have to configure with --enable-verbose to see
it.


OK, turned back the "linux.mk" patch.

I've added --enable-verbose to configure, bootstrap'ed and source'ed
again. The build cancelled at the same location and with the same error
message.

"fmgridif.cxx" was nowhere mentioned, only a "fmgridif.o". It's the last
file mentioned in a long list of .o files from module "svx".


Are you starting from a clean build each time?  If you just restart the
build, it will reuse the bad fmgridif.o.  It is necessary to recompile
fmgridif.cxx with the patched Library_svxcore.mk.


I always do a "build --prepare --from svx" before starting a new build.
I hope thats the right one. I don't find a "clean" or something else for
the "build"

Heard you guys could use a hand

2016-09-05 Thread lhicks 

Hi there,
My name is Logan Hicks, President of Eduarmor Inc.
I heard you guys were struggling with OpenOffice, and we might have a solution.
We currently run a program called PANDA, which stands for platform 
accessibility and development acceleration, and is targeted towards rapid 
development and accessibility to open source developers and open source 
projects.
We are a major champion of open source projects, and pour resources into 
sustaining open source projects that are struggling.
We understand you have a personnel deficiency for your project,  and we have 
access to over 14,000 people who could easily fill that gap.
Who should we talk to to discuss this further?
As a user of OpenOffice myself, I would hate to see if fade, gracefully or 
otherwise.
Respectfully,
Logan Hicks, aka Fallenour

Sent from my Verizon, Samsung Galaxy smartphone

Re: Help needed: Build error in bean and vcl

2016-09-05 Thread Don Lewis 
On  6 Sep, Marcus wrote:
> Am 09/05/2016 11:00 PM, schrieb Don Lewis:
>> On  5 Sep, Marcus wrote:
>>> Am 09/05/2016 10:39 PM, schrieb Don Lewis:
 On  5 Sep, Marcus wrote:
> Am 09/05/2016 09:33 PM, schrieb Don Lewis:
>> On  5 Sep, Marcus wrote:
>>> Am 09/05/2016 05:39 AM, schrieb Don Lewis:
 On  4 Sep, Don Lewis wrote:
> On  4 Sep, Marcus wrote:
>> Thanks a lot. "libXt-devel" was indeed not installed.
>>
>> But now it's breaking in svx:
>>
>> [...]
>>
>> =
>> Building module svx
>> =
>>
>> Entering /share/linux2/aoo/trunk/main/svx/prj
>>
>> cd ..&& make -s -r -j1&& make -s -r deliverlog
>> [ build LNK ] Library/libsvxcore.so
>> /share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/CxxObject/svx/source/fmcomp/fmgridif.o:
>> In function
>> `FmXGridControl::createPeer(com::sun::star::uno::Reference
>> const&, 
>> com::sun::star::uno::Reference
>> const&)':
>> fmgridif.cxx:(.text+0x68b2): undefined reference to `non-virtual 
>> thunk to
>> WindowListenerMultiplexer::acquire()'
>> /usr/bin/ld:
>> /share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/CxxObject/svx/source/fmcomp/fmgridif.o:
>> relocation R_X86_64_PC32 against undefined symbol
>> `_ZThn48_N25WindowListenerMultiplexer7acquireEv' can not be used when
>> making a shared object; recompile with -fPIC
>> /usr/bin/ld: final link failed: Bad value
>> collect2: error: ld returned 1 exit status
>> /share/linux2/aoo/trunk/main/solenv/gbuild/LinkTarget.mk:248: recipe 
>> for
>> target
>> '/share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/LinkTarget/Library/libsvxcore.so'
>> failed
>> make: ***
>> [/share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/LinkTarget/Library/libsvxcore.so]
>> Error 1
>> dmake:  Error code 2, while making 'all'
>>
>> 1 module(s):
>>  svx
>> need(s) to be rebuilt
>
> That looks very familiar.  What compiler version are you using?
>>>
>>> gcc 4.9.2
>>>
 Yup, it's gcc 4.9 bug.  This is what I did for the FreeBSD port to work
 around this problem:
 

 Unfortunately $(CCNUMVER) isn't available to gbuild so we can't disable
 optimization of the affected file only for gcc 4.9.
>>>
>>> I'm sorry but the error has not changed. I've compared the patched
>>> "Library_svxcore.mk" file with the original one and only these changes
>>> were made.
>>>
>>> In your patch a "dbaccess/source/ui/uno/makefile.mk" file is mentioned
>>> which I don't have. Is this related to the "--disable-odk" configure
>>> flag I've used and therefore is OK?
>>
>> Hmn, that's strange.  That makefile is still present in recent trunk.
>> It' doesn't have any relationship to --disable-odk.
>
> Yesterday I've done my very first checkout and a "svn update" a second
> ago in the directory doesn't got anything new. SWo, it's indeed strange.
>
>>> Is there any other way than to downgrade gcc?
>>
>> For the FreeBSD port, I'm not using that patch due to the lack of
>> $(CCNUMVER) on the gbuild side of thigs.  If we had that, then I would
>> have upstreamed the patch.  Instead, I'm still using the workaround in
>> the third to last paragraph.  The Makefile for the FreeBSD port does
>> this on-the-fly patch:
>>
>> .if ${COMPILER_TYPE} == gcc
>># g++49 -Os sometimes leaves inline class methods undefined,
>># affects fmgridif.cxx and ColumnControl.cxx
>># See:
>>if [ ${CXX} = g++49  ]; then \
>>${REINPLACE_CMD} -e "s/ := -Os/ := -Os 
>> -fno-devirtualize -fno-de
>> virtualize-speculatively/" ${WRKSRC}/solenv/gbuild/platform/freebsd.mk; \
>>${REINPLACE_CMD} -e "s/=-Os /=-Os -fno-devirtualize 
>> -fno-devirtu
>> alize-speculatively /" ${WRKSRC}/solenv/inc/unxfbsdi.mk; \
>>fi
>>
>>
>> For Linux you would have to patch main/solenv/gbuild/platform/linux.mk
>> (and main/solenv/inc/unxlng*.mk for non-x86_64 platforms).
>
> I've add the following to line 152, beside to the COMPILERNOOPTSFLAFS
>
> gb_COMPILEROPTFLAGS := O0
>
> I hope that this correct. If so, then unfortunately it doesn't make a
> change. Stil lthe same error.
>
>> On x86_64, the Library_svxcore.mk patch should have done the trick
>> though.  The problem is triggered by using -Os optimization and with
>> that change to

Re: Help needed: Build error in bean and vcl

2016-09-05 Thread Marcus 

Am 09/05/2016 11:00 PM, schrieb Don Lewis:

On  5 Sep, Marcus wrote:

Am 09/05/2016 10:39 PM, schrieb Don Lewis:

On  5 Sep, Marcus wrote:

Am 09/05/2016 09:33 PM, schrieb Don Lewis:

On  5 Sep, Marcus wrote:

Am 09/05/2016 05:39 AM, schrieb Don Lewis:

On  4 Sep, Don Lewis wrote:

On  4 Sep, Marcus wrote:

Thanks a lot. "libXt-devel" was indeed not installed.

But now it's breaking in svx:

[...]

=
Building module svx
=

Entering /share/linux2/aoo/trunk/main/svx/prj

cd ..&& make -s -r -j1&& make -s -r deliverlog
[ build LNK ] Library/libsvxcore.so
/share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/CxxObject/svx/source/fmcomp/fmgridif.o:
In function
`FmXGridControl::createPeer(com::sun::star::uno::Reference
const&, com::sun::star::uno::Reference
const&)':
fmgridif.cxx:(.text+0x68b2): undefined reference to `non-virtual thunk to
WindowListenerMultiplexer::acquire()'
/usr/bin/ld:
/share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/CxxObject/svx/source/fmcomp/fmgridif.o:
relocation R_X86_64_PC32 against undefined symbol
`_ZThn48_N25WindowListenerMultiplexer7acquireEv' can not be used when
making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
/share/linux2/aoo/trunk/main/solenv/gbuild/LinkTarget.mk:248: recipe for
target
'/share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/LinkTarget/Library/libsvxcore.so'
failed
make: ***
[/share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/LinkTarget/Library/libsvxcore.so]
Error 1
dmake:  Error code 2, while making 'all'

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


That looks very familiar.  What compiler version are you using?


gcc 4.9.2


Yup, it's gcc 4.9 bug.  This is what I did for the FreeBSD port to work
around this problem:


Unfortunately $(CCNUMVER) isn't available to gbuild so we can't disable
optimization of the affected file only for gcc 4.9.


I'm sorry but the error has not changed. I've compared the patched
"Library_svxcore.mk" file with the original one and only these changes
were made.

In your patch a "dbaccess/source/ui/uno/makefile.mk" file is mentioned
which I don't have. Is this related to the "--disable-odk" configure
flag I've used and therefore is OK?


Hmn, that's strange.  That makefile is still present in recent trunk.
It' doesn't have any relationship to --disable-odk.


Yesterday I've done my very first checkout and a "svn update" a second
ago in the directory doesn't got anything new. SWo, it's indeed strange.


Is there any other way than to downgrade gcc?


For the FreeBSD port, I'm not using that patch due to the lack of
$(CCNUMVER) on the gbuild side of thigs.  If we had that, then I would
have upstreamed the patch.  Instead, I'm still using the workaround in
the third to last paragraph.  The Makefile for the FreeBSD port does
this on-the-fly patch:

.if ${COMPILER_TYPE} == gcc
   # g++49 -Os sometimes leaves inline class methods undefined,
   # affects fmgridif.cxx and ColumnControl.cxx
   # See:
   if [ ${CXX} = g++49  ]; then \
   ${REINPLACE_CMD} -e "s/ := -Os/ := -Os -fno-devirtualize 
-fno-de
virtualize-speculatively/" ${WRKSRC}/solenv/gbuild/platform/freebsd.mk; \
   ${REINPLACE_CMD} -e "s/=-Os /=-Os -fno-devirtualize 
-fno-devirtu
alize-speculatively /" ${WRKSRC}/solenv/inc/unxfbsdi.mk; \
   fi


For Linux you would have to patch main/solenv/gbuild/platform/linux.mk
(and main/solenv/inc/unxlng*.mk for non-x86_64 platforms).


I've add the following to line 152, beside to the COMPILERNOOPTSFLAFS

gb_COMPILEROPTFLAGS := O0

I hope that this correct. If so, then unfortunately it doesn't make a
change. Stil lthe same error.


On x86_64, the Library_svxcore.mk patch should have done the trick
though.  The problem is triggered by using -Os optimization and with
that change to Library_svxcore.mk, fmgridif.cxx should be getting
compiled with -O0.  Can you check the log file to see if that is the
case?  You'll probably have to configure with --enable-verbose to see
it.


OK, turned back the "linux.mk" patch.

I've added --enable-verbose to configure, bootstrap'ed and source'ed
again. The build cancelled at the same location and with the same error
message.

"fmgridif.cxx" was nowhere mentioned, only a "fmgridif.o". It's the last
file mentioned in a long list of .o files from module "svx".


Are you starting from a clean build each time?  If you just restart the
build, it will reuse the bad fmgridif.o.  It is necessary to recompile
fmgridif.cxx with the patched Library_svxcore.mk.


I always do a "build --prepare --from svx" before starting a new build.
I hope thats the right one. I don't find a "clean" or something else for
the "build" comamnd.


Hmn, I wonder if --prepare does the right thing with gbuild ...

Try

Recruitment mailing list created

2016-09-05 Thread Patricia Shanahan 
The recruitment@ mailing list has been created, accepts messages, and 
appears in lists.apache.org.


If you are pushing the "OpenOffice needs developers" message, please add 
a suggestion that anyone who wants to help can subscribe to 
recruitm...@openoffice.apache.org by sending e-mail to 
recruitment-subscr...@openoffice.apache.org


The objective is to provide a place for new volunteers to introduce 
themselves and get suggestions for what to do next in a less 
overwhelming environment than dev@



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

Hi

2016-09-05 Thread Rahul Tumma 
I am just a beginner who wants to learn coding for real time applications.
I have basic knowledge of 1-2 programming languages but i have never worked
in a real time environment, in your technologies. I want to learn,develop
to code
and i want to be a life long member, in this project.

I don't believe Education & degrees are essential for any dreamer who wants
to code. On that note,I hope you can engage in any area of work so that i
have privilege of being involved in open office project.I am ready to
volunteer as a
communicator of social forum or any task you may deem suitable for me.

Eagerly awaiting your reply.

Thanks,
RahulT.

Re: Help needed: Build error in bean and vcl

2016-09-05 Thread Don Lewis 
On  5 Sep, Marcus wrote:
> Am 09/05/2016 10:39 PM, schrieb Don Lewis:
>> On  5 Sep, Marcus wrote:
>>> Am 09/05/2016 09:33 PM, schrieb Don Lewis:
 On  5 Sep, Marcus wrote:
> Am 09/05/2016 05:39 AM, schrieb Don Lewis:
>> On  4 Sep, Don Lewis wrote:
>>> On  4 Sep, Marcus wrote:
 Thanks a lot. "libXt-devel" was indeed not installed.

 But now it's breaking in svx:

 [...]

 =
 Building module svx
 =

 Entering /share/linux2/aoo/trunk/main/svx/prj

 cd ..&&make -s -r -j1&&make -s -r deliverlog
 [ build LNK ] Library/libsvxcore.so
 /share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/CxxObject/svx/source/fmcomp/fmgridif.o:
 In function
 `FmXGridControl::createPeer(com::sun::star::uno::Reference
 const&, 
 com::sun::star::uno::Reference
 const&)':
 fmgridif.cxx:(.text+0x68b2): undefined reference to `non-virtual thunk 
 to
 WindowListenerMultiplexer::acquire()'
 /usr/bin/ld:
 /share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/CxxObject/svx/source/fmcomp/fmgridif.o:
 relocation R_X86_64_PC32 against undefined symbol
 `_ZThn48_N25WindowListenerMultiplexer7acquireEv' can not be used when
 making a shared object; recompile with -fPIC
 /usr/bin/ld: final link failed: Bad value
 collect2: error: ld returned 1 exit status
 /share/linux2/aoo/trunk/main/solenv/gbuild/LinkTarget.mk:248: recipe 
 for
 target
 '/share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/LinkTarget/Library/libsvxcore.so'
 failed
 make: ***
 [/share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/LinkTarget/Library/libsvxcore.so]
 Error 1
 dmake:  Error code 2, while making 'all'

 1 module(s):
svx
 need(s) to be rebuilt
>>>
>>> That looks very familiar.  What compiler version are you using?
>
> gcc 4.9.2
>
>> Yup, it's gcc 4.9 bug.  This is what I did for the FreeBSD port to work
>> around this problem:
>> 
>>
>> Unfortunately $(CCNUMVER) isn't available to gbuild so we can't disable
>> optimization of the affected file only for gcc 4.9.
>
> I'm sorry but the error has not changed. I've compared the patched
> "Library_svxcore.mk" file with the original one and only these changes
> were made.
>
> In your patch a "dbaccess/source/ui/uno/makefile.mk" file is mentioned
> which I don't have. Is this related to the "--disable-odk" configure
> flag I've used and therefore is OK?

 Hmn, that's strange.  That makefile is still present in recent trunk.
 It' doesn't have any relationship to --disable-odk.
>>>
>>> Yesterday I've done my very first checkout and a "svn update" a second
>>> ago in the directory doesn't got anything new. SWo, it's indeed strange.
>>>
> Is there any other way than to downgrade gcc?

 For the FreeBSD port, I'm not using that patch due to the lack of
 $(CCNUMVER) on the gbuild side of thigs.  If we had that, then I would
 have upstreamed the patch.  Instead, I'm still using the workaround in
 the third to last paragraph.  The Makefile for the FreeBSD port does
 this on-the-fly patch:

 .if ${COMPILER_TYPE} == gcc
   # g++49 -Os sometimes leaves inline class methods undefined,
   # affects fmgridif.cxx and ColumnControl.cxx
   # See:
   if [ ${CXX} = g++49  ]; then \
   ${REINPLACE_CMD} -e "s/ := -Os/ := -Os -fno-devirtualize 
 -fno-de
 virtualize-speculatively/" ${WRKSRC}/solenv/gbuild/platform/freebsd.mk; \
   ${REINPLACE_CMD} -e "s/=-Os /=-Os -fno-devirtualize 
 -fno-devirtu
 alize-speculatively /" ${WRKSRC}/solenv/inc/unxfbsdi.mk; \
   fi


 For Linux you would have to patch main/solenv/gbuild/platform/linux.mk
 (and main/solenv/inc/unxlng*.mk for non-x86_64 platforms).
>>>
>>> I've add the following to line 152, beside to the COMPILERNOOPTSFLAFS
>>>
>>> gb_COMPILEROPTFLAGS := O0
>>>
>>> I hope that this correct. If so, then unfortunately it doesn't make a
>>> change. Stil lthe same error.
>>>
 On x86_64, the Library_svxcore.mk patch should have done the trick
 though.  The problem is triggered by using -Os optimization and with
 that change to Library_svxcore.mk, fmgridif.cxx should be getting
 compiled with -O0.  Can you check the log file to see if that is the
 case?  You'll probably have to configure with --enable-verbose to see
 it.
>>>
>>> OK, turned back the "linux.mk" patch.
>>>
>>> I've added --enable-verbose to

Re: Help needed: Build error in bean and vcl

2016-09-05 Thread Marcus 

Am 09/05/2016 10:39 PM, schrieb Don Lewis:

On  5 Sep, Marcus wrote:

Am 09/05/2016 09:33 PM, schrieb Don Lewis:

On  5 Sep, Marcus wrote:

Am 09/05/2016 05:39 AM, schrieb Don Lewis:

On  4 Sep, Don Lewis wrote:

On  4 Sep, Marcus wrote:

Thanks a lot. "libXt-devel" was indeed not installed.

But now it's breaking in svx:

[...]

=
Building module svx
=

Entering /share/linux2/aoo/trunk/main/svx/prj

cd ..&&make -s -r -j1&&make -s -r deliverlog
[ build LNK ] Library/libsvxcore.so
/share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/CxxObject/svx/source/fmcomp/fmgridif.o:
In function
`FmXGridControl::createPeer(com::sun::star::uno::Reference
const&, com::sun::star::uno::Reference
const&)':
fmgridif.cxx:(.text+0x68b2): undefined reference to `non-virtual thunk to
WindowListenerMultiplexer::acquire()'
/usr/bin/ld:
/share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/CxxObject/svx/source/fmcomp/fmgridif.o:
relocation R_X86_64_PC32 against undefined symbol
`_ZThn48_N25WindowListenerMultiplexer7acquireEv' can not be used when
making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
/share/linux2/aoo/trunk/main/solenv/gbuild/LinkTarget.mk:248: recipe for
target
'/share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/LinkTarget/Library/libsvxcore.so'
failed
make: ***
[/share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/LinkTarget/Library/libsvxcore.so]
Error 1
dmake:  Error code 2, while making 'all'

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


That looks very familiar.  What compiler version are you using?


gcc 4.9.2


Yup, it's gcc 4.9 bug.  This is what I did for the FreeBSD port to work
around this problem:


Unfortunately $(CCNUMVER) isn't available to gbuild so we can't disable
optimization of the affected file only for gcc 4.9.


I'm sorry but the error has not changed. I've compared the patched
"Library_svxcore.mk" file with the original one and only these changes
were made.

In your patch a "dbaccess/source/ui/uno/makefile.mk" file is mentioned
which I don't have. Is this related to the "--disable-odk" configure
flag I've used and therefore is OK?


Hmn, that's strange.  That makefile is still present in recent trunk.
It' doesn't have any relationship to --disable-odk.


Yesterday I've done my very first checkout and a "svn update" a second
ago in the directory doesn't got anything new. SWo, it's indeed strange.


Is there any other way than to downgrade gcc?


For the FreeBSD port, I'm not using that patch due to the lack of
$(CCNUMVER) on the gbuild side of thigs.  If we had that, then I would
have upstreamed the patch.  Instead, I'm still using the workaround in
the third to last paragraph.  The Makefile for the FreeBSD port does
this on-the-fly patch:

.if ${COMPILER_TYPE} == gcc
  # g++49 -Os sometimes leaves inline class methods undefined,
  # affects fmgridif.cxx and ColumnControl.cxx
  # See:
  if [ ${CXX} = g++49  ]; then \
  ${REINPLACE_CMD} -e "s/ := -Os/ := -Os -fno-devirtualize 
-fno-de
virtualize-speculatively/" ${WRKSRC}/solenv/gbuild/platform/freebsd.mk; \
  ${REINPLACE_CMD} -e "s/=-Os /=-Os -fno-devirtualize 
-fno-devirtu
alize-speculatively /" ${WRKSRC}/solenv/inc/unxfbsdi.mk; \
  fi


For Linux you would have to patch main/solenv/gbuild/platform/linux.mk
(and main/solenv/inc/unxlng*.mk for non-x86_64 platforms).


I've add the following to line 152, beside to the COMPILERNOOPTSFLAFS

gb_COMPILEROPTFLAGS := O0

I hope that this correct. If so, then unfortunately it doesn't make a
change. Stil lthe same error.


On x86_64, the Library_svxcore.mk patch should have done the trick
though.  The problem is triggered by using -Os optimization and with
that change to Library_svxcore.mk, fmgridif.cxx should be getting
compiled with -O0.  Can you check the log file to see if that is the
case?  You'll probably have to configure with --enable-verbose to see
it.


OK, turned back the "linux.mk" patch.

I've added --enable-verbose to configure, bootstrap'ed and source'ed
again. The build cancelled at the same location and with the same error
message.

"fmgridif.cxx" was nowhere mentioned, only a "fmgridif.o". It's the last
file mentioned in a long list of .o files from module "svx".


Are you starting from a clean build each time?  If you just restart the
build, it will reuse the bad fmgridif.o.  It is necessary to recompile
fmgridif.cxx with the patched Library_svxcore.mk.


I always do a "build --prepare --from svx" before starting a new build. 
I hope thats the right one. I don't find a "clean" or something else for 
the "build" comamnd.



BTW:
Due to dependencies for ant, junit, hamcreast and others I had to
install JDK 1.8.0. Dont' know if this matters somehoe.


Not for this

Re: Help needed: Build error in bean and vcl

2016-09-05 Thread Don Lewis 
On  5 Sep, Marcus wrote:
> Am 09/05/2016 09:33 PM, schrieb Don Lewis:
>> On  5 Sep, Marcus wrote:
>>> Am 09/05/2016 05:39 AM, schrieb Don Lewis:
 On  4 Sep, Don Lewis wrote:
> On  4 Sep, Marcus wrote:
>> Thanks a lot. "libXt-devel" was indeed not installed.
>>
>> But now it's breaking in svx:
>>
>> [...]
>>
>> =
>> Building module svx
>> =
>>
>> Entering /share/linux2/aoo/trunk/main/svx/prj
>>
>> cd ..&&   make -s -r -j1&&   make -s -r deliverlog
>> [ build LNK ] Library/libsvxcore.so
>> /share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/CxxObject/svx/source/fmcomp/fmgridif.o:
>> In function
>> `FmXGridControl::createPeer(com::sun::star::uno::Reference
>> const&, com::sun::star::uno::Reference
>> const&)':
>> fmgridif.cxx:(.text+0x68b2): undefined reference to `non-virtual thunk to
>> WindowListenerMultiplexer::acquire()'
>> /usr/bin/ld:
>> /share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/CxxObject/svx/source/fmcomp/fmgridif.o:
>> relocation R_X86_64_PC32 against undefined symbol
>> `_ZThn48_N25WindowListenerMultiplexer7acquireEv' can not be used when
>> making a shared object; recompile with -fPIC
>> /usr/bin/ld: final link failed: Bad value
>> collect2: error: ld returned 1 exit status
>> /share/linux2/aoo/trunk/main/solenv/gbuild/LinkTarget.mk:248: recipe for
>> target
>> '/share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/LinkTarget/Library/libsvxcore.so'
>> failed
>> make: ***
>> [/share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/LinkTarget/Library/libsvxcore.so]
>> Error 1
>> dmake:  Error code 2, while making 'all'
>>
>> 1 module(s):
>>  svx
>> need(s) to be rebuilt
>
> That looks very familiar.  What compiler version are you using?
>>>
>>> gcc 4.9.2
>>>
 Yup, it's gcc 4.9 bug.  This is what I did for the FreeBSD port to work
 around this problem:
 

 Unfortunately $(CCNUMVER) isn't available to gbuild so we can't disable
 optimization of the affected file only for gcc 4.9.
>>>
>>> I'm sorry but the error has not changed. I've compared the patched
>>> "Library_svxcore.mk" file with the original one and only these changes
>>> were made.
>>>
>>> In your patch a "dbaccess/source/ui/uno/makefile.mk" file is mentioned
>>> which I don't have. Is this related to the "--disable-odk" configure
>>> flag I've used and therefore is OK?
>>
>> Hmn, that's strange.  That makefile is still present in recent trunk.
>> It' doesn't have any relationship to --disable-odk.
> 
> Yesterday I've done my very first checkout and a "svn update" a second 
> ago in the directory doesn't got anything new. SWo, it's indeed strange.
> 
>>> Is there any other way than to downgrade gcc?
>>
>> For the FreeBSD port, I'm not using that patch due to the lack of
>> $(CCNUMVER) on the gbuild side of thigs.  If we had that, then I would
>> have upstreamed the patch.  Instead, I'm still using the workaround in
>> the third to last paragraph.  The Makefile for the FreeBSD port does
>> this on-the-fly patch:
>>
>> .if ${COMPILER_TYPE} == gcc
>>  # g++49 -Os sometimes leaves inline class methods undefined,
>>  # affects fmgridif.cxx and ColumnControl.cxx
>>  # See:
>>  if [ ${CXX} = g++49  ]; then \
>>  ${REINPLACE_CMD} -e "s/ := -Os/ := -Os -fno-devirtualize 
>> -fno-de
>> virtualize-speculatively/" ${WRKSRC}/solenv/gbuild/platform/freebsd.mk; \
>>  ${REINPLACE_CMD} -e "s/=-Os /=-Os -fno-devirtualize 
>> -fno-devirtu
>> alize-speculatively /" ${WRKSRC}/solenv/inc/unxfbsdi.mk; \
>>  fi
>>
>>
>> For Linux you would have to patch main/solenv/gbuild/platform/linux.mk
>> (and main/solenv/inc/unxlng*.mk for non-x86_64 platforms).
> 
> I've add the following to line 152, beside to the COMPILERNOOPTSFLAFS
> 
> gb_COMPILEROPTFLAGS := O0
> 
> I hope that this correct. If so, then unfortunately it doesn't make a 
> change. Stil lthe same error.
> 
>> On x86_64, the Library_svxcore.mk patch should have done the trick
>> though.  The problem is triggered by using -Os optimization and with
>> that change to Library_svxcore.mk, fmgridif.cxx should be getting
>> compiled with -O0.  Can you check the log file to see if that is the
>> case?  You'll probably have to configure with --enable-verbose to see
>> it.
> 
> OK, turned back the "linux.mk" patch.
> 
> I've added --enable-verbose to configure, bootstrap'ed and source'ed 
> again. The build cancelled at the same location and with the same error 
> message.
> 
> "fmgridif.cxx" was nowhere mentioned, only a "fmgridif.o". It's the last 
> file mentioned in a long list of .o files from module "svx".

Are you starting from a clean build each time?  If you just restart the

Re: Help needed: Build error in bean and vcl

2016-09-05 Thread Marcus 

Am 09/05/2016 09:33 PM, schrieb Don Lewis:

On  5 Sep, Marcus wrote:

Am 09/05/2016 05:39 AM, schrieb Don Lewis:

On  4 Sep, Don Lewis wrote:

On  4 Sep, Marcus wrote:

Thanks a lot. "libXt-devel" was indeed not installed.

But now it's breaking in svx:

[...]

=
Building module svx
=

Entering /share/linux2/aoo/trunk/main/svx/prj

cd ..&&   make -s -r -j1&&   make -s -r deliverlog
[ build LNK ] Library/libsvxcore.so
/share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/CxxObject/svx/source/fmcomp/fmgridif.o:
In function
`FmXGridControl::createPeer(com::sun::star::uno::Reference
const&, com::sun::star::uno::Reference
const&)':
fmgridif.cxx:(.text+0x68b2): undefined reference to `non-virtual thunk to
WindowListenerMultiplexer::acquire()'
/usr/bin/ld:
/share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/CxxObject/svx/source/fmcomp/fmgridif.o:
relocation R_X86_64_PC32 against undefined symbol
`_ZThn48_N25WindowListenerMultiplexer7acquireEv' can not be used when
making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
/share/linux2/aoo/trunk/main/solenv/gbuild/LinkTarget.mk:248: recipe for
target
'/share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/LinkTarget/Library/libsvxcore.so'
failed
make: ***
[/share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/LinkTarget/Library/libsvxcore.so]
Error 1
dmake:  Error code 2, while making 'all'

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


That looks very familiar.  What compiler version are you using?


gcc 4.9.2


Yup, it's gcc 4.9 bug.  This is what I did for the FreeBSD port to work
around this problem:


Unfortunately $(CCNUMVER) isn't available to gbuild so we can't disable
optimization of the affected file only for gcc 4.9.


I'm sorry but the error has not changed. I've compared the patched
"Library_svxcore.mk" file with the original one and only these changes
were made.

In your patch a "dbaccess/source/ui/uno/makefile.mk" file is mentioned
which I don't have. Is this related to the "--disable-odk" configure
flag I've used and therefore is OK?


Hmn, that's strange.  That makefile is still present in recent trunk.
It' doesn't have any relationship to --disable-odk.


Yesterday I've done my very first checkout and a "svn update" a second 
ago in the directory doesn't got anything new. SWo, it's indeed strange.



Is there any other way than to downgrade gcc?


For the FreeBSD port, I'm not using that patch due to the lack of
$(CCNUMVER) on the gbuild side of thigs.  If we had that, then I would
have upstreamed the patch.  Instead, I'm still using the workaround in
the third to last paragraph.  The Makefile for the FreeBSD port does
this on-the-fly patch:

.if ${COMPILER_TYPE} == gcc
 # g++49 -Os sometimes leaves inline class methods undefined,
 # affects fmgridif.cxx and ColumnControl.cxx
 # See:
 if [ ${CXX} = g++49  ]; then \
 ${REINPLACE_CMD} -e "s/ := -Os/ := -Os -fno-devirtualize 
-fno-de
virtualize-speculatively/" ${WRKSRC}/solenv/gbuild/platform/freebsd.mk; \
 ${REINPLACE_CMD} -e "s/=-Os /=-Os -fno-devirtualize 
-fno-devirtu
alize-speculatively /" ${WRKSRC}/solenv/inc/unxfbsdi.mk; \
 fi


For Linux you would have to patch main/solenv/gbuild/platform/linux.mk
(and main/solenv/inc/unxlng*.mk for non-x86_64 platforms).


I've add the following to line 152, beside to the COMPILERNOOPTSFLAFS

gb_COMPILEROPTFLAGS := O0

I hope that this correct. If so, then unfortunately it doesn't make a 
change. Stil lthe same error.



On x86_64, the Library_svxcore.mk patch should have done the trick
though.  The problem is triggered by using -Os optimization and with
that change to Library_svxcore.mk, fmgridif.cxx should be getting
compiled with -O0.  Can you check the log file to see if that is the
case?  You'll probably have to configure with --enable-verbose to see
it.


OK, turned back the "linux.mk" patch.

I've added --enable-verbose to configure, bootstrap'ed and source'ed 
again. The build cancelled at the same location and with the same error 
message.


"fmgridif.cxx" was nowhere mentioned, only a "fmgridif.o". It's the last 
file mentioned in a long list of .o files from module "svx".


BTW:
Due to dependencies for ant, junit, hamcreast and others I had to 
install JDK 1.8.0. Dont' know if this matters somehoe.


Marcus

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

Re: Help needed: Build error in bean and vcl

2016-09-05 Thread Don Lewis 
On  5 Sep, Marcus wrote:
> Am 09/05/2016 05:39 AM, schrieb Don Lewis:
>> On  4 Sep, Don Lewis wrote:
>>> On  4 Sep, Marcus wrote:
 Thanks a lot. "libXt-devel" was indeed not installed.

 But now it's breaking in svx:

 [...]

 =
 Building module svx
 =

 Entering /share/linux2/aoo/trunk/main/svx/prj

 cd ..&&  make -s -r -j1&&  make -s -r deliverlog
 [ build LNK ] Library/libsvxcore.so
 /share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/CxxObject/svx/source/fmcomp/fmgridif.o:
 In function
 `FmXGridControl::createPeer(com::sun::star::uno::Reference
 const&, com::sun::star::uno::Reference
 const&)':
 fmgridif.cxx:(.text+0x68b2): undefined reference to `non-virtual thunk to
 WindowListenerMultiplexer::acquire()'
 /usr/bin/ld:
 /share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/CxxObject/svx/source/fmcomp/fmgridif.o:
 relocation R_X86_64_PC32 against undefined symbol
 `_ZThn48_N25WindowListenerMultiplexer7acquireEv' can not be used when
 making a shared object; recompile with -fPIC
 /usr/bin/ld: final link failed: Bad value
 collect2: error: ld returned 1 exit status
 /share/linux2/aoo/trunk/main/solenv/gbuild/LinkTarget.mk:248: recipe for
 target
 '/share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/LinkTarget/Library/libsvxcore.so'
 failed
 make: ***
 [/share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/LinkTarget/Library/libsvxcore.so]
 Error 1
 dmake:  Error code 2, while making 'all'

 1 module(s):
svx
 need(s) to be rebuilt
>>>
>>> That looks very familiar.  What compiler version are you using?
> 
> gcc 4.9.2
> 
>> Yup, it's gcc 4.9 bug.  This is what I did for the FreeBSD port to work
>> around this problem:
>> 
>>
>> Unfortunately $(CCNUMVER) isn't available to gbuild so we can't disable
>> optimization of the affected file only for gcc 4.9.
> 
> I'm sorry but the error has not changed. I've compared the patched 
> "Library_svxcore.mk" file with the original one and only these changes 
> were made.
> 
> In your patch a "dbaccess/source/ui/uno/makefile.mk" file is mentioned 
> which I don't have. Is this related to the "--disable-odk" configure 
> flag I've used and therefore is OK?

Hmn, that's strange.  That makefile is still present in recent trunk.
It' doesn't have any relationship to --disable-odk.

> Is there any other way than to downgrade gcc?

For the FreeBSD port, I'm not using that patch due to the lack of
$(CCNUMVER) on the gbuild side of thigs.  If we had that, then I would
have upstreamed the patch.  Instead, I'm still using the workaround in
the third to last paragraph.  The Makefile for the FreeBSD port does
this on-the-fly patch:

.if ${COMPILER_TYPE} == gcc
# g++49 -Os sometimes leaves inline class methods undefined,
# affects fmgridif.cxx and ColumnControl.cxx
# See: 
if [ ${CXX} = g++49  ]; then \
${REINPLACE_CMD} -e "s/ := -Os/ := -Os -fno-devirtualize -fno-de
virtualize-speculatively/" ${WRKSRC}/solenv/gbuild/platform/freebsd.mk; \
${REINPLACE_CMD} -e "s/=-Os /=-Os -fno-devirtualize -fno-devirtu
alize-speculatively /" ${WRKSRC}/solenv/inc/unxfbsdi.mk; \
fi


For Linux you would have to patch main/solenv/gbuild/platform/linux.mk
(and main/solenv/inc/unxlng*.mk for non-x86_64 platforms).


On x86_64, the Library_svxcore.mk patch should have done the trick
though.  The problem is triggered by using -Os optimization and with
that change to Library_svxcore.mk, fmgridif.cxx should be getting
compiled with -O0.  Can you check the log file to see if that is the
case?  You'll probably have to configure with --enable-verbose to see
it.


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

Re: Help needed: Build error in bean and vcl

2016-09-05 Thread Marcus 

Am 09/05/2016 05:39 AM, schrieb Don Lewis:

On  4 Sep, Don Lewis wrote:

On  4 Sep, Marcus wrote:

Thanks a lot. "libXt-devel" was indeed not installed.

But now it's breaking in svx:

[...]

=
Building module svx
=

Entering /share/linux2/aoo/trunk/main/svx/prj

cd ..&&  make -s -r -j1&&  make -s -r deliverlog
[ build LNK ] Library/libsvxcore.so
/share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/CxxObject/svx/source/fmcomp/fmgridif.o:
In function
`FmXGridControl::createPeer(com::sun::star::uno::Reference
const&, com::sun::star::uno::Reference
const&)':
fmgridif.cxx:(.text+0x68b2): undefined reference to `non-virtual thunk to
WindowListenerMultiplexer::acquire()'
/usr/bin/ld:
/share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/CxxObject/svx/source/fmcomp/fmgridif.o:
relocation R_X86_64_PC32 against undefined symbol
`_ZThn48_N25WindowListenerMultiplexer7acquireEv' can not be used when
making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
/share/linux2/aoo/trunk/main/solenv/gbuild/LinkTarget.mk:248: recipe for
target
'/share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/LinkTarget/Library/libsvxcore.so'
failed
make: ***
[/share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/LinkTarget/Library/libsvxcore.so]
Error 1
dmake:  Error code 2, while making 'all'

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


That looks very familiar.  What compiler version are you using?


gcc 4.9.2


Yup, it's gcc 4.9 bug.  This is what I did for the FreeBSD port to work
around this problem:


Unfortunately $(CCNUMVER) isn't available to gbuild so we can't disable
optimization of the affected file only for gcc 4.9.


I'm sorry but the error has not changed. I've compared the patched 
"Library_svxcore.mk" file with the original one and only these changes 
were made.


In your patch a "dbaccess/source/ui/uno/makefile.mk" file is mentioned 
which I don't have. Is this related to the "--disable-odk" configure 
flag I've used and therefore is OK?


Is there any other way than to downgrade gcc?

Thanks

Marcus


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

Re: New volunteer

2016-09-05 Thread Patricia Shanahan 

Welcome aboard!

The first step is to build AOO on at least one computer. For windows, I 
found the step-by-step guide at 
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step 
most useful.


On 9/5/2016 8:42 AM, Thomas Seeley wrote:

Hello All!

My name is Thomas Seeley. I want to volunteer with OpenOffice to better
familiarize myself with the framework of open source software. This will
also give my something to do while I am convalescing.

My background in programming began with building control systems and
embedded control systems. In the meantime I became a tenured professor of
Computer Science; I've taught many programming languages including C, C++,
and SQL.

Regards,

Thomas E. Seeley, PE



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

Re: Kay's activities

2016-09-05 Thread Marcus 

Thanks for getting this info. That will help in case someone will need this.

Marcus



Am 09/05/2016 02:03 AM, schrieb Patricia Shanahan:

I think some of our troubles, including the Mac Buildbot issue, are
related to not identifying and picking up activities that were being
done by people who have left the project.

I asked Kay for some notes on her activities - posted here with her
permission:


I'll do my best. Here goes -- in reverse order of my particiaption

* buildbot script maintenance (recently Damajan and I). Before that,
Herbert Duerr

svn info:
https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/projects/openofficeorg.conf


Checkout is via: svn co
https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/projects


which contains build scripts for all projects

* monitoring BZ issues via iss...@openoffice.apache.org mailing list
Well presumably all developers do this.

* monitoring commits via comm...@openoffice.apache.org

* subscription to infra
Normally this is not a big deal, and it's a VERY BUSY list

* trying to fix bugs when I can
Well I am NOT a C++ programmer but was able to deal with stuff like
makefile problems

* editing info on the wiki occasionally
https://wiki.openoffice.org/wiki/Main_Page

* editing pages on the project web site
http://openoffice.apache.org/

*editing page on the end user web site
http://www.openoffice.org/

NOTE: Both the web sites above involve use of the ASF CMS and staging
areas.
See: http://openoffice.apache.org/website-local.html

for details on what someone needs to do to deal with this.
This is where I started with AOO --bringing over the old OpenOffice.org
web site with Dave Fisher.

* Updating the AOO update stuff when a new release comes out.
We have an "update URL" in AOO that is like an app inside AOO that pulls
new releases down for end users when I release comes up. Scripts are in:
http://svn.apache.org/viewvc/openoffice/updates-site/


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

New volunteer

2016-09-05 Thread Thomas Seeley 
Hello All!

My name is Thomas Seeley. I want to volunteer with OpenOffice to better
familiarize myself with the framework of open source software. This will
also give my something to do while I am convalescing.

My background in programming began with building control systems and
embedded control systems. In the meantime I became a tenured professor of
Computer Science; I've taught many programming languages including C, C++,
and SQL.

Regards,

Thomas E. Seeley, PE