date:20110726

On Tue, 2011-07-26 at 00:10 +0200, Cor Nouws wrote:
 Hi Caolán, *,
 
 Caolán McNamara wrote (25-07-11 13:27)
  On Mon, 2011-07-25 at 02:18 +0200, Cor Nouws wrote:
   Still, there are some issues that I would have to advice my
  customers about (in my work providing professional support for
  enterprises), since they could have effect on their specific work.
 
  If you wish to have a enterprise-ready or enterprise-ready concept,
  you then need to have an objective set of criteria that defines what
  that is. A check-list of features, bugs, or something. Ideally something
  which could then be coded into a automated regression test, and make the
  whole thing completely moot by cutting off at the knees the possibility
  of regression/changes happening of becoming non-enterprise ready.
 
 Sounds interesting to have that, but would very difficult too: what to 
 include, and what not, etc etc.

My point is just that; I don't know where the enterprise-ready term
wandered in as a meme, and if it is to be used as an argument for
release blocking, schedule changes, criteria for release, argument for
defining one version as stable and another not, etc. then surely it has
to be accompanied by an objective test.

The smoketest.sxw macro using test is a possible model for scripting up
some high-level test cases, e.g. there's been a bit of foo around mail
merge. It should be possible without any super-dooper development
knowledge to knock up a mail merge (non-email) test based on the basic
database smoketest section of that. That'd give an objective enterprise
mail-merge requirements pass test for example.


  From the open issues in #35673, IMO some should be looked at (*)  by 
 enterprises, when preparing the upgrade, though some of them are present 
 in 3.3.x too, I guess. Will try to have a closer look at that last point 
 (3.3.x  3.4.x) tomorrow (or the day after). But can only do that on 
 Ubuntu, not on Mac or Windows...
 
 Regards,
 Cor
 
 *) I would advise data-source connection plus mail merge in general, 
 plus 36631, 39447, 37015, 37024, 37030, 37487, 37620. 38542, 38595, 38745.

There's the tangled-up concept of blessing 3.3.X as enterprise-ready and
3.4.X as not. So if an above bug exist in 3.3.X as well as 3.4.Y, then
it presumably isn't relevant as a basis in selecting one LibreOffice
version over another or as a blocking criteria for the next version,
right ?.

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] smoketest fails

On Mon, 2011-07-25 at 20:46 -0400, Terrence Enger wrote:
 Greetings,
 
 I configured with options
 --disable-mozilla
 --enable-symbols
 --enable-debug
 --enable-dbgutil
 --enable-crashdump
 --without-junit
 and `make` seemed to complete normally, although I did notice 
 warnings going by.
 
 Now, `make dev-install` or `build` in smoketestoo_native/ fail 
 in various ways. 
 
 I have found 
 http://wiki.documentfoundation.org/Development/How_to_debug#Debugging_cppunit_tests,
  
 and I am trying with gdb to work slowly toward the problem.  
 Meanwhile, I wonder if  I might be the first to try what I 
 used to know in openoffice as a non-product build?  


 Will the smoketest survive a raised assertion?

Hmm, it depends. In indeed might be failing on a debug-only assertion. I
do run it in --enable-dbgutil mode but not --enable-debug. 

For the smoketest itself, if it fails the best thing to do is to run it
manually, it's just a document with some macros in it and draws a pretty
table at the end of what failed and what passed. So, after a failed make
dev-install, you still have an install in 
solver/350/unxlng*/installation

run the soffice from there, turn off macro security with
options-security-macros-low and manually open the smoketestdoc.sxw in
smoketestdoc/unxlng*/bin and click the start button and see what
happens.

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] tree open for gnumake hacking again ...

2011-07-26 Thread Matúš Kukan

Hi Michael, Bjoern, all

On 25 July 2011 13:34, Michael Meeks michael.me...@novell.com wrote:
 Hi Bjoern,

        First - this is great work :-) thanks for pulling this all together.

I agree, thanks.

        Matus - have you backed your work up as git format-patch output before
 trying to get git to re-sync them to master ? :-) And of course, I'm
 looking forward to your seeing work there: what module are you working
 on currently ?

Well, there are more. Is it bad idea to push more than one at the same time?
But nothing is ready now. Almost in every module is something I can't deal with.
Some questions: (maybe not all necessary, I will then try to learn and
decide more myself)

First: I can use templates from solenv/gbuild/templates? Asking mainly
because of license part of file.

Do we need for each module or even library FOO_DLLPUBLIC? Or I can
just use SAL_DLLPUBLIC_EXPORT.

What to do with libraries?
Can I break things on other platforms and somebody else will fix that?
or should I really try to not.
In basctl there was: IF WNT SHL1STDLIBS+= $(SHELLLIB)
(SHELLLIB=-lgdi32 -lshell32 -ladvapi32 -lcomdlg32)
So I should add all of them (but I don't think all are really used) or
just nothing and somebody will add the right one ?

Can I also change names of libraries?
-Name = SPECIAL_NAME(animcore);
+   Name = LIBNAME(animcore);
And because of things like
-SHL1IMPLIB= i$(TARGET) I should add something to RepositoryFixes?
And RepositoryFixes has section about WNT which has two parts but
there are common things mentioned twice. Maybe we could reorganize
that.

Is postprocess/rebase/coffbase.txt used? Do I need to change also that?

What to do with unused files or whole directories? remove or igore or
ask each time?

I've seen somewhere .IF $(L10N_framework)==. Is the same variable
present in gbuild?

Last important: In scaddins there were idl files processed:
http://opengrok.libreoffice.org/xref/calc/scaddins/source/analysis/makefile.mk#125
Is it possible to add them into offapi or somewhere?
But I was able to use generated hpp files just with adding:
-I$(realpath $(WORKDIR)/UnoApiHeaders/offapi) \
gb_Library_add_api,analysis,offapi was not enough, not sure why and
how it works.

Finally: Is there any preferred log message we want to use?

Thanks,
Matus

PS: What is the right place for this kind of questions? (to know in
the future, hopefully not /dev/null, I can try to ask less)
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Preparing announcement of the 3.4.2 release

2011-07-26 Thread Cor Nouws


Caolán McNamara wrote (26-07-11 10:57)

On Tue, 2011-07-26 at 00:10 +0200, Cor Nouws wrote:



Caolán McNamara wrote (25-07-11 13:27)

On Mon, 2011-07-25 at 02:18 +0200, Cor Nouws wrote:

  Still, there are some issues that I would have to advice my
customers about (in my work providing professional support for
enterprises), since they could have effect on their specific work.


If you wish to have a enterprise-ready or enterprise-ready concept,
you then need to have an objective set of criteria that defines what
that is. A check-list of features, bugs, or something. Ideally something
which could then be coded into a automated regression test, and make the
whole thing completely moot by cutting off at the knees the possibility
of regression/changes happening of becoming non-enterprise ready.


Sounds interesting to have that, but would very difficult too: what to
include, and what not, etc etc.


My point is just that; I don't know where the enterprise-ready term
wandered in as a meme,


   As explained in my initial mail, the term came up in the discussion 
around the 3.4.0 release. Since we say that a point-zero release 
definitely is not to be used in enterprise environments, that also hold 
the expectation that we can advise a later version as such.



and if it is to be used as an argument for
release blocking, schedule changes, criteria for release, argument for
defining one version as stable and another not, etc. then surely it has
to be accompanied by an objective test.


   If you see it as exact science: yes. But I do not see labelling a 
version as 'enterprise ready' as that.



The smoketest.sxw macro using test is a possible model for scripting up
some high-level test cases, e.g. there's been a bit of foo around mail
merge. It should be possible without any super-dooper development
knowledge to knock up a mail merge (non-email) test based on the basic
database smoketest section of that. That'd give an objective enterprise
mail-merge requirements pass test for example.


   Well, that should be attractive for part of the users at least!


   From the open issues in #35673, IMO some should be looked at (*)  by
enterprises, when preparing the upgrade, though some of them are present
in 3.3.x too, I guess. Will try to have a closer look at that last point
(3.3.x  3.4.x) tomorrow (or the day after). But can only do that on
Ubuntu, not on Mac or Windows...

Regards,
Cor

*) I would advise data-source connection plus mail merge in general,
plus 36631, 39447, 37015, 37024, 37030, 37487, 37620. 38542, 38595, 38745.


There's the tangled-up concept of blessing 3.3.X as enterprise-ready and
3.4.X as not. So if an above bug exist in 3.3.X as well as 3.4.Y, then
it presumably isn't relevant as a basis in selecting one LibreOffice
version over another or as a blocking criteria for the next version,
right ?.


   Yes, that is the logic behind it.
   The other side is, that 3.4.x offers much new and improvements to, 
that can well outweigh then some particular 3.4 bugs. And since that can 
easily be an individual choice, it can never be exact science drawing a 
sharp line. But based on current information, I would say 3.4.2 can be 
considered by most enterprise users.


Regards,

--
 - Cor
 - http://nl.libreoffice.org

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [REVIEWED] nss/moz: Add Linux 3.0 profile

Hi Thomas,

On Mon, 2011-07-25 at 19:42 +0200, Thomas Arnhold wrote:
 An additional comment: Problem without this fix is, that you won't be 
 able to compile Libreoffice (3.4) on a plattform with newest kernel. I 
 think this means it's a blocker.

Hey ho - we've already tagged rc3 of 3.4.2 so I think it'll need to be
put into 3.4.3 (out next month).

I've pushed it to libreoffice-3-4 :-)

Thanks !

Michael.

-- 
 michael.me...@novell.com  , Pseudo Engineer, itinerant idiot


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] LO Custom properties

Hi Swagat,

On Tue, 2011-07-26 at 11:45 +0530, swagat sharma wrote:
 Thank you for the support.
 Now I am getting build errors. I have downloaded the all the tarballs
 of libreoffice 3.3.2.2.

Oh - goodness; 3.3.2.2 is a horribly old code-base; also building from
tar-balls is really not recommended.

IMHO we need to provide a way for people to download the git
repositories in a way that they can understand; apparently using 'git
clone' is too hard for most.

Swagat - did you try cloning from git by using the http mirrors ?
[ perhaps we should default to that on the web-site or be more
explicit ? ]:

git clone http://anongit.freedesktop.org/git/libreoffice/bootstrap.git/

It would be great to find out how you ended up building from archives
of something so old Swagat - can you help us understand your thinking so
we can improve the docs ?

 I have added all the dependencies by running 
 sudo apt-get build-dep libreoffice

Great :-)

 from solver... failed Fetching dependencies for module postprocess
 from solver... failed Fetching dependencies for module packimages from

This looks like you don't have the 'postprocess' source archive
downloaded and inside src/ - or at least that unpacking has failed
somehow.

Without all the code you'll struggle to build it.

But of course, I'd really like to try to address your trouble with git
- Olivier was suffering the same thing some few days ago and I'm sure
its a common problem (but fewer are brave enough to ask perhaps) :-)

Thanks,

Michael.

-- 
 michael.me...@novell.com  , Pseudo Engineer, itinerant idiot


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] tree open for gnumake hacking again ...

2011-07-26 Thread Bjoern Michaelsen

Hi Matúš,
On Tue, 26 Jul 2011 11:18:05 +0200
Matúš Kukan matus.ku...@gmail.com wrote:

First: I can use templates from solenv/gbuild/templates? Asking mainly
because of license part of file.

IANAL, so I will refrain from answering that one (I assume you intend
to change the license).

Do we need for each module or even library FOO_DLLPUBLIC? Or I can
just use SAL_DLLPUBLIC_EXPORT.

Almost. Every library where the header is used to link against the
symbol from another Library. In those cases SAL_DLLPUBLIC_EXPORT would
work on *nix, but not on Windows. SAL_DLLPUBLIC_EXPORT is enough for
plain UNO-libs which just export the UNO factory functions.

see
http://webcache.googleusercontent.com/search?q=cache:1iVDdEXF5bcJ:blogs.oracle.com/GullFOSS/entry/why_some_compilers_suck_more
for details.

What to do with libraries?
Can I break things on other platforms and somebody else will fix that?
or should I really try to not.

At least trying is a good idea ;)

In basctl there was: IF WNT SHL1STDLIBS+= $(SHELLLIB)
(SHELLLIB=-lgdi32 -lshell32 -ladvapi32 -lcomdlg32)
So I should add all of them (but I don't think all are really used) or
just nothing and somebody will add the right one ?

While it is good to remove superfluous linking, I dont think breaking
master for that is a good idea. In case of doubt, file an easyhack
listing the suspicious linking and work through those later (or let
somebody else pick that task up).

Can I also change names of libraries?
-Name = SPECIAL_NAME(animcore);
+ Name = LIBNAME(animcore);

Yes, as long as they are not part of the URE (for UNO-API stability).

And because of things like
-SHL1IMPLIB= i$(TARGET) I should add something to RepositoryFixes?

RepositoryFixes is for all the adjustments where libs are not following
the usual conventions. The idea was, that when we once go binary
incompatible (LibreOffice 4.0 API), we can make RepositoryFixes.mk
empty and have alot more consistent naming (modulo external libs, where
we have no say in the naming). Using RepositoryFixes right now is also
a good idea, as renaming a lib in two build systems is just needless
pain (migrating to gbuild and renaming only there is much easier).

And RepositoryFixes has section about WNT which has two parts but
there are common things mentioned twice. Maybe we could reorganize
that.
Sure, go ahead! RepositoryFixes will always be messy, I am afraid
though. Its part of its nature. (It was once called the bad bank of
the new build system).

What to do with unused files or whole directories? remove or igore or
ask each time?

If it is plain dead code: remove. If it is test code with the hope to
be turned in a unittest: keep, maybe open a EasyHack/Bug about it.

I've seen somewhere .IF $(L10N_framework)==. Is the same variable
present in gbuild?

No.

Last important: In scaddins there were idl files processed:
http://opengrok.libreoffice.org/xref/calc/scaddins/source/analysis/makefile.mk#125
Is it possible to add them into offapi or somewhere?

Possible: sure, if there are no good reasons to keep the separation.

But I was able to use generated hpp files just with adding:
-I$(realpath $(WORKDIR)/UnoApiHeaders/offapi) \
gb_Library_add_api,analysis,offapi was not enough, not sure why and
how it works.

gb_Library_add_api adds an include path to $(OUTDIR)/inc/$(api) and
depends on the Package $(api). So to keep the scaddins stuff separate
you would need to create a Package that generates the headers to
$(OUTDIR)/inc/scaddinsapi for example. See the offapi/UnoApi_offapi.mk
and offapi/Package_offapi_inc.mk files for reference.

Best,

Bjoern

--
https://launchpad.net/~bjoern-michaelsen
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Preparing announcement of the 3.4.2 release

On Tue, 2011-07-26 at 11:23 +0200, Cor Nouws wrote:
 As explained in my initial mail, the term came up in the discussion 
 around the 3.4.0 release. Since we say that a point-zero release 
 definitely is not to be used in enterprise environments, that also hold 
 the expectation that we can advise a later version as such.

If the criteria is a rule of thumb of avoid automatically switching over
to X.Y.Z where Z == 0, then that's fair enough, seeing as that's a sort
of global rule of thumb for software :-)

 If you see it as exact science: yes. But I do not see labelling a 
 version as 'enterprise ready' as that.

Hmm, exact science sounds so much better to me than arbitrary
gut-feeling.

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] LO Custom properties

2011-07-26 Thread swagat sharma

Hi Michael,

Thanks for the reply.
I was not getting the codebase through git because I'm behind proxy. I tried
http as well, but couldn't manage to get the latest codebase.
The one I have was downloaded long back, so I was using it specifically for
my problem of custom properties.

And I read what you suggested to Olivier. But still I am unable to clone the
code. I'll try downloading the latest tarballs though. Because git is almost
next to impossible for me.

Thank You.
Regards,
Swagat

On Tue, Jul 26, 2011 at 3:17 PM, Michael Meeks michael.me...@novell.comwrote:

 Hi Swagat,

 On Tue, 2011-07-26 at 11:45 +0530, swagat sharma wrote:
  Thank you for the support.
  Now I am getting build errors. I have downloaded the all the tarballs
  of libreoffice 3.3.2.2.

 Oh - goodness; 3.3.2.2 is a horribly old code-base; also building
 from
 tar-balls is really not recommended.

IMHO we need to provide a way for people to download the git
 repositories in a way that they can understand; apparently using 'git
 clone' is too hard for most.

Swagat - did you try cloning from git by using the http mirrors ?
 [ perhaps we should default to that on the web-site or be more
 explicit ? ]:

git clone
 http://anongit.freedesktop.org/git/libreoffice/bootstrap.git/

It would be great to find out how you ended up building from
 archives
 of something so old Swagat - can you help us understand your thinking so
 we can improve the docs ?

  I have added all the dependencies by running
  sudo apt-get build-dep libreoffice

 Great :-)

  from solver... failed Fetching dependencies for module postprocess
  from solver... failed Fetching dependencies for module packimages from

 This looks like you don't have the 'postprocess' source archive
 downloaded and inside src/ - or at least that unpacking has failed
 somehow.

Without all the code you'll struggle to build it.

But of course, I'd really like to try to address your trouble with
 git
 - Olivier was suffering the same thing some few days ago and I'm sure
 its a common problem (but fewer are brave enough to ask perhaps) :-)

Thanks,

Michael.

 --
  michael.me...@novell.com  , Pseudo Engineer, itinerant idiot



___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] LO Custom properties

2011-07-26 Thread swagat sharma

Also when i hit git using http,

git clone http://anongit.freedesktop.org/libreoffice/bootstrap libo

I get the following error:

fatal: http://anongit.freedesktop.org/libreoffice/bootstrap/info/refs not
found: did you run git update-server-info on the server?

Has it to do something with the server or problem is from my end?
--
Swagat



On Tue, Jul 26, 2011 at 3:41 PM, swagat sharma swagat.sha...@gmail.comwrote:

 Hi Michael,

 Thanks for the reply.
 I was not getting the codebase through git because I'm behind proxy. I
 tried http as well, but couldn't manage to get the latest codebase.
 The one I have was downloaded long back, so I was using it specifically for
 my problem of custom properties.

 And I read what you suggested to Olivier. But still I am unable to clone
 the code. I'll try downloading the latest tarballs though. Because git is
 almost next to impossible for me.

 Thank You.
 Regards,
 Swagat

 On Tue, Jul 26, 2011 at 3:17 PM, Michael Meeks 
 michael.me...@novell.comwrote:

 Hi Swagat,

 On Tue, 2011-07-26 at 11:45 +0530, swagat sharma wrote:
  Thank you for the support.
  Now I am getting build errors. I have downloaded the all the tarballs
  of libreoffice 3.3.2.2.

 Oh - goodness; 3.3.2.2 is a horribly old code-base; also building
 from
 tar-balls is really not recommended.

IMHO we need to provide a way for people to download the git
 repositories in a way that they can understand; apparently using 'git
 clone' is too hard for most.

Swagat - did you try cloning from git by using the http mirrors ?
 [ perhaps we should default to that on the web-site or be more
 explicit ? ]:

git clone
 http://anongit.freedesktop.org/git/libreoffice/bootstrap.git/

It would be great to find out how you ended up building from
 archives
 of something so old Swagat - can you help us understand your thinking so
 we can improve the docs ?

  I have added all the dependencies by running
  sudo apt-get build-dep libreoffice

 Great :-)

  from solver... failed Fetching dependencies for module postprocess
  from solver... failed Fetching dependencies for module packimages from

 This looks like you don't have the 'postprocess' source archive
 downloaded and inside src/ - or at least that unpacking has failed
 somehow.

Without all the code you'll struggle to build it.

But of course, I'd really like to try to address your trouble with
 git
 - Olivier was suffering the same thing some few days ago and I'm sure
 its a common problem (but fewer are brave enough to ask perhaps) :-)

Thanks,

Michael.

 --
  michael.me...@novell.com  , Pseudo Engineer, itinerant idiot




___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Preparing announcement of the 3.4.2 release

2011-07-26 Thread Christian Lohmaier

On Tue, Jul 26, 2011 at 11:58 AM, Caolán McNamara caol...@redhat.com wrote:
 On Tue, 2011-07-26 at 11:23 +0200, Cor Nouws wrote:
     As explained in my initial mail, the term came up in the discussion
 around the 3.4.0 release. Since we say that a point-zero release
 definitely is not to be used in enterprise environments, that also hold
 the expectation that we can advise a later version as such.

 If the criteria is a rule of thumb of avoid automatically switching over
 to X.Y.Z where Z == 0, then that's fair enough, seeing as that's a sort
 of global rule of thumb for software :-)

But obviously not enough. The bug that made MS-Office flag LO-produced
files as corrupt for example is one of those bugs that prevent use in
business when you have to exchange ms-office formats, thus 3.4.1 still
deserves that warning.

     If you see it as exact science: yes. But I do not see labelling a
 version as 'enterprise ready' as that.

 Hmm, exact science sounds so much better to me than arbitrary
 gut-feeling.

Forget about the term. Think of it as would have been the version
released in OOo times with the known bugs.
That ultimately is what we are compared with after all (and people
already forgot about 2.0, so don't take that as an example)

And now to the decision: How should the release be flagged on the download-page?
* yellow exclamation mark/warning as it is now.
http://www.libreoffice.org/themes/libo/images/warning.png
* blue info / i icon
http://www.libreoffice.org/themes/libo/images/information.png
* green tick/OK icon like 3.3.3
http://www.libreoffice.org/themes/libo/images/tick.png
* other (please specify): __

Or put it more simple:
Do you recommend users to update to 3.4.2 or do you still refer to it
as for early-adaptors/curious users

ciao
Christian
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] SAL_WARN_UNUSED_RESULT

I've added a SAL_WARN_UNUSED_RESULT to sal/types.h which can be used
to decorate functions/methods whose return value *really really* must be
checked. It causes gcc to output a warning if the return type is
ignored. The cool kids build with --enable-werror so it's a build-time
error for them.

Using sparingly. Typically for methods equivalent to read where basing
decisions off data thought to be read, but not, would be a very bad
thing.

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Preparing announcement of the 3.4.2 release

Hi Christian,

On Tue, 2011-07-26 at 13:18 +0200, Christian Lohmaier wrote:
 But obviously not enough. The bug that made MS-Office flag LO-produced
 files as corrupt for example is one of those bugs that prevent use in

Sure sure - the real hope is that (once we are clean with it - still
work to do there) - we can use Microsoft's new binary document format
validator to automatically regression test this. Sadly the thing is not
open-source, so we can't easily use it except on Windows, but ... hey.

 Forget about the term. Think of it as would have been the version
 released in OOo times with the known bugs.

:-) that is hard to judge; people's memory gets rosier and rosier with
the passage of time, there were some pretty hideous bugs we shipped with
I think.

 And now to the decision: How should the release be flagged on the 
 download-page?
 * yellow exclamation mark/warning as it is now.
 http://www.libreoffice.org/themes/libo/images/warning.png

So - not that :-)

 * blue info / i icon
 http://www.libreoffice.org/themes/libo/images/information.png

Looks great to me. I suggest we also put it at the top of the page as
well.

 * green tick/OK icon like 3.3.3
 http://www.libreoffice.org/themes/libo/images/tick.png
 * other (please specify): __

:-) we can keep green for the ultra-stable release I guess.

How does that sound ? :-)

ATB,

Michael.

-- 
 michael.me...@novell.com  , Pseudo Engineer, itinerant idiot


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] LO Custom properties

Hi Swagat,

On Tue, 2011-07-26 at 15:45 +0530, swagat sharma wrote:
 Also when i hit git using http,

Hah - this is my fault; try:

git clone http://anongit.freedesktop.org/git/libreoffice/bootstrap.git libo

I'll update the website; 

 Has it to do something with the server or problem is from my end?

It is the idiot giving you the wrong link ;-)

Thanks !

Michael.

-- 
 michael.me...@novell.com  , Pseudo Engineer, itinerant idiot


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] development summary: year 2011, week 29

2011-07-26 Thread Petr Mladek

Hi,

this time a brief summary of what happened during the 29th week in 2011
on LibreOffice repositories and the living branches:

+ master:LO-3.5 development
+ libreoffice-3-3:   fixes for LO-3.3.4 bug fix release
+ libreoffice-3-4:   fixes for LO-3.4.2 bug fix release
+ libreoffice-3-4-2: final stabilization of the LO-3.4.2 release

There are two logs for each branch:

+ bugfixes-branch-week-year-week.txt lists all commits that 
reference a proper
  bug id from a variety of trackers, i.e. #i... referring to the 
OpenOffice
  issuezilla, fdo# to freedesktop, rhbz# to RedHat bugzilla

+ commit-log-branch-week-year-week.txt lists all relevant commits 
on the actual
  source repositories

Many thanks to all contributors - you make all the difference!


Best Regards,
Petr

nothing this week
+ calc
+ fix broken refresh() from UNO API (and Basic). (fdo#37767) [Kohei Yoshida]
+ filters
+ related correct import of shared formulas (fdo#39023) [Muthu Subramanian]
+ libs-gui
+ halffull width forms need to remain asian (fdo#38095) [Caolán McNamara]
+ writer
+ fix counting the paragraphs, . (fdo#36816) [Jan Holesovsky]
+ calc
+ fix for SetNamedRanges speedup (fdo#35357) [Laurent Godard]
+ fix for database ranges don't work in formulas (fdo#39333) [Markus Mohrhard]
+ fix for set upper limit for second parameter of tinv to 1E10 (fdo#37128) [Markus Mohrhard]
+ prevent double-deletes during removal of pivot tables. (fdo#39236) [Kohei Yoshida]
+ filters
+ related correct import of shared formulas (fdo#39023) [Muthu Subramanian]
+ libs-core
+ fix wrong RTTI baseclass for SfxViewEventHint (fdo#38768) [Thorsten Behrens]
+ on recovery from an autosave file use DefaultFilter, seems to fix (fdo#34805) [Tor Lillqvist]
+ libs-gui
+ add gd_GB (Gaelic, Scottish) locale data (i#117857) [Andras Timar]
+ halffull width forms need to remain asian (fdo#38095) [Caolán McNamara]
+ bootstrap
+ removed some entries (#3096) [Marc-Andre Laverdiere]
+ typo fix in Calc description (fdo#39483) [Andras Timar]
+ calc
+ fix for SetNamedRanges speedup (fdo#35357) [Laurent Godard]
+ fix for database ranges don't work in formulas (fdo#39333) [Markus Mohrhard]
+ fix for set upper limit for second parameter of tinv to 1E10 (fdo#37128) [Markus Mohrhard]
+ prevent double-deletes during removal of pivot tables. (fdo#39236) [Kohei Yoshida]
+ impress
+ bugfix : un-translated template names (part 1/2) (fdo#32895) [Peter Rabi]
+ libs-core
+ bugfix : un-translated template names (part 2/2) (fdo#32895) [Peter Rabi]
+ fix for unable to save protected file without pw (fdo#38561) [Markus Mohrhard]
+ on recovery from an autosave file use DefaultFilter, seems to fix (fdo#34805) [Tor Lillqvist]
+ splash screen fix for multi-head on Linux (fdo#33214) [Josh Heidenreich]
+ typo fix in Calc description (fdo#39483) [Andras Timar]
+ libs-gui
+ add gd_GB (Gaelic, Scottish) locale data (i#117857) [Andras Timar]
+ halffull width forms need to remain asian (fdo#38095) [Caolán McNamara]
+ use fontconfig's detected format when available (rhbz#715549) [Caolán McNamara]
+ writer
+ make text wrapping work in headers/footers too (fdo#39155) [Luboš Luňák]
nothing this week
+ common
+ version 3.4.2.2, tag libreoffice-3.4.2.2 (3.4.2-rc2) [Petr Mladek]
+ bootstrap
+ bump product version to 3.4.2-rc2, release number to 202 [Petr Mladek]
+ distro-install-desktop-integration: do not pack libreoffice-base.desktop twice [Petr Mladek]
+ distro-install-desktop-integration: put $PREFIXDIR/bin/soffice into file list [Petr Mladek]
+ distro-install-desktop-integration: work with normal user [Petr Mladek]
+ distro-install: fix en-US-only installation [Petr Mladek]
+ updated mdds package to 0.5.3. [Kohei Yoshida]
+ calc
+ avoid confusion with our windows api clash prevention [Fridrich Štrba]
+ fix broken refresh() from UNO API (and Basic). (fdo#37767) [Kohei Yoshida]
+ out-of-bounds array access fix. (Thanks to Fridrich too). [Muthu Subramanian]
+ filters
+ related correct import of shared formulas (fdo#39023) [Muthu Subramanian]
+ libs-extern
+ fix Windows build [Fridrich Strba]
+ updated mdds to 0.5.3. [Kohei Yoshida]
+ libs-extern-sys
+ don't let windows.h define min() and max() as macros [Tor Lillqvist]
+ libs-gui
+ fix typo in the last commit [Petr Mladek]
+ halffull width forms need to remain asian (fdo#38095) [Caolán McNamara]
+ translations
+ update translations from Pootle for LibO 3.4.2 rc2 [Andras Timar]
+ writer
+ fix counting the paragraphs, . (fdo#36816) [Jan Holesovsky]
+ starmath: check for edit window when inline editing is enabled [Miklos Vajna]
+ starmath: check for existing edit window [Miklos Vajna]
+ bootstrap
+ distro-install-desktop-integration: do not pack libreoffice-base.desktop twice [Petr

Re: [Libreoffice] [REVIEW] bugfixes which break the string freeze for 3.4.3

2011-07-26 Thread Andras Timar

2011/7/21 Andras Timar tima...@gmail.com:
 Hi,

 2 or 3 weeks ago we agreed on the tech. steering call that we allow
 bugfixes which break the string freeze, providing that translators have
 enough time to catch up before release. So I suggest the following
 patches to be cherry-picked to libreoffice-3-4 branch.


I'd like to add the bugfix for
https://bugs.freedesktop.org/show_bug.cgi?id=32895
Somebody some day marked it as critical.
http://cgit.freedesktop.org/libreoffice/libs-core/commit/?id=abec2797a9657380d8bd6ef7eda1219744f2edd6
http://cgit.freedesktop.org/libreoffice/impress/commit/?id=3ca0cf3b7f79c247e9f25ac7113dd6fbe9cf9d50
http://cgit.freedesktop.org/libreoffice/impress/commit/?id=576591ca3dd1028f644116f81651a1179dc0da84

Thanks,
Andras
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [GSoC 2011][svgexport] weekly report #9

2011-07-26 Thread Thorsten Behrens

Marco wrote:
 == 1 ==
 Changed the handling of slide and shape unique identifiers generation.
 Now the same class used for generating unique identifier by the odp
 format exporter is exploited.
 
Neat :)

 == 2 ==
 For each slide all animations are exported into the svg document:
 the exported animation elements are the same that are created by
 the odp format exporter.
 
Interesting - but maybe easier to have some pre-processed subset
first?

 == 3 ==
 Read SMIL documentation section on transition filters.
 In order to understand how to implement the javascript code for
 performing the exported animations, I started analyzing the slideshow
 animation engine.
 
Hmm - I guess re-implementing larger parts of the animation engine
in JS is out of scope for this project (though of course would be
cool to have) - maybe limiting ourselves to what smil is natively
supported in a browser (e.g.
https://developer.mozilla.org/en/svg/svg_animation_with_smil) is
better?

 I attached a patch set based on the master branch, as it was on
 Monday July 7, that includes all enhancements I implemented until now.
 
Thx a lot, will look into this - please give me a day or two, just
back from vacation. ;)

Cheers,

-- Thorsten


pgpk8wJoxZXWm.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [ANN] LibreOffice 3.4.2 RC3 available

2011-07-26 Thread Thorsten Behrens

Hi *,

for 3.4.2 rc3, we're now uploading builds to a public (but
non-mirrored - so don't spread news too widely!) place, as soon as
they're available. Grab them here:

http://dev-builds.libreoffice.org/pre-releases/

If you've a bit of time, please give them a try  report *critical*
bugs not yet in bugzilla here, so we can incorporate them into the
release notes. Please note that it takes approximately 24 hours to
populate the mirrors, so that's about the time we have to collect
feedback.

The list of fixed bugs in this release is here:

http://dev-builds.libreoffice.org/pre-releases/src/bugfixes-libreoffice-3-4-2-release-3.4.2.3.log

So playing with the areas touched there also greatly appreciated -
and validation that those bugs are really fixed.

Thanks a lot for your help,

-- Thorsten



pgp1loV58zI3Q.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [REVIEW] fix for fdo#37628: pssword button is always disabled

2011-07-26 Thread Kohei Yoshida

On Tue, 2011-07-26 at 01:37 -0400, Kohei Yoshida wrote:

 There is one minor issue.  The dialog that gets launched from the Change
 Password button also contains the optional password input for modifying
 document, and setting a new password there doesn't appear to change the
 modify-document password.  Not sure if this is worth fixing, or trivial
 to fix...

Just to spell out my intention more clearly, if nobody disagrees that
this minor quirk will not cause any issues (after all, right now, the
whole functionality is not working) within the next few days, I will
push Markus' patch with my sign-off, to the 3-4 branch (for 3.4.3), with
this as a known bug.  IMO this is still much better than what we
currently have.

Kohei

-- 
Kohei Yoshida, LibreOffice hacker, Calc
kyosh...@novell.com

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] linking against a .a and not exporting those symbols ?

a) On a vanilla/universal build we build static .as under Linux from
openssl-0.9.8, i.e. libssl.a and libcrypto.o. 
b) liboox links against these .a's. The resulting .so by default exports
the symbols of the .a which it used e.g. 

nm -D workdir/unxlngx6/LinkTarget/Library/libooxlo.so|grep
EVP_MD_CTX_create
00666d00 T EVP_MD_CTX_create

:-(

c) now python's libssl.so, whether system or internal, will link against
the system openssl.

Looking at some debug output here, it appears to me that on email-merge
(which goes out through python) we're screwed when liboox is dlopened
before ssl.so is dlopened, seeing as liboox now exports its copies of
the openssl-0.9.8 symbols and those ones win over the system openssl
libs that the python ssl.so apparently needs to function happily.

Is there a *easy* way to force the symbols of the .a to hidden
visibility at oox link-time ?. Munging the openssl build itself would be
painful, making a version-script would be painful, using objcopy or
something sounds insane.

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [ANN] LibreOffice 3.4.2 RC3 available

2011-07-26 Thread Rainer Bielefeld


Thorsten Behrens schrieb:

Hi *,

for 3.4.2 rc3, we're now uploading builds to a public


Hi,

just added Version LibO 3.4.2 RC3 to Bugzilla so that new bugs can be 
reported if necessary.


CU

Rainer
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [REVIEWED] bugfixes which break the string freeze for 3.4.3

Hi Andras,

On Thu, 2011-07-21 at 12:38 +0200, Andras Timar wrote:
 2 or 3 weeks ago we agreed on the tech. steering call that we allow
 bugfixes which break the string freeze, providing that translators have
 enough time to catch up before release. So I suggest the following
 patches to be cherry-picked to libreoffice-3-4 branch.

I reviewed and pushed all of these to libreoffice-3-4, the only concern
I had was:

 change 2007 XML to 2007/2010 XML in UI strings - fdo#36735
 http://cgit.freedesktop.org/libreoffice/filters/commit/?id=4f418c15105a519bf11229750c3578f53777aaf0

the libreoffice-3-4 had lots of (apparently duplicate and redundant)
'de' variants of filter names, I removed all of those - worth double
checking that that doesn't cause trouble I guess.

Otherwise they all look good. Any chance you can go through the bugs
and add will ship in 3.4.3, thanks or something to them ? :-)

Thanks,

Michael.

-- 
 michael.me...@novell.com  , Pseudo Engineer, itinerant idiot


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [REVIEW] bugfixes which break the string freeze for 3.4.3


On Tue, 2011-07-26 at 15:17 +0200, Andras Timar wrote:
 I'd like to add the bugfix for
 https://bugs.freedesktop.org/show_bug.cgi?id=32895
 Somebody some day marked it as critical.

:-) So - I'm not a huge fan of the code. What does:

+ for( int i = 0; i  nCount; ++i )
+ {
+ if( rString == ResId::toString( (const ResId)SfxResId( 
(sal_uInt16)(nSourceResIds + i) ) ) )
+ {
+ return ResId::toString( (const ResId)SfxResId( (sal_uInt16)(nDestResIds + i) 
) );
+ }
+ }

do ? it looks a tad baroque to me. I also dislike seeing it cut/pasted
into impress as well.

Can we get a cleaner reading patch, that re-uses that in impress ? :-)

ATB,

Michael.

-- 
 michael.me...@novell.com  , Pseudo Engineer, itinerant idiot


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] linking against a .a and not exporting those symbols ?

Hi Caolan,

On Tue, 2011-07-26 at 15:46 +0100, Caolán McNamara wrote:
 a) On a vanilla/universal build we build static .as under Linux from
 openssl-0.9.8, i.e. libssl.a and libcrypto.o. 

Oooh - nice catch :-)

 b) liboox links against these .a's. The resulting .so by default exports
 the symbols of the .a which it used e.g. 
 
 nm -D workdir/unxlngx6/LinkTarget/Library/libooxlo.so|grep
 EVP_MD_CTX_create
 00666d00 T EVP_MD_CTX_create

That is really dumb :-) this is presumably the joy of using visibility
markup instead of map files. 

 Is there a *easy* way to force the symbols of the .a to hidden
 visibility at oox link-time ?. Munging the openssl build itself would be
 painful, making a version-script would be painful, using objcopy or
 something sounds insane.

So some degree of munging the openssl build is necessary I think. If we
can be sure that we are going to link statically to that openssl - then
I believe if we compile it with:

-fvisibility=hidden

Then all of its symbols should disappear when we link them into liboox
- if we're lucky, perhaps some of the code will go too.

Or perhaps I mis-understood ;-) is it easy to inject those flags ?

ATB,

Michael.


-- 
 michael.me...@novell.com  , Pseudo Engineer, itinerant idiot


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [REVIEW] fix for fdo#37628: pssword button is always disabled


On Tue, 2011-07-26 at 10:37 -0400, Kohei Yoshida wrote:
 Just to spell out my intention more clearly, if nobody disagrees that
 this minor quirk will not cause any issues (after all, right now, the
 whole functionality is not working) within the next few days, I will  
 push Markus' patch with my sign-off, to the 3-4 branch (for 3.4.3), with
 this as a known bug.  IMO this is still much better than what we
 currently have.

Sounds reasonable to me. You've done some of that heavy-testing (TM) on
password protection that we know  love :-) ?

Thanks,

Michael.

-- 
 michael.me...@novell.com  , Pseudo Engineer, itinerant idiot


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [REVIEW] fix for fdo#37628: pssword button is always disabled

2011-07-26 Thread Kohei Yoshida

On Tue, 2011-07-26 at 18:25 +0100, Michael Meeks wrote:
 On Tue, 2011-07-26 at 10:37 -0400, Kohei Yoshida wrote:
  Just to spell out my intention more clearly, if nobody disagrees that
  this minor quirk will not cause any issues (after all, right now, the
  whole functionality is not working) within the next few days, I will
  push Markus' patch with my sign-off, to the 3-4 branch (for 3.4.3), with
  this as a known bug.  IMO this is still much better than what we
  currently have.
 
   Sounds reasonable to me. You've done some of that heavy-testing (TM) on
 password protection that we know  love :-) ?

Well, I wouldn't call it a heavy-testing per se.  Just a little more
than what I consider to be a reasonable amount of manual testing given
the nature of the code change.  But I did try to cover a variety of
corner cases as much as I humanly could.

Kohei

-- 
Kohei Yoshida, LibreOffice hacker, Calc
kyosh...@novell.com

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] patch for preserving the table alignment

2011-07-26 Thread Noel Power


On 18/07/11 10:41, Caolán McNamara wrote:

On Fri, 2011-07-15 at 16:35 +0100, Noel Power wrote:

Hi Caolán

could you have a look at this patch
http://cgit.freedesktop.org/libreoffice/writer/commit/?id=95351a519bec2833f5d936c20e3916a4e283b0f6

This should be a nice stroll down memory lane for you as it seems
related to http://openoffice.org/bugzilla/show_bug.cgi?id=1291, yes
issue #1291 !!!

Hmm, well I don't remember the code, I do remember the document itself,
cause its a nasty.

My intent with the SetFmtAttr is apparently to get a floating frame
which shrinks right down the the size of the table contained in it,
reset the positioning of the table so the left of the table is 0 from
the left of the frame and the right 0 from the right of the frame so
that it completely fills it widthwise.

If FULL isn't actually full width of the container, but automatic in
a full-width-of-the-container, but clip-to-the-page-width, sort of way,
that's a pain :-)

lets forget this, I see from trying this on a different machine I get 
the same (good) results as if I used the patch mentioned above e.g. this 
seems to be a font selection problem. I got confused because the word 
previous to the word that appears wrongly on the next line just happened 
to be close to the page margin ( and and also the column width was wrong 
). The change in the patch above allowed the column width to be closer 
to what it is in MSO and the display improved. So, while I do still 
believe there is an issue with the 'FULL' attribute and the fact it 
seems to truncate the table width and and column widths. However.. it 
seems that issue doesn't actually really affect the document in question 
and I suppose it's better I don't mess more with things I don't 
understand well enough :-(


thanks for looking though

Noel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PATCH] Fix parallel build crash in translate_toolkit requiring solenv

2011-07-26 Thread Tomáš Chvátal

--- translate_toolkit/prj/build.lst	2011-07-26 17:21:41.006169229 +0200
+++ translate_toolkit/prj/build.lst	2011-07-26 17:21:52.854170398 +0200
@@ -1,3 +1,3 @@
-trt translate_toolkit   :   PYTHON:python NULL
+trt translate_toolkit   :   solenv PYTHON:python NULL
 trt translate_toolkit   usr1-   all trt_mkout NULL
 trt translate_toolkit   nmake   -   all translate_toolkit NULL
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] DDEInitiate bug

2011-07-26 Thread Knut Olav Bøhmer

On 25 July 2011 18:15, Michael Meeks michael.me...@novell.com wrote:

 Hi Knut,

 On Mon, 2011-07-25 at 17:25 +0200, Knut Olav Bøhmer wrote:
  1. Where can I find the main-loop in LibreOffice

        Ah - that at one level easy - attach a debugger, and watch the
 backtrace for a bit ;-) the main main-loop lives inside vcl/ and handles
 95% of the application code - living under the 'solar mutex'.

Thanx.

  2. How do I start a program (LibreOffice) to trace from Visual Studio
  C++ 2008? (I know how to attach to an exsisting process)

        Sadly I don't know. I imagine you need to avoid the splash binary - and
 run soffice.bin. I would be tempted to remove soffice.exe rename
 soffice.bin - soffice.exe and debug that way.

I found it.
devenv /debugexe program args

I had to cd URE\bin\ because I got an error message about sal3.dll.

Why does we have two binaries?



        Oooh ! and if you can build / debug on windows :-) perhaps you could
 help fix the dumb-ness that we duplicate many megabytes of icons between
 soffice.bin and soffice.exe (?) it requires only a small set of hacks I
 think.

Do you have more information?

--
Knut Olav Bøhmer
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] Please i need your help from Miss Alima.

2011-07-26 Thread Miss Alima Mohameed

新しいメールアドレスをお知らせします新しいメールアドレス： alim_mo1...@yahoo.co.jp

Dearest one, I am Miss Alima Mohameed 21 years old. Please i have the sum of $7 
million that i need your help. I inhreated this money from my late father. 
Please if you will help me reply me back so that i can tell you more about me 
and the money.  

- Miss Alima Mohameed

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [REVIEWED] nss/moz: Add Linux 3.0 profile

2011-07-26 Thread Thomas Arnhold


On 07/26/2011 11:40 AM, Michael Meeks wrote:

Hi Thomas,

On Mon, 2011-07-25 at 19:42 +0200, Thomas Arnhold wrote:

An additional comment: Problem without this fix is, that you won't be
able to compile Libreoffice (3.4) on a plattform with newest kernel. I
think this means it's a blocker.


Hey ho - we've already tagged rc3 of 3.4.2 so I think it'll need to be
put into 3.4.3 (out next month).


Ah ok, didn't see that. Thanks!

Thomas

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs

https://bugs.freedesktop.org/show_bug.cgi?id=35673

Bug 35673 depends on bug 37499, which changed state.

Bug 37499 Summary: Find and Replace Values does not work
https://bugs.freedesktop.org/show_bug.cgi?id=37499

   What|Old Value   |New Value

 Resolution||DUPLICATE
 Status|ASSIGNED|RESOLVED

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs

https://bugs.freedesktop.org/show_bug.cgi?id=35673

Bug 35673 depends on bug 33379, which changed state.

Bug 33379 Summary: Searching in all sheets will not work after using the Find 
toolbar
https://bugs.freedesktop.org/show_bug.cgi?id=33379

   What|Old Value   |New Value

 Resolution||DUPLICATE
 Status|ASSIGNED|RESOLVED

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [REVIEW 3.4] In Calc, after using FindBar, the Search Replace options do not work any more

2011-07-26 Thread Jan Holesovsky

Hi,

https://bugs.freedesktop.org/show_bug.cgi?id=33593

The fix for that was provided in CWS dr78 which is integrated in
LibreOffice, but apparently got lost during a merge - I did not
investigate more if it happened already in Mercurial (when the CWS was
merged into DEV300), or later in git.  The commit that fixes that is
this:

http://cgit.freedesktop.org/libreoffice/calc/commit/?id=16b812b29614d8a321f6cf38a5908fcffc2baf7e

Please cherry-pick to libreoffice-3-4 (1 review), and push :-)

Thank you,
Kendy

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs

https://bugs.freedesktop.org/show_bug.cgi?id=35673

Bug 35673 depends on bug 33593, which changed state.

Bug 33593 Summary: FindBar use breaks the normal 'Find and replace' by columns
https://bugs.freedesktop.org/show_bug.cgi?id=33593

   What|Old Value   |New Value

 Resolution||FIXED
 Status|ASSIGNED|RESOLVED

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [REVIEW 3.4] FindBar silently reuses options from the Search Replace dialog

2011-07-26 Thread Jan Holesovsky

Hi,

https://bugs.freedesktop.org/show_bug.cgi?id=37179

When you set some options in the Seach Replace dialog, these days it
affects how the FindBar operates; ie. when you set 'Whole words only',
then this is reused when you search something using the FindBar too.

This seems to be unexpected - using the FindBar, one should be able to
find everything. The following patch fixes that, it always unsets
'Whole words only', and also 'Match case':

http://cgit.freedesktop.org/libreoffice/libs-core/commit/?id=245f4820d8a982bee1c528cc544bafa96e4582bf

It might be a bit controversial, and that's why I am adding UX advise
list. The thing is that the Search Replace dialog and FindBar are
tightly coupled. Whenever you set an option in the FindBar, it
immediately affects the Search Replace dialog, and vice versa. Try
yourself:

- open FindBar
- open also Search Replace dialog, and show More options
- search _forward_ for something in FindBar
- search _backward_
- see that the searching backwards checked the 'Search Backwards' in the
Search Replace dialog

With the patch I am proposing for cherry-picking to 3.4 (I have pushed
that to master), the options are unset when you use the FindBar, ie. it
resets whatever flags the user has set in the Search Replace dialog
too. This is not easy to fix, so I wonder if you consider this stop-gap
solution bearable for the users?

Thank you,
Kendy

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs

https://bugs.freedesktop.org/show_bug.cgi?id=35673

Bug 35673 depends on bug 37179, which changed state.

Bug 37179 Summary: [UX] options set in FindReplace dialogue, influence how 
Find tool bar works
https://bugs.freedesktop.org/show_bug.cgi?id=37179

   What|Old Value   |New Value

 Resolution||FIXED
 Status|ASSIGNED|RESOLVED

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [REVIEW] nss/moz: Add Linux 3.0 profile

On Mon, Jul 25, 2011 at 12:42 PM, Thomas Arnhold tho...@arnhold.org wrote:
 An additional comment: Problem without this fix is, that you won't be able
 to compile Libreoffice (3.4) on a plattform with newest kernel. I think this
 means it's a blocker.

on a side note: 'build' problem like that are never a 'blocker' to a
binary release.
we should not block a binary release because there are some build
issue on some platform / kernel level, not used to release.

Norbert
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] smoketest fails

2011-07-26 Thread Terrence Enger

On Tue, 2011-07-26 at 10:02 +0100, Caolán McNamara wrote:
 On Mon, 2011-07-25 at 20:46 -0400, Terrence Enger wrote:
  (snip)
  Will the smoketest survive a raised assertion?
 
 Hmm, it depends. In indeed might be failing on a debug-only assertion. I
 do run it in --enable-dbgutil mode but not --enable-debug. 

I have wimped out: reconfigured without --enable-debug and
rebuilt the whole thing; then `make dev-install` worked.

 
 For the smoketest itself, if it fails the best thing to do is to run it
 manually, it's just a document with some macros in it and draws a pretty
 table at the end of what failed and what passed. So, after a failed make
 dev-install, you still have an install in 
 solver/350/unxlng*/installation
 
 run the soffice from there, turn off macro security with
 options-security-macros-low and manually open the smoketestdoc.sxw in
 smoketestdoc/unxlng*/bin and click the start button and see what
 happens.

Neither in the previous build nor in the current does the
Macro Security button bring up the dialog I expect.  Dunno
what I did wrong; just hope it doesn't come back to bite me
later.

Thank you for your help.
Terry.


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] Small Question About sal_* Types

2011-07-26 Thread Marc-André Laverdière

This patch is bringing up a small question:

I thought we were trying to standardize the code to use sal_* types
everywhere...

Can anyone confirm/deny that?

Regards,

Marc-André Laverdière
Software Security Scientist
Innovation Labs, Tata Consultancy Services
Hyderabad, India

On 07/27/2011 06:54 AM, Kohei Yoshida wrote:
  sw/source/filter/html/parcss1.cxx |4 ++--
  sw/source/filter/html/parcss1.hxx |3 +--
  sw/source/filter/html/svxcss1.cxx |   29 +
  sw/source/filter/html/svxcss1.hxx |   13 -
  4 files changed, 16 insertions(+), 33 deletions(-)
 
 New commits:
 commit 04113a04a20d758d914833fc22d646831478bf1b
 Author: Kohei Yoshida kyosh...@novell.com
 Date:   Tue Jul 26 21:18:06 2011 -0400
 
 Replace SV_*_PTRARR with boost::ptr_vector.
 
 diff --git a/sw/source/filter/html/parcss1.cxx 
 b/sw/source/filter/html/parcss1.cxx
 index 5c0955f..3f3ccde 100644
 --- a/sw/source/filter/html/parcss1.cxx
 +++ b/sw/source/filter/html/parcss1.cxx
 @@ -1230,10 +1230,10 @@ sal_Bool CSS1Parser::ParseStyleOption( const String 
 rIn )
  return sal_True;
  }
  
 -sal_Bool CSS1Parser::SelectorParsed( const CSS1Selector * /* pSelector */, 
 sal_Bool /*bFirst*/ )
 +bool CSS1Parser::SelectorParsed( CSS1Selector* /* pSelector */, bool 
 /*bFirst*/ )
  {
  // Selektor loeschen
 -return sal_True;
 +return true;
  }
  
  sal_Bool CSS1Parser::DeclarationParsed( const String /*rProperty*/,
 diff --git a/sw/source/filter/html/parcss1.hxx 
 b/sw/source/filter/html/parcss1.hxx
 index 3a6fa46..5df550b 100644
 --- a/sw/source/filter/html/parcss1.hxx
 +++ b/sw/source/filter/html/parcss1.hxx
 @@ -270,8 +270,7 @@ protected:
  // Deklaration. Wird sal_True zurueckgegeben, wird der Selektor
  // geloscht, sonst nicht.
  // Die Implementierung dieser Methode gibt nur sal_True zuruck.
 -virtual sal_Bool SelectorParsed( const CSS1Selector *pSelector,
 - sal_Bool bFirst );
 +virtual bool SelectorParsed( CSS1Selector* pSelector, bool bFirst );
  
  // Diese Methode wird fuer jede geparsete Property aufgerufen. Wird
  // sal_True zurueckgegeben wird der Selektor geloscht, sonst nicht.
 diff --git a/sw/source/filter/html/svxcss1.cxx 
 b/sw/source/filter/html/svxcss1.cxx
 index 2fcf673..93b5fad 100644
 --- a/sw/source/filter/html/svxcss1.cxx
 +++ b/sw/source/filter/html/svxcss1.cxx
 @@ -71,11 +71,6 @@ typedef void (*FnParseCSS1Prop)( const CSS1Expression 
 *pExpr,
   SvxCSS1PropertyInfo rPropInfo,
   const SvxCSS1Parser rParser );
  
 -SV_IMPL_PTRARR( CSS1Selectors, CSS1Selector* )
 -
 -
 -/*  */
 -
  static CSS1PropertyEnum const aFontSizeTable[] =
  {
  { sCSS1_PV_xx_small, 0   },
 @@ -720,31 +715,26 @@ sal_Bool SvxCSS1Parser::StyleParsed( const CSS1Selector 
 * /*pSelector*/,
  return sal_True;
  }
  
 -sal_Bool SvxCSS1Parser::SelectorParsed( const CSS1Selector *pSelector,
 -sal_Bool bFirst )
 +bool SvxCSS1Parser::SelectorParsed( CSS1Selector *pSelector, bool bFirst )
  {
  if( bFirst )
  {
  OSL_ENSURE( pSheetItemSet, Where is the Item-Set for Style-Sheets? 
 );
  
 -// Dieses ist der erste Selektor einer Rule, also muessen
 -// die bisher geparsten Items auf die Styles verteilt werden
 -//   pSheetPropInfo-CreateBoxItem( *pSheetItemSet, 
 GetDfltBorderDist() );
 -for( sal_uInt16 i=0; iaSelectors.Count(); i++ )
 +for (size_t i = 0; i  aSelectors.size(); ++i)
  {
 -StyleParsed( aSelectors[i], *pSheetItemSet, *pSheetPropInfo );
 +StyleParsed( aSelectors[i], *pSheetItemSet, *pSheetPropInfo );
  }
  pSheetItemSet-ClearItem();
  pSheetPropInfo-Clear();
  
  // und die naechste Rule vorbereiten
 -if( aSelectors.Count() )
 -aSelectors.DeleteAndDestroy( 0, aSelectors.Count() );
 +aSelectors.clear();
  }
  
 -aSelectors.C40_INSERT( CSS1Selector, pSelector, aSelectors.Count() );
 +aSelectors.push_back(pSelector);
  
 -return sal_False; // den Selektor haben wir gespeichert. Loeschen 
 toedlich!
 +return false; // den Selektor haben wir gespeichert. Loeschen toedlich!
  }
  
  
 @@ -840,14 +830,13 @@ sal_Bool SvxCSS1Parser::ParseStyleSheet( const String 
 rIn )
  
  sal_Bool bSuccess = CSS1Parser::ParseStyleSheet( rIn );
  
 -for( sal_uInt16 i=0; iaSelectors.Count(); i++ )
 +for (size_t i = 0; i  aSelectors.size(); ++i)
  {
 -StyleParsed( aSelectors[i], *pSheetItemSet, *pSheetPropInfo );
 +StyleParsed( aSelectors[i], *pSheetItemSet, *pSheetPropInfo );
  }
  
  // und etwas aufrauemen
 -if( aSelectors.Count() )
 -aSelectors.DeleteAndDestroy( 0, aSelectors.Count() );
 +aSelectors.clear();
  pSheetItemSet-ClearItem();
  pSheetPropInfo-Clear();
  
 diff --git

Re: [Libreoffice] [PUSHED][PATCH] fix GNU/kFreeBSD build

On Mon, Jul 25, 2011 at 8:17 AM, Rene Engelhard r...@debian.org wrote:
 Hi,

 3.4.x got a#include sys/prctl.h in sal which isn't available
 on (k9FreeBSD - the GNU/kFreeBSD port is mostly using LINUX though :-)

 Fix:

 --- sal/osl/unx/thread.c-old    2011-07-22 00:16:33.0 +0200
 +++ sal/osl/unx/thread.c        2011-07-22 00:17:41.0 +0200
 @@ -37,7 +37,7 @@
  #include rtl/textenc.h
  #include sal/macros.h

 -#if defined LINUX
 +#if defined LINUX  ! defined __FreeBSD_kernel__
  #include sys/prctl.h
  #ifndef PR_SET_NAME
  #define PR_SET_NAME 15
 @@ -598,7 +598,7 @@
  }

  void SAL_CALL osl_setThreadName(char const * name) {
 -#if defined LINUX
 +#if defined LINUX  ! defined __FreeBSD_kernel__
     if (prctl(PR_SET_NAME, (unsigned long) name, 0, 0, 0) != 0) {
         OSL_TRACE(
             %s prctl(PR_SET_NAME) failed with errno %d, OSL_LOG_PREFIX,

 OK for -3-4?

+1

looks sane to me.
Pushed.

Norbert
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Small Question About sal_* Types

2011/7/26 Marc-André Laverdière marc-an...@atc.tcs.com:
 This patch is bringing up a small question:

 I thought we were trying to standardize the code to use sal_* types
 everywhere...

 Can anyone confirm/deny that?


No, not exactly.
it is actually the intention to use bool/true/false unless that break
the UNO API (and for 4.0 we will make sure that UNO API do suport the
native bool type, so that sal_Bool will be indeed strictly equal to
bool)
the goal is also to get rid of BOOL, but again being careful with uno
interaction: if uno - sal_Bool otherwise bool
(this is particularly tricky when touching the prototype of a virtual
function... as all of the derived virtual of a given function must be
change at once)

Norbert
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Small Question About sal_* Types

2011/7/26 Marc-André Laverdière marc-an...@atc.tcs.com:
 This patch is bringing up a small question:

 I thought we were trying to standardize the code to use sal_* types
 everywhere...

 Can anyone confirm/deny that?


and also, more generally for local variable that have no impact
what-so-ever with UNO interface it is ok to use standard type like
size_t

I _personnaly_ (as-in that is not necessarily a consensus view) think
that sal_* type should be reserved exclusively for UNO interface. and
for stuff that need 'cross-platform' serialization in general. that
would have the merit of drawing attention to these border-zone.
But of course that benefit would require a complete an systematic
review of sal_* usage... which is not practical... so the compromise
is use sal_* for sure in UNO case and serialisation case, but other
than that, let dev be and use sane standard type if they want to.


Norbert
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PUSHED][PATCH] Fix parallel build crash in translate_toolkit requiring solenv