RE: [DISCUSS] What Would OpenOffice Retirement Involve? (long)

[Dennis E. Hamilton]

> -Original Message-
> From: Phillip Rhodes [mailto:motley.crue@gmail.com]
> Sent: Thursday, September 1, 2016 21:49
> To: dev@openoffice.apache.org; Dennis Hamilton 
> Subject: Re: [DISCUSS] What Would OpenOffice Retirement Involve? (long)
> 
> >
> >
> > What alternative do you see?
> >
> >
> >
> There's no particular reason that I can see, that AOO shouldn't be able
> to
> produce secure software, issue releases and
> do all of those other things.  We've done it in the past (and yeah, I
> feel
> guilty about saying "we" since I haven't been very active. Mea culpa),
> and
> it's not like the project caught bubonic plague or something.  Yeah, I
> know
> a lot of people prefer to contribute to LO and not AOO, and that losing
> the
> people IBM was paying was a big hit.   But I can't help but think
> there's a
> way to get more people involved and contributing here.  So I'd rather
> see
> discussion around "how do we attract additional
> contributors (or fix whatever other problems we have)?"  than talk about
> a
> "retirement plan."  I really do think that if people start putting a lot
> of
> energy into that, it will rob even more energy from the project.
> 
> Or maybe there are other options that could be considered, even if only
> as
> interim steps.  Somebody mentioned something about a problem making Mac
> releases. OK fine, let's drop Mac support for now.  Maybe that frees up
> some energy for other things.  OK, radical suggestion and probably won't
> be
> met with a lot of support, but the point is to say, let's think outside
> the
> box a little and see if there are some other ideas we could adopt.
> 
> 
[orcmid] 

I think you will be heartened that there is just such an effort underway and 
many think that will be the answer.

Are you one of those who can "put a lot of energy into it?"  Do you know where 
you'd direct that energy to come up with likely candidates for becoming more 
involved?

With regard to interim steps, it is striking to realize that, as low as the 
MacOSX population is, it is almost double our Linux user base [;<).




> 
> Phil


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

RE: [DISCUSS] What Would OpenOffice Retirement Involve? (long)

[Dennis E. Hamilton]

> -Original Message-
> From: Phillip Rhodes [mailto:motley.crue@gmail.com]
> Sent: Thursday, September 1, 2016 21:23
> To: dev@openoffice.apache.org
> Cc: priv...@openoffice.apache.org
> Subject: Re: [DISCUSS] What Would OpenOffice Retirement Involve? (long)
> 
> > (3) I think that working towards being able to release rather than
> patch
> > as Patricia has suggested is our best way to solve the security issue.
> The
> > quick patch is not much faster and has been proven to be more of a
> > challenge then kick starting the broken build process.
> >
> 
> 
> Forgive me for being a little behind.  What is broken in the build
> process?
> Technical problem, or process issue, or other or what?
> 
[orcmid] 

This is off-topic for this thread, but it may be helpful in illustrating why 
the Board wants to know what the project's considerations are with respect to 
retirement and in particular, with regard to avoiding the situation I will now 
recount.

The remark about a patch has to do with CVE-2016-1513, with our advisory at 
.

The vulnerability, and a proof of concept were reported to the project on 
2016-10-20 as Apache OpenOffice 4.1.2 was going out the door.  

We had figured out the source-code fix in March.  

On June 7, the reporter was concerned about sitting on the disclosure any 
longer and gave us a June deadline, proposing to disclose even though we had 
not committed to an AOO update.  We were sitting on the fix because we didn't 
want to give anyone ideas when they saw it applied to the source code unless 
there was a release in the works.  

We negotiated a disclosure extension to July 21.  Part of that agreement was 
our working to create a hotfix instead of attempting to work up a full 
maintenance release (e.g., a 4.1.3).  On July 21 we issued an advisory that 
disclosed existence of the vulnerability without offering any repaired 
software.  

We had the corrected shared library at the time of disclosure, but had not 
tested much for possible regressions with it.  Also, instructions needed to be 
written.  General Availability of the Hotfix, 4.1.2-patch1, was on August 30, 
after more testing, QA of the instructions and the fix, and adding a couple of 
localizations.  The QA period did turn up a couple of glitches and improvements 
to the instructions and also included scripts to simplify the task for Windows 
users.

There are two prospects for this year: a 4.1.3 maintenance release for some 
important maintenance-only items and the 4.2.0 feature release.  In either case 
it is likely that an update of any kind will be a year since the release of 
Apache OpenOffice 4.1.2.

If anyone wants to look into the issues of producing releases, I suggest you 
confirm the 4.1.2 release by compiling it from the source archive using the 
available build instructions and see how well you can replicate the released 
binary for the same platform.  Where we fall the most short is having enough 
folks who can do this for Windows and MacOSX, covering almost 95% of our user 
base [;<).

> 
> Phil


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

Re: [DISCUSS] What Would OpenOffice Retirement Involve? (long)

[Phillip Rhodes]

>
>
> What alternative do you see?
>
>
>
There's no particular reason that I can see, that AOO shouldn't be able to
produce secure software, issue releases and
do all of those other things.  We've done it in the past (and yeah, I feel
guilty about saying "we" since I haven't been very active. Mea culpa), and
it's not like the project caught bubonic plague or something.  Yeah, I know
a lot of people prefer to contribute to LO and not AOO, and that losing the
people IBM was paying was a big hit.   But I can't help but think there's a
way to get more people involved and contributing here.  So I'd rather see
discussion around "how do we attract additional
contributors (or fix whatever other problems we have)?"  than talk about a
"retirement plan."  I really do think that if people start putting a lot of
energy into that, it will rob even more energy from the project.

Or maybe there are other options that could be considered, even if only as
interim steps.  Somebody mentioned something about a problem making Mac
releases. OK fine, let's drop Mac support for now.  Maybe that frees up
some energy for other things.  OK, radical suggestion and probably won't be
met with a lot of support, but the point is to say, let's think outside the
box a little and see if there are some other ideas we could adopt.



Phil

RE: [DISCUSS] What Would OpenOffice Retirement Involve? (long)

[Dennis E. Hamilton]

> -Original Message-
> From: Phillip Rhodes [mailto:motley.crue@gmail.com]
> Sent: Thursday, September 1, 2016 21:16
> To: dev@openoffice.apache.org; orc...@apache.org
> Subject: Re: [DISCUSS] What Would OpenOffice Retirement Involve? (long)
> 
> Wow, just wow.  I have to say, I think even broaching this topic is a
> mistake.  "Self-fulfilling prophecy"? Not even that, it'll be a "3rd
> party
> fulfilling prophecy" as soon as this hits the press.  There are a lot of
> people out there who seem to have it in for AOO and have for a while...
> now
> you *know* there will be a headline appearing in the next week, reading
> "Apache OpenOffice Mulls Retirement" or "AOO Begins To Wind Down", etc.
> Yeah, it's crappy journalism, but it's almost 100% certain to happen.
> And
> that's just going to dampen enthusiasm even more.
> 
> I wish I could say I had a magic bullet of an answer for how to get
> things
> moving again, but I don't.  But I don't think opening a discussion about
> retirement and giving AOO's enemies more ammunition is a strong tactical
> move.
[orcmid] 

You're right Phil, it is not meant to be a tactical (or even strategic) move in 
some sort of adversarial situation.

How else can we work through these difficulties, and understand our options as 
a community?  

Being a project of the Apache Software Foundation brings with it some rather 
unique requirements for operation in the public interest and operating in the 
open with our community, including the public that relies on Apache OpenOffice 
software.

I don't know any way to accomplish that in a way that outsiders can't spin 
however they like.  We need the engagement and many eyes and thoughts of our 
community, as reflected here on dev@.  

What alternative do you see?

> 
> 
> Phil
> 
> 
> This message optimized for indexing by NSA PRISM
> 
> On Thu, Sep 1, 2016 at 7:37 PM, Dennis E. Hamilton 
> wrote:
> 
> > Here is what a careful retirement of Apache OpenOffice could look
> like.
> >
> >   A. PERSPECTIVE
> >   B. WHAT RETIREMENT COULD LOOK LIKE
> >  1. Code Base
> >  2. Downloads
> >  3. Development Support
> >  4. Public-Project Community Interfaces
> >  5. Social Media Presence
> >  6. Project Management Committee
> >  7. Branding
> >
[ ... ] >


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

Re: [DISCUSS] What Would OpenOffice Retirement Involve? (long)

[Phillip Rhodes]

> (3) I think that working towards being able to release rather than patch
> as Patricia has suggested is our best way to solve the security issue. The
> quick patch is not much faster and has been proven to be more of a
> challenge then kick starting the broken build process.
>


Forgive me for being a little behind.  What is broken in the build process?
Technical problem, or process issue, or other or what?


Phil

Re: [DISCUSS] What Would OpenOffice Retirement Involve? (long)

[Phillip Rhodes]

Wow, just wow.  I have to say, I think even broaching this topic is a
mistake.  "Self-fulfilling prophecy"? Not even that, it'll be a "3rd party
fulfilling prophecy" as soon as this hits the press.  There are a lot of
people out there who seem to have it in for AOO and have for a while... now
you *know* there will be a headline appearing in the next week, reading
"Apache OpenOffice Mulls Retirement" or "AOO Begins To Wind Down", etc.
Yeah, it's crappy journalism, but it's almost 100% certain to happen.  And
that's just going to dampen enthusiasm even more.

I wish I could say I had a magic bullet of an answer for how to get things
moving again, but I don't.  But I don't think opening a discussion about
retirement and giving AOO's enemies more ammunition is a strong tactical
move.


Phil


This message optimized for indexing by NSA PRISM

On Thu, Sep 1, 2016 at 7:37 PM, Dennis E. Hamilton 
wrote:

> Here is what a careful retirement of Apache OpenOffice could look like.
>
>   A. PERSPECTIVE
>   B. WHAT RETIREMENT COULD LOOK LIKE
>  1. Code Base
>  2. Downloads
>  3. Development Support
>  4. Public-Project Community Interfaces
>  5. Social Media Presence
>  6. Project Management Committee
>  7. Branding
>
> A. PERSPECTIVE
>
> I have regularly observed that the Apache OpenOffice project has limited
> capacity for sustaining the project in an energetic manner.  It is also my
> considered opinion that there is no ready supply of developers who have the
> capacity, capability, and will to supplement the roughly half-dozen
> volunteers holding the project together.  It doesn't matter what the
> reasons for that might be.
>
> The Apache Project Maturity Model,
> ,
> identifies the characteristics for which an Apache project is expected to
> strive.
>
> Recently, some elements have been brought into serious question:
>
>  QU20: The project puts a very high priority on producing secure software.
>  QU50: The project strives to respond to documented bug reports in a
> timely manner.
>
> There is also a litmus test which is kind of a red line.  That is for the
> project to have a PMC capable of producing releases.  That means that there
> are at least three available PMC members capable of building a functioning
> binary from a release-candidate archive, and who do so in providing binding
> votes to approve the release of that code.
>
> In the case of Apache OpenOffice, needing to disclose security
> vulnerabilities for which there is no mitigation in an update has become a
> serious issue.
>
> In responses to concerns raised in June, the PMC is currently tasked by
> the ASF Board to account for this inability and to provide a remedy.  An
> indicator of the seriousness of the Board's concern is the PMC been
> requested to report to the Board every month, starting in August, rather
> than quarterly, the normal case.  One option for remedy that must be
> considered is retirement of the project.  The request is for the PMC's
> consideration among other possible options.  The Board has not ordered a
> solution.
>
> I cannot prediction how this will all work out.  It is remiss of me not to
> point out that retirement of the project is a serious possibility.
>
> There are those who fear that discussing retirement can become a
> self-fulfilling prophecy.  My concern is that the project could end with a
> bang or a whimper.  My interest is in seeing any retirement happen
> gracefully.  That means we need to consider it as a contingency.  For
> contingency plans, no time is a good time, but earlier is always better
> than later.
>
>
> B. WHAT RETIREMENT COULD LOOK LIKE
>
> Here is a provisional list of all elements that would have to be
> addressed, over a period of time, as part of any retirement effort.
>
> In order to understand what would have had to happen in a graceful
> process, the assumption below is that the project has already retired.
>
> Requests for additions and adjustments to this compilation are welcome.
>
>  1. CODE BASE
>
> 1.1 The Apache OpenOffice Subversion repository where code is
> maintained has been moved to "The Attic."  Apache Attic is an actual
> project, .  The source code would remain
> available and could be checked-out from Subversion by anyone interested in
> making use of it.  There is no means of committing changes.
>
> 1.2 Apache Externals/Extras consists of external libraries that are
> relied upon by the source code but are not part of the source code.  These
> were housed on SourceForge and elsewhere.  (a) They might have been
> archived in conjunction with the SVN (1.1).  (b) They might be identified
> in a way that someone attempting to build from source later on would be
> able to work with later versions of the external 

RE: [DISCUSS] What Would OpenOffice Retirement Involve? (long)

[Dennis E. Hamilton]

[BCC to PMC]

> -Original Message-
> From: Dave Fisher [mailto:dave2w...@comcast.net]
> Sent: Thursday, September 1, 2016 19:27
> To: priv...@openoffice.apache.org
> Cc: dev@openoffice.apache.org
> Subject: Re: [DISCUSS] What Would OpenOffice Retirement Involve? (long)
> 
> Hi Dennis,
> 
> I don't have objections to this topic, but I feel I need to make a few
> suggestions before this thread is either ignored or a confused mess.
> 
> (1) a long, official policy statement like this is best put into a wiki
> page where many can edit it and it can be an easy discussion and not a
> confused email mess that is started with something that is tl:dr. The
> maturity model was recently developed by the comdev participants on the
> wiki and email
> Effectively. This document needs to be developed in the same way.
[orcmid] 

Good idea.  I see no reason not to follow that path.  This was my 
thought-starter.

I was not intending an official policy statement.  It is a discussion request, 
with some background information for perspective.  (Oh, I had to use orcmid@ 
a.o because of the BCC, since that's how I am on private@ though.  I see the 
confusion I causes doing that.)


> 
> (2) why is this cross posted to private and DEV? To do so implies that
> there is some other non-open discussion in parallel. You and I have run
> into unexpected results from this strange cross posting practice of
> yours (hi Simon)
[orcmid] 

It was not cross-posted.  I intentionally did not do that.  The BCC was to 
private@, just as I am doing now.  It was an easy way to provide a heads-up to 
the PMC for a discussion to notice on dev@, since some don't siphon through all 
of the dev@ material regularly.  It is not on dev@ as a cross-posting.


> 
> (3) I think that working towards being able to release rather than patch
> as Patricia has suggested is our best way to solve the security issue.
> The quick patch is not much faster and has been proven to be more of a
> challenge then kick starting the broken build process.
[orcmid] 

That would be interesting to determine.  Now that we have released a Hotfix, I 
think we can get it done more quickly in the future, but it is certainly not as 
good as simply offering the community a full update to install.

That is a different subject though.  It would be great to have that outcome.

> 
> Regards,
> Dave
> 
> Sent from my iPhone
> 
> > On Sep 1, 2016, at 4:37 PM, Dennis E. Hamilton 
> wrote:
> >
> > Here is what a careful retirement of Apache OpenOffice could look
> like.
> >
> >  A. PERSPECTIVE
> >  B. WHAT RETIREMENT COULD LOOK LIKE
> > 1. Code Base
> > 2. Downloads
> > 3. Development Support
> > 4. Public-Project Community Interfaces
> > 5. Social Media Presence
> > 6. Project Management Committee
> > 7. Branding
> >
[ ... ]


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

Re: [DISCUSS] What Would OpenOffice Retirement Involve? (long)

[Pedro Giffuni]

Hmm ... the discussion sounds a bit like Brexit ...

With the important difference that it is now evident that Brexit
didn't have a plan.

Having a retirement plan is important for our users and for the ASF
and while I think the discussion is sane and important I think we should 
focus now on the next release. It is clear to me that

even if AOO were to be retired, we still have to push out a
new release mainly because we do have stuff that should see
the light of a release.

For the release we are certainly seeing some deficiencies:

- Can we responsibly deliver AOO 4.2.0 for the Mac? If the base/java
issue is as serious as it sounds and since we don't have much developer
feedback or even a buildbot, we may have to release 4.2.0 with a Mac
version!

After the release there are certainly much more things to discuss.

Pedro.


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

Re: Python update for testing

[Pedro Giffuni]

On 09/01/2016 Kay Schenk wrote:


On 09/01/2016 11:17 AM, Pedro Giffuni wrote:

Hello;

The python we are carrying for AOO 4.2.0 (2.7.8) has many security
vulnerabilities which may or may not have an effect on AOO.

In order to make future updates and particularly for Python 2.7.9, in
fact, we also needed to update OpenSSL, so now that Don updated
OpenSSL the basic update became possible. I tested the update
on FreeBSD but I had to hack for Windows buildfiles and this requires
testing.

People that regularly build windows please try this patch:

http://people.apache.org/~pfg/patches/python-update.diff

If there is no feedback I could try committing the change and keep an
eye on the buildbots, although this is certainly not too elegant.


The issue is if we can get a newer version of Python from a reputable
repo for CentOS 5.11 for i386 and x86_64 which will be our build
environment for *nix systems.

So, we need to investigate this first. I'm using python 2.7.10 on CentOS
6.8 but I don't remember where I got it. :/


Hmm ...

I don't think I understand very well what you are meaning here:

If you are using a pre-packaged python to build AOO, then the AOO
embedded python version is of no concern. If you are building the
internal python in AOO then it's in your best interest to have
something at least as up to date as the one that regularly comes
with your OS.

I don't really care very much about the python version used in BSD/Linux
/MacOS as it is likely users in those systems will have an up-to-date 
python version. Windows, on the other hand, depends on the specific 
python we are delivering.


Pedro.

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

Re: [DISCUSS] What Would OpenOffice Retirement Involve? (long)

[Dave Fisher]

Hi Dennis,

I don't have objections to this topic, but I feel I need to make a few 
suggestions before this thread is either ignored or a confused mess.

(1) a long, official policy statement like this is best put into a wiki page 
where many can edit it and it can be an easy discussion and not a confused 
email mess that is started with something that is tl:dr. The maturity model was 
recently developed by the comdev participants on the wiki and email
Effectively. This document needs to be developed in the same way.

(2) why is this cross posted to private and DEV? To do so implies that there is 
some other non-open discussion in parallel. You and I have run into unexpected 
results from this strange cross posting practice of yours (hi Simon)

(3) I think that working towards being able to release rather than patch as 
Patricia has suggested is our best way to solve the security issue. The quick 
patch is not much faster and has been proven to be more of a challenge then 
kick starting the broken build process.

Regards,
Dave

Sent from my iPhone

> On Sep 1, 2016, at 4:37 PM, Dennis E. Hamilton  wrote:
> 
> Here is what a careful retirement of Apache OpenOffice could look like.
> 
>  A. PERSPECTIVE
>  B. WHAT RETIREMENT COULD LOOK LIKE
> 1. Code Base
> 2. Downloads
> 3. Development Support
> 4. Public-Project Community Interfaces
> 5. Social Media Presence
> 6. Project Management Committee
> 7. Branding
> 
> A. PERSPECTIVE
> 
> I have regularly observed that the Apache OpenOffice project has limited 
> capacity for sustaining the project in an energetic manner.  It is also my 
> considered opinion that there is no ready supply of developers who have the 
> capacity, capability, and will to supplement the roughly half-dozen 
> volunteers holding the project together.  It doesn't matter what the reasons 
> for that might be.
> 
> The Apache Project Maturity Model,
> , 
> identifies the characteristics for which an Apache project is expected to 
> strive. 
> 
> Recently, some elements have been brought into serious question:
> 
> QU20: The project puts a very high priority on producing secure software.
> QU50: The project strives to respond to documented bug reports in a timely 
> manner.
> 
> There is also a litmus test which is kind of a red line.  That is for the 
> project to have a PMC capable of producing releases.  That means that there 
> are at least three available PMC members capable of building a functioning 
> binary from a release-candidate archive, and who do so in providing binding 
> votes to approve the release of that code.  
> 
> In the case of Apache OpenOffice, needing to disclose security 
> vulnerabilities for which there is no mitigation in an update has become a 
> serious issue.
> 
> In responses to concerns raised in June, the PMC is currently tasked by the 
> ASF Board to account for this inability and to provide a remedy.  An 
> indicator of the seriousness of the Board's concern is the PMC been requested 
> to report to the Board every month, starting in August, rather than 
> quarterly, the normal case.  One option for remedy that must be considered is 
> retirement of the project.  The request is for the PMC's consideration among 
> other possible options.  The Board has not ordered a solution. 
> 
> I cannot prediction how this will all work out.  It is remiss of me not to 
> point out that retirement of the project is a serious possibility.
> 
> There are those who fear that discussing retirement can become a 
> self-fulfilling prophecy.  My concern is that the project could end with a 
> bang or a whimper.  My interest is in seeing any retirement happen 
> gracefully.  That means we need to consider it as a contingency.  For 
> contingency plans, no time is a good time, but earlier is always better than 
> later.
> 
> 
> B. WHAT RETIREMENT COULD LOOK LIKE
> 
> Here is a provisional list of all elements that would have to be addressed, 
> over a period of time, as part of any retirement effort.   
> 
> In order to understand what would have had to happen in a graceful process, 
> the assumption below is that the project has already retired.
> 
> Requests for additions and adjustments to this compilation are welcome.
> 
> 1. CODE BASE
> 
>1.1 The Apache OpenOffice Subversion repository where code is maintained 
> has been moved to "The Attic."  Apache Attic is an actual project, 
> .  The source code would remain
> available and could be checked-out from Subversion by anyone interested in 
> making use of it.  There is no means of committing changes.
> 
>1.2 Apache Externals/Extras consists of external libraries that are relied 
> upon by the source code but are not part of the source code.  These were 
> housed 

Re: compiler warnings when building OpenOffice

[Don Lewis]

On  1 Sep, To: Don Lewis wrote:

> One of the -Wunused-parameter warnings led me to this questionable bit
> of code in filter/source/xsltfilter/containerhelper.hxx:
> 
> template
> inline void forEachMem(FuncType pFunc, ParamType aParam) const
> {
> forEach( ::boost::bind(pFunc, _1, aParam));
> }
> 
> template
> inline void forEachMem(FuncType pFunc, ParamType1 aParam1, ParamType2 
> aParam2) const
> {
> forEach( ::boost::bind(pFunc, -1, aParam1, aParam2 ));
> }
>  
> template typename ParamType3>
> inline void forEachMem( FuncType pFunc, ParamType1 aParam1, 
> ParamType2 aParam2, ParamType3 aParam3 ) const
> {
> forEach( ::boost::bind(pFunc, _1, aParam2, aParam2, aParam3 
> ));
> }
> 
> In the three parameter version of this code, it looks like aParam1
> should be used instead of using aParam2 twice.  Also, in the two
> parameter version of the code, it looks like _1 should be used instead
> of -1.  I haven't had a chance to investigate the possible symptoms of
> these errors or how to text the appropriate fix.

The answer is that the code in question does not appear to be used. Only
the version that doesn't take any parameters (not shown above) is used
in the filter module.

There are also copies of this code in the oox module that appear to be
correct.


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

Re: compiler warnings when building OpenOffice

[Don Lewis]

On  1 Sep, Patricia Shanahan wrote:
> I need a problem to work on. Would you like me to take a particular 
> compiler warning and try to sort it out?

Here is one:

/wrkdirs/usr/ports/editors/openoffice-devel2/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/inc/osl/diagnose.hxx:65:25:
 warning: 'osl_detail_ObjectRegistry_getMutex' has C-linkage specified, but 
returns user-defined type '::osl::Mutex &' which is incompatible with C 
[-Wreturn-type-c-linkage]

In sal/inc/osl/diagnose.hxx,
  ::osl::Mutex & SAL_CALL osl_detail_ObjectRegistry_getMutex()
is declared inside an extern "C" block, so it should have C linkage, but
it is returning a reference, which is a C++ thing.

The obvious fix would seem to be to move it out of the extern "C" block,
but I don't know what to do about the SAL_THROW_EXTERN_C() part of the
declaration.


Another one is -Woverloaded-virtual which has a number of instances.
These are the top three in terms of warning count (due to repeats):

main/solver/420/unxfbsdx.pro/inc/cppuhelper/compbase4.hxx:75:31: warning: 
'cppu::WeakComponentImplHelper4::addEventListener' hides overloaded virtual 
function [-Woverloaded-virtual]

main/solver/420/unxfbsdx.pro/inc/cppuhelper/compbase4.hxx:77:31: warning: 
'cppu::WeakComponentImplHelper4::removeEventListener' hides overloaded 
virtual function [-Woverloaded-virtual]

main/solver/420/unxfbsdx.pro/inc/canvas/base/graphicdevicebase.hxx:145:31: 
warning: 
'canvas::GraphicDeviceBase >, 
vclcanvas::SpriteDeviceHelper, vclcanvas::tools::LocalGuard, 
cppu::OWeakObject>::disposing' hides overloaded virtual function 
[-Woverloaded-virtual]

I'm not sure if there is really a problem here or if the warning is
harmless.


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

Re: compiler warnings when building OpenOffice

[Patricia Shanahan]

I need a problem to work on. Would you like me to take a particular 
compiler warning and try to sort it out?


On 9/1/2016 3:29 PM, Don Lewis wrote:

On 29 Aug, Don Lewis wrote:

When building OpenOffice trunk revsion r1758161 as a FreeBSD port on
FreeBSD 12.0-CURRENT with clang 3.8.0, I get the following warnings.
I'm mostly interested in the OpenOffice code and not the bundled
external code, so I specifically built the FreeBSD port it uses
--with-system-foo extensively which minimizes the compilation of third
party code.  The total number of warnings is 5105.

1175 -Wtautological-undefined-compare
 949 -Wunused-private-field
 660 -Wshift-negative-value
 391 -Wunused-parameter
 362 -Wunused-const-variable
 312 -Woverloaded-virtual
 177 -Wunused-variable
 116 -Winfinite-recursion
 109 -Wlogical-op-parentheses
  93 -Wsign-compare
  76 -Wdelete-non-virtual-dtor
  72 -Wint-to-void-pointer-cast
  63 -Wshadow
  55 -Wunused-function
  41 -Wformat
  36 -Wreturn-type-c-linkage
  30 -Wchar-subscripts
  27 -Wdeprecated-declarations
  26 -Wundefined-bool-conversion
  26 -Wsizeof-pointer-memaccess
  26 -Wformat-security
  24 -Wunused-local-typedef
  22 -Wmacro-redefined
  21 -Wswitch
  20 -Wbitwise-op-parentheses
  18 -Winvalid-source-encoding
  13 -Wuninitialized
  11 -Wtautological-compare
  11 -Wlogical-not-parentheses
  11 -Wdangling-else
   9 -Wmismatched-new-delete
   8 -Wimplicit-function-declaration
   8 -Wheader-guard
   8 -Wcomment
   7 -Wtautological-constant-out-of-range-compare
   7 -Wself-assign
   6 -Wunused-value
   6 -Wunneeded-internal-declaration
   6 -Wtautological-pointer-compare
   6 -Wpointer-bool-conversion
   6 -Wparentheses-equality
   6 -Wdynamic-class-memaccess
   6 -Wconstant-conversion
   5 -Wpointer-sign
   4 -Wnull-conversion
   3 -Wunsequenced
   3 -Wreorder
   3 -Wknr-promoted-parameter
   3 -Wint-to-pointer-cast
   2 -Wstrncat-size
   2 -Wstring-compare
   2 -Wsometimes-uninitialized
   2 -Wconstant-logical-operand
   2 -Warray-bounds
   1 -Wunused-comparison
   1 -Wunknown-pragmas
   1 -Wstring-plus-int
   1 -Wpotentially-evaluated-expression
   1 -Wnon-literal-null-conversion
   1 -Wmismatched-tags
   1 -Wincompatible-pointer-types-discards-qualifiers
   1 -Wimplicit-int
   1 -Wignored-qualifiers
   1 -Wformat-extra-args
   1 -Wcompare-distinct-pointer-types
   1 -Wc++11-compat-deprecated-writable-strings


Now down to 2708 warnings.  It'll be slower going from this point
forward because each of the remaining issues will have a much smaller
impact on the warning count that many of the ones I have already fixed.

FWIW, bundled icc is getting to be a significant contributer to the
remaining warnings.

One of the -Wunused-parameter warnings led me to this questionable bit
of code in filter/source/xsltfilter/containerhelper.hxx:

template
inline void forEachMem(FuncType pFunc, ParamType aParam) const
{
forEach( ::boost::bind(pFunc, _1, aParam));
}

template
inline void forEachMem(FuncType pFunc, ParamType1 aParam1, ParamType2 
aParam2) const
{
forEach( ::boost::bind(pFunc, -1, aParam1, aParam2 ));
}

template
inline void forEachMem( FuncType pFunc, ParamType1 aParam1, ParamType2 
aParam2, ParamType3 aParam3 ) const
{
forEach( ::boost::bind(pFunc, _1, aParam2, aParam2, aParam3 ));
}

In the three parameter version of this code, it looks like aParam1
should be used instead of using aParam2 twice.  Also, in the two
parameter version of the code, it looks like _1 should be used instead
of -1.  I haven't had a chance to investigate the possible symptoms of
these errors or how to text the appropriate fix.

 493 -Wunused-private-field
 391 -Wunused-parameter
 366 -Wunused-const-variable
 314 -Woverloaded-virtual
 181 -Wunused-variable
 109 -Wlogical-op-parentheses
  93 -Wsign-compare
  77 -Wdelete-non-virtual-dtor
  72 -Wint-to-void-pointer-cast
  63 -Wshadow
  56 -Wunused-function
  41 -Wformat
  36 -Wreturn-type-c-linkage
  30 -Wchar-subscripts
  27 -Wdeprecated-declarations
  26 -Wundefined-bool-conversion
  26 -Wsizeof-pointer-memaccess
  25 -Wtautological-undefined-compare
  24 -Wunused-local-typedef
  22 -Wmacro-redefined
  21 -Wswitch
  20 -Wbitwise-op-parentheses
  18 -Winvalid-source-encoding
  13 -Wuninitialized
  11 -Wtautological-compare
  11 -Wlogical-not-parentheses
  11 -Wdangling-else
   9 -Wmismatched-new-delete
   8 -Wimplicit-function-declaration
   8 -Wcomment
   7 -Wtautological-constant-out-of-range-compare
   7 -Wself-assign
   7 -Wheader-guard
   6 -Wunused-value
   6 -Wunneeded-internal-declaration
   6 -Wtautological-pointer-compare
   6 -Wpointer-bool-conversion
   6 -Wparentheses-equality
   6 -Wdynamic-class-memaccess
   6 -Wconstant-conversion
   5 -Wpointer-sign
   4 -Wnull-conversion
   3 -Wunsequenced
   3 -Wreorder
   3 -Wknr-promoted-parameter
   3 -Wint-to-pointer-cast
   2 -Wstrncat-size
   2 -Wstring-compare
   

Re: compiler warnings when building OpenOffice

[Don Lewis]

On 29 Aug, Don Lewis wrote:
> When building OpenOffice trunk revsion r1758161 as a FreeBSD port on
> FreeBSD 12.0-CURRENT with clang 3.8.0, I get the following warnings.
> I'm mostly interested in the OpenOffice code and not the bundled
> external code, so I specifically built the FreeBSD port it uses
> --with-system-foo extensively which minimizes the compilation of third
> party code.  The total number of warnings is 5105.
> 
> 1175 -Wtautological-undefined-compare
>  949 -Wunused-private-field
>  660 -Wshift-negative-value
>  391 -Wunused-parameter
>  362 -Wunused-const-variable
>  312 -Woverloaded-virtual
>  177 -Wunused-variable
>  116 -Winfinite-recursion
>  109 -Wlogical-op-parentheses
>   93 -Wsign-compare
>   76 -Wdelete-non-virtual-dtor
>   72 -Wint-to-void-pointer-cast
>   63 -Wshadow
>   55 -Wunused-function
>   41 -Wformat
>   36 -Wreturn-type-c-linkage
>   30 -Wchar-subscripts
>   27 -Wdeprecated-declarations
>   26 -Wundefined-bool-conversion
>   26 -Wsizeof-pointer-memaccess
>   26 -Wformat-security
>   24 -Wunused-local-typedef
>   22 -Wmacro-redefined
>   21 -Wswitch
>   20 -Wbitwise-op-parentheses
>   18 -Winvalid-source-encoding
>   13 -Wuninitialized
>   11 -Wtautological-compare
>   11 -Wlogical-not-parentheses
>   11 -Wdangling-else
>9 -Wmismatched-new-delete
>8 -Wimplicit-function-declaration
>8 -Wheader-guard
>8 -Wcomment
>7 -Wtautological-constant-out-of-range-compare
>7 -Wself-assign
>6 -Wunused-value
>6 -Wunneeded-internal-declaration
>6 -Wtautological-pointer-compare
>6 -Wpointer-bool-conversion
>6 -Wparentheses-equality
>6 -Wdynamic-class-memaccess
>6 -Wconstant-conversion
>5 -Wpointer-sign
>4 -Wnull-conversion
>3 -Wunsequenced
>3 -Wreorder
>3 -Wknr-promoted-parameter
>3 -Wint-to-pointer-cast
>2 -Wstrncat-size
>2 -Wstring-compare
>2 -Wsometimes-uninitialized
>2 -Wconstant-logical-operand
>2 -Warray-bounds
>1 -Wunused-comparison
>1 -Wunknown-pragmas
>1 -Wstring-plus-int
>1 -Wpotentially-evaluated-expression
>1 -Wnon-literal-null-conversion
>1 -Wmismatched-tags
>1 -Wincompatible-pointer-types-discards-qualifiers
>1 -Wimplicit-int
>1 -Wignored-qualifiers
>1 -Wformat-extra-args
>1 -Wcompare-distinct-pointer-types
>1 -Wc++11-compat-deprecated-writable-strings

Now down to 2708 warnings.  It'll be slower going from this point
forward because each of the remaining issues will have a much smaller
impact on the warning count that many of the ones I have already fixed.

FWIW, bundled icc is getting to be a significant contributer to the
remaining warnings.

One of the -Wunused-parameter warnings led me to this questionable bit
of code in filter/source/xsltfilter/containerhelper.hxx:

template
inline void forEachMem(FuncType pFunc, ParamType aParam) const
{
forEach( ::boost::bind(pFunc, _1, aParam));
}

template
inline void forEachMem(FuncType pFunc, ParamType1 aParam1, ParamType2 
aParam2) const
{
forEach( ::boost::bind(pFunc, -1, aParam1, aParam2 ));
}
 
template
inline void forEachMem( FuncType pFunc, ParamType1 aParam1, ParamType2 
aParam2, ParamType3 aParam3 ) const
{
forEach( ::boost::bind(pFunc, _1, aParam2, aParam2, aParam3 ));
}

In the three parameter version of this code, it looks like aParam1
should be used instead of using aParam2 twice.  Also, in the two
parameter version of the code, it looks like _1 should be used instead
of -1.  I haven't had a chance to investigate the possible symptoms of
these errors or how to text the appropriate fix.

 493 -Wunused-private-field
 391 -Wunused-parameter
 366 -Wunused-const-variable
 314 -Woverloaded-virtual
 181 -Wunused-variable
 109 -Wlogical-op-parentheses
  93 -Wsign-compare
  77 -Wdelete-non-virtual-dtor
  72 -Wint-to-void-pointer-cast
  63 -Wshadow
  56 -Wunused-function
  41 -Wformat
  36 -Wreturn-type-c-linkage
  30 -Wchar-subscripts
  27 -Wdeprecated-declarations
  26 -Wundefined-bool-conversion
  26 -Wsizeof-pointer-memaccess
  25 -Wtautological-undefined-compare
  24 -Wunused-local-typedef
  22 -Wmacro-redefined
  21 -Wswitch
  20 -Wbitwise-op-parentheses
  18 -Winvalid-source-encoding
  13 -Wuninitialized
  11 -Wtautological-compare
  11 -Wlogical-not-parentheses
  11 -Wdangling-else
   9 -Wmismatched-new-delete
   8 -Wimplicit-function-declaration
   8 -Wcomment
   7 -Wtautological-constant-out-of-range-compare
   7 -Wself-assign
   7 -Wheader-guard
   6 -Wunused-value
   6 -Wunneeded-internal-declaration
   6 -Wtautological-pointer-compare
   6 -Wpointer-bool-conversion
   6 -Wparentheses-equality
   6 -Wdynamic-class-memaccess
   6 -Wconstant-conversion
   5 -Wpointer-sign
   4 -Wnull-conversion
   3 -Wunsequenced
   3 -Wreorder
   3 -Wknr-promoted-parameter
   3 -Wint-to-pointer-cast
   2 -Wstrncat-size
   2 -Wstring-compare
   2 

Re: [REPORT] CVE-2016-1513 Security Advisory

[Marcus]

Great to see that this issue is solved finally.

Thanks to everyone who was involved. I want to express a special thanks 
to the developers Patricia, Damjan and Ariel for creating the binary 
files and Dennis for his coordination.


:-)

Marcus



Am 08/30/2016 05:46 PM, schrieb Dennis E. Hamilton:

[BCC PMC]

Today, Version 2.0 of the Advisory for CVE-2016-1513 has been issued.

There is now general availability of a Hotfix that can be downloaded and 
applied to installations of Apache OpenOffice 4.1.2.  The Hotfix details can be 
found at
.

Please review the README instructions before deciding to download and apply the 
Hotfix.

  - Dennis


-Original Message-
From: Dennis E. Hamilton [mailto:orc...@apache.org]
Sent: Thursday, July 21, 2016 09:43
To: dev@openoffice.apache.org
Subject: [REPORT] CVE-2016-1513 Security Advisory

[BCC AOO Users; BCC AOO PMC]

Today, advisory CVE-2016-1513 has been published with regard to
disclosure of a potentially-exploitable defect in crafted Impress
documents.  The advisory can be found at
.

There is no updated release at this time.  There is action underway.  We
can now discuss those actions and also seek assistance in the wider
community.


[ ... ]


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

Python update for testing

[Pedro Giffuni]

Hello;

The python we are carrying for AOO 4.2.0 (2.7.8) has many security
vulnerabilities which may or may not have an effect on AOO.

In order to make future updates and particularly for Python 2.7.9, in
fact, we also needed to update OpenSSL, so now that Don updated
OpenSSL the basic update became possible. I tested the update
on FreeBSD but I had to hack for Windows buildfiles and this requires
testing.

People that regularly build windows please try this patch:

http://people.apache.org/~pfg/patches/python-update.diff

If there is no feedback I could try committing the change and keep an
eye on the buildbots, although this is certainly not too elegant.

Once this change is done, it may be relatively easy to update Python
all the way to 2.7.12, the only big change to be aware of is a path
change for the Windows build files.

Pedro.

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

Re: Independent Entity to Develop and Further AOO

[Rory O'Farrell]

On Thu, 1 Sep 2016 09:58:04 -0700
"Dennis E. Hamilton"  wrote:

> 
> 
> > -Original Message-
> > From: Dr. Michael Stehmann [mailto:anw...@rechtsanwalt-stehmann.de]
> > Sent: Wednesday, August 31, 2016 22:04
> > To: dev@openoffice.apache.org
> > Subject: Re: Independent Entity to Develop and Further AOO
> > 
> > Am 01.09.2016 um 00:59 schrieb Simon Phipps:
> > > On Wed, Aug 31, 2016 at 11:44 PM, Dennis E. Hamilton <
> > > dennis.hamil...@acm.org> wrote:
> > >
> > >>
> > >>
> > >>> -Original Message-
> > >>> From: toki [mailto:toki.kant...@gmail.com]
> > >>> Sent: Wednesday, August 31, 2016 11:30
> > >>> To: dev@openoffice.apache.org
> > >>> Subject: Re: Independent Entity to Develop and Further AOO
> > >>>
> > >>> On 31/08/2016 16:26, Dennis E. Hamilton wrote:
> > >>>
> > >> I think that is the case because downstream producers, who get the
> > support
> > >> business, contribute to their upstream framework or source-code
> > distributor.
> > >>
> > >> What indication is there that any of that is working for Apache
> > >> OpenOffice?  Maybe if we stopped shipping binaries?  How would that
> > work
> > >> for the individuals who seem to dominate our download consumption?
> > >
> > >
> > > Since the "downstream" producers seem better equipped to deliver
> > signed and
> > > vulnerability-corrected binaries to non-specialist consumers on a
> > timely
> > > schedule, maybe delegating downloads to them would be a good option
> > for the
> > > project?
> > 
> > Stopping shipping binaries would cause some negative effect for our
> > project, so it might be an option, but not best one.
> > 
> > Binaries made by our community are essential for our QA.
> > 
> > Without them we stand "with empty hands" in the public with negative
> > effects for our brand and image.
> > 
> > Supporting our users by community members would break down.
> > 
> > So the impact for the improvement of our commity would be tremendous, if
> > we "delegate" this tasks to a third party.
> [orcmid] 
> 
> I agree with Michael.  Ceasing to provide builds from Apache OpenOffice but 
> having a downstream producer provide them would be retirement of Apache 
> OpenOffice in everything but name only.

I agree emphatically.  Most OO users want to download and go - they have not 
the time or skills to build a version, which  is not as trivial task, as 
frequenters of the dev ML will be aware.  

RoryOF 

> 
> Also, the "downstream" in this thread refers to sellers of support who 
> apparently package their own versions.  We see no contributions back to the 
> code base from any of those, whoever they might be.
> 
> This is different than existence of forks and openoffice.org-descendant 
> cousins who operate their own code base and support it, whoever those might 
> be.  While that might be disagreeable to some, it is in the spirit of 
> open-source and the commitment of the Apache Software Foundation to serving 
> the public interest.  (The protection of the respective trademarks is a 
> different matter with respect to avoiding confusion about the origin of the 
> effort.)
> 
> 
> > 
> > Kind regards
> > Michael
> > 
> > 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 
> 


-- 
Rory O'Farrell 

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

Re: Release 4.2: Regressions for investigation

[Kay Schenk]

OK, thank you, Pedro. It came up in my search because it's not marked as
RESOLVED. So, I did that just now.

On Thu, Sep 1, 2016 at 8:34 AM, Pedro Giffuni  wrote:

> Hello;
>
> FWIW, I fixed Issue 124091 a while ago. The commits are registered in
> Bugzilla.
>
> Pedro.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


-- 
--
Kay Schenk
Apache OpenOffice

"Things work out best for those who make
 the best of the way things work out."
   -- John Wooden

RE: Independent Entity to Develop and Further AOO

[Dennis E. Hamilton]

> -Original Message-
> From: Dr. Michael Stehmann [mailto:anw...@rechtsanwalt-stehmann.de]
> Sent: Wednesday, August 31, 2016 22:04
> To: dev@openoffice.apache.org
> Subject: Re: Independent Entity to Develop and Further AOO
> 
> Am 01.09.2016 um 00:59 schrieb Simon Phipps:
> > On Wed, Aug 31, 2016 at 11:44 PM, Dennis E. Hamilton <
> > dennis.hamil...@acm.org> wrote:
> >
> >>
> >>
> >>> -Original Message-
> >>> From: toki [mailto:toki.kant...@gmail.com]
> >>> Sent: Wednesday, August 31, 2016 11:30
> >>> To: dev@openoffice.apache.org
> >>> Subject: Re: Independent Entity to Develop and Further AOO
> >>>
> >>> On 31/08/2016 16:26, Dennis E. Hamilton wrote:
> >>>
> >> I think that is the case because downstream producers, who get the
> support
> >> business, contribute to their upstream framework or source-code
> distributor.
> >>
> >> What indication is there that any of that is working for Apache
> >> OpenOffice?  Maybe if we stopped shipping binaries?  How would that
> work
> >> for the individuals who seem to dominate our download consumption?
> >
> >
> > Since the "downstream" producers seem better equipped to deliver
> signed and
> > vulnerability-corrected binaries to non-specialist consumers on a
> timely
> > schedule, maybe delegating downloads to them would be a good option
> for the
> > project?
> 
> Stopping shipping binaries would cause some negative effect for our
> project, so it might be an option, but not best one.
> 
> Binaries made by our community are essential for our QA.
> 
> Without them we stand "with empty hands" in the public with negative
> effects for our brand and image.
> 
> Supporting our users by community members would break down.
> 
> So the impact for the improvement of our commity would be tremendous, if
> we "delegate" this tasks to a third party.
[orcmid] 

I agree with Michael.  Ceasing to provide builds from Apache OpenOffice but 
having a downstream producer provide them would be retirement of Apache 
OpenOffice in everything but name only.

Also, the "downstream" in this thread refers to sellers of support who 
apparently package their own versions.  We see no contributions back to the 
code base from any of those, whoever they might be.

This is different than existence of forks and openoffice.org-descendant cousins 
who operate their own code base and support it, whoever those might be.  While 
that might be disagreeable to some, it is in the spirit of open-source and the 
commitment of the Apache Software Foundation to serving the public interest.  
(The protection of the respective trademarks is a different matter with respect 
to avoiding confusion about the origin of the effort.)


> 
> Kind regards
> Michael
> 
> 



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

Re: Release 4.2: Regressions for investigation

[Pedro Giffuni]

Hello;

FWIW, I fixed Issue 124091 a while ago. The commits are registered in 
Bugzilla.


Pedro.


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

Volunteering with the Apache OpenOffice Community

[Ayaz Hussain]

Hi,


I am interested in gaining experience in technical writing and wanted to 
volunteer to create and maintain documentation for the OpenOffice project.


I would like to involved in tasks such as, updating the OpenOffice 
Administration Guide, and/or writing other documentation. Can you tell me how I 
can get involved, and what is needed on my part?

Many thanks,

Ayaz Hussain