Re: Reporting a problem with the OpenOffice website

2014-02-06 Thread Larry Gusaas

On 2014-02-05, 7:33 PM Gwen Hodder wrote:

Hello I’m have a problem with Apache open office.
this is what comes up below
The last time you opened OpenOffice, it unexpectedly quit while reopening windows. Do you 
want to try to reopen its windows again?


Then I click on cancel or reopen but it stays there and does nothing,
The only way I can close down my computer now is to turn it off at button.
Can you please advise me on how to fix this problem.
I have the latest open office download, but it still hasn’t solved the problem.

My computer is a MAC OSX 10.9.1

I look forward to your replay

Kind regards
Gwen



This is a known issue. If you had read the release notes, you would have seen the solution for 
the problem.

https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0.1+Release+Notes#AOO4.0.1ReleaseNotes-KnownIssues

You need to delete the folder org.openoffice.script.savedState. It is in the Saved 
Application State folder in your User/Library.


See this post on the user forum for detailed instructions: 
https://forum.openoffice.org/en/forum/viewtopic.php?f=17t=55755#p244931


--

As a courtesy I have sent a copy of this reply to you as well as to the mailing list. 
Do Not reply to me personally but just to the list at 
us...@openoffice.apache.org - replies to my personal email address will be 
ignored.

Since you are not subscribed to this list you may not see all the replies to 
your query.To subscribe Apache OpenOffice mailing lists go to
http://openoffice.apache.org/mailing-lists.html

For user support you can also use The OpenOffice.org Community Forum
http://user.services.openoffice.org/en/forum/

_

Larry I. Gusaas
Moose Jaw, Saskatchewan Canada
Website: http://larry-gusaas.com
An artist is never ahead of his time but most people are far behind theirs. - 
Edgard Varese




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



Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault

2014-02-06 Thread Andre Fischer

On 05.02.2014 20:02, Steele, Raymond wrote:


Andre,

We are not seeing any exception before the actual crash. Maybe I am 
not looking in the right place, but we've been using dbx intercept 
command to track any. Any other suggestions?




Raymond,

there a few thing you can do to find out if this is a local problem 
(broken in the constructor) or something more fundamental that is 
possibly caused by an error that happened much earlier.


- Comment out the last few lines:
  /*
WeakReferenceSidebarController xWeakController (this);
maSidebarControllerContainer.insert(
SidebarControllerContainer::value_type(
rxFrame,
xWeakController));
   */
That should tell us whether the crash is caused just by storing the weak 
reference.

The sidebar should still work in general but some updates may be lost.

- Replace the last few lines by this:
ReferenceSidebarController xThis (this, SAL_NO_ACQUIRE);
WeakReferenceSidebarController xWeakController (xThis);
maSidebarControllerContainer.insert(
SidebarControllerContainer::value_type(
rxFrame,
xWeakController));
That removes one (of two) acquire calls (I don't know yet why there is a 
second acquire,  after all the purpose of the weak reference is just 
/not/ to increase the reference count).


- Check the value of the reference count of 'SidebarController* this' 
(in OWeakObject::acquire, cppuhelper/source/weak.cxx) when line 168 of 
the SidebarController constructor is executed.

  In my case it is 3.

-Andre


  Also, I've attached the stack trace of the first and second 
notifyContextChangeEvent.  They are different.




That is OK.  They should be different.  But the stack trace of the 
second call looks broken.  The top two frames (notifyContextChangeEvent 
being called from Reference constructor) indicate that something is very 
wrong, like the vtable overwritten or not fully created.  One 
explanation (although I cannot say how probable that is) could be that 
the Solaris compiler has not fully created/initialized the vtable in the 
constructor.



Raymond

*From:*Steele, Raymond
*Sent:* Wednesday, February 05, 2014 9:48 AM
*To:* 'a...@openoffice.apache.org'; Herbert Duerr (h...@apache.org); 
dev@openoffice.apache.org

*Cc:* Meffe, David K; 'awf@gmail.com'
*Subject:* RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 
Runtime Memory Fault


Hi Andre,

Thanks for the response. We are looking at that now.

In the constructor of SidebarController at line 168 
WeakReference..., on your system, does the code step to 
 Reference.h: Line 359 -- XInterface operator, as it does during our run?


It appears  that at runtime Reference.hxx: Line 136 - 
_pInterface-acquire()  that occurs after WeakReference..  does not 
 execute as it does after addContextChangeEventListener a few lines 
above WeakReference. Do you see a similar behavior?  Can you provide 
the first 5-10 steps your code takes after WeakReference (line 168)?




Here are the requested frames

cppuhelper3MSC.dll!cppu::OWeakObject::acquire()  Line 204 C++
cppuhelper3MSC.dll!cppu::WeakComponentImplHelperBase::acquire() Line 236 
+ 0x9 bytesC++
sfx.dll!cppu::WeakComponentImplHelper4com::sun::star::ui::XContextChangeEventListener,com::sun::star::beans::XPropertyChangeListener,com::sun::star::ui::XSidebar,com::sun::star::frame::XStatusListener::acquire() 
Line 70 + 0xc bytesC++
sfx.dll!com::sun::star::uno::Referencesfx2::sidebar::SidebarController::Referencesfx2::sidebar::SidebarController(sfx2::sidebar::SidebarController 
* pInterface)  Line 136 + 0x12 bytesC++
sfx.dll!sfx2::sidebar::SidebarController::SidebarController(sfx2::sidebar::SidebarDockingWindow 
* pParentWindow, const 
com::sun::star::uno::Referencecom::sun::star::frame::XFrame  
rxFrame)  Line 168 + 0x12 bytesC++



Thanks!

Raymond

*From:*Steele, Raymond
*Sent:* Tuesday, February 04, 2014 3:59 PM
*To:* a...@openoffice.apache.org mailto:a...@openoffice.apache.org; 
Herbert Duerr (h...@apache.org mailto:h...@apache.org); 
dev@openoffice.apache.org mailto:dev@openoffice.apache.org

*Cc:* Meffe, David K
*Subject:* RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 
Runtime Memory Fault


Herbert,

Raymond and I have been using the dbx debugger feature of Solaris 
Studio 12.3 with an equivalent throw/catch feature 
(intercept/whocatches) and have found that the cases where we tried to 
intercept exceptions, they were unhandled. This includes inside the 
SidebarController where we have tracked the problem origination. We 
have stepped through the code multiple times and while we have found 
that the problem originates in the SidebarController, we cannot 
explain how it happens.


Using the debug tool we see that the SidebarController constructor 
doesn't complete because the segmentation fault occurs when the 
notifyContextChangeEvent is called a second time. The first time it is 
called it is located in the addContextChangeEventListener where 

Re: About openxml handling code

2014-02-06 Thread Andre Fischer

On 03.02.2014 18:54, Mayur wrote:

Found something interesting. Writer seems to reject any graphics in OOXML
documents - even VML ones. But there does seem to be code to support it.
Only, if a couple of tiny glitches were fixed, possibly Writer will start
showing VML shapes (at least). That'd work for all the 2007 MS word
documents, as well as for some 2010 documents which would have the vml data
in their mc:Alternativecontent tags. Here're the problems:
   i.  A function getNamespace( )  in
oox/source/shape/ShapeContextHandler.cxx always returned 0. The problem
seems to be a
   rather strange looking definition of the NMSP_MASK constant in
oox/source/token/namespaces.hxx.tail. It says there:
*const sal_int32 TOKEN_MASK* = static_castsal_int32* ( (1 
16) - 1 );  *
*   const sal_Int32 NMSP_MASK   = static_cast sal_Int32 (
SAL_MAX_INT16  ~TOKEN_MASK );*

  Why SAL_MAX_INT16? That would translate into (for windows)
*  TOKEN_MASK = static_castlong(0x);  // 65535*
*and NMSP_MASK = static_castlong(0x7FFF  ~TOKEN_MASK). //
which is 0x7FFF  0x = 0.*
   And
   Where as really, we should be looking for is the namespace value
which is in the higher two bytes. i.e. the following change fixes it.
*const sal_Int32 NMSP_MASK   = static_cast sal_Int32 (
SAL_MAX_INT32  ~TOKEN_MASK );*
That should set NMSP_MASK to the required 0x to obtain the
higher two bytes.


Good analysis.



To my mind, this sort of compactness isn't called for. Maybe, we
could have simply used a compact struct to store namespace and tag.


I always wondered why we keep namespace and token separable once they 
have been read into memory.  While the XML file is scanned it does makes 
sense to use the same token for names in different namespaces.  This 
keeps the number of tokens and thus the complexity of the scanner small 
(well, as small as possible).  But once we have the tag (namespace and 
name) in memory we should not have to extract namespace or name from a 
tag.  After all, if I have a name n in two namespaces a and b then a:n 
and b:n are two different things and we can use enum values a_n and b_n 
with arbitrary values to represent them.  But maybe I am missing something?


-Andre



  ii. In oox/source/vml/vmldrawingfragment.cxx, there's a switch in the
function onCreateContext that says:
 case VMLDRAWING_WORD:
   if ( isRootElement() )  {... }

   Is this so that whenever a vml file is received as a separate
document fragment, only then we create a shape context? Why not for the
inline (v:rect or other) objects? I tried removing the check, and instead
checking simply if nElement is a VML, then vml drawings were suddenly
visible in writer.

Is this a valid fix?



On Wed, Jan 29, 2014 at 1:24 PM, Andre Fischer awf@gmail.com wrote:


On 28.01.2014 13:47, Mayur wrote:


Hi,

I am very new to the OpenOffice code, and need some help understanding the
open-xml handling code. Could someone please answer the following
questions?

   i. There seem to be two distinct pieces of code that do open-xml parsing
in different ways. There's one part in writerfilter that has some
generated code (xslt based) that provides factories and classes for
creating different object types. And then, for sc and sd, all of the
parsing code is in the oox module and seems to be hand-written. Why is
that? Are there plans to move the parsing code to a common module?
(perhaps
oox ...)


Re why: OOXML import has been developed while OpenOffice was maintained by
Sun, later Oracle.  There where at least three development teams involved
(for Writer, Calc, Draw/Impress). Sometimes they did not communicate with
each other as well as they should have.  Having different modules is one of
the results.  But, as far as I know, writerfilter has some calls into oox
for shared functionality.

Re future plans: Some of us are thinking about improving the OOXML
support.  Consolidation of the code base into one module is a long term
goal.




ii. Probably a related question - why are drawing-ml shapes and pictures
not supported in sw, while they are supported in sc and sd? The parsing
code seems to be there. The tag wps:wsp has very little delta with the
p:sp
tag. Is this in works?


Well, see my above comments.
And, parsing OOXML is the easy part, importing the data into the
application model is the hard part.  Calc and Impress use the same model
for representing graphical objects, Writer has its own.

If you are interested in OOXML import/export then maybe we can work
together on improving it?

Regards,
Andre



thanks,
mayur



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





-
To unsubscribe, e-mail: 

Bugzilla: Keyword regression

2014-02-06 Thread Rainer Bielefeld

Hi,

currently the manual on
https://issues.apache.org/ooo/describekeywords.cgi seems to suggest to 
use that keyword also for problems what appeared between OOo 1.0.2 and 
OOo 1.0.3. Such use might be correct as a matter of form, but I think 
useless for QA and developers daly work.


regression key word indicates a major priority for fixing a bug, 
because appearance of new problems is bad for AOO's reputation. But a 
regression between OOo 1.0.0 and OOo 1.0.1 from 2001 (as an overstated 
example) is nothing what should cause major reputation loss for AOO in 2014.


So I recommend to limit use of Keyword regression for all Problems 
what appeared with AOO 3.4-dev or later and to add a corresponding hint 
in Bugzilla Help.


BTW: I recommend to keep those hints in Bugzilla short (not more than 2 
text rows or so) and do link to more elaborated help in the Wiki (for 
example).


Best regards

Rainer

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



Application Review - OpenOffice

2014-02-06 Thread Barrett, Ronnie

To whom it may concern,

Please review and complete the attached information request about your
applications currently in use at London Borough of Southwark.

The form should be completed and returned directly to the council inbox
moder...@southwark.gov.uk, not this inbox - Capita are collating this
information on behalf of London Borough of Southwark council.

Please however, respond to this email if there are any queries with this
request for information.
 LBS-OpenOffice-Application Information.doc

Many Thanks,

Ronnie Barrett


The email you received and any files transmitted with it are confidential, may 
be covered by legal and/or professional privilege and are intended solely for 
the use of the individual or entity to whom they are addressed.

If you have received this in error please notify us immediately.

If you are not the intended recipient of the email or the person responsible 
for delivering it to them you may not copy it, forward it or otherwise use it 
for any purpose or disclose its contents to any other person. To do so may be 
unlawful.

Where opinions are expressed in the email they are not necessarily those of 
Southwark Council and Southwark Council is not responsible for any changes made 
to the message after it has been sent.


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

Re: Application Review - OpenOffice

2014-02-06 Thread Rob Weir
On Thu, Feb 6, 2014 at 8:33 AM, Barrett, Ronnie
ronnie.barr...@southwark.gov.uk wrote:

 To whom it may concern,


Hello Ronnie,

We did receive your 27-page long questionnaire regarding the
capabilities and license of the OpenOffice application.   There may be
some misunderstanding here.   We are not a commercial vendor selling
licenses of software, providing formal support agreements, etc.  We
are a volunteer-led, non-profit open source project, making software
available for all to use for free.   We have no staff to fill out
lengthy government forms.  We're generally happy to respond to
technical questions regarding use of the product.  We're all
enthusiastic users of OpenOffice and love to share our knowledge of
the product.  But there is no one here to help you deal with your own
regulations.

What would typically happen in cases like this is that the private
sector partner, in this case Capita, would do the leg work and
research answers to these questions.  Most of them could be found on
our website without too much difficulty.   If a greater effort is
required, there are several consultants who specialize in
OpenOffice-related services, including those we list on our website:

http://www.openoffice.org/bizdev/consultants.html

Regards,

-Rob


 Please review and complete the attached information request about your
 applications currently in use at London Borough of Southwark.

 The form should be completed and returned directly to the council inbox
 moder...@southwark.gov.uk, not this inbox – Capita are collating this
 information on behalf of London Borough of Southwark council.

 Please however, respond to this email if there are any queries with this
 request for information.
 LBS-OpenOffice-Application Information.doc

 Many Thanks,

 Ronnie Barrett

 The email you received and any files transmitted with it are confidential,
 may be covered by legal and/or professional privilege and are intended
 solely for the use of the individual or entity to whom they are addressed.
 If you have received this in error please notify us immediately. If you are
 not the intended recipient of the email or the person responsible for
 delivering it to them you may not copy it, forward it or otherwise use it
 for any purpose or disclose its contents to any other person. To do so may
 be unlawful. Where opinions are expressed in the email they are not
 necessarily those of Southwark Council and Southwark Council is not
 responsible for any changes made to the message after it has been sent.



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

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



Getting started with development

2014-02-06 Thread Pranet Verma
Hi,
Could you please tell me how to get started with Open Office development?

I began by following this guide :
https://wiki.openoffice.org/wiki/Development
, but after building the source and installing the program when I reached
the first tutorial ( https://wiki.openoffice.org/wiki/Tutorial_Start ) it
failed(I'm pretty sure i followed all the steps but ctrl+T just doesnt work
like its supposed to) .
The page does seem to be outdated to me (considering some folder name and
syntax of files do not match with the guide, though i may be wrong), I was
wondering if there was a better source to learn from.

I'm reasonably comfortable with c/c++ , and am pretty active in competitive
programming, but developments new for me , so any help is appreciated.
Also, if possible could you direct me to modules using c/c++ specifically?
Im open to learning new languages, but to start with I would prefer working
in a familiar environment.

Thank You


Re: Bugzilla: Keyword regression

2014-02-06 Thread Rainer Bielefeld

Rob Weir schrieb:


I wonder whether a combination of the regression flag and the version
field would give us everything we need to know?



Hi,

that's the main intentions behind my suggestion. If we know we have had 
a regression (not too long ago, with Regression keyword) and also have 
found the version where it appeared, we can find the commit what causes 
the problem. With reasons for the commit fresh in their mind developers 
should be able to fix that quickly. With old regressions that's more 
difficult, nobody remembers why the code changes have been done and what 
later commits' functions will break after changes in that area.


So the regression keyword can be a flag showing that here is an 
annoying mishap what can be fixed with probably bearable costs.


CU

Rainer

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



Re: Application Review - OpenOffice

2014-02-06 Thread Donald Whytock
On Thu, Feb 6, 2014 at 9:27 AM, Rob Weir robw...@apache.org wrote:


 We did receive your 27-page long questionnaire regarding the
 capabilities and license of the OpenOffice application.   There may be
 some misunderstanding here.


I'm tempted to put that on my cube wall as a quote.


[Mwiki] a massive spam attack. Again

2014-02-06 Thread helen

Hi there,

I'm Helen, a Wiki admin. https://wiki.openoffice.org/wiki/User:Helen_russian

Since 5th Feb. MWiki is under a massive spam attack.
Please take a look: https://wiki.openoffice.org/wiki/Special:Log/delete 
, https://wiki.openoffice.org/wiki/Special:Log/block


Please help.

--
Regards,
Helen



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



Re: Application Review - OpenOffice

2014-02-06 Thread Jonathon


On February 6, 2014 5:33:20  Barrett wrote:

Please review and complete the attached information request about your 
applications currently in use at London Borough of Southwark.

A)  You sent your request to a mailing list whose subscribers are scattered 
across the globe. A mailing list that is archived on several sites on the 
Internet, including, but not exclusively, some that are part of the World Wide 
Web. The majority of the sites are open to the general public.

B) It is not uncommon for attachments to messages sent to mailing lists to be 
stripped, and removed from the message, between the sender, and the recipient. 
As such, best practices call for a URL to be provided, so the recipents can 
retrieve, and review the attachment.

C) Your request was sent to a list of developers. People who write, or review 
code. People who place little to no concern about distribution of the product. 
People whose concern about licencing starts with What licence is the source 
code distributed under? and ends with Is that source code available?

jonathon
-- 


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



Idea for a new feature

2014-02-06 Thread Isabel Prochner
Hello,

I have an idea for a new feature for a word-processing program. I think it
could be a helpful addition to Writer.

My programmer friend says it could be easy to create, but we'd need access
to the source code of the program.

Could you please let me know how to implement this idea, and how we could
become involved with Open Office?

I look forward to hearing from you.

Best regards,
Isabel Prochner


Re: Idea for a new feature

2014-02-06 Thread Alexandro Colorado
Which idea is it, the source code is publically browsable here:
http://svn.apache.org/viewvc/openoffice/trunk/

More info: https://openoffice.apache.org/source.html



On Thu, Feb 6, 2014 at 1:51 PM, Isabel Prochner
isabel.proch...@gmail.comwrote:

 Hello,

 I have an idea for a new feature for a word-processing program. I think it
 could be a helpful addition to Writer.

 My programmer friend says it could be easy to create, but we'd need access
 to the source code of the program.

 Could you please let me know how to implement this idea, and how we could
 become involved with Open Office?

 I look forward to hearing from you.

 Best regards,
 Isabel Prochner




-- 
Alexandro Colorado
Apache OpenOffice Contributor
http://www.openoffice.org
882C 4389 3C27 E8DF 41B9  5C4C 1DB7 9D1C 7F4C 2614


Re: [Mwiki] a massive spam attack. Again

2014-02-06 Thread Kay Schenk
On Thu, Feb 6, 2014 at 12:06 PM, Rob Weir robw...@apache.org wrote:

 On Thu, Feb 6, 2014 at 1:28 PM, jan i j...@apache.org wrote:
  On 6 February 2014 19:00, helen helenruss...@gmail.com wrote:
 
  Hi there,
 
  I'm Helen, a Wi admin.
 https://wiki.openoffice.org/wiki/User:Helen_russian
 
  Since 5th Feb. MWiki is under a massive spam attack.
  Please take a look: https://wiki.openoffice.org/wiki/Special:Log/delete,
  https://wiki.openoffice.org/wiki/Special:Log/block
 
 
  I warned about exactly that, but  I was asked (see JIRAs) to remove the
  cats (captcha). If you read the JIRA (which was watched be several in
 here)
  you will see my warning.
 
  The simple captcha we have in place, is browser safe, but not very
  efficient. I assume the admins as such wanted the change (otherwise I am
  sure the task would not have been added).
 
  Another captcha was suggested, but with the note not tested on
 mediawiki
  (or something similar). We only install extensions supported by mediawiki
  of course.
 

 A simpler solution:  Why not add back the cat captcha, but only show
 it to the spammers?


LOL!



 Regards,

 -Rob

 (OK.  That is a joke.  But I was once asked by a manager, many years
 ago, to improve a spell checker so it only reported misspellings of
 words that were in the dictionary.)


  If the admins wants a change, then please have a discussion about it on
 the
  ML, and once agreed upon, file a JIRA.
 
  rgds
  jan I.
 
 
  Please help.
 
  --
  Regards,
  Helen
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
  For additional commands, e-mail: dev-h...@openoffice.apache.org
 
 

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




-- 
-
MzK

Cats do not have to be shown how to have a good time,
 for they are unfailing ingenious in that respect.
   -- James Mason


Re: [Mwiki] a massive spam attack. Again

2014-02-06 Thread jan i
On 6 February 2014 21:06, Rob Weir robw...@apache.org wrote:

 On Thu, Feb 6, 2014 at 1:28 PM, jan i j...@apache.org wrote:
  On 6 February 2014 19:00, helen helenruss...@gmail.com wrote:
 
  Hi there,
 
  I'm Helen, a Wi admin.
 https://wiki.openoffice.org/wiki/User:Helen_russian
 
  Since 5th Feb. MWiki is under a massive spam attack.
  Please take a look: https://wiki.openoffice.org/wiki/Special:Log/delete,
  https://wiki.openoffice.org/wiki/Special:Log/block
 
 
  I warned about exactly that, but  I was asked (see JIRAs) to remove the
  cats (captcha). If you read the JIRA (which was watched be several in
 here)
  you will see my warning.
 
  The simple captcha we have in place, is browser safe, but not very
  efficient. I assume the admins as such wanted the change (otherwise I am
  sure the task would not have been added).
 
  Another captcha was suggested, but with the note not tested on
 mediawiki
  (or something similar). We only install extensions supported by mediawiki
  of course.
 

 A simpler solution:  Why not add back the cat captcha, but only show
 it to the spammers?

 Regards,

 -Rob

 (OK.  That is a joke.  But I was once asked by a manager, many years
 ago, to improve a spell checker so it only reported misspellings of
 words that were in the dictionary.)


I am happy, someone can make a joke out of a self imposed spam attack.

I am surely too serious in my work, but would much more ike to see a
community agreed solution, before we end having all admins fight spam (just
remember last time).

rgds
jan I.



  If the admins wants a change, then please have a discussion about it on
 the
  ML, and once agreed upon, file a JIRA.
 
  rgds
  jan I.
 
 
  Please help.
 
  --
  Regards,
  Helen
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
  For additional commands, e-mail: dev-h...@openoffice.apache.org
 
 

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




Re: Reporting a problem with the OpenOffice website

2014-02-06 Thread Marcus (OOo)

Am 02/06/2014 07:25 AM, schrieb Carol Miller:

Your product keeps downloading itself onto my computer. I do not want it!
How do I stop this?


From your description I conclude that you don't have initially 
downloaded OpenOffice from our website 
(http://www.openoffice.org/download/). Obviously you have got it from a 
website that has bad intentions.


From your mail I also conclude that you have a Windows system. So, 
maybe it's the best to deinstall / delete the software completely if 
this is possible. Then download the real OpenOffice from our website 
mentioned above.


Howeer, without further details I cannot tell you any more tipps.

For further help use our User's mailing list [1] or if you prefer visit 
the Forum [2] to share your problem with other users and ask for help.


[1] 
http://openoffice.apache.org/mailing-lists.html#users-mailing-list-public


[2] https://forum.openoffice.org/en/forum/

HTH

Marcus

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



Re: [Mwiki] a massive spam attack. Again

2014-02-06 Thread Andrea Pescetti

jan i wrote:

I warned about exactly that, but  I was asked (see JIRAs) to remove the
cats (captcha). If you read the JIRA (which was watched be several in here)
you will see my warning.


The idea was to replace the CAPTCHA with something better, otherwise we 
can (should) keep the current CAPTCHA and discuss a better solution in 
the meantime.


The cats cause incompatibilities and other issues, but if they are much 
more effective than the replacement let's go back to the cats as soon as 
possible and in the meantime see what's best to replace them (but 
something MORE effective, not LESS effective!).


Regards,
  Andrea.

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



RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault

2014-02-06 Thread Steele, Raymond
Andre,

When we commented out the section below, we were able to get the application to 
work correctly (although it did not let us save a spreadsheet to disk for some 
reason. Each time we hit okay to save after supplying a unique name, the 
filechooser closes, but instantly reappears again. It did let us save it as 
another format, such as .dif).

However, the application crashes when we replace the lines with:

ReferenceSidebarController xThis (this, SAL_NO_ACQUIRE);
WeakReferenceSidebarController xWeakController (xThis);
maSidebarControllerContainer.insert(
SidebarControllerContainer::value_type(
rxFrame,
xWeakController));


I've attached the stack trace of that crash. It crashes right after the 
SidebarController destructor on line 177 (which is empty).  Stepping from the 
destructor brings us into boost's checked_delete.hpp and eventually crashes at 
line 34 delete x. See attached stack trace. m_RefCount was 3 for us as well.

Thanks for taking the time to look into this, we are grateful.  Would you 
happen to be  located in the U.S.?


From: Andre Fischer [mailto:awf@gmail.com]
Sent: Thursday, February 06, 2014 2:03 AM
To: Steele, Raymond; a...@openoffice.apache.org; Herbert Duerr 
(h...@apache.org); dev@openoffice.apache.org
Cc: Meffe, David K; awf@gmail.com
Subject: Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory 
Fault

On 05.02.2014 20:02, Steele, Raymond wrote:
Andre,

We are not seeing any exception before the actual crash. Maybe I am not looking 
in the right place, but we've been using dbx intercept command to track any. 
Any other suggestions?

Raymond,

there a few thing you can do to find out if this is a local problem (broken in 
the constructor) or something more fundamental that is possibly caused by an 
error that happened much earlier.

- Comment out the last few lines:
  /*
WeakReferenceSidebarController xWeakController (this);
maSidebarControllerContainer.insert(
SidebarControllerContainer::value_type(
rxFrame,
xWeakController));
   */
That should tell us whether the crash is caused just by storing the weak 
reference.
The sidebar should still work in general but some updates may be lost.

- Replace the last few lines by this:
ReferenceSidebarController xThis (this, SAL_NO_ACQUIRE);
WeakReferenceSidebarController xWeakController (xThis);
maSidebarControllerContainer.insert(
SidebarControllerContainer::value_type(
rxFrame,
xWeakController));
That removes one (of two) acquire calls (I don't know yet why there is a second 
acquire,  after all the purpose of the weak reference is just /not/ to increase 
the reference count).

- Check the value of the reference count of 'SidebarController* this' (in 
OWeakObject::acquire, cppuhelper/source/weak.cxx) when line 168 of the 
SidebarController constructor is executed.
  In my case it is 3.

-Andre




  Also, I've attached the stack trace of the first and second 
notifyContextChangeEvent.  They are different.

That is OK.  They should be different.  But the stack trace of the second call 
looks broken.  The top two frames (notifyContextChangeEvent being called from 
Reference constructor) indicate that something is very wrong, like the vtable 
overwritten or not fully created.  One explanation (although I cannot say how 
probable that is) could be that the Solaris compiler has not fully 
created/initialized the vtable in the constructor.



Raymond

From: Steele, Raymond
Sent: Wednesday, February 05, 2014 9:48 AM
To: 'a...@openoffice.apache.orgmailto:a...@openoffice.apache.org'; Herbert 
Duerr (h...@apache.orgmailto:h...@apache.org); 
dev@openoffice.apache.orgmailto:dev@openoffice.apache.org
Cc: Meffe, David K; 'awf@gmail.commailto:awf@gmail.com'
Subject: RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory 
Fault

Hi Andre,

Thanks for the response. We are looking at that now.

In the constructor of SidebarController at line 168 WeakReference..., on your 
system, does the code step to  Reference.h: Line 359 - XInterface operator, as 
it does during our run?

It appears  that at runtime Reference.hxx: Line 136 - _pInterface-acquire()  
that occurs after WeakReference..  does not  execute as it does after 
addContextChangeEventListener a few lines above WeakReference. Do you see a 
similar behavior?  Can you provide the first 5-10 steps your code takes after 
WeakReference (line 168)?

Here are the requested frames

cppuhelper3MSC.dll!cppu::OWeakObject::acquire()  Line 204C++
 cppuhelper3MSC.dll!cppu::WeakComponentImplHelperBase::acquire()  Line 236 
+ 0x9 bytesC++
 
sfx.dll!cppu::WeakComponentImplHelper4com::sun::star::ui::XContextChangeEventListener,com::sun::star::beans::XPropertyChangeListener,com::sun::star::ui::XSidebar,com::sun::star::frame::XStatusListener::acquire()
  Line 70 + 0xc bytesC++
 

Re: [Mwiki] a massive spam attack. Again

2014-02-06 Thread jan i
On 6 February 2014 23:42, Andrea Pescetti pesce...@apache.org wrote:

 jan i wrote:

 I warned about exactly that, but  I was asked (see JIRAs) to remove the
 cats (captcha). If you read the JIRA (which was watched be several in
 here)
 you will see my warning.


 The idea was to replace the CAPTCHA with something better, otherwise we
 can (should) keep the current CAPTCHA and discuss a better solution in the
 meantime.

 The cats cause incompatibilities and other issues, but if they are much
 more effective than the replacement let's go back to the cats as soon as
 possible and in the see what's best to replace them (but something MORE
 effective, not LESS effective!).


May I politely correct you, the idea was NOT to replace the cats. The jira
was implemented by the word !

The exact wording is:

Wiki6: Cats/Dogs CAPTCHA for new user registration is quite broken. It
doesn't work in several browser configurations, it includes HTTP instead of
HTTPS https://issues.apache.org/ooo/show_bug.cgi?id=123695 - Recommended
solution: drop it entirely.  

That statement is pretty clear, how it can be read as moving to something
more effective slips my mind.

later the jira contains:

accessibility suggestion from Tyler (haven't tested MediaWiki
compatibility): there is a website which provides text-based CAPTCHA's in
the form of logic questions, math problems, etc. It provides an XML API.
See http://www.textcaptcha.com/ 

Apart from the facts, thats its a suggestion and not a decision (like that
above),  we do not use extensions that are not supported by mediawiki
(meaning downloadable from mediawiki.com and verified for our release). As
a sidenote, that captcha is pretty much the same as the standard which are
active right now. There are quite a lot of captcha´s out there, just
looking at mediawiki.com extensions gives a lot of choises.

At this point in time we have several choices:
1) leave the config as it is
2) reinstall cats
3) choose another captcha (in this case we need to decide which one).

I am not the one to overrule a community decision (Wiki6), but I will
happely implement another community decision.

rgds
jan I.





 Regards,
   Andrea.


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




Re: [Mwiki] a massive spam attack. Again

2014-02-06 Thread Rob Weir
On Thu, Feb 6, 2014 at 6:21 PM, jan i j...@apache.org wrote:
 On 6 February 2014 23:42, Andrea Pescetti pesce...@apache.org wrote:

 jan i wrote:

 I warned about exactly that, but  I was asked (see JIRAs) to remove the
 cats (captcha). If you read the JIRA (which was watched be several in
 here)
 you will see my warning.


 The idea was to replace the CAPTCHA with something better, otherwise we
 can (should) keep the current CAPTCHA and discuss a better solution in the
 meantime.

 The cats cause incompatibilities and other issues, but if they are much
 more effective than the replacement let's go back to the cats as soon as
 possible and in the see what's best to replace them (but something MORE
 effective, not LESS effective!).


 May I politely correct you, the idea was NOT to replace the cats. The jira
 was implemented by the word !

 The exact wording is:

 Wiki6: Cats/Dogs CAPTCHA for new user registration is quite broken. It
 doesn't work in several browser configurations, it includes HTTP instead of
 HTTPS https://issues.apache.org/ooo/show_bug.cgi?id=123695 - Recommended
 solution: drop it entirely.  

 That statement is pretty clear, how it can be read as moving to something
 more effective slips my mind.

 later the jira contains:

 accessibility suggestion from Tyler (haven't tested MediaWiki
 compatibility): there is a website which provides text-based CAPTCHA's in
 the form of logic questions, math problems, etc. It provides an XML API.
 See http://www.textcaptcha.com/ 

 Apart from the facts, thats its a suggestion and not a decision (like that
 above),  we do not use extensions that are not supported by mediawiki
 (meaning downloadable from mediawiki.com and verified for our release). As
 a sidenote, that captcha is pretty much the same as the standard which are
 active right now. There are quite a lot of captcha´s out there, just
 looking at mediawiki.com extensions gives a lot of choises.

 At this point in time we have several choices:
 1) leave the config as it is
 2) reinstall cats
 3) choose another captcha (in this case we need to decide which one).

 I am not the one to overrule a community decision (Wiki6), but I will
 happely implement another community decision.


I hope you can simply restore cats if that can be done without too
much trouble.  Then we can discuss further and come to a community
decision on what else to do, if anything.  I hope you agree that there
is zero benefit to accumulating additional spam while we discuss.

Fix the immediate problem, then we can discuss longer term.  This one
area that Apache Infra knows how to do well.  They know when it is
important to act rather than discuss.  I suggest that this is one of
those times.

Thanks!

-Rob

 rgds
 jan I.





 Regards,
   Andrea.


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



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



Re: [Mwiki] a massive spam attack. Again

2014-02-06 Thread jan i
On 7 February 2014 00:45, Rob Weir robw...@apache.org wrote:

 On Thu, Feb 6, 2014 at 6:21 PM, jan i j...@apache.org wrote:
  On 6 February 2014 23:42, Andrea Pescetti pesce...@apache.org wrote:
 
  jan i wrote:
 
  I warned about exactly that, but  I was asked (see JIRAs) to remove the
  cats (captcha). If you read the JIRA (which was watched be several in
  here)
  you will see my warning.
 
 
  The idea was to replace the CAPTCHA with something better, otherwise we
  can (should) keep the current CAPTCHA and discuss a better solution in
 the
  meantime.
 
  The cats cause incompatibilities and other issues, but if they are much
  more effective than the replacement let's go back to the cats as soon as
  possible and in the see what's best to replace them (but something MORE
  effective, not LESS effective!).
 
 
  May I politely correct you, the idea was NOT to replace the cats. The
 jira
  was implemented by the word !
 
  The exact wording is:
 
  Wiki6: Cats/Dogs CAPTCHA for new user registration is quite broken. It
  doesn't work in several browser configurations, it includes HTTP instead
 of
  HTTPS https://issues.apache.org/ooo/show_bug.cgi?id=123695 -
 Recommended
  solution: drop it entirely.  
 
  That statement is pretty clear, how it can be read as moving to something
  more effective slips my mind.
 
  later the jira contains:
 
  accessibility suggestion from Tyler (haven't tested MediaWiki
  compatibility): there is a website which provides text-based CAPTCHA's in
  the form of logic questions, math problems, etc. It provides an XML API.
  See http://www.textcaptcha.com/ 
 
  Apart from the facts, thats its a suggestion and not a decision (like
 that
  above),  we do not use extensions that are not supported by mediawiki
  (meaning downloadable from mediawiki.com and verified for our release).
 As
  a sidenote, that captcha is pretty much the same as the standard which
 are
  active right now. There are quite a lot of captcha´s out there, just
  looking at mediawiki.com extensions gives a lot of choises.
 
  At this point in time we have several choices:
  1) leave the config as it is
  2) reinstall cats
  3) choose another captcha (in this case we need to decide which one).
 
  I am not the one to overrule a community decision (Wiki6), but I will
  happely implement another community decision.
 

 I hope you can simply restore cats if that can be done without too
 much trouble.  Then we can discuss further and come to a community
 decision on what else to do, if anything.  I hope you agree that there
 is zero benefit to accumulating additional spam while we discuss.


Wiki have been upgraded, and respecting the jira I did not move the cat
extension.


 Fix the immediate problem, then we can discuss longer term.  This one
 area that Apache Infra knows how to do well.  They know when it is
 important to act rather than discuss.  I suggest that this is one of
 those times.


I happen to agree with you, and it has actually not been possible to create
new accounts for a while now.

The configuration is changed so that only sysops can create new accounts.

Now to the other partwe have discussed these issues for quite a long
time, so it was a fair assumption to accept the jira as the community wish.



 Thanks!

 -Rob

  rgds
  jan I.
 
 
 
 
 
  Regards,
Andrea.
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
  For additional commands, e-mail: dev-h...@openoffice.apache.org
 
 

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




Re: [Mwiki] a massive spam attack. Again

2014-02-06 Thread Dave Fisher
Hi -

The JIRA is quoted but links or the JIRA ID would be helpful along with a link 
to the ML thread where the decision was made.

It is hard to review this incident without these helpful pointers.

Thanks,
Dave

On Feb 6, 2014, at 4:22 PM, jan i wrote:

 On 7 February 2014 00:45, Rob Weir robw...@apache.org wrote:
 
 On Thu, Feb 6, 2014 at 6:21 PM, jan i j...@apache.org wrote:
 On 6 February 2014 23:42, Andrea Pescetti pesce...@apache.org wrote:
 
 jan i wrote:
 
 I warned about exactly that, but  I was asked (see JIRAs) to remove the
 cats (captcha). If you read the JIRA (which was watched be several in
 here)
 you will see my warning.
 
 
 The idea was to replace the CAPTCHA with something better, otherwise we
 can (should) keep the current CAPTCHA and discuss a better solution in
 the
 meantime.
 
 The cats cause incompatibilities and other issues, but if they are much
 more effective than the replacement let's go back to the cats as soon as
 possible and in the see what's best to replace them (but something MORE
 effective, not LESS effective!).
 
 
 May I politely correct you, the idea was NOT to replace the cats. The
 jira
 was implemented by the word !
 
 The exact wording is:
 
 Wiki6: Cats/Dogs CAPTCHA for new user registration is quite broken. It
 doesn't work in several browser configurations, it includes HTTP instead
 of
 HTTPS https://issues.apache.org/ooo/show_bug.cgi?id=123695 -
 Recommended
 solution: drop it entirely.  
 
 That statement is pretty clear, how it can be read as moving to something
 more effective slips my mind.
 
 later the jira contains:
 
 accessibility suggestion from Tyler (haven't tested MediaWiki
 compatibility): there is a website which provides text-based CAPTCHA's in
 the form of logic questions, math problems, etc. It provides an XML API.
 See http://www.textcaptcha.com/ 
 
 Apart from the facts, thats its a suggestion and not a decision (like
 that
 above),  we do not use extensions that are not supported by mediawiki
 (meaning downloadable from mediawiki.com and verified for our release).
 As
 a sidenote, that captcha is pretty much the same as the standard which
 are
 active right now. There are quite a lot of captcha´s out there, just
 looking at mediawiki.com extensions gives a lot of choises.
 
 At this point in time we have several choices:
 1) leave the config as it is
 2) reinstall cats
 3) choose another captcha (in this case we need to decide which one).
 
 I am not the one to overrule a community decision (Wiki6), but I will
 happely implement another community decision.
 
 
 I hope you can simply restore cats if that can be done without too
 much trouble.  Then we can discuss further and come to a community
 decision on what else to do, if anything.  I hope you agree that there
 is zero benefit to accumulating additional spam while we discuss.
 
 
 Wiki have been upgraded, and respecting the jira I did not move the cat
 extension.
 
 
 Fix the immediate problem, then we can discuss longer term.  This one
 area that Apache Infra knows how to do well.  They know when it is
 important to act rather than discuss.  I suggest that this is one of
 those times.
 
 
 I happen to agree with you, and it has actually not been possible to create
 new accounts for a while now.
 
 The configuration is changed so that only sysops can create new accounts.
 
 Now to the other partwe have discussed these issues for quite a long
 time, so it was a fair assumption to accept the jira as the community wish.
 
 
 
 Thanks!
 
 -Rob
 
 rgds
 jan I.
 
 
 
 
 
 Regards,
  Andrea.
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org
 
 


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



Re: [Mwiki] a massive spam attack. Again

2014-02-06 Thread Helen russian
2014-02-07 6:22 GMT+06:00 jan i j...@apache.org:


 The configuration is changed so that only sysops can create new accounts.


A lot of thank you, Jan! You are our savior.

For last 48 hours 3 wiki admins have deleted more than 1300 spam pages
and blocked more than 800 spammer accounts.


-- 
WBR,
Helen

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



Re: [Mwiki] a massive spam attack. Again

2014-02-06 Thread Andrea Pescetti

On 07/02/2014 jan i wrote:

May I politely correct you, the idea was NOT to replace the cats. The jira
was implemented by the word !


Yes, probably, but it was badly written in my mail that was then copied 
to JIRA. You, and a few others, know that the contents of that JIRA issue

https://issues.apache.org/jira/browse/INFRA-7173
result from an afternoon I spent during the holidays trying to put 
together all pending improvement suggestions that had come to us through 
many channels. I didn't take care to put many explanations there.



Wiki6: Cats/Dogs CAPTCHA for new user registration is quite broken. It
doesn't work in several browser configurations, it includes HTTP instead of
HTTPS https://issues.apache.org/ooo/show_bug.cgi?id=123695 - Recommended
solution: drop it entirely.  


That specific suggestion was worded that way because I had read from 
someone (you, maybe?) that with the new improvements there could (just a 
possibility) be the possibility to do without the CAPTCHA. We tried, it 
didn't work and it's no problem to fix it immediately.



That statement is pretty clear, how it can be read as moving to something
more effective slips my mind.


I wrote it in a wrong way giving somehow for granted that the MWiki 
upgrade would feature some native anti-spam measures and that those 
measures would suit our purpose. Again, we tried, they didn't, no 
problem to revert quickly.



At this point in time we have several choices:
1) leave the config as it is
2) reinstall cats
3) choose another captcha (in this case we need to decide which one).
I am not the one to overrule a community decision (Wiki6), but I will
happely implement another community decision.


The current remedy you put in place (no self account creation) will 
obviously work for the time being, thanks for being fast in reacting.


So let's move forward and see what we can implement now: where's the 
list of CAPTCHA solutions on mediawiki.com? Do you have any 
recommendations or, on the contrary, any extensions that Infra is not 
going to allow?


(By the way, the CAPTCHA issue exploded before I could review all items, 
but thank you for the work on all other pending issues! And let's get 
this one done properly too)


Regards,
  Andrea.

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



Re: [Mwiki] a massive spam attack. Again

2014-02-06 Thread jan i
On 7 February 2014 08:48, Andrea Pescetti pesce...@apache.org wrote:

 On 07/02/2014 jan i wrote:

 May I politely correct you, the idea was NOT to replace the cats. The jira
 was implemented by the word !


 Yes, probably, but it was badly written in my mail that was then copied to
 JIRA. You, and a few others, know that the contents of that JIRA issue
 https://issues.apache.org/jira/browse/INFRA-7173
 result from an afternoon I spent during the holidays trying to put
 together all pending improvement suggestions that had come to us through
 many channels. I didn't take care to put many explanations there.


  Wiki6: Cats/Dogs CAPTCHA for new user registration is quite broken. It
 doesn't work in several browser configurations, it includes HTTP instead
 of
 HTTPS https://issues.apache.org/ooo/show_bug.cgi?id=123695 - Recommended
 solution: drop it entirely.  


 That specific suggestion was worded that way because I had read from
 someone (you, maybe?) that with the new improvements there could (just a
 possibility) be the possibility to do without the CAPTCHA. We tried, it
 didn't work and it's no problem to fix it immediately.


  That statement is pretty clear, how it can be read as moving to something
 more effective slips my mind.


 I wrote it in a wrong way giving somehow for granted that the MWiki
 upgrade would feature some native anti-spam measures and that those
 measures would suit our purpose. Again, we tried, they didn't, no problem
 to revert quickly.


  At this point in time we have several choices:
 1) leave the config as it is
 2) reinstall cats
 3) choose another captcha (in this case we need to decide which one).
 I am not the one to overrule a community decision (Wiki6), but I will
 happely implement another community decision.


 The current remedy you put in place (no self account creation) will
 obviously work for the time being, thanks for being fast in reacting.

 So let's move forward and see what we can implement now: where's the list
 of CAPTCHA solutions on mediawiki.com? Do you have any recommendations
 or, on the contrary, any extensions that Infra is not going to allow?


Anything found in
http://www.mediawiki.org/wiki/Extension_Matrix/AllExtensions where
mediawiki version allows 1.22 should do.

Especially for CAPTCHA there is one other limitation. The extension must be
self supported, NO calls to third party sites (since this is often used to
collect information).

rgds
jan I.

(By the way, the CAPTCHA issue exploded before I could review all items,
 but thank you for the work on all other pending issues! And let's get this
 one done properly too)


 Regards,
   Andrea.

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