date:20110624


Hi Pedro,

plino wrote (24-06-11 02:03)

Cor Nouws wrote:


Plus - especially with the unfortunate experience from 3.4.0, and to do
something good for users, testers, marketing etc - IMO it is better that
in the end we have three weeks extra, than that we lack three days.
So I would really love to be on the save side ..



Thank you Cor for listening to the users instead of the mighty schedule


Well,  thanks for the complement .. :-)
But of course  ... I don't think that it is the intention of  the 
mighty schedule to hurt anyone or let alone the project :-) - we are 
all learning how this should work best for us. And that definitely will 
change over the months, years...



BTW since only Betas can be installed in parallel with the stable build
under Windows and that was not added to the 3.4.x branch (at least from my
understanding) I guess Windows Beta testers will have to wait for 3.5.x,
right?


Well, I don't see any betas coming for the 3.4.x branch, so whether is 
has been added or not, does not make sense.
I only can point to my favourite page: 
http://wiki.documentfoundation.org/Installing_in_parallel


I hope that helps people to run more versions (early versions) on 
Windows too, so that it give them the opportunity to give feed back in 
an early stage.
(Personal note: I really appreciate that I have not (or only seldom) to 
work with Windows any more. Public drawback: I cannot do serious testing 
there and already find it hard to understand, to follow the items going 
on Windows.)


Cheers,

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

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

Re: [Libreoffice] minutes of tech steering call ...


plino wrote (24-06-11 09:03)

Cor Nouws wrote:


Well, I don't see any betas coming for the 3.4.x branch, so whether is
has been added or not, does not make sense.


Unless TDF is going to adopt the absurd Chrome (and now Firefox) version
model, the next version should be 3.5.0 indeed.


Hmm - apart from your off topic comment on Chrome/FireFox - I see no 
rationale for that.
There is a monthly schedule for bug-fix releases that is very important 
for all kind of users. See http://wiki.documentfoundation.org/ReleasePlan



I guess we (Windows users) will have to wait :)


Wait for what? I don't understand what you are trying to say here.


I only can point to my favourite page:
http://wiki.documentfoundation.org/Installing_in_parallel

I hope that helps people to run more versions (early versions) on
Windows too, so that it give them the opportunity to give feed back in
an early stage.


As I mentioned before, that is useful for a very limited number of Windows
users.


But those that can, should use it and help others...


If TDF wants a significant number of  Windows beta testers that
simply won't do.


And as known, 3.5 betas will install without conflict with the 3.4.x 
installation, so where is the problem?



(Personal note: I really appreciate that I have not (or only seldom) to
work with Windows any more. Public drawback: I cannot do serious testing
there and already find it hard to understand, to follow the items going
on Windows.)


I'm sure more Windows users would be available for serious testing if TDF
took the Windows users more seriously and in proportion to the platform
importance (given the sheer number of users)


I know no evidence that Windows (users) is (are) not taken seriously.
I think it will help if people try more serious to improve on where we 
are, also with QA/testing, rather then complain.


Best,

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

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

Re: [Libreoffice] [PATCH] Fix for fdo#30550 Character count without spaces

2011-06-24 Thread John LeMoyne Castle

Hi Korrawit,

My take is:
-- you (and others) cannot reproduce fdo#37584 (redlined text disappears)
in 3-3 or 3-3-3 because my patch referenced in your original post [OP] is
not in the 3-3 branches.
-- you and others cannot reproduce 'leading quote as word' in your 3-3
build because the patch you submitted with OP has fixed that problem in 3-3
since 2011-06-21. Your OP patch is not yet in 3-3-3 official build so the
leading quote problem still exists there.

A word count problem that may still exist in 3-3(-3) is that the count may
be off when a selection ends in the middle of a word. Given that all of
3-3(-3) is supposed to be stable and the case where selection ends in
mid-word is an edge case (not the common use case of count doc or entire
section)...
I think that your elegant clipping=true fix already in 3-3 is the most that
should go into 3-3-3.

I repeat, *IF* my patch referenced in the OP goes into the 3-3(-3) area then
Cedric's fix should follow immediately. (That patch was intended as a fix
of the selection ends in mid-word issue and code cleanup.)

I think that the two patches given in your last message are already in
3-3(-3).
The Thomas Lange patch
http://cgit.freedesktop.org/libreoffice/libs-gui/commit/?id=cb9aa439fbb0a85829b1e61e292b1553512b0cb5
is already in 3.3(-3) and this is the patch that removed the deep copy at
the SwScanner level so that the deep copy in Cedric's fix is now required at
the outer CountWords (sp?) level. From following branch lines in QGit I
think this tl patch (dated 2010-12-08) got merged into 3-4 in late winter
~Feb 2011 and that's when redlining went south in 3-4. Or so I think after
following the link you posted and searching 'word count' and switching
branches and scrolling past hundreds of commits in QGit and ...

I hope this is clearer than my last post. I am *NOT* an expert in
configuration or even in word count but I have been studying the question of
'what is where? and when did it get there?' with an eye for both qa and dev.
I have tried to expose my thinking here in the hopes that it may help you
and that I will get corrected as needed, *not* because it is expert opinion.

Again, I hope this helps,
LeMoyne

--
View this message in context:
http://nabble.documentfoundation.org/PATCH-Fix-for-fdo-30550-Character-count-without-spaces-tp3092043p3103177.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] minutes of tech steering call ...


Cor Nouws wrote (24-06-11 09:21)


I know no evidence that Windows (users) is (are) not taken seriously.
I think it will help if people try more serious to improve on where we
are, also with QA/testing, rather then complain.


Hmm, while slicing an excellent mango (hmm ;-) , my thoughts drifted to 
this subject again (for the last time today!).
I have the feeling of fighting some acid rain, when replying to your 
mail Pedro. And indeed, I can imagine that this has been caused by the 
words used by some developers, in a much older thread. Some are so much 
convinced of what they think, and also bring that across in such a way, 
that it easily gives the impression that other opinions are moot or so. 
Which is a sad situation :-(

That might be an explanation for the feeling that I get with your mail.
But the again, probably I must have had written, expressed this before. 
So after acknowledging, my advise would still be the same: understand 
and improve ;-)


Have a nice day :-)
Cor

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

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

Re: [Libreoffice] minutes of tech steering call ...

2011-06-24 Thread John LeMoyne Castle

Michael @ OP - awesome set of notes! 

Cor @ 
 I only can point to my favourite page: 
 http://wiki.documentfoundation.org/Installing_in_parallel

Even though I have two build configs (3.4 and master), OOo3.2 and the 3.4
release installed, I have been frustrated in doing full triage/testing and
other qa by no access to 3.3  -  I can see why that is your favorite page
and now I can see why you (and others) are able to test issues in any
version.  

Thank you so much!  
LeMoyne

--
View this message in context: 
http://nabble.documentfoundation.org/minutes-of-tech-steering-call-tp3100951p3103230.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Potential Problems for LibreOffice on Mac with impending release of Lion OSX

Hi Alex,

On Fri, 2011-06-24 at 06:59 +0200, Alexander Thurgood wrote:
 I know this is likely to irk folks a little here

Ah not at all ;-) its nice to hear of up-coming problems before they
arrive.

 http://neowiki.neooffice.org/index.php/Lion_Upgrade_Issues

So the API deprecation issues are not so urgent, I hope Apple stays
backwards compatible here - so the first two items hopefully are not a
major issue for this release.

 Well, of course, we all know that Neo is more heavily dependent on Java
 for the implementation of some of its functionality, and thus may be

Yep - wrt. the other two issues: menubar and native widgets - it would
be fantastic if someone from QA could install a developer preview and
see what the story is: do we indeed have these bugs ?

HTH,

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] Potential Problems for LibreOffice on Mac with impending release of Lion OSX

2011-06-24 Thread Alexander Thurgood

Le 24/06/11 10:17, Michael Meeks a écrit :

Hi Michael,


   So the API deprecation issues are not so urgent, I hope Apple stays
 backwards compatible here - so the first two items hopefully are not a
 major issue for this release.

Hopefully :-))



Yep - wrt. the other two issues: menubar and native widgets - it would
 be fantastic if someone from QA could install a developer preview and
 see what the story is: do we indeed have these bugs ?
 

Well I have just been on the Apple Developer Connection site, but I was
refused download of the Developer Review, no doubt because I haven't
forked out the 100 USD/year that you need to pay in order to have access
to all of that yummy Mac developer goodness that Apple likes to shower
its customers with ;-) Having said that, it might be worth while for the
Foundation to use some of its monies to pay out for such a subscription
and make it available to one of the devs who does the regular Mac build.
Obviously, cost/benefit analysis etc, would be a good idea beforehand :-))

Alex

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

Re: [Libreoffice] minutes of tech steering call ...


On Fri, 2011-06-24 at 01:11 +0200, Cor Nouws wrote:
  * Posting TSC minutes on the blog ...
  + Norbert: wording is very terse, not enough context, not suitable
for mass public consumption.
  + Suggestion: needs to be expanded, and made more comprehensible,
someone who wants that can/should do it.
 
 Short highlights  + link to mail archive might be useful too..

Certainly - anyone is welcome to do the work and come up with that
content - the minutes are public; if someone writes a nice summary, I'm
happy to quickly sanity check it before release too.

HTH,

Michael.

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

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

[Libreoffice] LibreOffice / valgrind detection ...

Hi Julian,

On Thu, 2011-06-23 at 11:59 +0200, Julian Seward wrote:
 Oh, I think I missed answering the simple question here.  Thusly:

Ah indeed :-) and I missed that in the headers.

   #include valgrind.h
 
   bool running_under_valgrind (void)
   {
  return (RUNNING_ON_VALGRIND) ? true : false;
   }
 
 Is that what you want, or did you mean something different?

Yes; that was what I wanted, sorry I couldn't find it in the header
somehow - though it is clearly there ;-) 

Reading more carefully, it seems the #undef block at the bottom of a
recent svn's valgrind.h doesn't match the similar undef at the top - is
that intended ? [seems to miss eg. the s390 piece].

I wonder too whether (since the weak symbol thing doesn't seem to work
so well) whether exporting a type-safe function-pointer-table via a
single get-me-the-fn-table-or-null type method might be more readable;
though of course you'd still need the trap-doors in stubs behind that I
guess.

 You might want to cache the result of RUNNING_ON_VALGRIND
 so that the common (production) case overhead is reduced to
 a load and conditional branch, rather than the strange sequence
 of stores and rotates generated by the macro. 

Yep; we'd do it once just at the beginning.

Caolan - what do you think of doing:

diff --git a/sal/rtl/source/alloc_global.c b/sal/rtl/source/alloc_global.c
index fb95e83..4923428 100644
--- a/sal/rtl/source/alloc_global.c
+++ b/sal/rtl/source/alloc_global.c
@@ -35,6 +35,7 @@
 #include stdio.h
 
 #if !defined(FORCE_SYSALLOC)
+#include valgrind.h
 
 typedef enum { AMode_CUSTOM, AMode_SYSTEM, AMode_UNSET } AllocMode;
 
@@ -46,7 +47,13 @@ static void determine_alloc_mode(void)
 if (alloc_mode != AMode_UNSET)
 return;
 
-if (getenv(G_SLICE) != NULL)
+if (RUNNING_ON_VALGRIND)
+{
+putenv (G_SLICE=1);
+fprintf(stderr, LibreOffice: running under valgrind detected.\n);
+alloc_mode = AMode_SYSTEM;
+}
+else if (getenv(G_SLICE) != NULL)
 {
 alloc_mode = AMode_SYSTEM;
 fprintf(stderr, LibreOffice: Using system memory allocator.\n);


And dropping the 'memcheck.h' and 'valgrind.h' headers straight into
sal - they are BSD licensed anyway, then we could loose a lot of that
fluff in configure.ac / makefile around valgrind (?) perhaps we'd want a
environment variable for TRY_TO_VALGRIND_INTERNAL_ALLOCATORS too ;-)

That might help the QA guys automagically generate better valgrind
traces with less effort ?

ATB,

Michael.

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

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

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

2011-06-24 Thread bugzilla-daemon

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

Bug 35673 depends on bug 38590, which changed state.

Bug 38590 Summary: Possible fd-leak with speadsheet containing Chart objects
https://bugs.freedesktop.org/show_bug.cgi?id=38590

   What|Old Value   |New Value

 Resolution||FIXED
 Status|NEW |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] [ANNOUNCE] libreoffice-3.4.1.3 tag created (3.4.1-rc3)

2011-06-24 Thread Petr Mladek

Hi,

https://bugs.freedesktop.org/show_bug.cgi?id=38590 has been accepted as
a blocker. It has been fixed this morning and we created the
libreoffice-3.4.1.3 tag for 3.4.1-rc3 release.

The corresponding official builds will be available in the beginning of
the following week. If no blocker is found, it will be marked as final
by the end of the following week.

See the attached list of changes against 3.4.1-rc2.

You might switch your current 3-4 source tree to it using:

./g fetch --tags
./g checkout -b tag-libreoffice-3.4.1.3 libreoffice-3.4.1.3

See also the schedule at 
http://wiki.documentfoundation.org/ReleasePlan#3.4_release
and release criteria at http://wiki.documentfoundation.org/Release_Criteria


Many thanks for all contributions!

Best Regards,
Petr
+ calc
+ revert Fixed undisplayed calc page and header / footer borders (fdo#38590, fdo#36688) [Petr Mladek]
+ common
+ version 3.4.1.3, tag libreoffice-3.4.1.3 (3.4.1-rc3) [Petr Mladek]
+ bootstrap
+ bump product version to 3.4.1-rc3, release number to 103 [Petr Mladek]
+ disable the online update for the release. [Jan Holesovsky]
+ calc
+ revert Fixed undisplayed calc page and header / footer borders (fdo#38590, fdo#36688) [Petr Mladek]
+ translations
+ typo in hu [Andras Timar]
+ update translations from Pootle for LibO 3.4.1 rc2 [Andras Timar]
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Blockers for 3.4.1 release - central bug ID ?

2011-06-24 Thread Alexander Thurgood

Le 24/06/11 12:23, Cor Nouws a écrit :

Hi Cor, all,


 I thought we had the rationale of one issue for 3.4.x (#35673) most
 annoying bugs, where the candidates for fixing in one of the next ...
 bug-fix releases are gathered ...


You're right of course, but I just wanted to check that another
Über-issue hadn't been created in between, I will add it to #35673.


Alex



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

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

2011-06-24 Thread bugzilla-daemon

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

Alex Thurgood alex.thurg...@gmail.com changed:

   What|Removed |Added

 Depends on||38623

--- Comment #157 from Alex Thurgood alex.thurg...@gmail.com 2011-06-24 
04:57:38 PDT ---
Nominating 38623 - regression over 3.3.3, nasty crash on opening Word doc.

Alex

-- 
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] [SOLVED] Debug-mode getline-using sal unittest crashes, triggered by _GLIBCXX_DEBUG

On Thu, 2011-06-23 at 19:57 +0100, serv serva wrote:
 Your theory was right, I commented out all that concerns _GLIBCXX_DEBUG in :
 - sal/inc/unxgcc.mk
 - sal/gbuild/platform/unxgcc.mk
 
 Then remove sal/unxlng* and build again.
 Everything is ok.

Excellent, so...

We don't want anyone else to get hung up on that, so ideally we want a
bug filed against your distros libstdc++ about this. So could you see if
the test-case at
http://lists.apple.com/archives/cocoa-dev/2009/Sep/msg01096.html

when compiled with g++ -D_GLIBCXX_DEBUG crashes when you do
echo hello world | ./a.out and file a bug against whatever version of
libstdc++ you have about it.

C.
//compile with g++ -D_GLIBCXX_DEBUG
//see http://lists.apple.com/archives/cocoa-dev/2009/Sep/msg01096.html
//see http://lists.freedesktop.org/archives/libreoffice/2011-June/014191.html

#include iostream
#include string

int main (int argc, char * const argv[])
{
   std::string line;
   std::getline(std::cin, line);
   std::cout  Line is: \  line  \  std::endl;
   return 0;
}
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [REVIEW] add --backtrace, --strace, and --valgring option to soffice wrapper

On Wed, 2011-06-22 at 15:27 +0200, Petr Mladek wrote:
 Hi,
 
 Kendy suggested to add --backtrace, --strace, and --valgring to the
 soffice wrapper. It will make it easier for users to provide the debug
 info.
 
 I have realized it in master, see
 http://cgit.freedesktop.org/libreoffice/libs-core/commit/?id=dfe7581607e67ced5ff0fce9973b6f2fcd3dee62

typo in script: --vagrind, fix pushed to master

C.

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

Re: [Libreoffice] [PUSHED]PATCH] Update help fdo#31652

On Thu, 2011-06-23 at 18:46 +0200, Andras Timar wrote:
 Sorry, this breaks the string freeze in 3-3, 3-4 and 3-4-1. Translators
 expect that strings don't change in stable brances. I would say, it is
 easier for everyone, if we change strings in master only.

Seems nuts to me that its better to keep translations of incorrect help
content in sync than to have at least some of them right, but *shrug*,
whatever's easiest to manage.

C.

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

Re: [Libreoffice] LibreOffice / valgrind detection ...

2011-06-24 Thread Julian Seward


   Reading more carefully, it seems the #undef block at the bottom of a
 recent svn's valgrind.h doesn't match the similar undef at the top - is
 that intended ? [seems to miss eg. the s390 piece].

oh, our snafu.  will fix.

   Caolan - what do you think of doing:
 [...]

 +if (RUNNING_ON_VALGRIND)
 +{
 +putenv (G_SLICE=1);
 +fprintf(stderr, LibreOffice: running under valgrind
 detected.\n); +alloc_mode = AMode_SYSTEM;
 +}

Doesn't that give a potentially bad effect, that any lib-gnome-goop
library allocations that happen before that point will get done by
gnome's custom allocator, but it will subsequently get freed by the
system allocator?  Sounds like the express train to Segfault City Central.

Even if that doesn't fail .. wouldn't we wind up with a bunch of allocs
(prior to this point) that Memcheck doesn't know about, and a bunch
that it does?  That don't sound good.

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

[Libreoffice] [REVIEW] fdo#38623

i.e. crash in layout of a specific .doc
https://bugs.freedesktop.org/show_bug.cgi?id=38623

fix:
http://cgit.freedesktop.org/libreoffice/writer/commit/?id=fd768eb1d726e63a9c9cad0b245d1603eba6b5d9

in master. Need extra acks for 3-4, or additional ones for
3-4-whatever-we-are-now

C.

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

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

2011-06-24 Thread bugzilla-daemon

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

Bug 35673 depends on bug 38623, which changed state.

Bug 38623 Summary: CRASH, FILEOPEN - opening MS word processor document causes 
crash
https://bugs.freedesktop.org/show_bug.cgi?id=38623

   What|Old Value   |New Value

 Status|NEW |ASSIGNED
 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] fdo#38623

2011-06-24 Thread Alexander Thurgood

Le 24/06/11 15:34, Caolán McNamara a écrit :

Hi Caolàn,

 i.e. crash in layout of a specific .doc
 https://bugs.freedesktop.org/show_bug.cgi?id=38623
 
 fix:
 http://cgit.freedesktop.org/libreoffice/writer/commit/?id=fd768eb1d726e63a9c9cad0b245d1603eba6b5d9

Quicker than you can say jackrabbit, thanks.

Alex

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

Re: [Libreoffice] [GSoC][performance] patches for prefixing

Hi Matus,

On Wed, 2011-06-22 at 09:57 +0200, Matúš Kukan wrote:
 I'm sending some patches to allow prefixes for components and also
 I've done prefixing for some components. It hope it will work also for
 others. I've done make from clean. But when I tried to add prefix
 for comphelper's component, make check was unsuccessful.

Fun - perhaps there is a mapfile problem - whereby we are punching a
hole through the map file for the old component_getFactory name, and not
for the new foo_component_getFactory; at least I added a unit test to
cppuhelper and struggled with this for a bit myself ;-)

Anyhow - I've merged your core patches, reverted the ABI break in
cppuhelper and done that another way (with a polymorphic impl. instead
of a default argument type). I attach a 'redo.diff' - this doesn't
really solve the problem I think, we need to add a 'prefix' parameter to
this framework macro so we can specify that as being different for each
component I think - can you hack that up ?

It looks good to me, though 'make check' no longer passes - but then,
perhaps it didn't beforehand (hard to say without a far-too-substantial
wait). I'm running some more smoketests before pushing all the new
prefix updates around the place.

 And about merging libraries. Maybe we should do this in new branch.
 Not in master.

Right - I think perhaps we'll need to do some preparatory work to get
more gnumake usage out there. Also, of course we need to tweak all the
libraries that we plan to merge into one to have prefixed component
factories :-)

HTH,

Michael.

-- 
 michael.me...@novell.com  , Pseudo Engineer, itinerant idiot
diff --git a/framework/util/fwk.component b/framework/util/fwk.component
index c460ecb..139dd06 100755
--- a/framework/util/fwk.component
+++ b/framework/util/fwk.component
@@ -26,7 +26,7 @@
 *
 **--
 
-component loader=com.sun.star.loader.SharedLibrary
+component loader=com.sun.star.loader.SharedLibrary prefix=fw
 xmlns=http://openoffice.org/2010/uno-components;
   implementation name=com.sun.star.comp.frame.SessionListener
 service name=com.sun.star.frame.SessionListener/
diff --git a/framework/util/fwl.component b/framework/util/fwl.component
index 99c5ca7..5708efa 100755
--- a/framework/util/fwl.component
+++ b/framework/util/fwl.component
@@ -26,7 +26,7 @@
 *
 **--
 
-component loader=com.sun.star.loader.SharedLibrary
+component loader=com.sun.star.loader.SharedLibrary prefix=fw
 xmlns=http://openoffice.org/2010/uno-components;
   implementation name=com.sum.star.comp.framework.LanguageSelectionMenuController
 service name=com.sun.star.frame.PopupMenuController/
diff --git a/framework/util/fwm.component b/framework/util/fwm.component
index 624249f..58ddc91 100755
--- a/framework/util/fwm.component
+++ b/framework/util/fwm.component
@@ -26,7 +26,7 @@
 *
 **--
 
-component loader=com.sun.star.loader.SharedLibrary
+component loader=com.sun.star.loader.SharedLibrary prefix=fw
 xmlns=http://openoffice.org/2010/uno-components;
   implementation name=com.sun.star.comp.framework.HelpOnStartup
 service name=com.sun.star.task.Job/
diff --git a/framework/inc/macros/debug/registration.hxx b/framework/inc/macros/debug/registration.hxx
index bbb328e..a199fcf 100644
--- a/framework/inc/macros/debug/registration.hxx
+++ b/framework/inc/macros/debug/registration.hxx
@@ -57,7 +57,7 @@
 #define	LOG_REGISTRATION_GETFACTORY( SINFOTEXT )			\
 {\
 ::rtl::OStringBuffer sOut( 1024 );			\
-sOut.append( component_getFactory(): );	\
+sOut.append( fw_component_getFactory(): );	\
 sOut.append( SINFOTEXT );	\
 WRITE_LOGFILE( LOGFILE_REGISTRATION, sOut.makeStringAndClear() )			\
 }
diff --git a/framework/inc/macros/registration.hxx b/framework/inc/macros/registration.hxx
index f5510af..0de6a2e 100644
--- a/framework/inc/macros/registration.hxx
+++ b/framework/inc/macros/registration.hxx
@@ -57,8 +57,8 @@
 Please use follow public macros only!
 
 IFFACTORY( CLASS )			= use it as parameter for COMPONENT_GETFACTORY( IFFACTORIES )
-COMPONENTGETIMPLEMENTATIONENVIRONMENT		= use it to define exported function component_getImplementationEnvironment()
-COMPONENTGETFACTORY( IFFACTORIES )			= use it to define exported function component_getFactory()
+COMPONENTGETIMPLEMENTATIONENVIRONMENT		= use it to define exported function fw_component_getImplementationEnvironment()
+COMPONENTGETFACTORY( IFFACTORIES )			= use it to define exported function fw_component_getFactory()

[Libreoffice] [PUSHED] Re: [REVIEW] fdo#38623

2011-06-24 Thread Jan Holesovsky

Hi Caolan,

Caolán McNamara píše v Pá 24. 06. 2011 v 14:34 +0100:

 i.e. crash in layout of a specific .doc
 https://bugs.freedesktop.org/show_bug.cgi?id=38623
 
 fix:
 http://cgit.freedesktop.org/libreoffice/writer/commit/?id=fd768eb1d726e63a9c9cad0b245d1603eba6b5d9
 
 in master. Need extra acks for 3-4, or additional ones for
 3-4-whatever-we-are-now

Thank you for that, signed-off  cherry-picked to libreoffice-3-4, and
closed the bug.

Regards,
Kendy

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

[Libreoffice] [Hackfest] Ohio Linux Fest

2011-06-24 Thread drew

On Thu, 2011-06-23 at 15:36 -0400, drew wrote:
 Just a quick note.
 
 Have sent off the formal request to the OHLF organizers..will keep folks
 posted as specifics firm up.
 

Hi,

Quick note.

Exchanged a few emails with one of the other organizers of the show.

No final yes - but looks good.

One slight change is looking likely - moving this from Friday the 9th to
Saturday the 10th. 

I think that would be a plus.

//drew

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

Re: [Libreoffice] [GSoC] library merging


On Fri, 2011-06-24 at 10:45 +0100, Caolán McNamara wrote:
 On Fri, 2011-06-24 at 11:36 +0200, Matúš Kukan wrote:
  Any thoughts welcomed.
 
 I'm a little confused as to what the goal/purpose of all the stoc
 hackery and library merging is all about.

Hey - let me explain some more; (I had hoped Matus would be at the TSC
to explain but ...), anyhow, for the wider benefit:

* having fixed symbol names like component_doFoo means we cannot
  easily chop and change and move components from one library to
  another.
= ergo adding a custom prefix=foo and having
   foo_component_doFoo methods means we can move code
   around more easily.

* this also (potentially) enables some more easy static linking
  of everything into one-big-lump

* linking much more of our code together allows much more
  aggressive link-time / whole-program optimisation / inlineing
  etc.

* hopefully with such work in-place, we can cross-compile to
  Windows without taking a big performance hit from gcc vs. MSVC

* if we can link much more code into fewer objects, hopefully
  this reduces our seek cost on first-start pagein, and also
  starts to make code re-ordering much more useful / interesting

* if we can link much more into one lump, perhaps we can kill a
  lot of the symbols we currently use to chain one large pile of
  cruft to the one next-door :-)

So - Matus' work just starts that. Of course, we could do all of this
by simply creating a single, big component_getFactory type method and
renaming the children, and calling them as dependents from there and so
on but ... that is perhaps less flexible.

The question then is, which libraries should we be merging, which
underlies Matus' (sadly without a .txt extension so the attachment
cannot easily be viewed) 'libraries' list showing which of our libraries
are loaded by all five components, and thus which could/should be merged
into a single big firefox-style library [ at least that is the idea ].

Thoughts much appreciated. Clearly having them gnu-makeised as we go is
rather a key win, from the perspective of being able to build the object
files all in one throw in tail_build, and then link them as we see fit
later (?).

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] [GSOC][PATCH] Multiline inputbar

2011-06-24 Thread Noel Power


Hi Anurag
On 22/06/11 15:51, Anurag Jain wrote:

Hi Noel,

Resending the patch again along with the source files here.
as mentioned on Wed on iRC I pushed the patch to the feature branch. I 
had hoped to see the latest changes you made to correct the control size 
problem that I identified that was preventing your new control from 
being displayed before reviewing the patch further, I am not *that* 
familiar with libreoffice ui bits and pieces and was hoping to have 
something to run to test. Additionally on IRC it wasn't clear how you 
now were calcuating the the ScInputBarGroup width, I'd like to have seen 
the code for that


Anyway some comments on what is there so far, I think the 
ScInputBarGroup is taking shape, clearly it's very rough at this stage 
(  understandable since you had problems getting it to show ). One thing 
I would suggest here to
a) change the name of ScTextWindow to something like ScMultiLineTxtWin ( 
or any other suitable name )

b) restore the orig ScTextWindow class

I suggest this because it is intended when the gsoc code is initially 
integrated that it be configurable and for this reason it probably makes 
sense to preserve the original ScTextWindow class and distinguish it 
from your new implementation. This will make maintenance easier.
Then next thing to concentrate on is getting the multi-line textbox 
functionality to work and to make that behaviour switchable. I believe 
Kohei suggested adding a button to the ScInputBarGroup window. So, you 
need to be able to detect the button click and switch the state of the 
bIsMultiLine flag that you have already added ( presumably for this 
purpose ) please do a grep for PushButton  SetClickHdl in sc for sample 
code for handling the button.
When you get a button click you will need to resize your 
InputBarGroupbox window based on the new state of the bIsMultiLine flag 
and of course increase the height in multiples of the calculated height 
of a single line. e.g. in Multiline mode the ScInputGroupBox height 
should be some multiple of the calculated singleline height ( maybe 10 
as a default ? ) Of course the size of the ScMultiLineTxtWin (let's call 
it that for now but please rename it as you wish ) window needs to also 
be adjusted and everything resized. I would do this first before 
worrying about scrollbar behaviour.


regards
Noel


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

Re: [Libreoffice] [REVIEW] add --backtrace, --strace, and --valgring option to soffice wrapper

2011-06-24 Thread Petr Mladek

Caolán McNamara píše v Pá 24. 06. 2011 v 14:00 +0100:
 On Wed, 2011-06-22 at 15:27 +0200, Petr Mladek wrote:
  + writing output into valgrind.log instead of stdout; it should be 
easier for users
 
 Hmm, checking this here it appears that each subprocess spawned off
 overwrites/mangles the valgrind.log, see man valgrind. So --log-file as
 it stands doesn't work with the --trace-children-yes

I tried to solve it by redirecting the standard and the error output,
see
http://cgit.freedesktop.org/libreoffice/libs-core/commit/?id=20726f2d9584d8c969d5d762ad8238803f6d

Another solution would be let all tools to write on standard and error
outputs but we would loss the simplicity for normal users.

Finally, thanks for fixing the typo. I actually did not test running the
tool via the VALGRIND variable :-(


Best Regards,
Petr

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

Re: [Libreoffice] [PUSHED] Fix build by updating to new api

2011-06-24 Thread Jan Holesovsky

Hi Luke,

Luke Symes píše v Pá 24. 06. 2011 v 17:27 +1200:

I'm interested in working on gui stuff, especially the custom
animation workflow. I'm going to look at the reason for the slowdown
with changing animation properties; something to do with the presets
list taking ages to generate each time...
I'm interested in making libreoffice more 'native' on linux, although
that seems like it might take a while to understand how to improve the
situation there :)
Would it be good to go to the UX list for ideas/discussion do you
think?

This is cool! I have a list of my favorite UI annoyances that I'd like
to fix over time, but of course, I you are interested in taking some of
them over, that would be great :-) - I have proposed them as GSoC task
previously:

http://wiki.documentfoundation.org/Development/Gsoc/Ideas#UI_cleanup

Actually, I have already fixed one of those (Less intrusive look of the
toolbar button that leads to the hidden tools menu -
http://artax.karlin.mff.cuni.cz/~kendy/blog/archives/monthly/2011-06.html#2011-06-14T10_29_17.htm).

The easy ones include eg. the use mouse wheel over the zoom tool, or
blinking of the Start centre buttons, the more complicated would be the
re-think of what to do with our disappearing and reappearing toolbars
when you scroll a document in Writer. [But you seem to be interested
more in Impress, right?]

Wrt. the UX list, we have libreoffice-ux-adv...@lists.freedesktop.org .
If you want to hack on something UX-related, just propose your solution
there, and you'll get the feedback quickly :-)

All the best,
Kendy

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

[Libreoffice] Tarball fetching broken with --with-system-libs

2011-06-24 Thread Lubos Lunak


 Hello,

 could somebody who understands tarball fetching review the attached patch? I 
did make clean, pulled, configured with --with-systems-libs and during make I 
get:

dmake:  Error: -- 
`./unxlngx6.pro/misc/4bb835ea2225c8f5f6c2b2e63d25993c-libvisio-0.0.1.unpack' 
not found, and can't be made

 This seems to be a result of b246ad5ff409a7a51091c0b3c1fe50e0eb468fc4 in 
bootstrap and libvisio version update since my last build. The attached patch 
fixes the problem for me, but since I have no idea why those checks were 
there, I'm just checking.

-- 
 Lubos Lunak
 l.lu...@suse.cz
diff --git a/configure.in b/configure.in
index 217d8df..bda4ece 100755
--- a/configure.in
+++ b/configure.in
@@ -1959,8 +1959,7 @@ if test -z $TARFILE_LOCATION; then
 fi
 AC_SUBST(TARFILE_LOCATION)
 
-if test z$enable_fetch_external != zno \
-test -z $with_system_libs -a $with_system_jars != no; then
+if test z$enable_fetch_external != zno ; then
DO_FETCH_TARBALLS=YES
 fi
 AC_SUBST(DO_FETCH_TARBALLS)
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Couldn't debug fdo#30550 (WAS: Build failed in sfx2 in -3-3 branch)

2011-06-24 Thread Korrawit Pruegsanusak

Hello Petr, *
Thanks again and again!

Best Regards,
--
Korrawit Pruegsanusak
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [GSoC] library merging

On Fri, 2011-06-24 at 15:16 +0100, Michael Meeks wrote:
   Hey - let me explain some more; (I had hoped Matus would be at the TSC
 to explain but ...), anyhow, for the wider benefit:
 
   * having fixed symbol names like component_doFoo means we cannot
 easily chop and change and move components from one library to
 another.
   = ergo adding a custom prefix=foo and having
  foo_component_doFoo methods means we can move code
  around more easily.

Hmm, yeah, the passive uno registration stuff as it stood didn't really
help a lot here does it. That just removed the need to dlopen libs at
registration time to find out what's in it, component_getFactory was
still the required entry point to actually get at them them.

I never really bothered to look at
component_getImplementationEnvironment but I wonder if that could be
elided in 90% of cases. i.e. that all merged libraries are going to have
the same body there anyway.

So instead of a prefix tag that's always added to both
component_getImplementationEnvironment and component_getFactory, always
use component_getImplementationEnvironment, and just drop the duplicates
of those when libs are merged, and then instead of dlsyming prefix +
component_getFactory just, say, rename the current prefix thing to
be getFactory name which defaults to component_getFactory and dlsym
the getFactory name. Though I suppose that makes it a little more
difficult to undo a merge trivially.

   The question then is, which libraries should we be merging, which
 underlies Matus' (sadly without a .txt extension so the attachment
 cannot easily be viewed) 'libraries' list showing which of our libraries
 are loaded by all five components, and thus which could/should be merged
 into a single big firefox-style library [ at least that is the idea ].

Well, as a low-hanging fruit I suggest that all the *.uno.so in the list
that appear in the ure/lib install dir get merged together anyway. Those
are all typically very small, too small really, libraries.
libi18npaperlo.so and libi18nisolang1gcc3.so are too small too really.

I wonder though about the developer rebuild-time hit if the bigger ones
are linked into a mega-lib, sw and sc and svx are pretty big
thumb-twiddlers when linking ?

Some of these things are of course dlopened outside the uno-code path as
well, e.g. libdesktop_detectorlo IIRC

C.

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

Re: [Libreoffice] [PATCH] impress: after adding a new animation, scroll down to it in the list.

2011-06-24 Thread Radek Doulik

Hi Luke,

thanks for your patch!

On Fri, 2011-06-24 at 17:38 +1200, Luke Symes wrote:
 Hi there,
 
 
 This is a one-line patch to impress to make the animation list scroll
 down to show a newly added animation. Previously we didn't scroll the
 list at all.

I think better way of doing it might be

diff --git a/sd/source/ui/animations/CustomAnimationList.cxx
b/sd/source/ui/animations/CustomAnimationList.cxx
index cfb8463..f7d5b2b 100644
--- a/sd/source/ui/animations/CustomAnimationList.cxx
+++ b/sd/source/ui/animations/CustomAnimationList.cxx
@@ -533,6 +533,7 @@ void
CustomAnimationList::select( CustomAnimationEffectPtr pEffect, bool
bSelect
 if( pEntry-getEffect() == pEffect )
 {
 Select( pEntry, bSelect );
+MakeVisible( pEntry );
 break;
 }
 pEntry = static_cast CustomAnimationListEntry* (Next( pEntry
));


At least I am not reaching the part you modified when adding custom
animation thru custom animation pane (using the add button and custom
animation dialog). If we move it to the loop, it will be reached always
when selecting an entry - the select method is called recursively when
adding new pEntry in:

if( !pEntry  bSelect )
{
append( pEffect );
select( pEffect );
}

I wonder how do you reach that part of code?

Cheers
Radek


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

Re: [Libreoffice] [PATCH] [PUSHED:master] Fix for Bug 37484 - On any animation change, current position in list is lost

2011-06-24 Thread Radek Doulik

On Wed, 2011-06-22 at 05:03 -0600, Tor Lillqvist wrote:
 Thanks. If these work fine on Linux (i.e. X11), they can't be awfully
 broken on other windowing systems either, I hope. Pushed to master.

I run into a crash on startup in that part. I quickly fixed it, but it
might be better if you check that it plays nicely with your new code. Or
maybe make the ScrollToAbsPos not crash when called with unexpected
values, -1 for example.

It was happening when starting impress without loading presentation. I
guess you checked it only while loading presentation containing custom
animations?

Cheers
Radek

the quick fix:

commit 4be38046a5c2576b5b97ac47f7c0ea17444524ea
Author: Radek Doulik r...@novell.com
Date:   Fri Jun 24 17:10:22 2011 +0200

quick fix to avoid crash on impress's start

diff --git a/sd/source/ui/animations/CustomAnimationList.cxx
b/sd/source/ui/animations/CustomAnimationList.cxx
index 196fc53..cfb8463 100644
--- a/sd/source/ui/animations/CustomAnimationList.cxx
+++ b/sd/source/ui/animations/CustomAnimationList.cxx
@@ -742,7 +742,7 @@ void CustomAnimationList::update()
 // An entry has moved down out of view; scroll down one.
 ScrollToAbsPos( nFirstVis + 1 );
 }
-else
+else if ( nFirstVis != -1 )
 {
 // The selection is still in view, or it hasn't moved.
 ScrollToAbsPos( nFirstVis );



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

[Libreoffice] external LinLibertineG not available

2011-06-24 Thread Christian Lippka


I'm doing a windows build, fetching

881af2b7dca9b8259abbca00bbbc004d-LinLibertineG-20110101.zip

failed, looks like domain www.numbertext.org is expired.

Christian.

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

Re: [Libreoffice] [GSoC] library merging


On Fri, 2011-06-24 at 16:08 +0100, Caolán McNamara wrote:
 Hmm, yeah, the passive uno registration stuff as it stood didn't really
 help a lot here does it. That just removed the need to dlopen libs at
 registration time to find out what's in it, component_getFactory was
 still the required entry point to actually get at them them.

Right.

 I never really bothered to look at
 component_getImplementationEnvironment but I wonder if that could be
 elided in 90% of cases. i.e. that all merged libraries are going to have
 the same body there anyway.

AFAICS it is a total waste of breath :-) Matus - this is another task
worth looking at - can you do an audit of all
component_getImplementationEnvironment calls and see if any do anything
interesting ? [ and what the default is if it is not there ] :-) one fun
cleanup may be just binning all of them.

 So instead of a prefix tag that's always added to both
..
 Though I suppose that makes it a little more difficult to undo
 a merge trivially.

Quite; and:

 Well, as a low-hanging fruit I suggest that all the *.uno.so in the list
 that appear in the ure/lib install dir get merged together anyway. Those
 are all typically very small, too small really, libraries.
 libi18npaperlo.so and libi18nisolang1gcc3.so are too small too really.

Sounds good to me, particularly if they are un-conditionally loaded.

 I wonder though about the developer rebuild-time hit if the
 bigger ones are linked into a mega-lib, sw and sc and svx
 are pretty big thumb-twiddlers when linking ?

I guess one of the nice things about the new prefix is that (in theory
a least), we can have a release-build configuration where we link
*world* into one enormous library, with an hour-long link-time-
optimize / link / thrash phase - while keeping something like the
existing setup for faster developer re-linking, and do that from the
same object files.

 Some of these things are of course dlopened outside the uno-cod
 path as well, e.g. libdesktop_detectorlo IIRC

Right - and often to avoid or detect run-time dependencies; Matus -
what that means is that we can't really drop the separate libvcl
plugins, since each depends on libraries that we want to pull in at
run-time.

HTH,

Michael.

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


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

[Libreoffice] error output running from command line


Hi *,

Running 340rc2 / 333rc1 from command line, I sometimes get error 
reports. If I get it well, it is when I have placed images in a Writer doc.


Example 1:
cono@cono-tm-new:~$ LibO341rc2/libreoffice3.4/program/soffice
(soffice:1979): Gdk-WARNING **: XID collision, trouble ahead
[...]
(soffice:1979): Gdk-WARNING **: GdkWindow 0x3a77f17 unexpectedly destroyed
(soffice:1979): Gdk-WARNING **: XID collision, trouble ahead
[...]


Example 2:
cono@cono-tm-new:~$ LibO333rc1/libreoffice/program/soffice
(soffice:2213): Gdk-CRITICAL **: IA__gdk_window_get_events: assertion 
'GDK_IS_WINDOW (window)' failed
(soffice:2213): Glib-GObject-CRITICAL **: g_object_ref: assertion 
'G_IS_OBJECT (object)' failed
(soffice:2213): Glib-GObject-CRITICAL **: g_object_unref: assertion 
'G_IS_OBJECT (object)' failed

[...]

Running Ubuntu 11:04

Submit an issue?
How to make that useful?

Thanks,

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

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

Re: [Libreoffice] [tdf-discuss] [Hackfest] Ohio Linux Fest

2011-06-24 Thread Carl Symons

On Fri, Jun 24, 2011 at 7:13 AM, drew d...@baseanswers.com wrote:
 On Thu, 2011-06-23 at 15:36 -0400, drew wrote:
 Just a quick note.

 Have sent off the formal request to the OHLF organizers..will keep folks
 posted as specifics firm up.


 Hi,

 Quick note.

 Exchanged a few emails with one of the other organizers of the show.

 No final yes - but looks good.

 One slight change is looking likely - moving this from Friday the 9th to
 Saturday the 10th.

 I think that would be a plus.

 //drew


I agree that the 10th would be better. I am not familiar with OHLF
attendance, but Saturday at LFNW is by far the big day. There have
been some Friday events, but they are not so well attended.

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

Re: [Libreoffice] external LinLibertineG not available

2011-06-24 Thread Németh László

Hi,

I'm very sorry the problem, it was not intended. (In fact, I paid also
the next month for the domain, but my hosting provider/registrator
forgot to renewal the domain or inform me about the expiration. I
hope, it will be fixed soon, especially because I plan to release a
new version with a lot of important improvement (eg. combining
diacritics).

Temporarily here is the package:

http://www.math.u-szeged.hu/~bognarv/881af2b7dca9b8259abbca00bbbc004d-LinLibertineG-20110101.zip

Thanks for your mail,
László

2011/6/24 Christian Lippka c...@lippka.com:
 I'm doing a windows build, fetching

 881af2b7dca9b8259abbca00bbbc004d-LinLibertineG-20110101.zip

 failed, looks like domain www.numbertext.org is expired.

 Christian.

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

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

Re: [Libreoffice] external LinLibertineG not available

2011-06-24 Thread Németh László

Hi,

The problem was fixed by my provider.

Regards,
László

2011/6/24 Németh László nemeth.la...@gmail.com:
 Hi,

 I'm very sorry the problem, it was not intended. (In fact, I paid also
 the next month for the domain, but my hosting provider/registrator
 forgot to renewal the domain or inform me about the expiration. I
 hope, it will be fixed soon, especially because I plan to release a
 new version with a lot of important improvement (eg. combining
 diacritics).

 Temporarily here is the package:

 http://www.math.u-szeged.hu/~bognarv/881af2b7dca9b8259abbca00bbbc004d-LinLibertineG-20110101.zip

 Thanks for your mail,
 László

 2011/6/24 Christian Lippka c...@lippka.com:
 I'm doing a windows build, fetching

 881af2b7dca9b8259abbca00bbbc004d-LinLibertineG-20110101.zip

 failed, looks like domain www.numbertext.org is expired.

 Christian.

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


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

Re: [Libreoffice] [SOLVED] Debug-mode getline-using sal unittest crashes, triggered by _GLIBCXX_DEBUG

2011-06-24 Thread Julien Nabet


Le 24/06/2011 14:19, Caolán McNamara a écrit :

On Thu, 2011-06-23 at 19:57 +0100, serv serva wrote:

Your theory was right, I commented out all that concerns _GLIBCXX_DEBUG in :
- sal/inc/unxgcc.mk
- sal/gbuild/platform/unxgcc.mk

Then remove sal/unxlng* and build again.
Everything is ok.

Excellent, so...

We don't want anyone else to get hung up on that, so ideally we want a
bug filed against your distros libstdc++ about this. So could you see if
the test-case at
http://lists.apple.com/archives/cocoa-dev/2009/Sep/msg01096.html

when compiled with g++ -D_GLIBCXX_DEBUG crashes when you do
echo hello world | ./a.out and file a bug against whatever version of
libstdc++ you have about it.

Hello,

Badfully, I don't reproduce the pb with this file.
I made a rm -rf sal/unxlng* with the unchanged (so with GLIBCXX_DEBUG) 
files :

- sal/inc/unxgcc.mk
- sal/gbuild/platform/unxgcc.mk
and there's still the pb.


But when i use  the test file, nothing as you can see below :

$ g++ -D_GLIBCXX_DEBUG attachment.cxx
$ echo hello world | ./a.out
Line is: hello world

$ cat attachment.cxx
//compile with g++ -D_GLIBCXX_DEBUG
//see http://lists.apple.com/archives/cocoa-dev/2009/Sep/msg01096.html
//see 
http://lists.freedesktop.org/archives/libreoffice/2011-June/014191.html


#include iostream
#include string

int main (int argc, char * const argv[])
{
   std::string line;
   std::getline(std::cin, line);
   std::cout  Line is: \  line  \  std::endl;
   return 0;
}

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

Re: [Libreoffice] Tarball fetching broken with --with-system-libs

2011-06-24 Thread Jan Holesovsky

Hi Lubos,

Lubos Lunak píše v Pá 24. 06. 2011 v 16:40 +0200:

  could somebody who understands tarball fetching review the attached patch? I 
 did make clean, pulled, configured with --with-systems-libs and during make I 
 get:
 
 dmake:  Error: -- 
 `./unxlngx6.pro/misc/4bb835ea2225c8f5f6c2b2e63d25993c-libvisio-0.0.1.unpack' 
 not found, and can't be made
 
  This seems to be a result of b246ad5ff409a7a51091c0b3c1fe50e0eb468fc4 in 
 bootstrap and libvisio version update since my last build. The attached patch 
 fixes the problem for me, but since I have no idea why those checks were 
 there, I'm just checking.

The check for ' test -z $with_system_libs -a $with_system_jars !=
no' has been there from the very introduction of DO_FETCH_TARBALLS,
and after b246ad5ff409a7a51091c0b3c1fe50e0eb468fc4 seems wrong to me; so
please go ahead, and push your change :-)

Thank you,
Kendy

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

Re: [Libreoffice] [REVIEW 3.4] Disable online update


Jan Holesovsky wrote (24-06-11 11:52)

If we do an additional build, let's disable the online update - there is
something rotten around XPath that makes LibreOffice looking like always
up-to-date, even though it should report a new version.


Ah, that at least explains why we had so much trouble with it in the 
past :-\


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

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

Re: [Libreoffice] minutes of tech steering call ...