Re: [Libreoffice] problems with scp2
On Jul 31, 2011, at 12:32 AM, Bjoern Michaelsen wrote: On Sat, 30 Jul 2011 10:45:03 +0200 Stephan Bergmann stephan.bergmann.secondary-gM/ye1e23mwn+bqq9rb...@public.gmane.org wrote: No. While linking wants the unversioned libFOO.so (thanks to passing them as -lFOO to the linker), running the unit tests wants the versioned libFOO.so.3 (thanks to the SONAME). Im glad to have told Matúš to put this on the ML, it deserves a more thorough investigation. ;) Well, since gbuild as of now has no notion of versioned SONAMES or filenames(1), I assume the Matúš-migrated salhelper module would create a lib with name libuno_salhelpergcc3.so and no explicit SONAME (since no --soname switches are used). readelf -a| grep SONAME on it would return nothing. Given that, every library linked against that lib (in a BFS) would link against the (fallback) unversioned filename, and that would work fine in the build and out of it. Hi Björn. What do you mean with BFS here? Generally, existing code (i.e., extensions) having a recorded dependency against libuno_salhelpergcc3.so.3 will no longer work if they do not find a file with that exact name. (Or do you imply that, on Linux, the dynamic loader special cases this and would still be happy if it only found some libuno_salhelpergcc3.so? I am not aware of that, and it would be Linux-only, probably not working on e.g. Solaris.) Using such a lib in the solver should not be a problem for the build. However, even if it would be easily possible to add the SONAME upon installation, it would be quite an ugly hack. So does it hurt to have unversioned/missing SONAMEs in the installation? I strongly suggest to add SONAME support to gbuild. For one, it is common ELF practice to use external versioning (i.e., via a trailing .so.X at a library's filename/SONAME) to discriminate among incompatible versions of a library. And for another, we already use that external versioning scheme for the libraries that comprise the URE interface, and I see no reason to change that (causing incompatibility with existing code). Well, if we would symlink in the installation as before, old external clients wouldnt be hurt, as they still find their libs. But newly created external libraries would be created linking against an unversioned/missing SONAME (because they would fall back to the resolved filename). Would that hurt? Right now, from a practical point of view, I guess: no. No linux distro supports installing different versions of the product, let alone from different major releases. So if I am not mistaken, the benefit of versioned SONAMEs -- while being the Right Thing(tm) -- are mostly theoretical as of now. Of course, the magic is all in the words as of now -- requirements might change. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] problems with scp2
Hi Stephan, On Mon, 1 Aug 2011 08:42:21 +0200 Stephan Bergmann stephan.bergmann.second...@googlemail.com wrote: What do you mean with BFS here? build from scratch Generally, existing code (i.e., extensions) having a recorded dependency against libuno_salhelpergcc3.so.3 will no longer work if they do not find a file with that exact name. Right, but extensions would not be run against the solver, but against an installation (where I suggested one needs to keep symlinks anyway). The suggestion was: - keep no SONAME or libuno_salhelpergcc3.so (unversioned) in solver and installation - still generate symlinks in installation so that in a installation (but not in solver), both libuno_salhelpergcc3.so and libuno_salhelpergcc3.so.3 are visible. (Or do you imply that, on Linux, the dynamic loader special cases this and would still be happy if it only found some libuno_salhelpergcc3.so? I am not aware of that, and it would be Linux-only, probably not working on e.g. Solaris.) no. I strongly suggest to add SONAME support to gbuild. For one, it is common ELF practice to use external versioning (i.e., via a trailing .so.X at a library's filename/SONAME) to discriminate among incompatible versions of a library. I came to the same conclusion: While the other scenario might work, it will end up like a evil genius dialog in the end: But why did you do this? -- Because I can!. Thats not a good reason in itself. But maybe even the symlinks do not need to be manually declared and created in solver. To follow the conventions of the host system calling ldconfig -n $OUTDIR/lib after installing and before using the lib should be enough. However, experimenting with this does not seem to create an unversioned symlink. I created a dir with a few random libs: libxml2.so.2.7.8 (SONAME:libxml2.so.2) libcairo.so.2.11000.2 (SONAME: libcairo.so.2) libuno_salhelpergcc3.so.3 (SONAME: libuno_salhelpergcc3.so.3) and got: libuno_salhelpergcc3.so.3 - libuno_salhelpergcc3.so.3 libxml2.so.2 - libxml2.so.2.7.8 libcairo.so.2 - libcairo.so.2.11000.2 so it does not create symlinks for the unversioned so (although those are quite common in /usr/lib here). For fun I move the lib libuno_salhelpergcc3.so.3 to libuno_salhelpergcc3.so and got: libuno_salhelpergcc3.so.3 - libuno_salhelpergcc3.so (changed) libxml2.so.2 - libxml2.so.2.7.8 libcairo.so.2 - libcairo.so.2.11000.2 Which does not make me happy either. So I guess we need to create the symlinks (at least the unversioned ones) manually indeed. Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Blocker Bug for 3.4.2 release
Hi, 2011/7/30 Rainer Bielefeld libreoff...@bielefeldundbuss.de: I decided to rate Bug 39510 - CRASH closing document with footnotes https://bugs.freedesktop.org/show_bug.cgi?id=39510 as a blocker, because LibO currently is unusable for scientific texts or other ones with many footnotes, see my Comment 7 in the bug. I know it's rather late and I do not know whether everyone will rate that one like me, but may be you can check severity of that bug? I am sharing Rainers opinion. Is there any decision on this? Volker -- Volker Merschmann Member of The Document Foundation http://www.documentfoundation.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Blocker Bug for 3.4.2 release
Rainer Bielefeld píše v So 30. 07. 2011 v 11:01 +0200: Hello, I decided to rate Bug 39510 - CRASH closing document with footnotes https://bugs.freedesktop.org/show_bug.cgi?id=39510 as a blocker, because LibO currently is unusable for scientific texts or other ones with many footnotes, see my Comment 7 in the bug. I know it's rather late and I do not know whether everyone will rate that one like me, but may be you can check severity of that bug? I see the crash also with LO-3.4.0-final on SLED11-SP1-x86_64 = it is an older bug. Nobody escalated it earlier, so it can't block the 3.4.2 release. BTW: The crash happens when people close the document. It usually happens when people close the whole application = It is ugly, it might block saving other opened documents but it should not cause that much harm in most cases. So I would be in doubt to consider it as a blocker anyway. I am sorry to say this but affected users need to wait on more month for LO-3.4.3 release. In the meantime, I have mentioned it at http://wiki.documentfoundation.org/ReleaseNotes/3.4#Most_annoying_bugs_in_3.4.0 Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Java 7 - not recognised in LO in Windows Vista
On Sat, 2011-07-30 at 13:57 +0200, Francois Tigeot wrote: These problems were detected only 5 days before the official Java 7 release, so Oracle had no time to fix those bugs They knew before the release date their product was broken and they still shipped it. Unbelievable. We do the same - checkout the release notes, and 'most annoying' bugs list[1] :-) [ help fixing them much appreciated ] but on the other hand we can re-spin our release rather more quickly ;-) so I'd hope that we would fix this sort of thing. Instead of taking steps to enable the use of Java 7, we may want to actively discourage it for now. Sounds reasonable. ATB, Michael. [1] - https://bugs.freedesktop.org/show_bug.cgi?id=35673 dependencies -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] fix Kabyle_Algeria [kab_DZ] absent currency symbol
On Fri, 2011-07-29 at 20:12 +0200, Eike Rathke wrote: * In locale data replaceTo must not be empty if replaceFrom isn't. + Also added check to locale data compiler to prevent this in future. * Fixed a currency format's group separator. * Marked LANGUAGE_USER_KABYLE (0x0659) obsolete as LANGUAGE_TAMAZIGHT_LATIN Looks nice :-) it makes me wonder if we want this as a low-risk bug-fix in 3.4.3 (?). 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] Java 7 - not recognised in LO in Windows Vista
On Mon, Aug 01, 2011 at 10:08:24AM +0100, Michael Meeks wrote: On Sat, 2011-07-30 at 13:57 +0200, Francois Tigeot wrote: These problems were detected only 5 days before the official Java 7 release, so Oracle had no time to fix those bugs They knew before the release date their product was broken and they still shipped it. Unbelievable. We do the same - checkout the release notes, and 'most annoying' bugs Not for such severe ones. I hope a bug corrupting documents for 90% of users would be considered a release blocker ;) Cheers, -- Francois Tigeot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Ridiculous xml?
Hi Ryan, On Sat, 2011-07-30 at 12:04 +0100, Ryan Jendoubi wrote: That was from content.xml. Interestingly, their definition is different when I save the document out as .fodt: Hmm; that seems quite odd :-) fodt should intercept the same ODF export filter at a very low level, certainly below the semantic understanding of styles. I suspect (as you suggested) the problem is produced by an import filter - so, finding a very small test case: perhaps just a hello world document, and chasing through the style creation process perhaps in the debugger to see where that new style is created would be a good approach. Then again, if you can produce it just by typing hello world we may have something more interesting - can you ? and we should prolly have a bug filed to collect all your great research. All the best, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Git hangs?
Hello Any git command i isssue does not gives me a response anymore. e.g. git clone git://anongit.freedesktop.org/libreoffice/bootstrap libo or ./g pull -r is there somenthing going in the git repo? Thanks -- Olivier Hallot Founder and Steering Commitee Member The Document Foundation ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Blocker Bug for 3.4.2 release
On Mon, 2011-08-01 at 10:54 +0200, Petr Mladek wrote: BTW: The crash happens when people close the document. It usually happens when people close the whole application = It is ugly, We've seen a number of similar bugs in recent times, some of which have been quite long standing; there is some thought that the XCloseListener impl. and 'notifyClosing' may not be being called correctly these days. That of course, may well trigger a number of issues - eg. one worked around in basic's sb.cxx in recent times, potentially redlining related crashes on close etc. Might be nice if someone had time to dig into / disprove that hypothesis. Then again, it's always nice to fix latent bugs in various shutdown paths ;-) 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] possible error in Wiki list of fixed bugs
Hello Nino,
The source is [1]: I simply merged (copy-pasted) the individual RC's to
one page.
But I agree that the issue number doesn't refer to the correct issue and
we should ask the developer list (done) for better and more accurate
information.
Cheers,
Leif Lodahl
[1] http://wiki.documentfoundation.org/Releases/3.4.2/RC1#calc
Den 01-08-2011 12:38, Nino skrev:
Leif,
you were the first one who put this list[1] on the wiki, so may I ask you how
you generated the list?
Reason: there seems to be a wrong issue number under calc:
* always set column offset to 0 {{fdo|38456}} [Katarina Machalkova] [2]
Bug does not seem to have to do with column offset or with LibO at all
Thanks.
Or should I have asked this better on the dev list?
Nino
[1] http://wiki.documentfoundation.org/Releases/3.4.2_info_about_fixes
[2] https://bugs.freedesktop.org/show_bug.cgi?id=38456
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] problems with scp2
On Aug 1, 2011, at 10:02 AM, Bjoern Michaelsen wrote: On Mon, 1 Aug 2011 08:42:21 +0200 Stephan Bergmann stephan.bergmann.secondary-gM/ye1e23mwn+bqq9rb...@public.gmane.org wrote: Generally, existing code (i.e., extensions) having a recorded dependency against libuno_salhelpergcc3.so.3 will no longer work if they do not find a file with that exact name. Right, but extensions would not be run against the solver, but against an installation (where I suggested one needs to keep symlinks anyway). The suggestion was: - keep no SONAME or libuno_salhelpergcc3.so (unversioned) in solver and installation - still generate symlinks in installation so that in a installation (but not in solver), both libuno_salhelpergcc3.so and libuno_salhelpergcc3.so.3 are visible. OK, I see. I strongly suggest to add SONAME support to gbuild. For one, it is common ELF practice to use external versioning (i.e., via a trailing .so.X at a library's filename/SONAME) to discriminate among incompatible versions of a library. I came to the same conclusion: While the other scenario might work, it will end up like a evil genius dialog in the end: But why did you do this? -- Because I can!. Thats not a good reason in itself. But maybe even the symlinks do not need to be manually declared and created in solver. To follow the conventions of the host system calling ldconfig -n $OUTDIR/lib after installing and before using the lib should be enough. However, experimenting with this does not seem to create an unversioned symlink. I created a dir with a few random libs: libxml2.so.2.7.8 (SONAME:libxml2.so.2) libcairo.so.2.11000.2 (SONAME: libcairo.so.2) libuno_salhelpergcc3.so.3 (SONAME: libuno_salhelpergcc3.so.3) and got: libuno_salhelpergcc3.so.3 - libuno_salhelpergcc3.so.3 libxml2.so.2 - libxml2.so.2.7.8 libcairo.so.2 - libcairo.so.2.11000.2 so it does not create symlinks for the unversioned so (although those are quite common in /usr/lib here). For fun I move the lib libuno_salhelpergcc3.so.3 to libuno_salhelpergcc3.so and got: libuno_salhelpergcc3.so.3 - libuno_salhelpergcc3.so (changed) libxml2.so.2 - libxml2.so.2.7.8 libcairo.so.2 - libcairo.so.2.11000.2 Which does not make me happy either. So I guess we need to create the symlinks (at least the unversioned ones) manually indeed. And I would create the symlinks in the solver explicitly, anyway, not via ldconfig. ldconfig is imprecise, in that it takes a whole directory as input; and you would want to be able to link against a lib as soon as it is built, so would call ldconfig multiple times on $OUTDIR/lib (right?), which sounds like a bad idea in a parallel build. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] fdo#36843 and libadabaslo.so
Hi Francois, Thanks very much for your response. On Sun, 31 Jul 2011 20:01:15 +0200, Francois Tigeot ftig...@wolfpond.org wrote: In tracing a reproducible bug https://bugs.freedesktop.org/show_bug.cgi?id=36843 on a Debian squeeze box, I stumbled on missing 'libadabaslo.so' while 'libadabasuilo.so' is installed. Because LibO 3.3.2 came with both 'libadabasli.so' and 'libabadasuili.so', I am wondering whether something has changed expectedly or unexpectedly. While investigating a similar issue on NetBSD, I discovered the libadabas* file was hardcoded to be installed or not depending on the target platform name. This file is the Adabas D client library; a crippled version of the Adabas D database was bundled with old versions of StarOffice (2000-2003 timeframe). Back in June, I found out there was no evidence of this database engine beeing used after 2004, so I disabled the installation of the library for all platforms. Thanks, finally I have reached the changes, and also found the missing libadabas irrelevant with the above bug in general because I could not reproduce the one on Mac OS X. But still, if a driver refers to libadabaslo.so should it be fixed? If no user is discovered then, all Adabas D code will certainly be removed from the trunk after the first release of LibreOffice 3.5. OK, by the way the adabas*ui* part, which seems an extension, would remains? Any suggestions? I wouldn't think too much about it for now; the idea is to keep the client code in-tree (but disabled) so that if someone who needs it discovers it isn't there anymore with 3.5, it can be reactivated quickly. Sounds reasonable to me. Cheers, -- Takeshi Abe -- Francois Tigeot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] DDEInitiate bug
On 27 July 2011 14:06, Michael Meeks michael.me...@novell.com wrote: Hi Knut, On Tue, 2011-07-26 at 23:20 +0200, Knut Olav Bøhmer wrote: 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 Great ;-) I had to cd URE\bin\ because I got an error message about sal3.dll. Why does we have two binaries? Well - one in theory is a small binary that passes its arguments to the main 'factory' process that is running: this speeds up the 2nd launch. Unfortunately the 'small-ness' of that binary is bloated to (was it 3 or 6 Mb I forget) by all the embedded icons needed for associating that with the umpteen file-types we support [ or something ]. 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? Those same icons are then all present in soffice.bin as well in order to get window icons correct. Instead of that we should just be loading the window icons from our images.zip [ where they also live ], and setting them on the window at run-time I think. That is what we do for the gtk+ backend, cf. GtkSalFrame::SetIcon and just needs replicating for Windows - so we can drop that duplication. gtk+ has a means of doing this for windows, so there is the API support there somewhere. Now that I have my DDEInitiate-bug-workaround tested (and it works) I have some more time to do this. I think I should first find a solution to the DDEInitiate bug in LibreOffice, then I could start to work on the icon isssue. It sounds doable, as I can look in to what the Gtk version does. I have updated the bug-report at https://bugs.freedesktop.org/process_bug.cgi Should the icon-issue be registered in the bugtracking system? -- Knut Olav Bøhmer ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Git hangs?
Hi Olivier, On Mon, 2011-08-01 at 06:51 -0300, Olivier Hallot wrote: Any git command i isssue does not gives me a response anymore. Ok - that is bad, e.g. git clone git://anongit.freedesktop.org/libreoffice/bootstrap libo Do you have access via the git:// protocol ? or is that firewalled ? try adding a '-v' to see where it gets to. or ./g pull -r is there somenthing going in the git repo? Not yet; work is planned to merge them in about a week's time, requiring a new checkout of a single git repository rather than lots (which should help). Beyond that - we did a 'git gc' on the server which substantially shrunk our repos - from 6gb - 2gb or so, which should help http:// checkouts I think [ which themselves have terrible feedback ]. Failing -v helping, an 'strace -f' might show something useful. Oh, and thanks for your patch ! great to see that go in :-) All the bestm 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] Git hangs?
Hi Olivier, *, On Mon, Aug 1, 2011 at 11:51 AM, Olivier Hallot olivier.hal...@documentfoundation.org wrote: Any git command i isssue does not gives me a response anymore. e.g. git clone git://anongit.freedesktop.org/libreoffice/bootstrap libo or ./g pull -r is there somenthing going in the git repo? No general problem. Server in Germany: $ time git clone git://anongit.freedesktop.org/libreoffice/bootstrap Initialized empty Git repository in /home/cloph/nobackup/bootstrap/.git/ remote: Counting objects: 101826, done. remote: Compressing objects: 100% (22641/22641), done. remote: Total 101826 (delta 78356), reused 101536 (delta 78141) Receiving objects: 100% (101826/101826), 21.43 MiB | 4.44 MiB/s, done. Resolving deltas: 100% (78356/78356), done. real0m14.025s user0m4.780s sys 0m0.610s Server in the US: $ time git clone git://anongit.freedesktop.org/libreoffice/bootstrap Cloning into bootstrap... remote: Counting objects: 101826, done. remote: Compressing objects: 100% (22641/22641), done. remote: Total 101826 (delta 78356), reused 101536 (delta 78141) Receiving objects: 100% (101826/101826), 21.43 MiB | 5.42 MiB/s, done. Resolving deltas: 100% (78356/78356), done. real0m17.236s user0m7.140s sys 0m1.752s It might of course have been a temporary outage, who knows - so does the problem remain now? ciao Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] fix Kabyle_Algeria [kab_DZ] absent currency symbol
Hi Michael, On Monday, 2011-08-01 10:17:24 +0100, Michael Meeks wrote: * In locale data replaceTo must not be empty if replaceFrom isn't. + Also added check to locale data compiler to prevent this in future. * Fixed a currency format's group separator. * Marked LANGUAGE_USER_KABYLE (0x0659) obsolete as LANGUAGE_TAMAZIGHT_LATIN Looks nice :-) it makes me wonder if we want this as a low-risk bug-fix in 3.4.3 (?). No risk, and the sooner LANGUAGE_USER_KABYLE and its language listbox entry are removed the less chance is that documents written in MS formats will contain that value if picked as text attribution from the language list. Eike -- PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication. Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD pgpzNZPvCFUFh.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [MHST] GDB doesn't show name of methods in backtrace
Hi there, On Thu, 2011-07-28 at 01:09 +0700, Ta Duc Tung wrote: I've tried to make with debug=t but no change. GDB log still the same :( Any one please help! You need to 'make clean' in sw and then 'make debug=true' - and -then- you need to ensure that your install is linked to the dev tree with solenv/bin/linkoo. Then you need to re-run gdb, (with ooenv sourced), and you should have more luck. 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] fdo#37693 macros creating random table borders
On Thursday 28 of July 2011, Caolán McNamara wrote: proposing this fix for 3-4 http://cgit.freedesktop.org/libreoffice/writer/commit/?id=a7058d28e5d36778b 9f16308632ffb4c9608479c Reviewed, pushed. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] French dictionaries update: 3.8 to 4.2.1
2011/7/25 Olivier R. olivier.nore...@gmail.com: Hello all, Here is a patch to update the French dictionaries: 3.8 4.2.1. Thanks, I pushed it to both master and libreoffice-3-4 branches. Best regards, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] problems with scp2
On Mon, 1 Aug 2011 12:56:32 +0200 Stephan Bergmann stephan.bergmann.second...@googlemail.com wrote: And I would create the symlinks in the solver explicitly, anyway, not via ldconfig. ldconfig is imprecise, in that it takes a whole directory as input; and you would want to be able to link against a lib as soon as it is built, so would call ldconfig multiple times on $OUTDIR/lib (right?), which sounds like a bad idea in a parallel build. Well, there is ldconfig -l with would prevent the parallelization problems, but as we need manual symlinks for the unversioned link anyway, I think thats moot. Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] possible error in Wiki list of fixed bugs
Hello all, On Mon, Aug 1, 2011 at 17:53, leif leiflod...@gmail.com wrote: But I agree that the issue number doesn't refer to the correct issue and we should ask the developer list (done) for better and more accurate information. Seems to be a typo. It should be fdo#38457. Follow this patch's thread here: http://lists.freedesktop.org/archives/libreoffice/2011-June/014344.html Best Regards, -- Korrawit Pruegsanusak ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] source tarballs: gzip files as .tar.bz2?
Hello Miklos, On Mon, Aug 1, 2011 at 05:28, Miklos Vajna vmik...@frugalware.org wrote: $ file libreoffice-artwork-3.4.2.3.tar.bz2 libreoffice-artwork-3.4.2.3.tar.bz2: gzip compressed data, from Unix, last modified: Sat Jul 30 22:28:37 2011 Did I miss something or there seems to be a bug maybe in bin/lo-pack-sources? This is fixed by Thorsten. http://listarchives.libreoffice.org/global/website/msg05679.html Best Regards, -- Korrawit Pruegsanusak ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] fix Kabyle_Algeria [kab_DZ] absent currency symbol
On Mon, 2011-08-01 at 13:54 +0200, Eike Rathke wrote: Looks nice :-) it makes me wonder if we want this as a low-risk bug-fix in 3.4.3 (?). No risk, and the sooner LANGUAGE_USER_KABYLE and its language listbox entry are removed the less chance is that documents written in MS formats will contain that value if picked as text attribution from the language list. Great; read / cherry-picked to libreoffice-3-4 as two commits. 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] possible error in Wiki list of fixed bugs
Am Montag, 1. August 2011, um 16:21:18 schrieb Korrawit Pruegsanusak: Hello all, On Mon, Aug 1, 2011 at 17:53, leif leiflod...@gmail.com wrote: But I agree that the issue number doesn't refer to the correct issue and we should ask the developer list (done) for better and more accurate information. Seems to be a typo. It should be fdo#38457. ok, fixed. Nino ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] git apply vs git am (was: Re: [PATCH] fix Kabyle_Algeria [kab_DZ] absent currency symbol)
On Mon, 01 Aug 2011 11:23:36 -0400 Kohei Yoshida kyosh...@novell.com wrote: I just wanted to mention this in case of similar problems in the future. A hopefully very limited range of future where this might still be an issue. ;-) Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [MHST] GDB doesn't show name of methods in backtrace
Hello all, On Mon, Aug 1, 2011 at 21:45, Ta Duc Tung tatung2...@gmail.com wrote: Thanks for your reply, Michael :-) Sorry if this is a dump question but, how to ensure that my install is linked to the dev tree with solenv/bin/linkoo ? Not Michael ;) but IMHO you should run $ solenv/bin/linkoo with appropriate parameters. Best Regards, -- Korrawit Pruegsanusak ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] problems in number format dialog
Hi Samphan,
On Monday, 2011-08-01 11:54:31 +0700, Samphan Raruenrom wrote:
We're reading this discussion and patches.
Great, could you please apply the attached patches and check if that
suits the needs of the Thai community?
Thanks
Eike
--
PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
fdo#38956 related changes in split components repository to support LCID changes
From: Eike Rathke o...@erack.de
---
cui/source/tabpages/numfmt.cxx |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/cui/source/tabpages/numfmt.cxx b/cui/source/tabpages/numfmt.cxx
index 03fb706..b92831e 100644
--- a/cui/source/tabpages/numfmt.cxx
+++ b/cui/source/tabpages/numfmt.cxx
@@ -1394,6 +1394,10 @@ IMPL_LINK( SvxNumberFormatTabPage, ClickHdl_Impl,
ImageButton*, pIB)
if ( !nErrPos ) // Syntax ok?
{
+// May be sorted under a different locale if LCID was parsed.
+if (bAdded)
+aLbLanguage.SelectLanguage( pNumFmtShell-GetCurLanguage() );
+
if(nCatLbSelPos==CAT_CURRENCY)
{
aLbCurrency.SelectEntryPos((sal_uInt16)pNumFmtShell-GetCurrencySymbol());
fdo#38956 related changes in split libs-core repository to support LCID changes
From: Eike Rathke o...@erack.de
---
svx/source/items/numfmtsh.cxx | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/svx/source/items/numfmtsh.cxx b/svx/source/items/numfmtsh.cxx
index 837fdea..9f70817 100644
--- a/svx/source/items/numfmtsh.cxx
+++ b/svx/source/items/numfmtsh.cxx
@@ -289,6 +289,20 @@ sal_Bool SvxNumberFormatShell::AddFormat( String rFormat,
xub_StrLen rErrPos,
bInserted = pFormatter-PutEntry( rFormat, rErrPos,
nCurCategory, nAddKey,
eCurLanguage );
+if (bInserted)
+{
+// May be sorted under a different locale if LCID was parsed.
+const SvNumberformat* pEntry = pFormatter-GetEntry( nAddKey);
+if (pEntry)
+{
+LanguageType nLang = pEntry-GetLanguage();
+if (eCurLanguage != nLang)
+{
+// Current language's list would not show entry, adapt.
+eCurLanguage = nLang;
+}
+}
+}
}
if ( bInserted ) // eingefuegt
Fix fdo#38956 discarding bracketed prefixes in number formats, such as [RED]
From: Eike Rathke o...@erack.de
* Fixed discarding of prefixes.
* Fixed the broken handling of Thai calendar and numerals speciality.
* Added bits to actually display a format with embedded LCID in the dialog.
---
svl/inc/svl/zforlist.hxx| 16
svl/source/numbers/zforlist.cxx |2 +
svl/source/numbers/zformat.cxx | 139 ++-
3 files changed, 125 insertions(+), 32 deletions(-)
diff --git a/svl/inc/svl/zforlist.hxx b/svl/inc/svl/zforlist.hxx
index eef1904..d1519ea 100644
--- a/svl/inc/svl/zforlist.hxx
+++ b/svl/inc/svl/zforlist.hxx
@@ -42,6 +42,7 @@
#include svl/nfkeytab.hxx
#include map
+#include set
class Date;
class SvStream;
@@ -225,6 +226,8 @@ typedef Table SvNumberFormatterIndexTable;
typedef ::std::map sal_uInt32, sal_uInt32 SvNumberFormatterMergeMap;
+typedef ::std::set LanguageType NfInstalledLocales;
+
/** Language/country dependent currency entries
*/
@@ -343,6 +346,9 @@ public:
*/
static const sal_uInt16 INPUTSTRING_PRECISION;
+/** THE set of installed locales. */
+static NfInstalledLocales theInstalledLocales;
+
/// Preferred ctor with service manager and language/country enum
SvNumberFormatter(
const ::com::sun::star::uno::Reference
::com::sun::star::lang::XMultiServiceFactory xSMgr,
@@ -801,6 +807,16 @@ public:
/// Skip a NumberFormatter in stream, Chart needs this
static void SkipNumberFormatterInStream( SvStream );
+/** Check if a specific locale has supported locale data. */
+static bool IsLocaleInstalled( LanguageType eLang )
+{
+// The set is initialized as a side effect of the currency table
+// created, make sure that exists, which usually is the case unless a
+// SvNumberFormatter was never instanciated.
+GetTheCurrencyTable();
+return theInstalledLocales.find( eLang) != theInstalledLocales.end();
+}
+
private:
::com::sun::star::uno::Reference
::com::sun::star::lang::XMultiServiceFactory xServiceManager;
diff --git a/svl/source/numbers/zforlist.cxx b/svl/source/numbers/zforlist.cxx
index bc0df6a..a4a0c82 100644
--- a/svl/source/numbers/zforlist.cxx
+++ b/svl/source/numbers/zforlist.cxx
@@ -195,6 +195,7 @@ SV_IMPL_PTRARR( NfWSStringsDtor, String* );
const sal_uInt16 SvNumberFormatter::UNLIMITED_PRECISION =
[Libreoffice] Request for a VM
Hi, As you may know Fedora 14 does not release F14 based Libo RPMs but for F15. I would like to take care of building Libo for F14. If some one install Libo RPMs manually he/she wont get automatic updates. I am trying to maintain a repository where users can easily install Libo on F14 using the YUM. Highly appreciate if I could get a VM to start the build process. -- Danishka Navin http://danishkanavin.blogspot.com http://twitter.com/danishkanavin http://identi.ca/danishka http://www.flickr.com/photos/danishkanavin/ ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] produce smaller .res files with the resource compiler
On Sun, 2011-07-24 at 08:48 -0500, Norbert Thiebaud wrote:
Are you sure you actually saved that 'much' ? presumably this 2158
bytes repeated 71 times should compress well enough when packaged
Well - it is repeated umpteen times per language; and how well that
compresses is anyone's guess.
Please review it, I'm not sure if such low level hacks are acceptable. :)
Looks pretty ugly to me. That code seems neglected enough without
adding another layer of WTF-factor for the poor soul that one day will
want/have to maintain it.
Quite - that was a nightmare of a patch ;-) Luckily a spent a few
minutes while running a backup to turn it into something nicer:
I think this is more like what you want to be doing. We would
want to remove the code that dumps this table in tools/ - it seems
to be only enabled as DBG_UTIL - and (as you say) seems to be unused.
Potentially, if we were a bit braver; we could (I guess)
experiment with shrinking nRT's size down to sal_uInt16 (at least in the
file format), and see if nId is really necessary in those headers - but
perhaps I'm missing something there. No doubt it would be worth doing
some fprintf goodness during an incremental re-build of all the resource
files to work out what the scopes are there.
Anyhow - needs a bit more testing of course, but hopefully is
maintainable. It shrinks:
cd filter/
touch ./source/graphicfilter/eps/epsstr.src
build hexdump -C ./unxlngi6.pro/bin/epsen-US.res
quite touchingly :-) I'd like to see the RSC_VERSIONCONTROL record
completely expunged from the code (ideally) on both sides and the
headers, completely gone.
ATB,
Michael.
From 56991b23947d7d2307cc4bc039b8b0a2a0cd8da1 Mon Sep 17 00:00:00 2001
From: Michael Meeks michael.me...@novell.com
Date: Mon, 1 Aug 2011 17:36:56 +0100
Subject: [PATCH] remove name-to-ver-control map contents from
RSC_VERSIONCONTROL record
Based on a patch from Andras, this removes a set of un-used
debugging type strings from all lang-pack resource files.
---
rsc/source/parser/rscinit.cxx | 24
1 files changed, 0 insertions(+), 24 deletions(-)
diff --git a/rsc/source/parser/rscinit.cxx b/rsc/source/parser/rscinit.cxx
index ae6b7b6..b4591bd 100644
--- a/rsc/source/parser/rscinit.cxx
+++ b/rsc/source/parser/rscinit.cxx
@@ -58,29 +58,6 @@
#define INS_WINBIT( pClass, WinBit ) \
InsWinBit( pClass, #WinBit, n##WinBit##Id );
-/** C O D E **/
-void NameToVerCtrl( RSCINST aVersion, RscTop * pClass,
-RscTop * pClassString )
-{
-if( pClass )
-{
-NameToVerCtrl( aVersion, (RscTop *)pClass-Left(), pClassString );
-{
-RSCINST aVI;
-RSCINST aStr;
-
-// Namen in Versionskontrolle einsetzen
-aVersion.pClass-
- GetElement( aVersion, RscId( pClass-GetTypId() ),
- pClassString, RSCINST(), aVI );
-aStr = aVI.pClass-GetVariable( aVI, pHS-getID( TEXT ),
-RSCINST() );
-aStr.pClass-SetString( aStr, pHS-getString( pClass-GetId()
).getStr() );
-}
-NameToVerCtrl( aVersion, (RscTop *)pClass-Right(), pClassString );
-}
-}
-
/*
|*
|* RscTypCont::Init()
@@ -926,7 +903,6 @@ void RscTypCont::Init()
pClassSfxSlotInfo = InitClassSfxSlotInfo( pClassMgr );
pRoot-Insert( pClassSfxSlotInfo );
}
-NameToVerCtrl( aVersion, pRoot, pClassString );
aNmTb.SetSort();
}
--
1.7.3.4
--
michael.me...@novell.com , Pseudo Engineer, itinerant idiot
--
michael.me...@novell.com , Pseudo Engineer, itinerant idiot
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] source tarballs: gzip files as .tar.bz2?
On Mon, Aug 01, 2011 at 09:27:12PM +0700, Korrawit Pruegsanusak detective.conan.1...@gmail.com wrote: This is fixed by Thorsten. http://listarchives.libreoffice.org/global/website/msg05679.html Indeed. Thanks a lot! pgppx2vIytEpq.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] MSWordExportBase::ExportDocument: check if we have a DocShell
Hello Noel, I recently tested the copypaste export (using RTF) on master and got a crash. The attached patch solves the issue here. OK to push, or you want to add a check in the called SwMSConvertControls constructor? Thanks. From 9ab1204db32020ad0d70e91fb06e12b9c6a2b398 Mon Sep 17 00:00:00 2001 From: Miklos Vajna vmik...@frugalware.org Date: Mon, 1 Aug 2011 19:55:42 +0200 Subject: [PATCH] MSWordExportBase::ExportDocument: check if we have a DocShell This fixes a crash during RTF export invoked by copypaste, as the called constructor would unconditionally dereference the DocShell's pointer since commit 183c9723dce0296baa0a38220199a1aa0e9f52ca. --- sw/source/filter/ww8/wrtww8.cxx |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sw/source/filter/ww8/wrtww8.cxx b/sw/source/filter/ww8/wrtww8.cxx index edad4b1..cf07bc8 100644 --- a/sw/source/filter/ww8/wrtww8.cxx +++ b/sw/source/filter/ww8/wrtww8.cxx @@ -2925,7 +2925,7 @@ void MSWordExportBase::ExportDocument( bool bWriteAll ) if ( !pOleMap) pOleMap = new WW8OleMaps; -if ( !pOCXExp ) +if ( !pOCXExp pDoc-GetDocShell() ) pOCXExp = new SwMSConvertControls( pDoc-GetDocShell(), pCurPam ); // #i81405# - Collect anchored objects before changing the redline mode. -- 1.7.6 pgpv94joJohSt.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Attention for PHP developers - 30 points off for all Nusphere php products
Dear PHP Developer, We would like to inform you about the latest PhpED 6.1 release from our strategic partner NuSphere, Inc. As a business owner and a manager of your technical team for web development, you will definitely benefit from it. If you are not the right person, please forward this note to someone who is responsible for a web development project in your organization. Here is our proposal: Use this coupon code: ALL-OTH-30-O-19020 to get a 30% discount on every PhpED related product in Nusphere's store! Follow this link: https://shop.nusphere.com/customer/home.php?cat=9 and enter the coupon code during the checkout. In response to all marketing surveys that we ran, the top reasons listed for purchase decision on PhpED have always included PHP Debugger (http://www.nusphere.com/products/php_debugger.htm) and the speed of the Editor. The recent release of PhpED 6.1 includes JavaScript code completion and other new features - to view, please click on the following link: http://www.nusphere.com/products/phped_new_features.htm Best Regards, The PHP Sales Team at PhpED60.com P.S. Please reply with unsubscribe in your subject line if you are not interested to receive communications from us. ___ 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 Eike Rathke o...@erack.de changed: What|Removed |Added Depends on||38956 -- 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] Build problem on Linux 3.0; plea for workflow
In nss, security/coreconf they reference e.g. Linux2.6.mk. Building on 3.0.0 this fails because there is no Linux3.0.mk. All that would be needed to fix this is copy Linux2.6.mk to Linux3.0.mk. The workflow for your builds is unusual in that it unpacks the subsidiary tarballs and charges right into building things. In a normal build workflow, you would have untar, possible patch, configure, possible patch, make. In your workflow, there is no opportunity to get control back for even the simplest of workarounds. If there is a way to do site-local patches in your workflow between the unpacking and the building steps, I haven't found it documented. I beg you to think this over and decide to do something about it. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Build problem on Linux 3.0; plea for workflow
Hi Marty, On 08/02/2011 12:02 AM, Marty Jack wrote: If there is a way to do site-local patches in your workflow between the unpacking and the building steps, I haven't found it documented. I beg you to think this over and decide to do something about it. I've already fixed this in master and it will be in 3.4.3: http://cgit.freedesktop.org/libreoffice/libs-extern-sys/commit/?id=64609b5e174e44bfc49c29cb871d057af740edeb Thomas ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Family Health Info
Note : If you received this mail accidently kindly Unsubscribe Now mailto:shambh...@healthbeautycareonline.com ?subject=Unsubscribe hbcoor forward a copy of this mail to shambh...@healthbeautycareonline.com mailto:shambh...@healthbeautycareonline.com Hi, Visit my interesting blog on health and beauty care. The blog is full of rich information. Visit the site http://healthbeautycareonline.com http://healthbeautycareonline.com Thanks for your time. Regards ... Shambhavi Note : If you received this mail accidently kindly Unsubscribe Now mailto:shambh...@healthbeautycareonline.com ?subject=Unsubscribe hbcoor forward a copy of this mail to shambh...@healthbeautycareonline.com mailto:shambh...@healthbeautycareonline.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Request for a VM
Hello, I am not sure what exactly you are asking for. My desktop is F15 and I run a virtual machine on my desktop all the time. VirtualBox OSE is free software, and Fedora is free software. So it should be easy :) Maybe I got your question wrong... would you please rephrase? Marc-André Laverdière Software Security Scientist Innovation Labs, Tata Consultancy Services Hyderabad, India On 08/01/2011 10:13 PM, Danishka Navin wrote: Hi, As you may know Fedora 14 does not release F14 based Libo RPMs but for F15. I would like to take care of building Libo for F14. If some one install Libo RPMs manually he/she wont get automatic updates. I am trying to maintain a repository where users can easily install Libo on F14 using the YUM. Highly appreciate if I could get a VM to start the build process. -- Danishka Navin http://danishkanavin.blogspot.com http://twitter.com/danishkanavin http://identi.ca/danishka http://www.flickr.com/photos/danishkanavin/ ___ 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] Small Question About sal_* Types
I remember that one rocket disintegrated because of an issue of types... https://secure.wikimedia.org/wikipedia/en/wiki/Ariane_5_Flight_501 Thankfully, LO shouldn't be used in this way... but mismatching of types (especially between modules) can be a source of a gazillion bugs and a few security issues. I guess that is the reason why POSIX and Windows APIs have created all sorts of types like HANDLE and size_t :) I am inclined to think that we should follow suit and standardize on the sal_* types, and not just on the boundaries. We are already in the process of fixing our internals with vectors and different string APIs, so that change could be done gradually as we go along. Just my 2 paisa ;) Marc-André Laverdière Software Security Scientist Innovation Labs, Tata Consultancy Services Hyderabad, India On 07/27/2011 10:25 AM, Norbert Thiebaud wrote: 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 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
