Re: [Libreoffice] [PATCH] build system patches
On 09/07/2011 03:14 AM, Norbert Thiebaud wrote: On Tue, Sep 6, 2011 at 5:32 PM, Peter Foleypefol...@verizon.net wrote: Hi, Here are some patches for various problems I encountered while building libreoffice. 0001-libcrnf.a is that a consequence of http://cgit.freedesktop.org/libreoffice/core/commit/?id=291b85778669b4e4e276faab22add9d0e80046df ? I would suspect so. That one apparently also broke my Mac OS X build, but I did not yet find time to look into it. (What fits somewhat nicely is that it shows up in a chroot build. My impression from the Mac OS X build failure logs was that building moz now inadvertently takes certain libraries from the system, instead of from (now) intended to be built in nss vs. (before) being built as part of building moz itself, and those libraries are not present, on Mac OS X nor in a chroot. Something like that.) -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] instsetoo_native part of build failing on Windows
Hi This is a Windows7 machine, with Visual Studio 2008 Express. The instsetoo_native part of the seems to be failing because of some missing dict_*.oxt files, see attached log. Any ideas? Thanks, Noel Grandin. Disclaimer: http://www.peralex.com/disclaimer.html = (1/1) Building module instsetoo_native = Entering /cygdrive/c/libreoffice/git2/libo/instsetoo_native/inc_openoffice/windows/msi_languages Entering /cygdrive/c/libreoffice/git2/libo/instsetoo_native/util dmake: makefile.mk: line 235: Warning: -- Prior to dmake 4.5 only one %-target per target-definition worked reliably. Check your makefiles. dmake: makefile.mk: line 290: Warning: -- Prior to dmake 4.5 only one %-target per target-definition worked reliably. Check your makefiles. mkdir.exe -p ../wntmsci12.pro/misc/openoffice/msi_templates mkdir.exe -p ../wntmsci12.pro/misc/ooolangpack/msi_templates mkdir.exe -p ../wntmsci12.pro/misc/ooohelppack/msi_templates mkdir.exe -p ../wntmsci12.pro/misc/ure/msi_templates mkdir.exe -p ../wntmsci12.pro/misc/sdkoo/msi_templates mkdir.exe -p ../wntmsci12.pro/misc/openoffice/msi_templates/Binary mkdir.exe -p ../wntmsci12.pro/misc/ooolangpack/msi_templates/Binary mkdir.exe -p ../wntmsci12.pro/misc/ooohelppack/msi_templates/Binary mkdir.exe -p ../wntmsci12.pro/misc/ure/msi_templates/Binary mkdir.exe -p ../wntmsci12.pro/misc/sdkoo/msi_templates/Binary /usr/bin/cp -u ../inc_openoffice/windows/msi_templates/*.* ../wntmsci12.pro/misc/openoffice/msi_templates /usr/bin/cp -u ../inc_ooolangpack/windows/msi_templates/*.* ../wntmsci12.pro/misc/ooolangpack/msi_templates /usr/bin/cp -u ../inc_ooohelppack/windows/msi_templates/*.* ../wntmsci12.pro/misc/ooohelppack/msi_templates /usr/bin/cp -u ../inc_ure/windows/msi_templates/*.* ../wntmsci12.pro/misc/ure/msi_templates /usr/bin/cp -u ../inc_sdkoo/windows/msi_templates/*.* ../wntmsci12.pro/misc/sdkoo/msi_templates /usr/bin/cp -u ../inc_openoffice/windows/msi_templates/Binary/*.* ../wntmsci12.pro/misc/openoffice/msi_templates/Binary /usr/bin/cp -u ../inc_ooolangpack/windows/msi_templates/Binary/*.* ../wntmsci12.pro/misc/ooolangpack/msi_templates/Binary /usr/bin/cp -u ../inc_ooohelppack/windows/msi_templates/Binary/*.* ../wntmsci12.pro/misc/ooohelppack/msi_templates/Binary /usr/bin/cp -u ../inc_ure/windows/msi_templates/Binary/*.* ../wntmsci12.pro/misc/ure/msi_templates/Binary /usr/bin/cp -u ../inc_sdkoo/windows/msi_templates/Binary/*.* ../wntmsci12.pro/misc/sdkoo/msi_templates/Binary /bin/rm -f ../wntmsci12.pro/misc/openoffice/msi_templates/Binary/Image.bmp /bin/rm -f ../wntmsci12.pro/misc/ooolangpack/msi_templates/Binary/Image.bmp /bin/rm -f ../wntmsci12.pro/misc/ooohelppack/msi_templates/Binary/Image.bmp /bin/rm -f ../wntmsci12.pro/misc/ure/msi_templates/Binary/Image.bmp /bin/rm -f ../wntmsci12.pro/misc/sdkoo/msi_templates/Binary/Image.bmp /bin/rm -f ../wntmsci12.pro/misc/openoffice/msi_templates/Binary/Banner.bmp /bin/rm -f ../wntmsci12.pro/misc/ooolangpack/msi_templates/Binary/Banner.bmp /bin/rm -f ../wntmsci12.pro/misc/ooohelppack/msi_templates/Binary/Banner.bmp /bin/rm -f ../wntmsci12.pro/misc/ure/msi_templates/Binary/Banner.bmp /bin/rm -f ../wntmsci12.pro/misc/sdkoo/msi_templates/Binary/Banner.bmp cp ../res/nologoinstall.bmp ../wntmsci12.pro/misc/openoffice/msi_templates/Binary/Image.bmp cp ../res/nologoinstall.bmp ../wntmsci12.pro/misc/ooolangpack/msi_templates/Binary/Image.bmp cp ../res/nologoinstall.bmp ../wntmsci12.pro/misc/ooohelppack/msi_templates/Binary/Image.bmp cp ../res/nologoinstall.bmp ../wntmsci12.pro/misc/ure/msi_templates/Binary/Image.bmp cp ../res/nologoinstall.bmp ../wntmsci12.pro/misc/sdkoo/msi_templates/Binary/Image.bmp cp ../res/nologobanner.bmp ../wntmsci12.pro/misc/openoffice/msi_templates/Binary/Banner.bmp cp ../res/nologobanner.bmp ../wntmsci12.pro/misc/ooolangpack/msi_templates/Binary/Banner.bmp cp ../res/nologobanner.bmp ../wntmsci12.pro/misc/ooohelppack/msi_templates/Binary/Banner.bmp cp ../res/nologobanner.bmp ../wntmsci12.pro/misc/ure/msi_templates/Binary/Banner.bmp cp ../res/nologobanner.bmp ../wntmsci12.pro/misc/sdkoo/msi_templates/Binary/Banner.bmp C:/cygwin/bin/perl -w C:/libreoffice/git2/libo/solenv/bin/make_installer.pl -f ../util/openoffice.lst -l en-US -p LibreOffice_Dev -u ../wntmsci12.pro -buildid 0 -msitemplate ../wntmsci12.pro/misc/openoffice/msi_templates -msilanguage ../wntmsci12.pro/misc/win_ulffiles -format native Subroutine installer::epmfile::getcwd redefined at C:/libreoffice/git2/libo/solenv/bin/modules/installer/epmfile.pm line 43 ... checking environment variables ... make_installer.pl, version 1.0 Product list file: ../util/openoffice.lst Taking setup script from solver Unpackpath: C:/libreoffice/git2/libo/instsetoo_native/wntmsci12.pro Compiler: wntmsci12 Product: LibreOffice_Dev BuildID: 0 Build: OOO350 No minor set Product version Using default installpath Package format: native msi
Re: [Libreoffice] instsetoo_native part of build failing on Windows
Hi, 2011/9/7 Noel Grandin n...@peralex.com: Hi This is a Windows7 machine, with Visual Studio 2008 Express. The instsetoo_native part of the seems to be failing because of some missing dict_*.oxt files, see attached log. Any ideas? Did you update dictionaries repo recently? These packages were added there a few days ago. I think you updated the core repo but you forgot to update the dictionaries repo. Best regards, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Bug 40673 - unify build parallelization and use gnu makes --load-average feature where available
Hi list,
I just proposed the following at
https://bugs.freedesktop.org/show_bug.cgi?id=40673 :
The ways to specify
build parallelization are way to complex and confusing.
I propose the following solution:
1) We use --with-num-cpus and --with-max-jobs and --with-sense-load
2) --with-num-cpus defaults to the number of cpus on the machine and is
stored in GMAKE_PARALELLISM only
3) --with-max-jobs defaults to the number of cpus divided by two on the
machine and is stored in GMAKE_MODULE_PARALELLISM only
4) --with-sense-load defaults to T unless using icecream or on
windows (where it is ) and is stored in GMAKE_SENSE_LOAD
5) all calls to build.pl are done as:
build.pl -P$((${GMAKE_PARALELLISM}/${GMAKE_MODULE_PARALELLISM})) --
-P${GMAKE_MODULE_PARALELLISM}
6) gbuild calls (including tail_build) are done as:
make -srj$((${GMAKE_PARALELLISM}*4))
-l$((${GMAKE_PARALELLISM}+1)) when GMAKE_SENSE_LOAD is not empty, or as:
make -srj${GMAKE_MODULE_PARALELLISM}
otherwise (exception: tail build might use GMAKE_PARALELLISM)
The variables @BUILD_NCPUS@ and @BUILD_MAX_JOBS@ will be removed.
Configure should warn, if GMAKE_MODULE_PARALELLISM is bigger than
GMAKE_PARALELLISM and set it to GMAKE_PARALELLISM.
Any objections to that implementation?
Best,
Bjoern
--
https://launchpad.net/~bjoern-michaelsen
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] instsetoo_native part of build failing on Windows
Hi Andras I'm new at this, so forgive my ignorance, but as far as I know I'm building out of only one repo: git://anongit.freedesktop.org/libreoffice/core Regards, Noel. Andras Timar wrote: Hi, 2011/9/7 Noel Grandin n...@peralex.com: Hi This is a Windows7 machine, with Visual Studio 2008 Express. The instsetoo_native part of the seems to be failing because of some missing dict_*.oxt files, see attached log. Any ideas? Did you update dictionaries repo recently? These packages were added there a few days ago. I think you updated the core repo but you forgot to update the dictionaries repo. Best regards, Andras Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] build system patches
On Wed, Sep 7, 2011 at 1:47 AM, Stephan Bergmann sberg...@redhat.com wrote: On 09/07/2011 03:14 AM, Norbert Thiebaud wrote: On Tue, Sep 6, 2011 at 5:32 PM, Peter Foleypefol...@verizon.net wrote: Hi, Here are some patches for various problems I encountered while building libreoffice. 0001-libcrnf.a is that a consequence of http://cgit.freedesktop.org/libreoffice/core/commit/?id=291b85778669b4e4e276faab22add9d0e80046df ? I would suspect so. That one apparently also broke my Mac OS X build, but I did not yet find time to look into it. (What fits somewhat nicely is that it shows up in a chroot build. My impression from the Mac OS X build failure logs was that building moz now inadvertently takes certain libraries from the system, instead of from (now) intended to be built in nss vs. (before) being built as part of building moz itself, and those libraries are not present, on Mac OS X nor in a chroot. Something like that.) humm.. and that would also explain the 0002- patch (well not the patch but the reason that motivated it) I think you are right, and maybe the commit above should be revisited in light of these... (I means instead of papering over the symptom :-) ) I do not build mozila on my tinderox, so I did not see them poping-up at the time :-( Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] build system patches
On 09/07/2011 10:28 AM, Norbert Thiebaud wrote: On Wed, Sep 7, 2011 at 1:47 AM, Stephan Bergmannsberg...@redhat.com wrote: On 09/07/2011 03:14 AM, Norbert Thiebaud wrote: On Tue, Sep 6, 2011 at 5:32 PM, Peter Foleypefol...@verizon.netwrote: Hi, Here are some patches for various problems I encountered while building libreoffice. 0001-libcrnf.a is that a consequence of http://cgit.freedesktop.org/libreoffice/core/commit/?id=291b85778669b4e4e276faab22add9d0e80046df ? I would suspect so. That one apparently also broke my Mac OS X build, but I did not yet find time to look into it. (What fits somewhat nicely is that it shows up in a chroot build. My impression from the Mac OS X build failure logs was that building moz now inadvertently takes certain libraries from the system, instead of from (now) intended to be built in nss vs. (before) being built as part of building moz itself, and those libraries are not present, on Mac OS X nor in a chroot. Something like that.) humm.. and that would also explain the 0002- patch (well not the patch but the reason that motivated it) I think you are right, and maybe the commit above should be revisited in light of these... (I means instead of papering over the symptom :-) ) Yes, definitely dig in and try to understand the root cause, than fixing the symptoms. Putting kendy as the author of the above changeset on cc. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Bug 40673 - unify build parallelization and use gnu makes --load-average feature where available
On Wed, Sep 7, 2011 at 3:02 AM, Bjoern Michaelsen
bjoern.michael...@canonical.com wrote:
Hi list,
I just proposed the following at
https://bugs.freedesktop.org/show_bug.cgi?id=40673 :
The ways to specify
build parallelization are way to complex and confusing.
I propose the following solution:
1) We use --with-num-cpus and --with-max-jobs and --with-sense-load
2) --with-num-cpus defaults to the number of cpus on the machine and is
stored in GMAKE_PARALELLISM only
3) --with-max-jobs defaults to the number of cpus divided by two on the
machine and is stored in GMAKE_MODULE_PARALELLISM only
4) --with-sense-load defaults to T unless using icecream or on
windows (where it is ) and is stored in GMAKE_SENSE_LOAD
5) all calls to build.pl are done as:
build.pl -P$((${GMAKE_PARALELLISM}/${GMAKE_MODULE_PARALELLISM})) --
-P${GMAKE_MODULE_PARALELLISM}
6) gbuild calls (including tail_build) are done as:
make -srj$((${GMAKE_PARALELLISM}*4))
-l$((${GMAKE_PARALELLISM}+1)) when GMAKE_SENSE_LOAD is not empty, or as:
make -srj${GMAKE_MODULE_PARALELLISM}
otherwise (exception: tail build might use GMAKE_PARALELLISM)
The variables @BUILD_NCPUS@ and @BUILD_MAX_JOBS@ will be removed.
Configure should warn, if GMAKE_MODULE_PARALELLISM is bigger than
GMAKE_PARALELLISM and set it to GMAKE_PARALELLISM.
Any objections to that implementation?
yep. it is even more complicated that the current scheme.
I mean:
build.pl -P$((${GMAKE_PARALELLISM}/${GMAKE_MODULE_PARALELLISM})) --
-P${GMAKE_MODULE_PARALELLISM}
really ? ok so on my Mac I build with max-job=8 num-cpu=6... what
value should I use to get the same result under the new scheme?
(today that means I get up to 8 jobs with up to 6 task per, except for
tail_build where I got 8 -- note that tail_build tend to run alone)
for info, right now the mode is
GMAKE_PARALLELISM=max(nb-cpu.max-jobs)
that value is used for tail_build only
GMAKE_MODULE_PARALLELISM=max-job (because that is how it was, so that
avoided 'regression'. that value is used for gmake module other than
tail_build.
in fine, only GMAKE_PARRALLELISM should be relevant as stuff get
accumulated under tail_build
Now, yes, if it works (I never tested it), the load average sound
more promising than a pure -j n... but then if it works, then why even
bother with -j n at all...
if --with-sens-load is present then use the value specified or default
to nb_cpu + 1 like you said, but then use -j without value...
Actually, the end-game should be --with-sense-load=n that use -l n on
platform that support it and -j n on windows... n default to nb_cpu +
1
(btw: I've been recently experimenting with these value to find the
best combination on a 48 cores machines (4 x 12 core).
Norbert
PS: with ExternalLib.mk I was able to use the fact that sub-make can
coordinate with the main make for //ism. so eventually most of what we
build should end-up controlled by one //ism factor - with the
exception of ant base stuff I suppose... java, a pain as always...
actually ICU may also be a big pain...
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] fdo#37195, [PUSHED] take two on the where did my dictionaries go
2011/9/2 Caolán McNamara caol...@redhat.com: On Thu, 2011-09-01 at 13:52 +0100, Caolán McNamara wrote: Attached is the backport for 3-4 as this code changed a little between 3-4 and master. caolanm-Andras: could you arrange to have the attached tested ? https://bugs.freedesktop.org/show_bug.cgi?id=37195 testing seems to show success here. Pushed to libreoffice-3-4. Many thanks, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Bug 40673 - unify build parallelization and use gnu makes --load-average feature where available
On Wed, 7 Sep 2011 04:02:36 -0500 Norbert Thiebaud nthieb...@gmail.com wrote: really ? ok so on my Mac I build with max-job=8 num-cpu=6... what value should I use to get the same result under the new scheme? Counter question: Why would you want to get that result? max-job=8 num-cpu=6 gets you something unpredictable between 6 and 48 jobs. The only way why it should work is because modern unix handles overcommitment quite decently (RAM might be more of an issue, but not with your machine). I think you would be just as fast with the new defaults, if not faster. (today that means I get up to 8 jobs with up to 6 task per, except for tail_build where I got 8 -- note that tail_build tend to run alone) I doubt you will ever run the 8 dmake dirs unless you compile binfilter. Now, yes, if it works (I never tested it), the load average sound more promising than a pure -j n... but then if it works, then why even bother with -j n at all... It works, but: a) on distributed builders (icecream, distcc) the load of the host is not a good measure b) having no limit on -j is risky on start as make will spawn jobs like mad, because most jobs are io-bound in the beginning c) Windows has no sensible load measure if --with-sens-load is present then use the value specified or default to nb_cpu + 1 like you said, but then use -j without value... see b) Also -l will lessen the pain of overcommitment: have some old dmake dirs running and gnu make will 'fill up' the available remaining free load to optimal cpu-usage. Best, Bjoern PS.: Well, I took a look at the count of objects in our build -- ~60% are in gbuild already, and of the remaining ones openssl, berkeleydb, icu, autodoc (which has to die), connectivity and sal are big ones. openssl and berkeleydb and icu are external ones which we should build with gnu make paralellization too. And autodoc has to die (Did I say that already?). -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] Patch for importing hyperliks from .doc files
2011/9/7 Caolán McNamara caol...@redhat.com: On Mon, 2011-09-05 at 23:57 +0200, Knut Olav Bøhmer wrote: 2011/9/5 Caolán McNamara caol...@redhat.com: On Sun, 2011-09-04 at 00:29 +0200, Knut Olav Břhmer wrote: Hi, This patch solves a serious problem experienced by many companies and need to be included in libreoffice. I'm using this patch with my own build for my customers with ooo 3.2.1 http://openoffice.org/bugzilla/show_bug.cgi?id=114485 Which patch exactly, my patch from #12 or #15 above or something additional ? I think I was using the update patch to handle real-world documents. But it was so long time ago that I compiled it so I don't remember. Do you remember what you needed to improve to make it correct? Is there any example where the patch would not work? The reason I didn't go ahead with that patch IIRC, is because there appear to be *three* places where the hyperlink gets set, and the patch sets two of them, but not the two that really matter. i.e. there's the inline hyperlink in the field itself, there's some hyperlinks stored in the DocumentSummaryStream metadata, and then there's hyperlinks in the data stream associated with basically some FormField structure linked to the field. I think my patch set the DocumentSummaryStream one, but hacking documents manually showed that word used the FormField one if it exists over the metadata one, so I don't think the patch is quite right. Well, in my buggy.doc the hyperlink was located 3 places. Hyperlinks in theese two location was wrong (as I already explaind in the bugreport): gsf cat buggy.doc WordDocument # (I guess this is where FormFields are located) gsf cat buggy.doc Data This was right: gsf cat buggy.doc DocumentSummaryInformation And that's what your patch is using. If LibreOffice would use anything else for this docs, it would be wrong. So if you change it again, I can not use it. Harald, can you confirm that this patch fixes the problem for your docs too? Noel was playing with the fieldfield stuff IIRC, new parsers and the like, which might have some bearing on these, at least on getting the parser right to read the same hyperlink value as word reads. I don't know, but if there is no hyperlink in DocumentSummaryInformation, then word might use the FormField link over the Data one. Best regartds -- Knut Olav Bøhmer ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Bug 40673 - unify build parallelization and use gnu makes --load-average feature where available
On Wed, Sep 7, 2011 at 4:39 AM, Bjoern Michaelsen bjoern.michael...@gmail.com wrote: On Wed, 7 Sep 2011 04:02:36 -0500 Norbert Thiebaud nthiebaud-re5jqeeqqe8avxtiumw...@public.gmane.org wrote: really ? ok so on my Mac I build with max-job=8 num-cpu=6... what value should I use to get the same result under the new scheme? Counter question: Why would you want to get that result? because countless run with many different values show that to a the sweet spot on that box :-) max-job=8 num-cpu=6 gets you something unpredictable between 6 and 48 jobs. The only way why it should work is because modern unix handles overcommitment quite decently (RAM might be more of an issue, but not with your machine). I think you would be just as fast with the new defaults, if not faster. (today that means I get up to 8 jobs with up to 6 task per, except for tail_build where I got 8 -- note that tail_build tend to run alone) I doubt you will ever run the 8 dmake dirs unless you compile binfilter. all I know is that if I lower that, my elapse suffer, and I can see that the cpu is not fully loaded... (and not I/O bound either) Now, yes, if it works (I never tested it), the load average sound more promising than a pure -j n... but then if it works, then why even bother with -j n at all... It works, but: a) on distributed builders (icecream, distcc) the load of the host is not a good measure b) having no limit on -j is risky on start as make will spawn jobs like mad, because most jobs are io-bound in the beginning ok. c) Windows has no sensible load measure if --with-sens-load is present then use the value specified or default to nb_cpu + 1 like you said, but then use -j without value... see b) Also -l will lessen the pain of overcommitment: have some old dmake dirs running and gnu make will 'fill up' the available remaining free load to optimal cpu-usage. don't get me wrong I'm all for -l :-) my beef is with the temporary complication of the max-jobs/nb-cpu rules... add -l support, but let's leave alone nb-cpu/max-jobs for now... a few months and we should have almost everything it not everything under gbuild... then things will get much simpler and saner... Best, Bjoern PS.: Well, I took a look at the count of objects in our build -- ~60% are in gbuild already, and of the remaining ones openssl, berkeleydb, icu, autodoc (which has to die), connectivity and sal are big ones. openssl and berkeleydb and icu are external ones which we should build with gnu make paralellization too. ICU might be a problem... their build system is a home-brew nightmare. with plenty of the dreaded 'bootstrapping' involved. (mmeek: hints hints :-) ) And autodoc has to die (Did I say that already?). Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 Bug 35673 depends on bug 37195, which changed state. Bug 37195 Summary: Dictionary access lost after LibO upgrade https://bugs.freedesktop.org/show_bug.cgi?id=37195 What|Old Value |New Value Resolution||FIXED Status|ASSIGNED|RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] map files: how to update? [was: cppu::OPropertySetHelper ABI backwards compatibility]
On Mon, Sep 05, 2011 at 09:57:30AM +0200, Stephan Bergmann wrote: On Sep 2, 2011, at 5:13 PM, Lionel Elie Mamane wrote: I assume the vtable obviously has to be exported. No, need not be exported (if none of the ctors and dtors are inline). Ah, I had not declared the copy constructor and assignment operator well, which led to the vtable being necessary to export. That is fixed now. Revised patch attached; if it is good to go (especially with respect to questions above), I'll commit (with a better commit message). gcc3.map in the latest patch (sent this morning): - Do not export the thunks (_ZThn), not needed externally. Well, the build fails if they are not exported. So for now, I export them. If the fact that they are needed comes from an error in the class design, please let me know what to do to fix that. Here's the failing build log: = (1/1) Building module comphelper = Entering /home/master/src/libreoffice/core/comphelper/prj cd .. make -s -r -j4 make -s -r deliverlog [ build CXX ] comphelper/source/property/opropertybag [ build CXX ] comphelper/source/property/propagg [ build CXX ] comphelper/source/property/propertybag [ build CXX ] comphelper/source/property/propertycontainer [ build CXX ] comphelper/source/property/propertycontainerhelper [ build CXX ] comphelper/source/property/propertystatecontainer [ build CXX ] comphelper/source/property/propmultiplex [ build CXX ] comphelper/source/property/propstate [ build DEP ] LNK:Library/libcomphelpgcc3.so [ build LNK ] Library/libcomphelpgcc3.so /home/master/src/libreoffice/core/workdir/unxlngx6/CxxObject/comphelper/source/property/opropertybag.o:(.data.rel.ro._ZTVN10comphelper12OPropertyBagE[vtable for comphelper::OPropertyBag]+0x270): undefined reference to `non-virtual thunk to cppu::OPropertySetHelper2::enableChangeListenerNotification(unsigned char)' /home/master/src/libreoffice/core/workdir/unxlngx6/CxxObject/comphelper/source/property/propagg.o:(.data.rel.ro._ZTVN10comphelper29OPropertySetAggregationHelperE[vtable for comphelper::OPropertySetAggregationHelper]+0x200): undefined reference to `non-virtual thunk to cppu::OPropertySetHelper2::enableChangeListenerNotification(unsigned char)' /home/master/src/libreoffice/core/workdir/unxlngx6/CxxObject/comphelper/source/property/propstate.o:(.data.rel.ro._ZTVN10comphelper20OStatefulPropertySetE[vtable for comphelper::OStatefulPropertySet]+0x258): undefined reference to `non-virtual thunk to cppu::OPropertySetHelper2::enableChangeListenerNotification(unsigned char)' /home/master/src/libreoffice/core/workdir/unxlngx6/CxxObject/comphelper/source/property/propstate.o:(.data.rel.ro._ZTVN10comphelper20OPropertyStateHelperE[vtable for comphelper::OPropertyStateHelper]+0x1d0): undefined reference to `non-virtual thunk to cppu::OPropertySetHelper2::enableChangeListenerNotification(unsigned char)' collect2: ld returned 1 exit status make: *** [/home/master/src/libreoffice/core/workdir/unxlngx6/LinkTarget/Library/libcomphelpgcc3.so] Error 1 dmake: Error code 2, while making 'all' -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] build system patches
On Wed, Sep 07, 2011 at 07:21:42AM +0200, Lionel Elie Mamane wrote:
On Tue, Sep 06, 2011 at 07:27:38PM -0500, Norbert Thiebaud wrote:
On Tue, Sep 6, 2011 at 5:32 PM, Peter Foley pefol...@verizon.net wrote:
Here are some patches for various problems I encountered while
building libreoffice.
From 913ba23fd2552436c7c48e83fd1d6ec7de6c2e96 Mon Sep 17 00:00:00 2001
From: Peter Foley pefol...@verizon.net
Date: Mon, 5 Sep 2011 21:39:22 -0400
Subject: [PATCH 2/7] /usr/local/lib
If /usr/local/lib doesn't exist the Mozilla build fails.
This patch fixes the build failure.
Is that an observed behavior or a speculated one ?
I get the same problem (or a very similar one), and reported it as fdo
bug #39852.
I mean:
1/ why on earth would our build ever try to create or even install
something in /usr/loca/bin when building an external lib. if we do,
then the fix is to stop that madness, not encourage it :-)
More precisely, it tries to create ${LIBDIR}; by default, that is
/usr/local/lib, but if one passed --prefix and/org --libdir to
autogen.sh, then it is another directory.
Why the library files are declared in the Makefile.in to depend on
LIBDIR, I have not idea, since they are build locally, not in
LIBDIR. I disabled that (commit
34a3046698890676d492d46dfb628d51eb823395) and works for me. Let's see
if it breaks something else :)
--
Lionel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSOC] how to call python code from the menu
On Tue, 2011-09-06 at 19:49 +0200, Xisco Faulí wrote: Hello, I've tried to follow your steps but placing the code in wizards/com/sun/star/wizards/fax/CallWizard.py. So far I haven't been able to build it successfully. It complains and says: ERROR: File not found: CallWizard.py I see that wizards has been converted to gmake in the meantime, so it no longer uses dmake makefile.mk stuff, we need some gbuild support for copying .py files into their final locations with some form of pyuno .component file support support. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] build only xpcom in moz: not working
Hi, In your commit 291b85778669b4e4e276faab22add9d0e80046df (Build our mozilla (module moz) against the nss we have built anyway.) This hunk: --- a/moz/makefile.mk +++ b/moz/makefile.mk @@ -174,7 +184,7 @@ MOZ_CROSSCOMPILE=CROSS_COMPILE=1 CC=$(CC) -arch $(MOZ_ARCH) CXX=$(CXX) -arch CONFIGURE_ACTION=$(null,$(MOZ_ARCH) $(NULL) $(MOZ_CROSSCOMPILE)) ../configure $(MOZILLA_CONFIGURE_FLAGS) -BUILD_ACTION:=$(GNUMAKE) -j$(EXTMAXPROCESS) +BUILD_ACTION:=cd mozilla/X_objdir/xpcom ; $(GNUMAKE) -j$(EXTMAXPROCESS) .IF $(GUI)==UNX .IF $(COMNAME)==sunpro5 Does not do what you intend from it. 1) Not robust: if the cd fails, the next command (make) is run anyway. Please use instead of ; when chaining commands. 2) solenv/inc/tg_ext.mk prepends cd $(P_BUILD_DIR) when calling BUILD_ACTION, so what is done is e.g.: cd misc/build/mozilla/X_objdir cd mozilla/X_objdir/xpcom ; $(GNUMAKE) -j$(EXTMAXPROCESS) the second cd fails and thus make is executed in X_objdir and not in xpcom. Doing make only in xpcom fails from a clean state (some files that are needed are not built), so I've completely reverted that hunk for now. Feel free to do whatever you meant by this hunk in a way that works :) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [REVIEW] vcredist update, fdo#40399
Hi, Microsoft released a new version of Microsoft Visual C++ 2008 Service Pack 1 Redistributable Package. I updated it in master: http://cgit.freedesktop.org/libreoffice/core/commit/?id=31cd83043eb3bf89be33a9064e04c080883bd14c Please find attached the two patches for libreoffice-3-4. Best regards, Andras 0001-bootstrap-update-to-latest-version-of-vcredist-fdo-40399.patch Description: Binary data 0001-libs-core-update-to-latest-version-of-vcredist-fdo-40399.patch Description: Binary data ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] visibility markup and tests, gotchas
For the cppunit tests there's a wrinkle in that to be able to use symbols which have been visibility marked up to be *private* the .o files with those symbols need to be linked into the test shared lib. e.g. sc's ucalc an sw'd swdoc-test cppunit tests are these When the visibility of the symbols required by a test are public the test shared lib can just be linked to the shared lib in which the symbols live, e.g. sc's and sw's filters-test are these, as are most tests. There's a gotcha if you have e.g. the sw swdoc-test test which is linked together from the same .o's which go into libsw and then get your test to dlopen something which links to the *real* libsw, i.e. duplicate symbols and weird things happen. i.e. the .doc and .rtf filters in sw are implemented by a libmsword.so which links to libsw. *If* the .doc and .rtf filter tests were in swdoc-test then they will fail in some very odd and hard-to-debug ways seeing as libswdoctest.so would end up dlopening indirectly libmsword.so which is linked to libsw.so which comprises of copies of the same .os as comprise libswdoctest.so Anyway, that's why the filters-test in sw and sc are separate from the fat test of the internal apis. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] LibreOffice API documentation is now online
Hello, As a result of the LibreOffice Hackfest 2011 in Munich, the LibreOffice API documentation is now online at http://api.libreoffice.org Thanks to Andras and Miklos for their great work! Maybe someone can add the link to our website? Thanks, Florian -- Florian Effenberger flo...@documentfoundation.org Steering Committee and Founding Member of The Document Foundation Tel: +49 8341 99660880 | Mobile: +49 151 14424108 Skype: floeff | Twitter/Identi.ca: @floeff ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] Patch for importing hyperliks from .doc files
On 07/09/11 09:02, Caolán McNamara wrote: On Mon, 2011-09-05 at 23:57 +0200, Knut Olav Bøhmer wrote: 2011/9/5 Caolán McNamaracaol...@redhat.com: On Sun, 2011-09-04 at 00:29 +0200, Knut Olav Břhmer wrote: [...] Noel was playing with the fieldfield stuff IIRC, new parsers and the like, which might have some bearing on these, at least on getting the parser right to read the same hyperlink value as word reads. C. At the moment I kinda lack the context of the above ( and due to my ongoing mail problems with the list I even miss the beginning of this thread ) However in my adventures with the formfield stuff I don't recall doing anything with hyperlinks per-se, I might have tweaked some offset or something to do with a hyperlink record in order to properly read/skip something that was failing over but afaik I didn't tweak anything to do with actual parsing of hyperlinks ( afaik ) Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED][REVIEW-3-4] Fix leak in pdf export
On Sun, 2011-09-04 at 11:49 +0200, Thorsten Behrens wrote: Hi there, Andor kindly fixed $subject (that got independently fixed on master) - could someone please review, sign-off push to -3-4? Looks correct to me, pushed to 3-4. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 Bug 35673 depends on bug 39510, which changed state. Bug 39510 Summary: CRASH closing document with footnotes https://bugs.freedesktop.org/show_bug.cgi?id=39510 What|Old Value |New Value Resolution|FIXED | Status|RESOLVED|REOPENED -- 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] [PUSHED] new BITxxx functions for ODF 1.2
Hi Wolfgang, On Sunday, 2011-09-04 11:28:58 +0200, l...@pechlaner.at wrote: I've made the new Functions BITAND, BITOR, BITXOR BITRSHIFT and BITLSHIFT,, how declared in the ODF 1.2 specification. Can anyone have a look on this Patches. So you successfully waded your way through, good :) As a basis for the commit I used the version without whitespace changes and with blanks instead of tabs provided by Thorsten and Niko (thanks guys!). It seems you were working on a rather old version of the split repositories, I suggest you upgrade to the OneGit core repository, see http://www.libreoffice.org/get-involved/developers/ For my usual nitpicks and changes ;-) please see http://cgit.freedesktop.org/libreoffice/core/commit/?id=c6b49f9098fb6c9816202e8d465c342788736af5 Please also confirm that you contribute this and future patches licensed under LGPLv3+ and MPL 1.1 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 signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Updated [Patch] new BITxxx functions for ODF 1.2
Hi Korrawit, On Tuesday, 2011-09-06 21:52:46 +0700, Korrawit Pruegsanusak wrote: And please s/interger/integer ;) Did that in the commit. Also, it seems that you haven't check the range of ishift yet, whether it is between -48 and 48 (from your description), or it isn't necessary? I don't have knowledge on this. Actually those don't have to be restricted and I implemented another algorithm to support larger values. My last nitpick, what about the strings capitalization? Also did that. Eike -- PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication. Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] map files: how to update? [was: cppu::OPropertySetHelper ABI backwards compatibility]
On 09/07/2011 12:14 PM, Lionel Elie Mamane wrote: On Mon, Sep 05, 2011 at 09:57:30AM +0200, Stephan Bergmann wrote: On Sep 2, 2011, at 5:13 PM, Lionel Elie Mamane wrote: I assume the vtable obviously has to be exported. No, need not be exported (if none of the ctors and dtors are inline). Ah, I had not declared the copy constructor and assignment operator well, which led to the vtable being necessary to export. That is fixed now. good Revised patch attached; if it is good to go (especially with respect to questions above), I'll commit (with a better commit message). gcc3.map in the latest patch (sent this morning): - Do not export the thunks (_ZThn), not needed externally. Well, the build fails if they are not exported. So for now, I export them. If the fact that they are needed comes from an error in the class design, please let me know what to do to fix that. Hm, had *thought* they were not really needed, and had run a small test case to verify, but it seems there are nevertheless cases where they *are* needed. If you have no inline functions left (neither implicit nor explicit ones, incl. default functions provided by the compiler), then poor class design cannot be the reason. -- Just export them, I would say. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Updated [Patch] new BITxxx functions for ODF 1.2
Hi Olivier, On Sunday, 2011-09-04 16:42:38 -0300, Olivier Hallot wrote: If pushed, these new functions should be advertised in the Release notes. What's the procedure for that? Eike -- PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication. Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] License for my patch
Hi, all my pathes are under LPGLv3+ and MPL 1.1. free software for free people. Wolfgang ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Mail problems with this list (Was Re: [REVIEW] Patch for importing hyperliks from .doc files)
Hi, Noel Power wrote (07-09-11 13:19) At the moment I kinda lack the context of the above ( and due to my ongoing mail problems with the list I even miss the beginning of this thread ) Had this too. Just subscribed with a different address to get around it (i.e. receive mails again). Had troubles too with bugs.freedesktop mail. Is sort of solved by a setting (...) done by one of the admins, that holds till the next reboot :-\ I was advised that Reverse DNS was the problem. However, checking mine via internet tools gives OK as outcome (but that could haven been just after the admin had done 'the setting'. :-( -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] dev with access to Windows/MSVC build sought
Could someone with access to Windows/MSVC build please update cppuhelper/source/msvc_win32_intel.map ? You need to make the equivalent changes as section UDK_3.8 in gcc3.map, following the revert of the recent changes there by Kohei and the introduction of OPropertySetHelper2. I made some changes based on guessing the MSVC name mangling format, but you'll need to check them, and my changes are nearly certainly incomplete. See http://udk.openoffice.org/common/man/apicppclasses.html for some general and MSVC-specific instructions. -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Mail problems with this list (Was Re: [REVIEW] Patch for importing hyperliks from .doc files)
On 07/09/2011 14:15, Cor Nouws wrote: Hi, Noel Power wrote (07-09-11 13:19) At the moment I kinda lack the context of the above ( and due to my ongoing mail problems with the list I even miss the beginning of this thread ) Had this too. Just subscribed with a different address to get around it (i.e. receive mails again). Had troubles too with bugs.freedesktop mail. Is sort of solved by a setting (...) done by one of the admins, that holds till the next reboot :-\ I was advised that Reverse DNS was the problem. However, checking mine via internet tools gives OK as outcome (but that could haven been just after the admin had done 'the setting'. :-( I would poke Kendy as i have been blocked for emails bouncing when I havent sent any on a particular day to the list. It could be the emails you guys are having issues with are either greylisted or blocked on the mailing list ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] build only xpcom in moz: not working
On 09/07/2011 12:36 PM, Lionel Elie Mamane wrote: In your commit 291b85778669b4e4e276faab22add9d0e80046df (Build our mozilla (module moz) against the nss we have built anyway.) [...] Doing make only in xpcom fails from a clean state (some files that are needed are not built), so I've completely reverted that hunk for now. Feel free to do whatever you meant by this hunk in a way that works :) see also thread around http://lists.freedesktop.org/archives/libreoffice/2011-September/017824.html -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Try to improve LibreOffice
Hello! Can I try to improve LibreOffice? I had found task «Improving Saving Information Icon in the Status Bar» (http://bugs.freedesktop.org/show_bug.cgi?id=39430). But I don't know who can help me, who can give me icons. -- Best Regards, Dmitry attachment: dmitry_ashkadov.vcf___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Updated [Patch] new BITxxx functions for ODF 1.2
Hi Regina, On Wednesday, 2011-09-07 15:04:47 +0200, Regina Henschel wrote: I see a lot of sal_uInt64 in the code. Is that supported for Windows? As far as I know at least the MSVC Express has only 4Byte long. Umm.. now that you mention.. sal/inc/sal/types.h has #if (_MSC_VER = 1000) typedef __int64 sal_Int64; typedef unsigned __int64 sal_uInt64; so what evaluates _MSC_VER to in MSVCE? Also noticing there #define SAL_CONST_UINT64(x) x##ui64 so the constant I introduced probably should use that. If MSVCE doesn't support 64bit values I might do some tricks using the double mantissa. Eike -- PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication. Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] gbuild of external libraries and question about apparently special case like zlib, jpeg etc.
Hi Norbert, On Sunday, 2011-09-04 16:47:04 -0500, Norbert Thiebaud wrote: I've been working on gbuildification of 'external libraires' taking the approach of untar - patch - configure - post_patch (sometimes it may be easier/useful to patch the result of configure, rather that the input) - make - make install (--prefix=solver) and make uninstall to clean the 'delivered stuff Please ensure that creating a patch on top of the others still works, in dmake that's the create_patch target in solenv/inc/tg_ext.mk 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 signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Updated [Patch] new BITxxx functions for ODF 1.2
On 09/07/2011 04:37 PM, Eike Rathke wrote: Hi Regina, On Wednesday, 2011-09-07 15:04:47 +0200, Regina Henschel wrote: I see a lot of sal_uInt64 in the code. Is that supported for Windows? As far as I know at least the MSVC Express has only 4Byte long. Umm.. now that you mention.. sal/inc/sal/types.h has #if (_MSC_VER= 1000) typedef __int64 sal_Int64; typedef unsigned __int64 sal_uInt64; so what evaluates _MSC_VER to in MSVCE? Also noticing there #define SAL_CONST_UINT64(x) x##ui64 so the constant I introduced probably should use that. If MSVCE doesn't support 64bit values I might do some tricks using the double mantissa. But we use sal_[u]Int64 all over the code base, and the default case in sal/types.h (to typedef it to a struct of smaller ints) is long gone, so I would assume _MSC_VER=1000 really means any _MSC_VER here. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] undo/redo inserting cells in merged cells with shadows result in strange behavior
Hi Markus, On Tuesday, 2011-09-06 21:47:16 +0200, Markus Mohrhard wrote: this patch removes some code that resulted in strange behavior with merged areas and shadows. That doesn't look right. ExtendMerge() includes a row/column that is affected by the merged area's shadow and needs to be repainted after redo. The code extended the merged area by one column/row which resulted in strange behavior with undo/redo. And the strange behavior is? It seems that the code was an old hack for the ui part that is no longer needed. I doubt that. Or what did change in that area? Eike -- PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication. Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] License for my patch
Hi Wolfgang, On Wednesday, 2011-09-07 14:58:50 +0200, Wolfgang Pechlaner wrote: all my pathes are under LPGLv3+ and MPL 1.1. free software for free people. Great :-) 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 signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Updated [Patch] new BITxxx functions for ODF 1.2
Visual Studio has supported 64-bit int types (long long) since at least Visual Studio 2005. See here: http://msdn.microsoft.com/en-us/library/s3f49ktz(v=vs.80).aspx http://msdn.microsoft.com/en-us/library/s3f49ktz%28v=vs.80%29.aspx _MSC_VER evaluates to the version of the Visual Studio compiler. See here: http://msdn.microsoft.com/en-us/library/b0084kay(v=VS.80).aspx http://msdn.microsoft.com/en-us/library/b0084kay%28v=VS.80%29.aspx Eike Rathke wrote: Hi Regina, On Wednesday, 2011-09-07 15:04:47 +0200, Regina Henschel wrote: I see a lot of sal_uInt64 in the code. Is that supported for Windows? As far as I know at least the MSVC Express has only 4Byte long. Umm.. now that you mention.. sal/inc/sal/types.h has #if (_MSC_VER = 1000) typedef __int64 sal_Int64; typedef unsigned __int64 sal_uInt64; so what evaluates _MSC_VER to in MSVCE? Also noticing there #define SAL_CONST_UINT64(x) x##ui64 so the constant I introduced probably should use that. If MSVCE doesn't support 64bit values I might do some tricks using the double mantissa. Eike ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Updated [Patch] new BITxxx functions for ODF 1.2
Hi Eike, Eike Rathke schrieb: Hi Regina, On Wednesday, 2011-09-07 15:04:47 +0200, Regina Henschel wrote: I see a lot of sal_uInt64 in the code. Is that supported for Windows? As far as I know at least the MSVC Express has only 4Byte long. Umm.. now that you mention.. sal/inc/sal/types.h has #if (_MSC_VER= 1000) typedef __int64 sal_Int64; typedef unsigned __int64 sal_uInt64; so what evaluates _MSC_VER to in MSVCE? How can I get that information? In Env.Host.sh I get the lines: SIZEOF_SHORT=2 SIZEOF_INT=4 SIZEOF_LONG=4 SIZEOF_LONGLONG=8 SIZEOF_POINTER=4 Kind regards Regina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] cppcheck cleanliness: duplicate expression
Hello all, Attached patch will clear the cppcheck warning for duplicate expression on both sides of ''. Best Regards, -- Korrawit Pruegsanusak 0001-cppcheck-cleaning-duplicate-expression-on-both-sides.patch Description: Binary data ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] odd (master) style application bug ...
Hi guys, Playing with the (beautiful) merging fix on master - I was struck by the apparent reality that calc has broken style application. Load the attached in master, double click 'Fun' in the style-list - no big/green madness :-) Try on 3.4.x and it works as expected. Hopefully it's easy; I have: 5b80048a1ef119db569f9e9a259e94e773201b1f And of course, perhaps I've broken my build (its entirely possible I have some un-committed work). Thanks, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot style.ods Description: application/vnd.oasis.opendocument.spreadsheet ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] undo/redo inserting cells in merged cells with shadows result in strange behavior
Hi Markus, On Tuesday, 2011-09-06 21:47:16 +0200, Markus Mohrhard wrote: this patch removes some code that resulted in strange behavior with merged areas and shadows. The code extended the merged area by one column/row which resulted in strange behavior with undo/redo. It seems that the code was an old hack for the ui part that is no longer needed. Ok, after some discussion on IRC and inspecting details it turned out the old behavior was terribly wrong. Cherry-picked to 3-4 http://cgit.freedesktop.org/libreoffice/calc/commit/?h=libreoffice-3-4id=577bf305f26f70cb3ef9dee9f0063f83e51b 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 signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSOC] how to call python code from the menu
On Wed, 2011-09-07 at 11:24 +0100, Caolán McNamara wrote: On Tue, 2011-09-06 at 19:49 +0200, Xisco Faulí wrote: Hello, I've tried to follow your steps but placing the code in wizards/com/sun/star/wizards/fax/CallWizard.py. So far I haven't been able to build it successfully. It complains and says: ERROR: File not found: CallWizard.py I see that wizards has been converted to gmake in the meantime, so it no longer uses dmake makefile.mk stuff, we need some gbuild support for copying .py files into their final locations with some form of pyuno .component file support support. dtardon was good enough to put together the gmake stuff needed to get this bootstrapped, which are now committed to master. So here's your patch back again, except gbuildified so this should work to make wizards-fax stick hello world into writer. There's still a lot of nasty things, dumping the .py directly into program as opposed to making some sort of subdir into which they can go, but maybe it'll help C. From 9e5fa73cecb5ce2676bde611e4ab38611c9533d4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Caol=C3=A1n=20McNamara?= caol...@redhat.com Date: Wed, 7 Sep 2011 17:15:52 +0100 Subject: [PATCH] demo, for the purposes of saying hello world --- instsetoo_native/util/makefile.mk |1 + .../registry/data/org/openoffice/Office/Common.xcu |2 +- postprocess/packcomponents/makefile.mk |2 +- scp2/source/ooo/file_ooo.scp | 12 ++ scp2/source/ooo/module_hidden_ooo.scp |2 +- scripting/prj/d.lst|1 + wizards/Module_wizards.mk |2 +- wizards/Pyuno_fax.mk | 34 wizards/com/sun/star/wizards/fax/CallWizard.py | 175 wizards/com/sun/star/wizards/fax/fax.component |6 +- 11 files changed, 87 insertions(+), 152 deletions(-) create mode 100644 wizards/Pyuno_fax.mk diff --git a/instsetoo_native/util/makefile.mk b/instsetoo_native/util/makefile.mk index 6880750..fc1cc61 100644 --- a/instsetoo_native/util/makefile.mk +++ b/instsetoo_native/util/makefile.mk @@ -74,6 +74,7 @@ LOCALPYFILES= \ $(BIN)$/pythonloader.py \ $(BIN)$/officehelper.py \ $(BIN)$/mailmerge.py \ +$(BIN)$/CallWizard.py \ $(BIN)$/msgbox.py .ENDIF diff --git a/officecfg/registry/data/org/openoffice/Office/Common.xcu b/officecfg/registry/data/org/openoffice/Office/Common.xcu index 998ab38..85d4480 100644 --- a/officecfg/registry/data/org/openoffice/Office/Common.xcu +++ b/officecfg/registry/data/org/openoffice/Office/Common.xcu @@ -400,7 +400,7 @@ /node node oor:name=m1 oor:op=replace install:module=writer prop oor:name=URL oor:type=xs:string - value service:com.sun.star.wizards.fax.CallWizard?start/value + value service:com.sun.star.wizards.fax.CallWizard?insert/value /prop prop oor:name=Title value xml:lang=en-US~Fax.../value diff --git a/postprocess/packcomponents/makefile.mk b/postprocess/packcomponents/makefile.mk index 33f0f01..05bf897 100644 --- a/postprocess/packcomponents/makefile.mk +++ b/postprocess/packcomponents/makefile.mk @@ -370,7 +370,7 @@ my_components += evoab my_components += component/avmedia/source/gstreamer/avmediagstreamer .END -my_ooo_components = mailmerge +my_ooo_components = mailmerge component/wizards/com/sun/star/wizards/fax/fax .INCLUDE: target.mk diff --git a/scp2/source/ooo/file_ooo.scp b/scp2/source/ooo/file_ooo.scp index 61589b6..4583dec 100644 --- a/scp2/source/ooo/file_ooo.scp +++ b/scp2/source/ooo/file_ooo.scp @@ -472,6 +472,18 @@ STD_JAR_FILE( gid_File_Jar_Saxon, saxon9 ) #endif #endif +#ifndef AIX +#ifndef DISABLE_PYUNO +File gid_File_PyFax +TXT_FILE_BODY; +Dir = gid_Dir_Program; +Name = CallWizard.py; +Styles = (PACKED); +End +#endif +#endif + + #ifndef SYSTEM_LIBTEXTCAT_DATA // fingerprint files (lm) diff --git a/scp2/source/ooo/module_hidden_ooo.scp b/scp2/source/ooo/module_hidden_ooo.scp index 273f802..c25c87b 100644 --- a/scp2/source/ooo/module_hidden_ooo.scp +++ b/scp2/source/ooo/module_hidden_ooo.scp @@ -139,7 +139,7 @@ Module gid_Module_Root_Files_3 gid_File_Jar_Table, gid_File_Jar_Letter, gid_File_Jar_Form, - gid_File_Jar_Fax, + gid_File_PyFax, gid_File_Jar_Agenda, gid_File_Jar_Web, gid_File_Jar_Query, diff --git a/scripting/prj/d.lst b/scripting/prj/d.lst index f1caf45..5deedbe 100644 --- a/scripting/prj/d.lst +++ b/scripting/prj/d.lst @@ -16,6 +16,7 @@ mkdir: %_DEST%\bin\pyuno ..\%__SRC%\lib\lib*static*.dylib %_DEST%\lib\lib*static*.dylib ..\%__SRC%\misc\mailmerge.component %_DEST%\xml\mailmerge.component +..\%__SRC%\misc\fax.component %_DEST%\xml\fax.component ..\%__SRC%\misc\ScriptFramework.component %_DEST%\xml\ScriptFramework.component ..\%__SRC%\misc\ScriptProviderForJava.component %_DEST%\xml\ScriptProviderForJava.component
Re: [Libreoffice] Updated [Patch] new BITxxx functions for ODF 1.2
Hmm,MSC_VER 1600 is VC++ 2010
1500 is VC++ 2008
I don't have any older versions installed at the moment. (The enclosed program
I used to find these has CRLF for newlines and probably no tabs.)
- Dennis
-Original Message-
From: libreoffice-bounces+dennis.hamilton=acm@lists.freedesktop.org
[mailto:libreoffice-bounces+dennis.hamilton=acm@lists.freedesktop.org] On
Behalf Of Regina Henschel
Sent: Wednesday, September 07, 2011 07:58
To: Korrawit Pruegsanusak; l...@pechlaner.at; Thorsten Behrens;
libreoffice@lists.freedesktop.org
Subject: Re: [Libreoffice] Updated [Patch] new BITxxx functions for ODF 1.2
Hi Eike,
Eike Rathke schrieb:
Hi Regina,
On Wednesday, 2011-09-07 15:04:47 +0200, Regina Henschel wrote:
I see a lot of sal_uInt64 in the code. Is that supported for
Windows? As far as I know at least the MSVC Express has only 4Byte
long.
Umm.. now that you mention.. sal/inc/sal/types.h has
#if (_MSC_VER= 1000)
typedef __int64 sal_Int64;
typedef unsigned __int64 sal_uInt64;
so what evaluates _MSC_VER to in MSVCE?
How can I get that information?
In Env.Host.sh I get the lines:
SIZEOF_SHORT=2
SIZEOF_INT=4
SIZEOF_LONG=4
SIZEOF_LONGLONG=8
SIZEOF_POINTER=4
Kind regards
Regina
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
/* showdefs.c Program to report the compiler definitions that were set when
*it was compiled.
*
*1.00 2005-09-13-16:09 This programs uses preprocessor tricks to see
* what the settings of possibly pre-defined macros are.
*1.01 2005-09-13-22:43 correct the number of underscores in front of
* cplusplus and MSVC_RUNTIME_CHECKS
*1.10 2005-09-14-07:48 Put in some conditional code around the pragma
* and add information for compiling as either C, C++, and C++
* without exception handling to show the differences in the
* settings that the compiler figures out from the name of the
* source program. Add more documentation inspired by my
* long-distance pair-programming buddy Bill Anderson's running this
* against GCC.
*
* $Header: /MyProjects/ShowDefs/showdefs.c 1 06-03-23 9:07 Orcmid $
*/
#include stdio.h
/* for printf() */
#include string.h
/* for strlen() */
#define TV(X) #X
/* Always produce a string, even when X is empty */
#define SHOW(X, SP) printf(SP #X %s\n, \
( tv = TV(X), \
strlen(tv) == 0 \
? is defined \
: strcmp(tv, #X) == 0 \
? undefined \
: TV(is defined to X) ) )
#ifdef _MSC_VER
#pragma warning(disable: 4003)
/* Do not warn about TV(x) when not enough parameters (i.e., x empty) */
#endif
int main()
{/* Report predefined macros that may be set by default in this compiler.
*/
char *tv; /* pointer to the token value string */
printf(\nshowdef 1.10 Check for documented pre-processor macros);
printf(\n that might be predefined in this compile.\n);
printf(\n Supported ANSI/ISO Macros:\n);
SHOW(__DATE__, );
SHOW(__FILE__, );
SHOW(__LINE__, );
SHOW(__STDC__, );
SHOW(__TIME__, );
printf(\n Supported (VC++?) reflection support:\n);
SHOW(__COUNTER__, );
SHOW(__cplusplus, );
SHOW(__FUNCTION__, );
SHOW(__FUNCDNAME__,);
SHOW(__FUNCSIG__, );
SHOW(__TIMESTAMP__,);
printf(\n VC++ MS-Specific Macros:\n);
SHOW(_ATL_VER, );
SHOW(_CHAR_UNSIGNED, );
SHOW(_CPPLIB_VER, );
SHOW(_CPPRTTI, );
SHOW(_CPPUNWIND, );
SHOW(_DEBUG, );
SHOW(_DLL, );
SHOW(_M_ALPHA, );
SHOW(_M_IA64, );
SHOW(_M_IX86, );
SHOW(_M_MPPC, );
SHOW(_M_MRX000,);
SHOW(_M_PPC, );
SHOW(_MANAGED, );
SHOW(_MFC_VER, );
SHOW(_MSC_EXTENSIONS, );
SHOW(_MSC_VER, );
SHOW(__MSVC_RUNTIME_CHECKS,);
SHOW(_MT, );
SHOW(_NATIVE_WCHAR_T_DEFINED, );
SHOW(_WCHAR_T_DEFINED, );
SHOW(_WIN32, );
SHOW(_WIN64, );
printf(\n And some favorites when compiling Windows code:\n);
SHOW(_INC_WINDOWS, );
Re: [Libreoffice] Updated [Patch] new BITxxx functions for ODF 1.2
Um, of course, having 64 bit integers and having the bit-wise functions work on them at full width is a bit different. Easy to test though. The Visual C++ Express Editions have had the same 64-bit (long long) support as the full-up Visual Studio Professional editions, etc., since the first (Visual C++ Express Edition 2005). - Dennis -Original Message- From: libreoffice-bounces+dennis.hamilton=acm@lists.freedesktop.org [mailto:libreoffice-bounces+dennis.hamilton=acm@lists.freedesktop.org] On Behalf Of Noel Grandin Sent: Wednesday, September 07, 2011 07:49 To: Regina Henschel; Korrawit Pruegsanusak; l...@pechlaner.at; Thorsten Behrens; libreoffice@lists.freedesktop.org Subject: Re: [Libreoffice] Updated [Patch] new BITxxx functions for ODF 1.2 Visual Studio has supported 64-bit int types (long long) since at least Visual Studio 2005. See here: http://msdn.microsoft.com/en-us/library/s3f49ktz(v=vs.80).aspx http://msdn.microsoft.com/en-us/library/s3f49ktz%28v=vs.80%29.aspx _MSC_VER evaluates to the version of the Visual Studio compiler. See here: http://msdn.microsoft.com/en-us/library/b0084kay(v=VS.80).aspx http://msdn.microsoft.com/en-us/library/b0084kay%28v=VS.80%29.aspx Eike Rathke wrote: Hi Regina, On Wednesday, 2011-09-07 15:04:47 +0200, Regina Henschel wrote: I see a lot of sal_uInt64 in the code. Is that supported for Windows? As far as I know at least the MSVC Express has only 4Byte long. Umm.. now that you mention.. sal/inc/sal/types.h has #if (_MSC_VER = 1000) typedef __int64 sal_Int64; typedef unsigned __int64 sal_uInt64; so what evaluates _MSC_VER to in MSVCE? Also noticing there #define SAL_CONST_UINT64(x) x##ui64 so the constant I introduced probably should use that. If MSVCE doesn't support 64bit values I might do some tricks using the double mantissa. Eike ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Updated [Patch] new BITxxx functions for ODF 1.2
Hi Dennis, Dennis E. Hamilton schrieb: Um, of course, having 64 bit integers and having the bit-wise functions work on them at full width is a bit different. Easy to test though. The Visual C++ Express Editions have had the same 64-bit (long long) support as the full-up Visual Studio Professional editions, etc., since the first (Visual C++ Express Edition 2005). Thanks, I didn't know, that is works in Express Editions too. When my build is finished, I can try the new functions nevertheless and report, if I get an error. Kind regards Regina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Updated [Patch] new BITxxx functions for ODF 1.2
Hi Eike Well... no specific procedure, except to edit the wiki as I did (just to not forget it): http://wiki.documentfoundation.org/ReleaseNotes/3.5#Calc Olivier Em 07-09-2011 09:51, Eike Rathke escreveu: Hi Olivier, On Sunday, 2011-09-04 16:42:38 -0300, Olivier Hallot wrote: If pushed, these new functions should be advertised in the Release notes. What's the procedure for that? Eike -- Olivier Hallot Founder, Steering Commitee Member - The Document Foundation Voicing the enterprise needs LibreOffice translation leader for Brazilian Portuguese +55-21-8822-8812 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Updated [Patch] new BITxxx functions for ODF 1.2
Visual Studio has supported 64-bit int types (long long) since at least Visual Studio 2005. Isn't __int64 (and unsigned __int64) the more traditional name for the 64-bit integer types in MSVC? long long is newer in MSVC; in other compilers it is of course the normal one. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Licensing
___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Try to improve LibreOffice
Hi Dmitry, all! Am Mittwoch, den 07.09.2011, 18:10 +0400 schrieb Dmitry. A. Ashkadov: Hello! Can I try to improve LibreOffice? I had found task «Improving Saving Information Icon in the Status Bar» (http://bugs.freedesktop.org/show_bug.cgi?id=39430). Great! But I don't know who can help me, who can give me icons. The icons are part of the issue 39430 - there is a bug property called URL which refers to the TDF wiki. The link is: http://wiki.documentfoundation.org/File:Status-Bar-Saving-Info-icons.zip (Ah, just saw that Andras already added the link in a comment.) Since we talk about the icons: it would be great if you could exchange all the icons, since the unsaved changes icon seems to either be wrong or be wrongly scaled at the moment. Currently the contact in the bug (Paulo) is temporarily offline due to his studies - so feel free to contact me or anybody in the Design team. The best way to do that is to ping the Design Team is the mailing list libreoffice-ux-advise (no subscription required). More information at [1]. Otherwise, I've CCed myself on that issue. Thanks for you help! :-) Cheers, Christoph [1] http://wiki.documentfoundation.org/Design#Communication ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] convert Mesa to gbuild
On 07.09.2011 21:15, Peter Foley wrote: This is my first attempt at converting a module to gbuild so I'd appreciate it if someone knowlegeable about gbuild could take a look. Thanks, Peter hi Peter, looks good, didn't know we have such a simple module :) only thing missing is that you should add the module to the top-level Module_ooo.mk. actually it seems somebody renamed it to RepositoryModule_ooo.mk. ok, fits in better with the other RepositoryFoo.mk stuff. but why not just RepositoryModule.mk? uhm, sorry for the digression :) regards, michael ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Licensing
On Wed, 7 Sep 2011, Peter Foley wrote: All of my patches are contributed under MPL 1.1/GLPv3+/LGPLv3+ Thanks, Peter ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] convert Mesa to gbuild
On Wed, Sep 7, 2011 at 2:45 PM, Michael Stahl m...@openoffice.org wrote: On 07.09.2011 21:15, Peter Foley wrote: This is my first attempt at converting a module to gbuild so I'd appreciate it if someone knowlegeable about gbuild could take a look. Thanks, Peter hi Peter, looks good, didn't know we have such a simple module :) I wonder would that work dep wise to just have a packaging step ? only thing missing is that you should add the module to the top-level Module_ooo.mk. and also tell the slideshow module to depend on it (right now it is done via build.lst... but Mesa can be integrated to tail_build, as it fulfill the requirement to do so) which might be a problem since I don't know that we have an api to declare pure include-packaging mode dep... the closest thing we have is gb_LinkTarget_add_api, but it is an overkill here as it try to add stuff in $INCLUDE... actually it seems somebody renamed it to RepositoryModule_ooo.mk. yep, because there was a clash with Module_tail_build.mk (which needed to be at the root) and the fact the gmake search for anything Module_* , so it was accidentally picking up Module_ooo.mk. Hence the rename. ok, fits in better with the other RepositoryFoo.mk stuff. but why not just RepositoryModule.mk? Some hope/anticipation that there may be more than one product sharing the same spaces ? not sure... Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] convert Mesa to gbuild
ok, fits in better with the other RepositoryFoo.mk stuff. but why not just RepositoryModule.mk? Some hope/anticipation that there may be more than one product sharing the same spaces ? not sure... I have never fully understood why we have these Repository*.mk files in the top directory at all. Why can't this stuff, for us in LibreOffice, be in solenv/gbuild? --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Updated [Patch] new BITxxx functions for ODF 1.2
Hi Olivier, On Wednesday, 2011-09-07 15:59:29 -0300, Olivier Hallot wrote: Well... no specific procedure, except to edit the wiki as I did (just to not forget it): http://wiki.documentfoundation.org/ReleaseNotes/3.5#Calc Thanks, just needed a pointer.. Eike -- PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication. Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] odd (master) style application bug ...
Hi, Michael Meeks wrote (07-09-11 17:37) Playing with the (beautiful) merging fix on master - I was struck by the apparent reality that calc has broken style application. Load the attached in master, double click 'Fun' in the style-list - no big/green madness :-) Try on 3.4.x and it works as expected. Hopefully it's easy; I have: 5b80048a1ef119db569f9e9a259e94e773201b1f And of course, perhaps I've broken my build (its entirely possible I have some un-committed work). It's already there for some time. Oldest build I have here, does show it too: 2011-08-19 Build ID: 35913b9-4eb4f62-260b7c1 more findings: apply style fun nothing happens (visible) document is dirty use bucket, then switch to page styles no shows, swith to cell styles empty too Cheers, -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] fix for fdo#33960 cross reference to a list number, dot bug makes sw/qa/complex/writer fail
On Wednesday 07 September 2011, Stephan Bergmann wrote: Troy, will you come up with a fix that brings sw/source/core/doc/number.cxx and sw/qa/complex/writer/CheckCrossReferences.java in sync again? I won't be able to do that until mid November due to other commitments. -- t...@troy.rollo.name - Sydney, Australia signature.asc Description: This is a digitally signed message part. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Updated [Patch] new BITxxx functions for ODF 1.2
Hi Regina, On Wednesday, 2011-09-07 16:58:04 +0200, Regina Henschel wrote: so what evaluates _MSC_VER to in MSVCE? How can I get that information? In Env.Host.sh I get the lines: SIZEOF_LONGLONG=8 I think if long long is supported to be 8 bytes we can safely assume that the typedef of sal_uInt64 does the right thing :) And as Stephan mentioned, we already use it all over the place. Eike -- PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication. Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] convert Mesa to gbuild
On 07.09.2011 22:40, Tor Lillqvist wrote:
ok, fits in better with the other RepositoryFoo.mk stuff.
but why not just RepositoryModule.mk?
Some hope/anticipation that there may be more than one product sharing
the same spaces ? not sure...
I have never fully understood why we have these Repository*.mk files
in the top directory at all. Why can't this stuff, for us in
LibreOffice, be in solenv/gbuild?
there's a reason why they are called Repository*.mk: the idea was that
every HG repository would have these at the root, and you could then
combine all of them (via the gb_REPOS variable) into a single make process.
in Hamburg we had the ooo, sun (non-free) and (since DEV300m101)
l10n HG repositories.
but apparently LO has never made use of this mechanism; instead ugly
symlinks are created to link the modules that are not in core into the
top-level directory.
ok, guess this has the advantage that you probably don't need to use the
horrible source_config contraption... as i suggested a different mailing
list today, build.pl should just respect ${gb_REPOS}, then source_config
is unnecessary.
regards,
michael
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] convert Mesa to gbuild
On Wed, 7 Sep 2011 15:32:21 -0500 Norbert Thiebaud nthieb...@gmail.com wrote: I wonder would that work dep wise to just have a packaging step ? $(call gb_Library_get_headers_target,libthatneedsmesa) : \ $(call gb_Package_get_target,Mesa_inc) Of course, we could create a new name for that, but IMHO that is simple enough as is. ok, fits in better with the other RepositoryFoo.mk stuff. but why not just RepositoryModule.mk? Some hope/anticipation that there may be more than one product sharing the same spaces ? not sure... Not only hope, but actually a hard requirement. There has been this other product which was closely related to OOo, you know ... Also: solenv/gbuild was originally created to be project-agnostic, and in theory the contents of that dir should be independent of the first project which happens to use it. And gbuild needed to be able to build multiple sources from independent repositories (without resorting to dirty symlink tricks -- exactly the stuff that did bite us on cygwin then). Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [REVIEW] new patch for svgwriter
Hello, After having listened the advice of Caolán and Thorsten, here is a new patch for svgwriter.cxx (filter module). I hope having followed the guidelines and haven't missed anything this time. Julien. http://nabble.documentfoundation.org/file/n3318017/newpatchsvgwriter.txt newpatchsvgwriter.txt PS : as usual, if it's ok, just tell me and I'll commit and push it on master repo. -- View this message in context: http://nabble.documentfoundation.org/REVIEW-svgwriter-SVGActionWriter-ImplWriteText-uses-auto-prt-with-new-tp3306210p3318017.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] [PATCH] convert Mesa to gbuild
On 07.09.2011 22:32, Norbert Thiebaud wrote: On Wed, Sep 7, 2011 at 2:45 PM, Michael Stahl m...@openoffice.org wrote: On 07.09.2011 21:15, Peter Foley wrote: This is my first attempt at converting a module to gbuild so I'd appreciate it if someone knowlegeable about gbuild could take a look. Thanks, Peter hi Peter, looks good, didn't know we have such a simple module :) I wonder would that work dep wise to just have a packaging step ? only thing missing is that you should add the module to the top-level Module_ooo.mk. and also tell the slideshow module to depend on it (right now it is done via build.lst... but Mesa can be integrated to tail_build, as it fulfill the requirement to do so) which might be a problem since I don't know that we have an api to declare pure include-packaging mode dep... the closest thing we have is gb_LinkTarget_add_api, but it is an overkill here as it try to add stuff in $INCLUDE... good catch, that indeed seems to be missing. guess gb_LinkTarget__add_internal_headers can't be used if the headers come from a different module, because it would break module-only build? how about something like this: define gb_LinkTarget_add_external_headers $(call gb_LinkTarget_get_external_headers_target,$(1)) :| \ $(call gb_Package_get_target,$(2)) endef ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] speed up localized builds by introducing po2lo
Hi,
We discussed with Andras that one of the bottleneck of a build with many
languages is the slowness of the po2oo script from translations-toolkit.
I gave it a try to rewrite it as a standalone script, and it seems to be
quite fast here:
$ time po2oo --skipsource -i hu/ -o hu.sdf -l hu -t en-US.sdf hu.sdf
real0m32.842s
user0m29.205s
sys 0m1.439s
$ time ./po2lo --skipsource -i hu/ -o hu.sdf -l hu -t en-US.sdf hu.sdf
real0m3.756s
user0m3.344s
sys 0m0.143s
The localized sdf file differs, but once you sort its contents, it's the
same for me.
Note that this does not remove the dependency on translations-toolkit:
the oo2po script is still used (but that's not invoked during a normal
build).
I'm attaching two patches:
- one for core.git, which adds the new po2lo script (localize was
already in solenv/bin, so I pot this one there as well).
- one for translations.git to actually use the new script: here I took a
look at how python is invoked in filters and did the same.
Andras, could you please give it some testing? I didn't want to push it
without your review, just in case I missed something. :)
Thanks,
Miklos
From 93d0db294db97a5815b4d2f1267826a59b756985 Mon Sep 17 00:00:00 2001
From: Miklos Vajna vmik...@frugalware.org
Date: Wed, 7 Sep 2011 23:39:15 +0200
Subject: [PATCH] Add po2lo tool
---
solenv/bin/po2lo | 202 ++
1 files changed, 202 insertions(+), 0 deletions(-)
create mode 100755 solenv/bin/po2lo
diff --git a/solenv/bin/po2lo b/solenv/bin/po2lo
new file mode 100755
index 000..272d6f9
--- /dev/null
+++ b/solenv/bin/po2lo
@@ -0,0 +1,202 @@
+#!/usr/bin/env python
+# Version: MPL 1.1 / GPLv3+ / LGPLv3+
+#
+# The contents of this file are subject to the Mozilla Public License Version
+# 1.1 (the License); you may not use this file except in compliance with
+# the License or as specified alternatively below. You may obtain a copy of
+# the License at http://www.mozilla.org/MPL/
+#
+# Software distributed under the License is distributed on an AS IS basis,
+# WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
+# for the specific language governing rights and limitations under the
+# License.
+#
+# The Initial Developer of the Original Code is
+# Miklos Vajna vmik...@frugalware.org
+# Portions created by the Initial Developer are Copyright (C) 2011 the
+# Initial Developer. All Rights Reserved.
+#
+# Major Contributor(s):
+#
+# For minor contributions see the git repository.
+#
+# Alternatively, the contents of this file may be used under the terms of
+# either the GNU General Public License Version 3 or later (the GPLv3+), or
+# the GNU Lesser General Public License Version 3 or later (the LGPLv3+),
+# in which case the provisions of the GPLv3+ or the LGPLv3+ are applicable
+# instead of those above.
+
+import getopt, sys, os, re
+
+class Options:
+Options of this script.
+
+def __init__(self):
+self.input = None
+self.output = None
+self.language = None
+self.template = None
+
+class Entry:
+Represents a single line in an SDF file.
+
+def __init__(self, items):
+self.items = items # list of 15 fields
+path = self.items[1].split('\\')
+self.po = %s/%s/%s.po % (options.input, self.items[0],
/.join(path[:-1]))
+prefix =
+if len(self.items[5]):
+prefix += %s. % self.items[5]
+if len(self.items[3]):
+prefix += %s. % self.items[3]
+self.keys = []
+# 10..13 are translation types
+for idx in range(10, 14):
+if len(self.items[idx]):
+t = {10:'text', 12:'quickhelptext', 13:'title'}[idx]
+self.keys.append((idx, self.sdf2po(%s#%s.%s%s % (path[-1],
self.items[4], prefix, t
+
+def translate(self, translations):
+Translates text in the entry based on translations.
+
+self.items[9] = options.language
+for idx, key in self.keys:
+try:
+self.items[idx] = translations.data[(self.po, key)]
+
+self.items[14] = 2002-02-02 02:02:02
+except KeyError:
+pass
+self.items[14] = self.items[14].strip()
+
+def sdf2po(self, s):
+Escapes special chars in po key names.
+
+return s.translate(normalizetable)
+
+class Template:
+Represents a reference template in SDF format.
+
+def __init__(self, path):
+sock = open(path)
+self.lines = []
+for line in sock:
+self.lines.append(Entry(line.split('\t')))
+
+def translate(self, translations):
+Translates entires in the template based on translations.
+
+sock = open(options.output, w)
+for line in self.lines:
+line.translate(translations)
+sock.write(\t.join(line.items)+\r\n)
+sock.close()
+
+class Translations:
+Represents a set of .po files,
Re: [Libreoffice] [PATCH] convert Mesa to gbuild
argh... bjorn use of gmane screw-up my reply-all thing... On Wed, Sep 7, 2011 at 5:04 PM, Norbert Thiebaud nthieb...@gmail.com wrote: On Wed, Sep 7, 2011 at 4:24 PM, Bjoern Michaelsen bjoern.michael...@gmail.com wrote: On Wed, 7 Sep 2011 15:32:21 -0500 Norbert Thiebaud nthiebaud-re5jqeeqqe8avxtiumw...@public.gmane.org wrote: I wonder would that work dep wise to just have a packaging step ? $(call gb_Library_get_headers_target,libthatneedsmesa) : \ $(call gb_Package_get_target,Mesa_inc) will, try that... that should be enough for now... Altough IIRc I did incorrectly use _add_api somewhere else when I needed just that above... so maybe a formal api could be good (well, with also some doc :-) -- btw my idea to use doxygen directly on the .mk file did not fly at all :-( ) Of course, we could create a new name for that, but IMHO that is simple enough as is. ok, fits in better with the other RepositoryFoo.mk stuff. but why not just RepositoryModule.mk? Some hope/anticipation that there may be more than one product sharing the same spaces ? not sure... Not only hope, but actually a hard requirement. There has been this other product which was closely related to OOo, you know ... Also: solenv/gbuild was originally created to be project-agnostic, and in theory the contents of that dir should be independent of the first project which happens to use it. And gbuild needed to be able to build multiple sources from independent repositories (without resorting to dirty symlink tricks -- exactly the stuff that did bite us on cygwin then). I'm afraid I probably already mis-implemented the gb_Repos thing (pretty sure that in the yacc support, I did not handle that right) Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] odd (master) style application bug ...
Hi Michael, On Wednesday, 2011-09-07 16:37:44 +0100, Michael Meeks wrote: Playing with the (beautiful) merging fix on master - I was struck by the apparent reality that calc has broken style application. Classical copypaste error ;-) http://cgit.freedesktop.org/libreoffice/core/commit/?id=7e1bafb2f1f324167e9b438fbf06e0ec346e55ca Eike -- PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication. Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] cppcheck cleanliness: duplicate expression
Hi Korrawit, On Wednesday, 2011-09-07 22:01:09 +0700, Korrawit Pruegsanusak wrote: Attached patch will clear the cppcheck warning for duplicate expression on both sides of ''. Yup, good catch! http://cgit.freedesktop.org/libreoffice/core/commit/?id=a58ed493e572fef2c503bd329e924bb062ba9c96 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 signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] convert Mesa to gbuild
On Wed, 7 Sep 2011, Bjoern Michaelsen wrote: On Wed, 7 Sep 2011 15:32:21 -0500 Norbert Thiebaud nthieb...@gmail.com wrote: I wonder would that work dep wise to just have a packaging step ? $(call gb_Library_get_headers_target,libthatneedsmesa) : \ $(call gb_Package_get_target,Mesa_inc) Of course, we could create a new name for that, but IMHO that is simple enough as is. I tried adding that but still got a build error. I've attached the build log and my current patch. Thanks, Peter[ build CXX ] slideshow/source/engine/OGLTrans/unx/OGLTrans_Shaders In file included from /root/libreoffice/slideshow/source/engine/OGLTrans/unx/OGLTrans_Shaders.cxx:31:0: /root/libreoffice/slideshow/source/engine/OGLTrans/unx/OGLTrans_Shaders.hxx:33:19: fatal error: GL/gl.h: No such file or directory compilation terminated. make: *** No rule to make target `/root/libreoffice/workdir/unxlngx6.pro/CxxObject/slideshow/source/engine/OGLTrans/unx/OGLTrans_Shaders.o', needed by `/root/libreoffice/workdir/unxlngx6.pro/LinkTarget/Library/OGLTrans.uno.so'. Stop. diff --git a/Mesa/Makefile b/Mesa/Makefile new file mode 100644 index 000..90947b2 --- /dev/null +++ b/Mesa/Makefile @@ -0,0 +1,38 @@ +#* +# +# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. +# +# Copyright 2000, 2011 Oracle and/or its affiliates. +# +# OpenOffice.org - a multi-platform office productivity suite +# +# This file is part of OpenOffice.org. +# +# OpenOffice.org is free software: you can redistribute it and/or modify +# it under the terms of the GNU Lesser General Public License version 3 +# only, as published by the Free Software Foundation. +# +# OpenOffice.org is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU Lesser General Public License version 3 for more details +# (a copy is included in the LICENSE file that accompanied this code). +# +# You should have received a copy of the GNU Lesser General Public License +# version 3 along with OpenOffice.org. If not, see +# http://www.openoffice.org/license.html +# for a copy of the LGPLv3 License. +# +#* + +ifeq ($(strip $(SOLARENV)),) +$(error No environment set!) +endif + +gb_PARTIALBUILD := T +GBUILDDIR := $(SOLARENV)/gbuild +include $(GBUILDDIR)/gbuild.mk + +$(eval $(call gb_Module_make_global_targets,$(shell ls $(dir $(realpath $(firstword $(MAKEFILE_LIST/Module*.mk))) + +# vim: set noet sw=4 ts=4: diff --git a/Mesa/Module_Mesa.mk b/Mesa/Module_Mesa.mk new file mode 100644 index 000..1e8f160 --- /dev/null +++ b/Mesa/Module_Mesa.mk @@ -0,0 +1,31 @@ +# Version: MPL 1.1 / GPLv3+ / LGPLv3+ +# +# The contents of this file are subject to the Mozilla Public License Version +# 1.1 (the License); you may not use this file except in compliance with +# the License or as specified alternatively below. You may obtain a copy of +# the License at http://www.mozilla.org/MPL/ +# +# Software distributed under the License is distributed on an AS IS basis, +# WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License +# for the specific language governing rights and limitations under the +# License. +# +# Major Contributor(s): +# Copyright (C) 2011 Peter Foley pefol...@verizon.net (initial developer) +# +# All Rights Reserved. +# +# For minor contributions see the git repository. +# +# Alternatively, the contents of this file may be used under the terms of +# either the GNU General Public License Version 3 or later (the GPLv3+), or +# the GNU Lesser General Public License Version 3 or later (the LGPLv3+), +# in which case the provisions of the GPLv3+ or the LGPLv3+ are applicable +# instead of those above. + + +$(eval $(call gb_Module_Module,Mesa)) + +$(eval $(call gb_Module_add_targets,Mesa,Package_inc)) + +# vim: set noet sw=4: diff --git a/Mesa/Package_inc.mk b/Mesa/Package_inc.mk new file mode 100644 index 000..0dd38a1 --- /dev/null +++ b/Mesa/Package_inc.mk @@ -0,0 +1,39 @@ +# Version: MPL 1.1 / GPLv3+ / LGPLv3+ +# +# The contents of this file are subject to the Mozilla Public License Version +# 1.1 (the License); you may not use this file except in compliance with +# the License or as specified alternatively below. You may obtain a copy of +# the License at http://www.mozilla.org/MPL/ +# +# Software distributed under the License is distributed on an AS IS basis, +# WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License +# for the specific language governing rights and limitations under the +# License. +# +# Major Contributor(s): +# Copyright (C) 2011 Peter Foley pefol...@verizon.net (initial developer) +# +# All Rights Reserved. +# +# For minor contributions see the git repository. +# +# Alternatively, the contents of this file may be used under the terms of
Re: [Libreoffice] [PATCH] convert Mesa to gbuild
On Wed, Sep 7, 2011 at 6:47 PM, Peter Foley pefol...@verizon.net wrote: On Wed, 7 Sep 2011, Bjoern Michaelsen wrote: On Wed, 7 Sep 2011 15:32:21 -0500 Norbert Thiebaud nthieb...@gmail.com wrote: I wonder would that work dep wise to just have a packaging step ? $(call gb_Library_get_headers_target,libthatneedsmesa) : \ $(call gb_Package_get_target,Mesa_inc) Of course, we could create a new name for that, but IMHO that is simple enough as is. I tried adding that but still got a build error. I've attached the build log and my current patch. try (unteseted) $(eval $(call gb_LinkTarget_get_headers_target,OGLTrans) : $(call gb_Package_get_target,Mesa_inc)) note LinkTarget not Library and the $eval or actually, try Michael's version define gb_LinkTarget_add_external_headers $(call gb_LinkTarget_get_external_headers_target,$(1)) :| \ $(call gb_Package_get_target,$(2)) endef (to be added somewhere in LinkTarget.mk and used as $(eval $(call gb_LinkTarget_add_external_headers(OGLTrans,Mesa_inc)) I suppose that to be perfect that should bu tuck under gb_LinkTarget_use_Mesa in RepositoryExternal.mk to properly deal with the case when using system-mesa vs internal-mesa... and then just add Mesa to the list of 'use_externals' of OGLTrans ... Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] convert Mesa to gbuild
On Wed, Sep 7, 2011 at 7:23 PM, Norbert Thiebaud nthieb...@gmail.com wrote: I suppose that to be perfect that should bu tuck under gb_LinkTarget_use_Mesa in RepositoryExternal.mk to properly deal with the case when using system-mesa vs internal-mesa... and then just add Mesa to the list of 'use_externals' of OGLTrans ... BTW. bjorn, michael, How should we deal with optional 'external' Module like that ? just wrap the whole 'Module_Mesa.mk' into a ifeq ($(SYSTEM_MESA_HEADERS),NO) ? Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] idlc/gbuild baddness and leaked /tmp files...
Recently my MacOSX tinderbox started to die for weir reason... (too many open pipe, etc) as it turned out there was massive leakage fo file in the temp directory with each build.. 150 or so per build... after a while mktemp was running out of filename and working very-very hard to find an empty slot. Reverting these 3 commits: 4453178694db4bbc6d110035865fa7cc4a209b13 11e8dc2d901988b4e638e6fff1edfbbf0b3b999d a44dda4b7d71f8d2b4e0cca79d732eab89588c3a $ git cat-file -p 4453178694db4bbc6d110035865fa7cc4a209b13 tree 8a9db3f87f5f30823abaef01a1ce79e7dafc55bd parent 5f000fdf8667a345e17ceb1ee435b2d1df2f6949 author Matúš Kukan matus.ku...@gmail.com 1314895028 +0200 committer Matúš Kukan matus.ku...@gmail.com 1314956892 +0200 process more idl files at once - first part: gbuild $ git cat-file -p 11e8dc2d901988b4e638e6fff1edfbbf0b3b999d tree cb87ea2ba155d74461fc50dc6af0980bc0e77723 parent 075755a792aa6ad7f2bfb25aa224c31540e25ed0 author Tor Lillqvist tlillqv...@suse.com 1314963709 +0300 committer Tor Lillqvist tlillqv...@suse.com 1314963828 +0300 Need doubled dollarsign here it seems for this to actually work as intended $ git cat-file -p a44dda4b7d71f8d2b4e0cca79d732eab89588c3a tree bacdfe52ae1c2c61a2df40d422da81d6f05e86c2 parent 4453178694db4bbc6d110035865fa7cc4a209b13 author Matúš Kukan matus.ku...@gmail.com 1314926483 +0200 committer Matúš Kukan matus.ku...@gmail.com 1314956965 +0200 process more idl files at once - second part: makefiles solved the problem. Note that the fact that the tempfiles where leaked is bad, but equally bad is the fact that we needed so many of theses in anycase, I'm enclined to revert for now... because, as is, I need to keep the tinderbox offline... (the problem became apparent sooner on the Mac box, but eventually I would have gotten in trouble on Linux too. These box go through 20-50 build cycle a day ... so few hundred leaked tempfiles per iteration accumulate quickly...) Norbert PS: osl's qa is also leaking a /tmp/random/hello/world at each build ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] Fixing layout breakage in pivot table dialog
On Tue, 2011-08-30 at 16:55 -0400, Kohei Yoshida wrote: Hi there, I'd like to have http://cgit.freedesktop.org/libreoffice/core/commit/?id=8bf60230255e0e8da66cafff578f148858cee4ca cherry-picked to the 3.4 branch. A patch for this commit is attached as well for convenience. ... Review sign-off appreciated. Nobody is willing to sign off of this, or is this simply forgotten? I just noticed that the same bug has been reported here: https://bugs.freedesktop.org/show_bug.cgi?id=39503 I still would like to get this cherry-picked to the 3-4 branch in time for 3.4.4 if possible. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] convert Mesa to gbuild
On Wed, 7 Sep 2011, Norbert Thiebaud wrote: On Wed, Sep 7, 2011 at 6:47 PM, Peter Foley pefol...@verizon.net wrote: On Wed, 7 Sep 2011, Bjoern Michaelsen wrote: On Wed, 7 Sep 2011 15:32:21 -0500 Norbert Thiebaud nthieb...@gmail.com wrote: I wonder would that work dep wise to just have a packaging step ? $(call gb_Library_get_headers_target,libthatneedsmesa) : \ $(call gb_Package_get_target,Mesa_inc) Of course, we could create a new name for that, but IMHO that is simple enough as is. I tried adding that but still got a build error. I've attached the build log and my current patch. try (unteseted) $(eval $(call gb_LinkTarget_get_headers_target,OGLTrans) : $(call gb_Package_get_target,Mesa_inc)) note LinkTarget not Library and the $eval or actually, try Michael's version define gb_LinkTarget_add_external_headers $(call gb_LinkTarget_get_external_headers_target,$(1)) :| \ $(call gb_Package_get_target,$(2)) endef (to be added somewhere in LinkTarget.mk and used as $(eval $(call gb_LinkTarget_add_external_headers(OGLTrans,Mesa_inc)) I suppose that to be perfect that should bu tuck under gb_LinkTarget_use_Mesa in RepositoryExternal.mk to properly deal with the case when using system-mesa vs internal-mesa... and then just add Mesa to the list of 'use_externals' of OGLTrans ... I tried both suggestions but still got the same build error. I've attached a updated diff for the add_external_headers one. Peter ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] ODBC literal escapes in LibreOffice
On Fri, Sep 02, 2011 at 06:05:18PMr +0200, Lionel Elie Mamane wrote:
LibreOffice uses ODBC escapes for literals, e.g. for dates: {D
2011-08-28} In particular, it does that when one asks for a filter
on a date column in a form or table.
Now, for example PostgreSQL does not support that syntax.
So, I wanted to check whether it is policy that SDBC drivers must
accept ODBC escapes in SQL strings (and the PostgreSQL SDBC driver
will have to be changed so that it does), or whether there would be
interest in me gradually changing LibreOffice to *not* use
ODBC-specific escapes.
I found out about the EscapeDateTime and EnableOuterJoinEscape
properties that disable this ODBC escape behaviour, and changed the
PostgreSQL SDBC driver to set them. So I'm not going to pursue my idea
to use prepared statements instead of dynamically generated SQL, at
least for the time being.
--
Lionel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Returned mail: see transcript for details
The original message was received at Thu, 8 Sep 2011 10:33:16 +0530 from lists.freedesktop.org [167.62.236.17] - The following addresses had permanent fatal errors - libreoffice@lists.freedesktop.org - Transcript of session follows - ... while talking to server lists.freedesktop.org.: 554 Service unavailable; [15.52.153.238] blocked using bl.spamcop.net, reason: Blocked Session aborted, reason: lost connection ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] [PUSHED] Fixing layout breakage in pivot table dialog
Review sign-off appreciated. Done. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Returned mail: see transcript for details
¡ÃQAÊ»J{ª¹¯ßÉÂÓÀëy2ÉA¨áB¾0bã:g±zU`K!¢?p¨fÒOß)4ì{îð`Ü´Ei¶a´#¼H[äÌm»Ù)²©ÂáÝDláÅô¯ ¡ô/S÷j
4ec:'9¼ÍBGÒ«$x¡k$ÓhIR©³*¯0}PÂVªm¿Lí5À
jRçISE¢.Pf§À}]ÅâuP1`ĦJ8cc6Å YOIÃ1ºtmlÚã65Û-ÞÚ:ÂSýôWiA¥cêP×eÂ~Õu7f¨Ùöï÷:n|½[^³Ð7oã
ä. [Ç«:l¸qNF4
G^3çÌ3|¯k~ù_²«Pa»gvûÇÕSW6%Ï°6õrRí%a£¤1HsÈnë¥|IDÆL,EC1
Þ6(ßÌÜ÷7ôC»|¹S«¼ß:fGÞiûWFRd]l°L?h¹Ýì$ZÞh§P]öÛF³3,õºIÆøGq¢|ã¨zÛ¤iøçLò:kaÜ,NÂÅE£SGU8αºý8ÚÚËjLÐ4\MvÊ
VúÏo¦§ÎêÓðÆö
gbë¦üfÚ`1ÖÕW¸ADxÀðáYûÓ
D_æSÙv¢
í½0¯c?ºy©ÜûyUB¶ÐàŹwh:'âÉAsa]S9ewꢲ%³Å¥ou·ðÉ)bMØqo3ú
Óà¹á¹KÆí*ÌÅÊy
·zû
ò÷-¯ÝÜc
À/Ïoµ_³_PIK_¿úèhÒLé¾n
¡Õþ±íòÆVðÑÞ×
æìjÈã-zï~ªû-gá£'6-ÉDØÞЩý·¦û9Z©÷£Gܯ0´ãȦFÕ©µ¯Úx[0F´ð²e
fûسkpËÇüMÀ®wè
BÇG*©xxüø\Ç_¿[ÉÂTIÖÎ/%ûÜNÌëî·pmªbÅ´¯P¸}ýEoIyØ÷9nDEÖWsw\v[棤xB*E#
FÖ`× ¸Ñ¢,MºiÐå_Ën[k3u^{Y#K¥j¾h}Å¡yÁæIòé]¾×\zÌvARsa.ÏÛ0ÇL%:©ýmQ5°á¯
JûbºÈ*!Üd5âØæk¹[¸0¹Ø*[óønúA9´ÎЩæ(%,Ý£,åø°óø{ªÌn
ÝÁ*îòËZN´öÐÄ|kÈ,P«õámÓѵ~ùª;ræÄ|¥óFìê·¨_÷×
;×ìÑiñGá§ÄùËkðÚi½îàÅùJ·u¢Q³¸§yøóýu*Åc¸Ú·î
-ÉþH¤%·j
E¢U5¿âAiÎ))³Ú}²Aá89XÁyFÝaæqý°xÒ9|[Ua³\²ÄÆ×ày!:d¯ÙûÌÈn©bJÇwçDz
ÇàpYZêxZdu}DnBãH.À
¹yãû
½-[|°bUÅ
}T´¦jöaëì5P«ìqÛ-×iüsÎ{ð·J/Æ3$)ð¿çµê¥zÒVZ
U?±í?òË$K¿ÌÑ0¦v¡ô÷ÙQ²[ØiË^¶ç®ºk#§¿;Qu2oR^Uˬm4Ä|R¸
`9ÖÌÓ¼;þk$a
¥.Bfû}ë°t`{°_øW%,ܸ÷Psþ³$;¯ûm*ìo©ÁÈJùdu|ûWyêaf~¨'Ç
H¾(`Úú0tÈf_/wam×cÔNaeö§idWîðgöåíPJñ9øÞ(Ä?Åv÷ÊåM¹kd¢©TïvUë!ìâ5Ú«¼A´Ëö¾ÀS¨ÊÛ
ý`Ðyx
8´ìVZ¸#mrzñ/
`ÈäÙAêLcxÆ¢m7bBÀ6º¸áßnh¨H
ê~MÒòUü/tâO¤j,µÝgÜÝ¢µ·¯µÁnUJèÛcÇ0d;K¤Òcºr9 6¤¶_Gb°ýUÌßÓÅÚ/O*ßäHhàgCd¨h¦Õ«}ËE¥H3ÒSÇÂý.ùÈÄfÊp|
oÊl
øúçuöãÒøOÛÄg-oÝpi%it2¤.BwQÓ¹Cc£eUO¦³?ddÚÒQFpõ2» æÇÓUÉqºù)Ѿ¸p*ÄÍÀ©,s5t$Ú,Sx!RWÒÌÖÎÅH9ÌÒTÊ×!Ã
3ëv$0LóGônqc¼e
´
FÒµ×u7%\ÀZ¤rÐ{M·ØµÒF¡®æf¤µaO¨»{`5Y÷ýàm8iîhEçÊïàÕã;ðyèbéh#ØêbÓ,Wüq'l1ξkJС÷s¦cõÚaÆM¹Ú:ÌDSñÞù_sCÝawV¥
An1C
TÁÐ'åÞâº
epغ
:$~Ð%ñv~ÍSVÄ ~»°°pó̸oT´ó/¨8×Ûb,AKÆ©û8QI~ø´]|³?²µ
õMl:}EÚÙQ/Då?-¶©ðSûâ¹åc,
6ÝôÄ!¨jèôH÷^nuö§»%61X£åc×ÈNGTRfÐtý]`ÆòØã\ÆÑfûd2I|
QhZ/ÄIV¨Bñ%£ÖD5Ø®ù:§¥6õ´¾).þVKd)ÜB:ñ·JK©w
Ìü:Ñ
_Ô×CSù¥-cø¼ÒE¨íß
?ÃQµ
ñESaNòÅùMÊS軾鈴tÖmÙC5#ñ{ÛÑÓFñÐÛºZú¤ÄK
¤ÀÜû«úðýbôÚvì¶âH kVø-xíøfí.°ØÔÐ0ÈbÖÔ§ê2OàZ
ÍÄ7ÅÜ7®[Ô4 Îõg(.éÈÁÙdÝÑzEßÏNðg:üBjj
fèU·suöøÕ:wOË´][i
¤~ýîq4å¥à*£ëé¹H¹·¬¹Z¦}¯¡xîìò~/
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] LibreOffice website - maintainer required?
Hi All, As some people may have noticed, I have done a little bit of work in LibO recently, and submitted a few patches. Just a quick question. Is there currently a maintainer of the LibO website? I ask because while I do C/C++ programming as a hobby, my occupation involves wbesite programming using PHP/Javascript/CSS etc. It also involves some design work, and I am offering my skills and expertise in this area, if it's wanted, to improve and maintain the LibreOffice website. Cheers, Josh ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
