Re: [Libreoffice] [ANN] LibreOffice 3.4.1 RC3 available
Hi Thorsten, Thorsten Behrens wrote (28-06-11 07:48) hm, are you interested in single commits? That would be in the http://download.documentfoundation.org/libreoffice/src/commit-log-libreoffice-3-4-1-release-3.4.1.2.log files - of course they are additive, i.e. to get all changes between 3.4.0 and 3.4.1rc3, concat the relevant log files. OK! Easiest solution is probably to use git directly (from the toplevel source dir): bin/lo-commit-stat --log-suffix=release-3.4.1.3 . libreoffice-3.3.99.1..libreoffice-3.4.1.3 or for bugfixes only: bin/lo-commit-stat --bugs --log-suffix=release-3.4.1.3 . libreoffice-3.3.99.1..libreoffice-3.4.1.3 (kudos to Petr for the nice script) Ah, great :-) Have to remove "translations" first from the @Pieces, but then it runs fine. ( Now only make sure that my local version is in sinc and such and that I pass the right tags ;-) ) Thanks, Cor -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Replace DBG_ with OSL in writer and remove debug.hxx
On Tue, Jun 07, 2011 at 10:48:36PM +0200, Jacek Wolszczak wrote: > Hi, > > BTW, does anyone use DBG_PROFSTART and DBG_PROFSTOP or could these be > removed altogether? They are used for profiling. I do not know if anyone here knows about their existence, so it might well be the simplest thing to remove them and be done with it :) As an alternative, they can be probably replaced by RTL_LOGFILE_CONTEXT (see sal/inc/rtl/logfile.hxx). But I admit I have never used it, so consider this just hand-waving :) D. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [ANN] LibreOffice 3.4.1 RC3 available
Cor Nouws wrote: > Found no problem with some tasks I did yesterday. > So Thanks :-) > Thank you for checking! > >The list of fixed bugs in this release is here: > > > >http://dev-builds.libreoffice.org/pre-releases/src/bugfixes-libreoffice-3-4-1-release-3.4.1.3.log > > Must have been asked before, so sorry that I do not remember, nor > have marked (will do that now), but how to retrieve a list of all > changes (or even selection X, Y of those) 3.4.0rc2 > 3.4.1rc3 ? > Hi Cor, hm, are you interested in single commits? That would be in the http://download.documentfoundation.org/libreoffice/src/commit-log-libreoffice-3-4-1-release-3.4.1.2.log files - of course they are additive, i.e. to get all changes between 3.4.0 and 3.4.1rc3, concat the relevant log files. Easiest solution is probably to use git directly (from the toplevel source dir): bin/lo-commit-stat --log-suffix=release-3.4.1.3 . libreoffice-3.3.99.1..libreoffice-3.4.1.3 or for bugfixes only: bin/lo-commit-stat --bugs --log-suffix=release-3.4.1.3 . libreoffice-3.3.99.1..libreoffice-3.4.1.3 (kudos to Petr for the nice script) HTH, -- Thorsten pgp2o7r4Zmktv.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Michael Meeks schrieb: >Oh - well - since master is going to turn into 3.5, if that is not > parallel installing, then we have a problem Hi, I believe most testers can live with every behavior, but behavior must be predictable. We ned some Help (Wiki: QA/DailyBuilds) with exact descriptions how to use - for every operating system and every variation of the Daily build. Currently I see 3 folders for WIN and have to guess how the contained builds will behave, how they should be used and for what they are. CU Rainer ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [ANN] LibreOffice 3.4.1 RC3 available
Hi *, Thorsten Behrens wrote (27-06-11 01:09) http://dev-builds.libreoffice.org/pre-releases/ If you've a bit of time, please give them a try& report *critical* bugs not yet in bugzilla here, so we can incorporate them into the release notes. Please note that it takes approximately 24 hours to populate the mirrors, so that's about the time we have to collect feedback. Found no problem with some tasks I did yesterday. So Thanks :-) The list of fixed bugs in this release is here: http://dev-builds.libreoffice.org/pre-releases/src/bugfixes-libreoffice-3-4-1-release-3.4.1.3.log Must have been asked before, so sorry that I do not remember, nor have marked (will do that now), but how to retrieve a list of all changes (or even selection X, Y of those) 3.4.0rc2 > 3.4.1rc3 ? Thanks, -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] RTF support
On Mon, Jun 27, 2011 at 04:03:41PM -0700, tracey002 wrote: > Would it be of any real help if I sent you the 1.9.1 RTF spec with the > type-Os in the RTF controls corrected? Hi Tracey, If you think the spec has typos, then please send those to its authors, not to me. > If not, I won't bother because I use a dial-up connection. Don't worry about that, a typical minimal rtf import bug reproducer is under 1KB. pgpfLxDpjd15a.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] RTF support
Would it be of any real help if I sent you the 1.9.1 RTF spec with the type-Os in the RTF controls corrected? If not, I won't bother because I use a dial-up connection. Attached is a list of the rtf Controls that I have assembled. Thanks, Tracey - Original Message - From: Miklos Vajna [via Document Foundation Mail Archive] To: tracey002 Sent: Monday, June 27, 2011 5:51 PM Subject: Re: RTF support On Mon, Jun 27, 2011 at 12:28:25PM -0700, tracey002 <[hidden email]> wrote: > I had discovered that Open Office Writer does NOT really support functional > RTF features (the ones that I tried anyway). > When I posted issues to an OpenOffice Users Group, I was re-directed to > Libre Office. > Can I help in some way? Hi, Sure, if you find an RTF-related bug, then see here: http://wiki.documentfoundation.org/BugReport#LibreOffice_Bug_Reports Search bugzilla if it's already known, if not, then try to create a minimal reproducder: - import bugs: rtf format - export bugs: odt format Then we'll try to fix. Thanks. ___ LibreOffice mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/libreoffice attachment0 (205 bytes) Download Attachment -- If you reply to this email, your message will be added to the discussion below: http://nabble.documentfoundation.org/RTF-support-tp3114982p3115712.html To unsubscribe from RTF support, click here. -- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.901 / Virus Database: 271.1.1/3729 - Release Date: 06/27/11 01:34:00 No virus found in this outgoing message. Checked by AVG - www.avg.com Version: 9.0.901 / Virus Database: 271.1.1/3729 - Release Date: 06/27/11 01:34:00 -- View this message in context: http://nabble.documentfoundation.org/RTF-support-tp3114982p3115751.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] RTF support
On Mon, Jun 27, 2011 at 12:28:25PM -0700, tracey002 wrote: > I had discovered that Open Office Writer does NOT really support functional > RTF features (the ones that I tried anyway). > When I posted issues to an OpenOffice Users Group, I was re-directed to > Libre Office. > Can I help in some way? Hi, Sure, if you find an RTF-related bug, then see here: http://wiki.documentfoundation.org/BugReport#LibreOffice_Bug_Reports Search bugzilla if it's already known, if not, then try to create a minimal reproducder: - import bugs: rtf format - export bugs: odt format Then we'll try to fix. Thanks. pgp7f5QcmB8hf.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Replacing ByteString with rtl::OString
Hi, the next problem: SvMemoryStream::ReadLine() isn't happy with argument of type "rtl::OString&"... httprequest.cxx: In member function 'sal_Bool HttpRequest::Execute()': httprequest.cxx:165:34: error: no matching function for call to 'SvMemoryStream::ReadLine(rtl::OString&)' tools/stream.hxx:447:15: note: candidate is: sal_Bool SvStream::ReadLine(ByteString&) Any hints how to get over that hurdle? Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Debug compilation fails in sal module
Hello,
With the help of moggi in IRC, i got this :
Reading symbols from
/home/maryline/compile-libreoffice/libo/clone/ure/sal/unxlngi6/bin/cppunittester...done.
(gdb) run
Starting program:
/home/maryline/compile-libreoffice/libo/clone/ure/sal/unxlngi6/bin/cppunittester
../../../unxlngi6/lib/libosl_process.so
[Thread debugging using libthread_db enabled]
*** glibc detected *** Error: File
/home/maryline/compile-libreoffice/libo/clone/ure/sal/cpprt/operators_new_delete.cxx,
Line 96: operator delete mismatch
[New Thread 0xb7bbdb70 (LWP 24474)]
[New Thread 0xb73acb70 (LWP 24475)]
[Thread 0xb73acb70 (LWP 24475) exited]
Program received signal SIGABRT, Aborted.
0xb7fe2424 in __kernel_vsyscall ()
(gdb) bt full
#0 0xb7fe2424 in __kernel_vsyscall ()
No symbol table info available.
#1 0xb7c34911 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
resultvar =
pid = -1210712076
selftid = 24471
#2 0xb7c37d42 in abort () at abort.c:92
act = {__sigaction_handler = {sa_handler = 0xb7d5fff4,
sa_sigaction = 0xb7d5fff4}, sa_mask = {__val = {3063940352, 3221204208,
381, 192, 3063939088, 3084255220, 3063939088, 0, 0,
3221204268, 3063949064, 8008, 3063939088, 3084255220, 3063939088,
3063940352, 3221204268, 3083310045, 180, 3063940352,
3084255220, 20, 3221204428, 3083675847, 3063940728, 3063940728, 180,
16384, 3084251200, 0, 3084895800, 27}}, sa_flags = 25,
sa_restorer = 0x17}
sigs = {__val = {32, 0 }}
#3 0xb7c6a9d5 in __libc_message (do_abort=2, fmt=0xb7d3fa70 "*** glibc
detected *** %s: %s: 0x%s ***\n")
at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
ap =
fd = 7
on_2 =
list =
nlist =
cp =
written = false
#4 0xb7c74ac1 in malloc_printerr (action=, str=0x6
, ptr=0xb7c02cd0) at malloc.c:6283
buf = "b7c02cd0"
cp =
#5 0xb7c76328 in _int_free (av=, p=optimized out>) at malloc.c:4795
size = 0
nextchunk = 0x5f97
nextsize = 3087006400
prevsize =
bck =
fwd =
errstr = 0x6
__func__ = "_int_free"
#6 0xb7c793dd in __libc_free (mem=0xb7c02cd0) at malloc.c:3738
ar_ptr = 0xb7d613c0
p = 0x6
#7 0xb7f1e92a in rtl_freeMemory_SYSTEM (p=0xb7c02cd0) at alloc_global.c:301
No locals.
#8 0xb7f1e9c4 in rtl_freeMemory (p=0xb7c02cd0) at alloc_global.c:371
No locals.
#9 0x0804e1e9 in deallocate (p=0xb7c02cd8, rTraits=...)
at
/home/maryline/compile-libreoffice/libo/clone/ure/sal/cpprt/operators_new_delete.cxx:184
No locals.
#10 0x0804e237 in operator delete (p=0xb7c02cd8)
at
/home/maryline/compile-libreoffice/libo/clone/ure/sal/cpprt/operators_new_delete.cxx:201
No locals.
#11 0x0804d7c3 in __gnu_cxx::new_allocator::deallocate
(this=0xbfffb5ab, __p=0xb7c02cd8 "")
at /usr/include/c++/4.6/ext/new_allocator.h:98
No locals.
#12 0x0804cd9d in std::basic_string,
std::allocator >::_Rep::_M_destroy (this=0xb7c02cd8, __a=...)
at /usr/include/c++/4.6/bits/basic_string.tcc:451
__size = 13
#13 0x0804c78e in std::basic_string,
std::allocator >::_Rep::_M_dispose (this=0xb7c02cd8, __a=...)
at /usr/include/c++/4.6/bits/basic_string.h:244
No locals.
#14 0x0804d5f7 in std::basic_string,
std::allocator >::reserve (this=0xbfffb7c0, __res=17)
at /usr/include/c++/4.6/bits/basic_string.tcc:513
__a = {<__gnu_cxx::new_allocator> = {},
}
__tmp = 0x805cc24 ""
#15 0x0804d721 in std::basic_string,
std::allocator >::append (this=0xbfffb7c0,
__s=0x805aaa8 "SYSTEM_LIBXSLT=NO", __n=17) at
/usr/include/c++/4.6/bits/basic_string.tcc:310
__len = 17
#16 0xb7e082f8 in std::basic_istream >&
std::getline, std::allocator
>(std::basic_istream >&,
std::basic_string, std::allocator >&,
char) ()
from
/home/maryline/compile-libreoffice/libo/solver/350/unxlngi6/lib/libstdc++.so.6
No symbol table info available.
#17 0xb7be4e67 in Test_osl_executeProcess::read_child_environment
(this=0x8053148, env_container=0xbfffb868)
at
/home/maryline/compile-libreoffice/libo/clone/ure/sal/qa/osl/process/osl_process.cxx:480
temp_file_name = {pData = 0x805a918}
file = { >> =
{ >> = { =
{}, _M_tie = 0x0, _M_fill = 0 '\000', _M_fill_init =
false, _M_streambuf = 0xbfffb6b0, _M_ctype = 0xb7e8fc00,
_M_num_put = 0x0, _M_num_get = 0x0}, _vptr.basic_istream
= 0xb7c0258c, _M_gcount = 0},
_M_filebuf = {std::char_traits >> = {_vptr.basic_streambuf = 0xb7c02608,
_M_in_beg = 0x805aaa8 "SYSTEM_LIBXSLT=NO", _M_in_cur =
0x805aaa8 "SYSTEM_LIBXSLT=NO", _M_in_end = 0x805caa7 "",
_M_out_beg = 0x0, _M_out_cur = 0x0, _M_out_end = 0x0,
_M_buf_locale = {static none = 0, static ctype = 1,
static numeric = 2, static collate = 4, static time =
8, static monetary = 16, static messages = 32, static all = 63,
_M_impl = 0xb7e8fa74, static _S_classic = out>, static _S_
Re: [Libreoffice] Debug compilation fails in sal module
Le 27/06/2011 22:47, Markus Mohrhard a écrit :
Hello Julien,
Error: File
/home/maryline/compile-libreoffice/libo/clone/ure/sal/cpprt/operators_new_delete.cxx,
Line 96: operator delete mismatch
/usr/include/c++/4.6/debug/safe_iterator.h:193:error: attempt to
dereference a past-the-end iterator.
Objects involved in the operation:
iterator "this" @ 0x0xbe966380 {
type =
N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPSsNSt9__cxx19986vectorISsN3rtl9AllocatorISsEENSt7__debug6vectorISsS8_
(mutable iterator);
state = past-the-end;
references sequence with type
`NSt7__debug6vectorISsN3rtl9AllocatorISs' @ 0x0xbe966380
}
this helps a lot. We had a similar situation some days ago. When built
with debug symbols some additional checks are performed to ensure that
iterators are not missused. So it would be a good step if you could
debug the unit test and as soon as you get a SIG ABORT get a backtrace
and post it here or fix the problem. I think that we derefence
vector::end() or something like this.
http://wiki.documentfoundation.org/Development/How_to_debug#Debugging_cppunit_tests
Hello,
I'd like to do this but when I launch "run" in gdb it does the test 1
which is Ok. How to launch the test 2 (I'm a beginner with gdb) ?
Julien.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Debug compilation fails in sal module
Hello Julien,
>
> Error: File /home/maryline/compile-**libreoffice/libo/clone/ure/**
> sal/cpprt/operators_new_**delete.cxx, Line 96: operator delete mismatch
> /usr/include/c++/4.6/debug/**safe_iterator.h:193:error: attempt to
> dereference a past-the-end iterator.
>
> Objects involved in the operation:
> iterator "this" @ 0x0xbe966380 {
> type = N11__gnu_debug14_Safe_**iteratorIN9__gnu_cxx17__**
> normal_iteratorIPSsNSt9__**cxx19986vectorISsN3rtl9Allocat**
> orISsEENSt7__**debug6vectorISsS8_ (mutable iterator);
> state = past-the-end;
> references sequence with type
> `NSt7__**debug6vectorISsN3rtl9Allocator**ISs'
> @ 0x0xbe966380
> }
>
this helps a lot. We had a similar situation some days ago. When built with
debug symbols some additional checks are performed to ensure that iterators
are not missused. So it would be a good step if you could debug the unit
test and as soon as you get a SIG ABORT get a backtrace and post it here or
fix the problem. I think that we derefence vector::end() or something like
this.
http://wiki.documentfoundation.org/Development/How_to_debug#Debugging_cppunit_tests
Regards,
Markus
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Debug compilation fails in sal module
Le 27/06/2011 22:06, Arnaud Versini a écrit :
Hello,
I've the same problem with this autogen on Ubuntu 10.04 64 too:
--without-junit
--enable-debug
--enable-symbols
We're 3 (3 "declared" :-) ) but for the moment it seems to concern only
Debian/Ubuntu (32 or 64 bits). Have other Linux or BSD distros the same
pb ? What about Mac and Windows ? (Of course, when it's compiled in
debug mode)
Here is 1 more test when I comment out the line 481 from with
qa/osl/process/osl_process.cxx (env_container->push_back(line);)
I get :
==22499==by 0x408756E:
CppUnit::TestRunner::run(CppUnit::TestResult&, std::string const&) (in
/home/maryline/compile-libreoffice/libo/solver/350/unxlngi6/lib/libcppunit-1.12.so.1)
==22499==by 0x804BBBE: sal_main() (cppunittester.cxx:148)
==22499==by 0x804B730: main (cppunittester.cxx:89)
==22499== Address 0x482b850 is 0 bytes inside data symbol
"_ZGVNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE"
==22499==
Error: File
/home/maryline/compile-libreoffice/libo/clone/ure/sal/cpprt/operators_new_delete.cxx,
Line 96: operator delete mismatch
/usr/include/c++/4.6/debug/safe_iterator.h:193:error: attempt to
dereference a past-the-end iterator.
Objects involved in the operation:
iterator "this" @ 0x0xbe966380 {
type =
N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPSsNSt9__cxx19986vectorISsN3rtl9AllocatorISsEENSt7__debug6vectorISsS8_
(mutable iterator);
state = past-the-end;
references sequence with type
`NSt7__debug6vectorISsN3rtl9AllocatorISs' @ 0x0xbe966380
}
==22977==
==22977== HEAP SUMMARY:
==22977== in use at exit: 33,115 bytes in 422 blocks
==22977== total heap usage: 2,179 allocs, 1,747 frees, 240,329 bytes
allocated
==22977==
Memcheck: mc_leakcheck.c:1012 (vgMemCheck_detect_memory_leaks): the
'impossible' happened.
==22977== Block 0x483c000..0x483cfff overlaps with block
0x483c000..0x483c57fThis is usually caused by using
VALGRIND_MALLOCLIKE_BLOCKin an inappropriate way. at 0x3803B51E: ???
(in /usr/lib/valgrind/memcheck-x86-linux)
sched status:
running_tid=2
I attached the file for the details.
Julien.
=
Building module sal
=
Entering /home/maryline/compile-libreoffice/libo/sal/inc
Entering /home/maryline/compile-libreoffice/libo/sal/typesconfig
Entering /home/maryline/compile-libreoffice/libo/sal/osl/all
Entering /home/maryline/compile-libreoffice/libo/sal/rtl/source
--- ALWAYSDBGFILES ---
`../../unxlngi6/slo/debugprint.obj' is up to date
--- ALWAYSDBGFILES OVER ---
Entering /home/maryline/compile-libreoffice/libo/sal/osl/unx
Entering /home/maryline/compile-libreoffice/libo/sal/textenc
Entering /home/maryline/compile-libreoffice/libo/sal/util
Entering /home/maryline/compile-libreoffice/libo/sal/cpprt
Entering /home/maryline/compile-libreoffice/libo/sal/cppunittester
Entering /home/maryline/compile-libreoffice/libo/sal/qa/osl/getsystempathfromfileurl
Entering /home/maryline/compile-libreoffice/libo/sal/qa/rtl/cipher
--
- start unit test #1 on library ../../../unxlngi6/lib/librtl_cipher.so
--
: && LD_LIBRARY_PATH=/home/maryline/compile-libreoffice/libo/clone/ure/sal/unxlngi6/lib:/home/maryline/compile-libreoffice/libo/solver/350/unxlngi6/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}} valgrind --tool=memcheck --leak-check=full --show-reachable=yes --num-callers=50 ../../../unxlngi6/bin/cppunittester ../../../unxlngi6/lib/librtl_cipher.so
==23403== Memcheck, a memory error detector
==23403== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==23403== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==23403== Command: ../../../unxlngi6/bin/cppunittester ../../../unxlngi6/lib/librtl_cipher.so
==23403==
OK (24)
==23403==
==23403== HEAP SUMMARY:
==23403== in use at exit: 302 bytes in 4 blocks
==23403== total heap usage: 1,221 allocs, 1,217 frees, 284,869 bytes allocated
==23403==
==23403== 8 bytes in 1 blocks are still reachable in loss record 1 of 4
==23403==at 0x4025018: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==23403==by 0x4103906: rtl_allocateMemory_SYSTEM (alloc_global.c:294)
==23403==by 0x4103976: rtl_allocateMemory (alloc_global.c:329)
==23403==by 0x41039E8: rtl_allocateZeroMemory (alloc_global.c:383)
==23403==by 0x40DD85B: osl_setCommandArgs (process_impl.cxx:242)
==23403==by 0x40DE097: sal_detail_initialize (salinit.cxx:39)
==23403==by 0x804B72B: main (cppunittester.cxx:89)
==23403==
==23403== 20 bytes in 1 blocks are still reachable in loss record 2 of 4
==23403==at 0x4023796: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==23403==by 0x4403105: _dlerror_run (dlerror.c:142)
==23403==by 0x4402B40: dlopen@@GLIBC_2.1 (dlopen.c:88)
==23403==by 0x408AD70: CppUnit::DynamicLibraryManager::doLoadLibrary(std::string
Re: [Libreoffice] Debug compilation fails in sal module
Hello, I've the same problem with this autogen on Ubuntu 10.04 64 too: --without-junit --enable-debug --enable-symbols 2011/6/23 serv serva > > De: Caolán McNamara > > Objet: Re: [Libreoffice] Debug compilation fails in sal module > > À: "Julien Nabet" > > Cc: libreoffice@lists.freedesktop.org > > Date: Jeudi 23 juin 2011, 12h52 > > On Thu, 2011-06-23 at 11:42 +0100, > > Caolán McNamara wrote: > > > On Wed, 2011-06-22 at 21:52 +0200, Julien Nabet > > wrote: > > > > Le 22/06/2011 13:55, Caolán McNamara a écrit : > > > > > On Tue, 2011-06-21 at 23:18 +0200, Julien > > Nabet wrote: > > > > >> I'm completely stucked, could it be a > > bug in one of the C++ libraries of > > > > >> Debian testing ? > > > ... > > > > I'm going to take a look at it and hope to find > > something. > > > > Some more thoughts, this is the debug build, this may be > > triggered by > > _GLIBCXX_DEBUG in solenv, removing those and rm -rf > > sal/unxlng* and a > > rebuild could test that theory. > > Your theory was right, I commented out all that concerns _GLIBCXX_DEBUG in > : > - sal/inc/unxgcc.mk > - sal/gbuild/platform/unxgcc.mk > > Then remove sal/unxlng* and build again. > Everything is ok. > > Julien. > ___ > LibreOffice mailing list > LibreOffice@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/libreoffice > -- Arnaud Versini ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSoC 2011][svgexport] weekly report #4
Marco wrote: > >Seems that > >0001-svg-export-filter-added-support-for-browsing-filters.patch is > >self-contained & functional, I'd commit that to master - for the two > >remaining patches, would you be happy with cleaning them up a bit & > > do you mean removing commented code and debugging code or else ? > Hi Marco, huh, terribly sorry for missing this mail - yes, I meant the debugging / commented out code. > >have incremental improvements from them committed as well? > > Sorry I don't catch the meaning! (an English issue from my side!) > Well, no deeper meaning here - just asking whether we can commit that as-is, since it's definitely an improvement over the current state. Thing is, since AFAIK you're working on -3-4, I'd only commit to master, and would like to prevent those two branches from diverging too far. Anyway, I like your 0001-svg-export-filter-added-support-for-browsing-filters.patch & will commit that tonight. :) Cheers, -- Thorsten pgp70gj0nCIch.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] RTF support
I had discovered that Open Office Writer does NOT really support functional RTF features (the ones that I tried anyway). When I posted issues to an OpenOffice Users Group, I was re-directed to Libre Office. Can I help in some way? Please advise. Thanks, Tracey As an End User, my experience has been to export (Documents and/or Data) in simple HTML or RTF text format for other End Users to use in their word Processor or Spreadsheet. -- View this message in context: http://nabble.documentfoundation.org/RTF-support-tp3114982p3114982.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 for make to help in gbuild debugging
On Mon, Jun 27, 2011 at 12:37 PM, Norbert Thiebaud wrote:
> On Mon, Jun 27, 2011 at 12:26 PM, Norbert Thiebaud
> wrote:
>> On Mon, Jun 27, 2011 at 12:03 PM, Tor Lillqvist
>> wrote:
If we do that, we definitely should then also add built-in mkdir and cp
commands in it,
>>>
>>> Hmm, or actually, I don't think that will be such a great win after all, as
>>> the gbuild recipies where tons of mkdir commands are being run typically
>>> are in a shell expression with && anyway, so they couldn't be run as
>>> "built-in" simple make commands anyway. Forget it.
>>
>> Yeah, but maybe there is something to be investigated to avoid fork
>> when running recipies... I've read somewhere that spawn was much more
>> performant than fork under cywin (note: I don;t know if make already
>> do that or not, nor what are the implication...)
>>
>> Another thing: I think most of these mkdir could be avoided at the
>> cost of another layer of dependencies: create rules for every target
>> so that the parent directory is a pre-req target and have rules for
>> directories to build them... that should put most of the the workload
>> on make itself an limit drastically the number of mkdir...
>
> Another solution is a quick and dirty path to make to have ot try to
> create the base directory of a target before running a recipe for it.
something like
diff -r -u make-3.82/commands.c make-3.82-lo_trace/commands.c
--- make-3.82/commands.c2010-07-12 20:20:37.0 -0500
+++ make-3.82-lo_trace/commands.c 2011-06-27 13:48:40.0 -0500
@@ -437,6 +437,45 @@
}
}
^L
+static int _create_dirname(const char* name)
+{
+char buffer[PATH_MAX + 1];
+char* cursor;
+
+if(name == NULL)
+{
+return 0;
+}
+strncpy(buffer, name, PATH_MAX);
+buffer[PATH_MAX] = 0;
+cursor = buffer + strlen(buffer);
+while(cursor > buffer)
+{
+if(*cursor == '/' || *cursor == '\\')
+{
+struct stat s;
+*cursor = 0;
+if(stat(buffer, &s))
+{
+if(errno == ENOENT)
+{
+if(_create_dirname(buffer))
+{
+return -1;
+}
+return mkdir(buffer, 0777);
+}
+}
+else
+{
+return 0;
+}
+}
+cursor -= 1;
+}
+return -1;
+}
+
/* Execute the commands to remake FILE. If they are currently executing,
return or have already finished executing, just return. Otherwise,
fork off a child process to run the first command line in the sequence. */
@@ -446,6 +485,7 @@
{
const char *p;
+ _create_dirname(file->name);
/* Don't go through all the preparations if
the commands are nothing but whitespace. */
Note: this need hardening on windows to deal with C:\ and //xxx stuf
and possibly with /./ or /../ in the path (I'm not sure they are
possible at that stage of make)
Norbert
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Michael Meeks wrote: > > Oh - well - since master is going to turn into 3.5, if that is not > parallel installing, then we have a problem - is it the case that the > 3.5 (master) snapshots - whatever we call them version-wise [ what do we > do there ? ] do not parallel install on windows still ? > I tested once with a master from the Provo tinderbox and it did install in parallel correctly so I'm keeping my hopes up for 3.5.x Michael Meeks wrote: > > Good feedback plino ! :-) Sometimes I manage to contribute positively ;) -- View this message in context: http://nabble.documentfoundation.org/minutes-of-tech-steering-call-tp3100951p3114786.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] development summary: year 2011, week 24
Hi John,
I am happy that your are working on it and have some nice results.
John LeMoyne Castle píše v Pá 24. 06. 2011 v 02:38 -0700:
> Hi Petr,
> Sorry about the confusion I created on a previous summary thread in my
> brainstorming attempt to get development summaries into the wiki.
> I know it was bad because it even seemed to infect your response a little.
I am not aware of any confusion. It is normal to have different views on
something and exchange ideas :-)
> This should be clearer.
>
> Here is an example of a wrapper (wiki-dev-sum)
> http://nabble.documentfoundation.org/file/n3103449/wiki-dev-sum wiki-dev-sum
OK, if I understand it correctly, it has the following purpose:
1. purpose is to generate the statistic for all active branches.
Well, this might make sense. I actually use a similar
wrapper that updates the repository to a given branch
and get the last changes. It is written in bash. Please,
find it attached.
It would be great to pass the list of branches via the
command line options.
You could use --option= even in bash. You could get
the param via:
param=`echo $arg | sed "s/--option=//"`
Note that the situation is a bit complicated. I have separate
git tree for master, libreoffice-3-4* and libreoffice-3-3*
branches because they are not compatible:
+ libreoffice-3-3 uses "build" repo as the
toplevel dir ; "bootstrap" repo is in
build/clone/bootstrap.
+ libreoffice-3-4 uses "bootstrap" as the top level
module
+ master is going to be switched to "single" git
repository, see
http://wiki.documentfoundation.org/Development/One_Git_Conversion
Well, it might be interesting to move this functionality to
the lo-commit-stat script. You could add new option:
--branches=[,...]
I created extra wrapper because it was easier to do it in
bash and I wanted a quick solution ;-)
2. purpose is to define the start and end day according to the
week.
It would be great to have it in the lo-commit-stat script. It
is very useful also for generating the plain log for E-mail.
Could you please add --year= --week= --last-week
options int lo-commit-stat? You could do something like:
if (defined $last_week) {
$year = get_this_year();
$week = get_this_week();
}
if (defined $week && ! defined $year) {
$year = get_this_year();
}
if (defined $week && defined $year) {
die "Error: Do not define extra git arguments together
with --year, --week, --this-week options"
if (@git_args);
@git_args = get_git_args_for_feek($year, $week);
$log_suffix = "week-$year-$week" unless (defined
$log_suffix)
}
You need not process these options in the wiki-dev-sum
wrapper. It might be enough to pass them to the
lo-commit-stat script.
3. Is there any other purpose of the wiki-dev-sum script?
BTW1: I was not sure what the --echo option means. Such functionality is
usually enabled via the option "--verbose" ;-)
Also the following negative condition looks a bit cryptic:
(! defined $echo) || show_call
I think that
(defined $verbose) && show_call(...)
or
show_call(...) if (defined $verbose);
is slightly better readable ;-)
BTW2: Using /tmp/commit-log-$branch-wiki.log is a bit dangerous because
any user could write to this file (security hole, write access
problems). I suggest to create a temporary directory
under /tmp/wiki-dev-sum-XX and put files under it. The question is
why you need the temp file at all. It would be better if lo-commit-stat
generates the right file to the final location and no postprocessing is
needed.
> that operates on a slightly modified lo-commit-stat script (basically just
> adds --wiki format option)
> http://nabble.documentfoundation.org/file/n3103449/lo-commit-stat
> lo-commit-stat
It looks great. I am just not sure about the change:
--- cut ---
-(defined $top_dir) || die "Error: top directory is not defined\n";
+if (! defined $top_dir) {
+ usage();
+ exit;
+}
--- cut ---
I think that the user might be confused why it prints help and what is
the exact problem.
> The intention is to make as few changes as possible in lo-commit-stat while
> getting to where a Weekly Development Summary wiki page is generated easily.
Do not hesitate to do more changes in lo-commit-stat ;-)
> I attached full scripts and not patches because the pair is brand new and
Re: [Libreoffice] [SOLVED] Debug-mode getline-using sal unittest crashes, triggered by _GLIBCXX_DEBUG
Le 27/06/2011 16:57, Caolán McNamara a écrit :
On Fri, 2011-06-24 at 20:02 +0200, Julien Nabet wrote:
But when i use the test file, nothing as you can see below :
$ g++ -D_GLIBCXX_DEBUG attachment.cxx
$ echo hello world | ./a.out
Line is: "hello world"
Hmm, hard to track down a reproducible test-case then. Anything in
echo hello world | valgrind ./a.out ?
$ cat test.c
#include
#include
using namespace std;
int main (int argc, char * const argv[]) {
string line;
getline(cin, line);
cout << "Line is: \"" << line << "\"" << endl;
return 0;
}
$ g++ -D_GLIBCXX_DEBUG test.c
$ echo hello world| valgrind ./a.out
==2612== Memcheck, a memory error detector
==2612== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==2612== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==2612== Command: ./a.out
==2612==
Line is: "hello world"
==2612==
==2612== HEAP SUMMARY:
==2612== in use at exit: 0 bytes in 0 blocks
==2612== total heap usage: 5 allocs, 5 frees, 96 bytes allocated
==2612==
==2612== All heap blocks were freed -- no leaks are possible
==2612==
==2612== For counts of detected and suppressed errors, rerun with: -v
==2612== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 6)
$
And was this with a system cppunit or the built-in one ?
libcppunit-1.12-1 and libcppunit-dev are not installed and in
config.log, I've got :
configure:14349: checking which cppunit to use
configure:14449: result: internal
So I suppose I use the build-in one.
Are there other tests I could do ?
Julien.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] patch for make to help in gbuild debugging
On Mon, Jun 27, 2011 at 12:26 PM, Norbert Thiebaud wrote: > On Mon, Jun 27, 2011 at 12:03 PM, Tor Lillqvist wrote: >>> If we do that, we definitely should then also add built-in mkdir and cp >>> commands in it, >> >> Hmm, or actually, I don't think that will be such a great win after all, as >> the gbuild recipies where tons of mkdir commands are being run typically are >> in a shell expression with && anyway, so they couldn't be run as "built-in" >> simple make commands anyway. Forget it. > > Yeah, but maybe there is something to be investigated to avoid fork > when running recipies... I've read somewhere that spawn was much more > performant than fork under cywin (note: I don;t know if make already > do that or not, nor what are the implication...) > > Another thing: I think most of these mkdir could be avoided at the > cost of another layer of dependencies: create rules for every target > so that the parent directory is a pre-req target and have rules for > directories to build them... that should put most of the the workload > on make itself an limit drastically the number of mkdir... Another solution is a quick and dirty path to make to have ot try to create the base directory of a target before running a recipe for it. i don't like it because it will never be accepted upstream and would prevent building without a patched version... But since there is a platform/* support we could have conditional on windows to not do the mkdir if we have the 'right' make. (iow maintain the buidability with a vanilla make, but still improve perf when a 'lo-make' is available.) Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] patch for make to help in gbuild debugging
On Mon, Jun 27, 2011 at 12:03 PM, Tor Lillqvist wrote: >> If we do that, we definitely should then also add built-in mkdir and cp >> commands in it, > > Hmm, or actually, I don't think that will be such a great win after all, as > the gbuild recipies where tons of mkdir commands are being run typically are > in a shell expression with && anyway, so they couldn't be run as "built-in" > simple make commands anyway. Forget it. Yeah, but maybe there is something to be investigated to avoid fork when running recipies... I've read somewhere that spawn was much more performant than fork under cywin (note: I don;t know if make already do that or not, nor what are the implication...) Another thing: I think most of these mkdir could be avoided at the cost of another layer of dependencies: create rules for every target so that the parent directory is a pre-req target and have rules for directories to build them... that should put most of the the workload on make itself an limit drastically the number of mkdir... Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] patch for make to help in gbuild debugging
> If we do that, we definitely should then also add built-in mkdir and cp > commands in it, Hmm, or actually, I don't think that will be such a great win after all, as the gbuild recipies where tons of mkdir commands are being run typically are in a shell expression with && anyway, so they couldn't be run as "built-in" simple make commands anyway. Forget it. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] No Python scripts visible in UI - build 350m1 from master nightly 27/06/2011 for Mac OSX
Le 27/06/11 18:53, Alexander Thurgood a écrit :
And here's the error message :
Error while installing extension MRI - UNO Object Inspection Tool. The
error message is: python-loader:exceptions.SyntaxError: ('invalid
syntax',
('/Applications/LibO-dev.app/Contents/basis-link/program/pythonloader.py',
116, 29, 'except ImportError as e:\n')), traceback follows
no traceback available
The extension will not be installed.
Alex
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] No Python scripts visible in UI - build 350m1 from master nightly 27/06/2011 for Mac OSX
Le 27/06/11 18:23, Alexander Thurgood a écrit : Trying to install a Python extension via the Extensions Manager fails with an error message complaining about XUnoInterface, and from then on the Python scripting extension appears grayed out in the extensions list. Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] patch for make to help in gbuild debugging
> You know; the temptation to check-in and build our own gnumake is growing on > me ;-) If we do that, we definitely should then also add built-in mkdir and cp commands in it, for the benefit of especially us poor Windows builders... But probably pointless to try to upstream that. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Re; windows daily builds availability
On Mon, Jun 27, 2011 at 9:35 AM, Caolán McNamara wrote: > On Mon, 2011-06-27 at 07:19 -0700, plino wrote: >> Petr Mladek wrote: >> > >> > It is well recommended to use daily builds from >> > http://dev-builds.libreoffice.org/daily/. They include the very last >> > fixes and can be installed in parallel with the announced builds. >> > >> >> That may be true for other OSes but not for Windows. Once LO gets to 3.5.x >> that will (hopefully) be a correct statement. > > Yes, we need to get windows and mac master daily builds especially. > There's only two tinderboxes listed at > http://tinderbox.libreoffice.org/MASTER/status.html and I think they've > been turned over to 3.4.X series. My mac one push dailies, and it is based on 'master' http://dev-builds.libreoffice.org/daily/MacOSX_10.6.7_Intel_no-moz/master/2011-06-27_08.26.21/ Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Extension manager does not start when dragging extensions from Finder onto main app window - build 350m1 from master nightly 27/06/2011 for Mac OSX
Le 27/06/11 18:27, Alexander Thurgood a écrit : Drag and drop also works if the extension is dropped onto the App icon in the Dock. This then launches the Extension Manager and proposes installation of the extension. Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Extension manager does not start when dragging extensions from Finder onto main app window - build 350m1 from master nightly 27/06/2011 for Mac OSX
Le 27/06/11 18:27, Alexander Thurgood a écrit : In fact, the behaviour of the Extension Manager is very strange. If I attempt to install an extension via the Tools > Extensions menu, the manager window does not appear, it is hidden from view, until the user repeats the menu action of Tools > Extensions, at which point the manager window appears, but on a different virtual desktop. Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Extension manager does not start when dragging extensions from Finder onto main app window - build 350m1 from master nightly 27/06/2011 for Mac OSX
So testing, testing, 1..2..3... ;-) In 3.3.x and 3.4.x you can drag and drop extensions from the Mac OSX Finder onto the LibreOffice main application window and it will launch the Extensions Manager. This no longer works in the nightly build from yesterday. Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] No Python scripts visible in UI - build 350m1 from master nightly 27/06/2011 for Mac OSX
Le 27/06/11 18:04, Alexander Thurgood a écrit : Not still a remnant of this I hope : https://bugs.freedesktop.org/show_bug.cgi?id=37015 Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Hi Michael, *, On Mon, Jun 27, 2011 at 5:49 PM, Michael Meeks wrote: > On Mon, 2011-06-27 at 07:19 -0700, plino wrote: >> That may be true for other OSes but not for Windows. Once LO gets to 3.5.x >> that will (hopefully) be a correct statement. > > Oh - well - since master is going to turn into 3.5, if that is not > parallel installing, then we have a problem - is it the case that the > 3.5 (master) snapshots - whatever we call them version-wise [ what do we > do there ? ] do not parallel install on windows still ? The problem with parallel-installability on windows did only apply to the release version, not to the LO-Dev variant. But of course if the bots that are providing builds are using the release configuration, including --enable-release-build configure switch, the build won't create LO-Dev packages. So I'm not sure whether your point is that LO 3.5.0 shall be installed next to LO 3.4.x on Windows instead of updating, or whether your point was only about the daily builds (where LO-Dev builds should be provided) ciao Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] patch for fdo#38561: can't save pw protected file without pw
The "Change Password" feature is not present in LibreOffice 3.3.2. It does appear in some sort of partially-implemented form in LibreOffice 3.4. I suspect that there may be interference of that feature with encryption-password handling. - Dennis ESSAY ON ENCRYPTION VERSUS LOCKING AND HOW DIFFERENT THEIR PASSWORDS ARE We need to remember that password use for encryption (i.e., Save As ... dialog Save with password check box) is very different from a password used for locking things in the document. Lock passwords are inherently insecure, since the hash is recorded in the document. So it is really not doing much harm to cache them, although they are a potential security exposure too. (I can understand why one might create and hold onto multiple hashes for a lock when it is not known which hash will be required by a format the document might be saved in and also while the user may still be fiddling with lock settings.) ENCRYPTION PASSWORDS DO NOT NEED A CACHE Encryption passwords should not be retained very long, and there is only one hash needed for an encryption password. Since it is known at the time the Save As ... is being done which initial-password hash algorithm will be used, this is when the password should be requested. As soon as all the key generations have been done and the file saved in encrypted form, that hash should disappear. There is no meaningful further use for it and it is a critical secret. Knowledge of that hash is enough for an attacker to be able to decrypt the document. Any memory residue of the original password and the hash used for encryption key generation must be obliterated as soon as possible for each of them. Even if there is a future provision for ODF 1.x encryption following signing (i.e., on an already-saved document), the password should not be requested until the encryption process is prepared to commence. So again, there is need to produce only the one initial password hash, depending on what the implementation of password-based key derivation requires, and that hash should disappear from memory (ideally, the stack or a randomized local heap allocation) as soon as the encryption completes. For decryption, the need for a password or its hash is likewise of short duration. Fitting the decryption password-hash into some common hash cache is not only unnecessary, it risks disclosure. Furthermore, on the off chance that a user uses the same password for encryption and for locking, there is an exposure to having a lingering cache even for locking, though if a machine is compromised the cache is the least of our worries. (Lock hashes are inaccessible in an encrypted document, but unencrypted documents from the same party definitely provide a source of hashes that one would try first in an attack on an encrypted document.) THIS MAY BE AN INTERFERENCE WITH CHANGES FOR LOCKING The partially implemented "change password" button on the LibreOffice 3.4 Document Properties | General tab, if related to encryption, doesn't make any sense to me. If it is related to document protection (not encryption) it is in the wrong place. CALLING THE WRONG THINGS "SECURITY" IS NOTHING BUT TROUBLE Calling protection a security feature is also problematic since locking a document against writing or making untracked changes is not a security feature. Protection (not encryption) in all forms is trivially subverted unless the document is signed, and that's an authenticity feature, not a security feature. If we are so confused about what is security and what is not, how are we helping users adopt safe practices and to, possibly, comprehend what is unsafe about actions they find convenient. I am thinking about the tendency to use the same memorable password for something as trivial as a lock and as important as an encryption password or for something even more valuable. I have a utility on my computer that will crack SHA1 hashes of not too long, memorable passwords in mere seconds using a well-crafted brute-force attack and the high-end GPU of my video card. Putting password hashes where they can be retrieved and attacked is an arms race we cannot win by simply choosing more complex hash algorithms and allowing users to believe their lives have been made more secure. - Dennis -Original Message- From: libreoffice-bounces+dennis.hamilton=acm@lists.freedesktop.org [mailto:libreoffice-bounces+dennis.hamilton=acm@lists.freedesktop.org] On Behalf Of Markus Mohrhard Sent: Monday, June 27, 2011 01:40 To: Andras Timar Cc: libreoffice-dev Subject: Re: [Libreoffice] [REVIEW] patch for fdo#38561: can't save pw protected file without pw Hello Andras, It's not clear to me why the functionality works in 3.3. Encryption data is not cleared there, too. I only had a closer look at the xls export and we didn't use the EncryptionData in the export there, at least not to detect i
Re: [Libreoffice] No Python scripts visible in UI - build 350m1 from master nightly 27/06/2011 for Mac OSX
Le 27/06/11 17:52, Christian Lohmaier a écrit : Hi *, > Well - no matter what switch: Do you have it in the installed build? > After all that is what counts. > If it's not there, then we can start digging in to why it is not > included / whether the right configure switch was used. ls /Applications/LibO-dev.app/Contents/share/extensions NLPSolver presenter-screen dict-en report-builder dict-es script-provider-for-beanshell dict-fr script-provider-for-javascript package.txt script-provider-for-python pdfimport wiki-publisher presentation-minimizer ls -an /Applications/LibO-dev.app/Contents/share/extensions/script-provider-for-python/ total 88 drwxr-xr-x@ 6 501 80204 27 jui 10:40 . drwxr-xr-x@ 15 501 80510 27 jui 10:40 .. drwxr-xr-x@ 3 501 80102 27 jui 10:40 META-INF -r--r--r--@ 1 501 80661 27 jui 10:40 description.xml -r--r--r--@ 1 501 80 38360 27 jui 10:40 pythonscript.py drwxr-xr-x@ 3 501 80102 27 jui 10:40 registration Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] No Python scripts visible in UI - build 350m1 from master nightly 27/06/2011 for Mac OSX
Hi Alexander, *, On Mon, Jun 27, 2011 at 5:35 PM, Alexander Thurgood wrote: > Le 27/06/11 17:33, Alexander Thurgood a écrit : > > I thought Tor had changed the python stuff so that the switch was now : > > --enable-python=auto Well - no matter what switch: Do you have it in the installed build? After all that is what counts. If it's not there, then we can start digging in to why it is not included / whether the right configure switch was used. If it is there, then the problem is more serious, and would require a much deeper look. ciao Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Hi there, On Mon, 2011-06-27 at 07:19 -0700, plino wrote: > That may be true for other OSes but not for Windows. Once LO gets to 3.5.x > that will (hopefully) be a correct statement. Oh - well - since master is going to turn into 3.5, if that is not parallel installing, then we have a problem - is it the case that the 3.5 (master) snapshots - whatever we call them version-wise [ what do we do there ? ] do not parallel install on windows still ? It also seems, that we don't in fact have windows or linux daily / release snapshots of master either - which is not a happy place to be; any thoughts on that Fridrich ? Good feedback plino ! :-) Thanks, Michael. -- michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] No Python scripts visible in UI - build 350m1 from master nightly 27/06/2011 for Mac OSX
Le 27/06/11 17:33, Alexander Thurgood a écrit : I thought Tor had changed the python stuff so that the switch was now : --enable-python=auto Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] No Python scripts visible in UI - build 350m1 from master nightly 27/06/2011 for Mac OSX
Le 27/06/11 17:26, Christian Lohmaier a écrit : Hi Christian, > > > Does that build include the python-scripting-provider extension? > > If not, then it's a build-configuration problem > I seem to recall it being in the build log, and so checked : --enable-ext-scripting-python --with-extension-integration were both included. Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] No Python scripts visible in UI - build 350m1 from master nightly 27/06/2011 for Mac OSX
Hi Alexander, On Mon, Jun 27, 2011 at 5:14 PM, Alexander Thurgood wrote: > > Downloaded daily build from yesterday for Mac : > > MacOSX_10.6.7_Intel_no-moz/master/2011-06-27_08.26.21 Does that build include the python-scripting-provider extension? If not, then it's a build-configuration problem (Tools|Extension Manager) ciao Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED][PATCH] fix broken image paths in help fdo#37509
On Mon, 2011-06-27 at 14:54 +0200, Andras Timar wrote: > 2011/6/27 Andras Timar : > > Can someone please push this to 3-4. I pushed a slightly different > > version to master (image paths were changes in master). > > two more paches of the same type: > http://cgit.freedesktop.org/libreoffice/help/commit/?id=ac114c54e5aa5c487070efe88dc3334503a81c95 > http://cgit.freedesktop.org/libreoffice/help/commit/?id=5a6bf68cdeac23f873fa58246c42d426d3b552ff Also pushed to 3-4 C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] No Python scripts visible in UI - build 350m1 from master nightly 27/06/2011 for Mac OSX
Hi *, Downloaded daily build from yesterday for Mac : MacOSX_10.6.7_Intel_no-moz/master/2011-06-27_08.26.21 Installed, started. There is no Python script menu entry in the Tools > Macros > Organise UI menu, only Basic, Javascript and Beanshell. They are present in the app bundle in : /Applications/LibO-dev.app/Contents/basis-link/share/Scripts Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: [PATCH] fix broken image paths in help fdo#37509
On Mon, 2011-06-27 at 12:51 +0200, Andras Timar wrote: > Hi, > > Can someone please push this to 3-4. Looks sane to me, pushed. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] can no longer encrypt files if build with --disable-mozilla
On Sun, 2011-06-26 at 20:26 +0200, Markus Mohrhard wrote: > Hello, > > is it in our intention that we can no longer encrypt files if we build > with --disable-mozilla? It seems that this was introduced through our > latest merge from OOo. It seems that we need SHA-1 and SHA256 since > the latest merge. SHA-1 still works but for SHA-256 we rely on NSS > which is disabled if we build with --disable-mozilla. This looks wrong to me, --disable-mozilla should only disable the "moz" build, not nss. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [SOLVED] Debug-mode getline-using sal unittest crashes, triggered by _GLIBCXX_DEBUG
On Fri, 2011-06-24 at 20:02 +0200, Julien Nabet wrote: > But when i use the test file, nothing as you can see below : > > $ g++ -D_GLIBCXX_DEBUG attachment.cxx > $ echo hello world | ./a.out > Line is: "hello world" Hmm, hard to track down a reproducible test-case then. Anything in echo hello world | valgrind ./a.out ? And was this with a system cppunit or the built-in one ? C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
On Fri, 2011-06-24 at 19:21 -0500, Norbert Thiebaud wrote: > As caolan said in another post, 'master' should no be seen as > 'unstable'. 'master' should be seen as the latest version about to be > released... Sure there will be time when master breaks... but that > should be rare and short-lived. There is also the need to distinguish between the *build* breaking and the code/binaries themselves being broken. The first is mostly a developer annoyance, though causes delays in getting dailies available for a platform and delays in development, but ultimately not having an effect on the quality of the product itself. The second is the real problem. Detecting problems early at the developer side, e.g. right at the moment they cock it up rather than later on when its available for qa, is a good thing. On that side of stuff we have currently... a) the smoketest which is automatically run now (on Linux and Mac) when a development does a make dev-install, so if the thing builds at all, it should be fairly guaranteed to be capable of basic use b) a pile of run-at-build-time unit tests which exercise things like .rtf import, .doc import, .xls import and other more obscure items. Again those should make it nigh impossible for a dev to break those fundamentally. c) the "make check" heavy weight subsequent checks automation, which is in need of some love in e.g. forms, and an updated test or two in sw, etc. That needs more work at the moment, though it did already find a problem in the binaryurp rework. b already IMO proved itself by e.g. finding early the potential cockups in the calc mdds work on windows, some obscure i18n text categorization stuff, the fascinating difference in some threading issues between windows and linux etc, some otherwise undetected merge problems in the .doc import etc. And, almost be definition, the only ones in the b category that anyone other than the originating developer gets to hear about are the different-platform ones. This is the right way in general for devs to go IMO, fix a bug and add a test to make sure it stays fixed. The gcc guys test-suite is a good example here. Hopefully the goal should be that what qa end up looking at are the "human" level things, stuff that doesn't work the way it's advertised, and GUI interactions that are hard to capture with unit tests. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] external LinLibertineG not available
On Mon, 2011-06-27 at 10:26 +0100, Michael Meeks wrote: > On Fri, 2011-06-24 at 17:48 +0200, Christian Lippka wrote: > > I'm doing a windows build, fetching > > > > 881af2b7dca9b8259abbca00bbbc004d-LinLibertineG-20110101.zip > > > > failed, looks like domain www.numbertext.org is expired. > > Which makes me wonder: why are we not mirroring these ourselves ? I > feel slightly nervous about the build downloading files from here, there > & everywhere :-) We have md5sum/sha1sum there so we're ok from that pov, outages are an issue. I'd be happy enough to use e.g. sourceforge mirrors for some of those souces, e.g. if we didn't include the checksum into the download urls themselves but listed them side-by-side and let the download do the rename if they match, allowing us to stick downloads.sourceforge.net urls directly in there without having to ask Fridrich or someone to upload the files to the download url. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Re; windows daily builds availability
On Mon, 2011-06-27 at 07:19 -0700, plino wrote: > Petr Mladek wrote: > > > > It is well recommended to use daily builds from > > http://dev-builds.libreoffice.org/daily/. They include the very last > > fixes and can be installed in parallel with the announced builds. > > > > That may be true for other OSes but not for Windows. Once LO gets to 3.5.x > that will (hopefully) be a correct statement. Yes, we need to get windows and mac master daily builds especially. There's only two tinderboxes listed at http://tinderbox.libreoffice.org/MASTER/status.html and I think they've been turned over to 3.4.X series. Given that the windows ones are a bottleneck, this is something where people with spare windows boxes can help out right now, e.g. see http://artax.karlin.mff.cuni.cz/~kendy/blog/archives/monthly/2011-02.html#2011-02-18T21_38_49.htm about how to set them up. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Petr Mladek wrote: > > It is well recommended to use daily builds from > http://dev-builds.libreoffice.org/daily/. They include the very last > fixes and can be installed in parallel with the announced builds. > That may be true for other OSes but not for Windows. Once LO gets to 3.5.x that will (hopefully) be a correct statement. You can in fact install 3.4.x in such a way that it doesn't uninstall or overwrite the stable build. But it is a hack. Not a proper install. Interestingly I have mentioned in another (ignored) topic that the Windows daily builds are based on code previous to the pre-releases (pre release is on 3.4.1rc3, daily builds are based on 3.4.1rc1) After a quick check, it seems that ALL daily builds for all OSes are based on 3.4.1rc1... I must be missing the logic here... -- View this message in context: http://nabble.documentfoundation.org/minutes-of-tech-steering-call-tp3100951p3113845.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] opengrok - all code
Hello all, On Mon, Jun 27, 2011 at 18:02, Andras Timar wrote: > Can you please remove "translations" module from the "all code" > shourcut? I have to click that 50 times a day. :) And maybe add "testing" into "all code" as well? Best Regards, -- Korrawit Pruegsanusak ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] patch for make to help in gbuild debugging
On Mon, Jun 27, 2011 at 6:03 AM, Michael Meeks wrote: > > On Sat, 2011-06-25 at 15:44 -0500, Norbert Thiebaud wrote: >> > I submitted the patch to the bug-make mailing list > > You know; the temptation to check-in and build our own gnumake is > growing on me ;-) you know you want to (TM) ... IMHO there are a few > nonsensical things that are done of utter pointlessness in there. I wouldn't mind so long as we keep that in dev-tools and don't mess with the main repos. iow: we build by default with the 'standard' make, but direct dev that are interested to dev-tools to get a better 'make'. Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Blockers for 3.4.1 release - central bug ID ?
Le 27/06/11 15:20, Petr Mladek a écrit : Hi Petr, > Blockers has to be linked to the meta bug for most annoying bugs > (fdo#35673) and set the severity "Blocker", see > http://wiki.documentfoundation.org/Release_Criteria#Blocker_Bug_Nomination Thanks, already done :-) Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Blockers for 3.4.1 release - central bug ID ?
Alexander Thurgood píše v Pá 24. 06. 2011 v 11:54 +0200: > Hi, > > I might have missed it, but do we have a bug ID for blockers for the > 3.4.1 release ? Blockers has to be linked to the meta bug for most annoying bugs (fdo#35673) and set the severity "Blocker", see http://wiki.documentfoundation.org/Release_Criteria#Blocker_Bug_Nomination Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] fix broken image paths in help fdo#37509
2011/6/27 Andras Timar : > Can someone please push this to 3-4. I pushed a slightly different > version to master (image paths were changes in master). two more paches of the same type: http://cgit.freedesktop.org/libreoffice/help/commit/?id=ac114c54e5aa5c487070efe88dc3334503a81c95 http://cgit.freedesktop.org/libreoffice/help/commit/?id=5a6bf68cdeac23f873fa58246c42d426d3b552ff Thanks, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [REVIEW] fdo#38457: Crash in DataPilot on moving the fields
Ladies & gents,
attached patch (somehow) fixes the crash in Calc's DataPilot caused by field
indexes being off-by-N. Consequent attempt to move such fields leads to
segfault.
It is regression from 3.3, the orig code was as follows:
SCCOL nColAdd = 0;
if ( bForFile )
{
// in old file format, columns are within document, not within source
range
DBG_ASSERT( pSheetDesc, "FillOldParam: bForFile, !pSheetDesc" );
nColAdd = pSheetDesc->aSourceRange.aStart.Col();
}
where 'if' branch has been unused since 2004 at least, as 'bForFile' variable
has been always set to false elsewhere in the code.
Later, it has been changed into this:
SCCOL nColAdd = pSheetDesc->GetSourceRange().aStart.Col();
apparently to fix a build failure (commit 523a8f41388f6d). But this seems to
produce wrong results -- shifts column index of DP field by N and attempt to
move such field crashes the whole thing.
From the comment in the 3.3 code (mentioning "old file format") I guess we can
assume column offset always set to 0 i.e. no column offset at all. But not
really sure about that, this is Yoshida-san's baby.
Consequently, some further code cleanup could be needed (i.e. nCollAdd param
can be completely removed from lcl_FillOldFields() ), but that's more a
material for master branch
hB.
--
\ Katarina Machalkova
\\\__o LibO developer
__\\\'/_ & hedgehog painter
From 19dada4d1cf45b1042788cd6ec3c7ea56c45e3a6 Mon Sep 17 00:00:00 2001
From: Katarina Machalkova
Date: Mon, 27 Jun 2011 13:35:01 +0200
Subject: [PATCH] fdo#38456: Always set column offset to 0
Setting it to anything else moves field indexes off-by-N and causes crash
in some cases (the original code has been unused since 2004 at least)
---
sc/source/core/data/dpobject.cxx |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/sc/source/core/data/dpobject.cxx b/sc/source/core/data/dpobject.cxx
index 472c451..93bfebb 100644
--- a/sc/source/core/data/dpobject.cxx
+++ b/sc/source/core/data/dpobject.cxx
@@ -1860,9 +1860,6 @@ sal_Bool ScDPObject::FillOldParam(ScPivotParam& rParam) const
// ppLabelArr / nLabels is not changed
SCCOL nSrcColOffset = 0;
-if (IsSheetData())
-// source data column offset is only for internal sheet source.
-nSrcColOffset = pSheetDesc->GetSourceRange().aStart.Col();
bool bAddData = ( lcl_GetDataGetOrientation( xSource ) == sheet::DataPilotFieldOrientation_HIDDEN );
lcl_FillOldFields(
--
1.7.3.4
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] patch for make to help in gbuild debugging
I'll add the internal gmake suggestion as a TSC topic for Thursday; personally I'd love to have a nice, faster, internal, GPL licensed build tool in our tree ;-) On Mon, 2011-06-27 at 13:24 +0200, Bjoern Michaelsen wrote: > @Michael: Did you try it again with "make -sr gb_CHECKOBJECTOWNER=" > because the checks for duplicate objects create some huge strings(*). nice - that is better: real0m12.445s user0m11.611s sys 0m0.771s vs. real0m18.068s user0m17.193s sys 0m0.805s without it; so ~6 secs difference; I wonder if tail-build should perhaps turn that off, leaving it for developers to see when they re-build just their piece [ inconsistent I know but ... ;-]. Thanks, Michael. -- michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] patch for make to help in gbuild debugging
Hi Michael, *, On Mon, Jun 27, 2011 at 1:03 PM, Michael Meeks wrote: > [...] > You know; the temptation to check-in and build our own gnumake is > growing on me ;-) :-) I wouldn't object to this - as gnumake >=3.81 is a requirement that has to be manually installed on Mac OSX 10.4/PPC, (as XCode 2.x only comes with make 3.80) > you know you want to (TM) ... IMHO there are a few > nonsensical things that are done of utter pointlessness in there. Getting rid of those will be an additional benefit. ciao Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] patch for make to help in gbuild debugging
Hi Michael, all, On Mon, 27 Jun 2011 12:03:16 +0100 Michael Meeks wrote: > It takes me only ~10 seconds to compile (and the same to > configure (urk)) gnumake. > > My current incremental, no-op tail_build takes: > > real 0m18.519s > user 0m17.679s > sys 0m0.769s > > Which seems too slow (and it's set to get worse) - 500ms or > more of that seems to be in verify_file_database() eg. which just > wanders around banging on the L2 cache checking strings are still > strings to no useful purpose ;-) but no doubt there is a lot more > that we can do to get this improved. Waiting for a 2014 release is cleary not nice. IMHO we should still get our stuff upstream, because diverting from upstream might create new "interesting" problems. So my proposal would be: - upstream patches - get them through some basic review upstream - add them to our patched version when reviewed upstream This way our patched version will: - not featurecreep away from upstream - get reviews by upstream - essentially be a prerelease of an upcoming make version - allow distros to still build with their default make by backporting the same patches that we do @Michael: Did you try it again with "make -sr gb_CHECKOBJECTOWNER=" because the checks for duplicate objects create some huge strings(*). Best, Bjoern (*) http://nabble.documentfoundation.org/gbuild-use-gb-CHECKOBJECTOWNER-to-check-for-double-linked-objects-td2827818.html > ATB, > > Michael. > -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSoC] library merging
Hi Matus, On Sat, 2011-06-25 at 16:21 +0200, Matúš Kukan wrote: > Well, that seems to be true. I haven't look at all yet. There is about > 240 of them. Heh :-) hopefully a ./g grep -6 component_getImple # will show you most of them rather quickly. > But sometimes there also exist things like in: > http://opengrok.libreoffice.org/xref/components/extensions/source/preload/services.cxx#59 > That doesn't seem interesting to me, but I don't know, maybe it > actually does something relevant. Ooh - you discovered some more junk code - nice. It would be wonderful if you could hunt down and kill any uses of this 'preload' code - we don't do OEM preloads, similarly we don't have product registration either so killing both of these components and their related scp2/ would be nice: STD_LIB_FILE( gid_File_Lib_Preload, preload) SPECIAL_COMPONENT_LIB_FILE( gid_File_Lib_Productregistration, productregistration.uno ) would help to shrink the codebase, distributed binary size and compile time. > And default is: throw loader::CannotActivateFactoryException. > There always has to be some function. Ok - but lets just not require this. AFAICS there is no good reason not to default to the C++ / current-language-binding-name for that. > So, if CPPU_CURRENT_LANGUAGE_BINDING_NAME can be also defined in > shlib, we could use that directly to set the variable. Right, it should be: cppu/inc/uno/lbnames.h:#define CPPU_CURRENT_LANGUAGE_BINDING_NAME CPPU_STRINGIFY( CPPU_ENV ) > I may be missing something but if not I'd just remove > component_getImplementationEnvironment if it is not doing something > special and set the variable directly in shlib. I don't think you're missing anything :-) Also I've never seen this 'getImplementationEnvironmentExt' method used - and it is another pretty pointless (slowish) dlsym lookup on activating a component - it seems to be the case that this is to allow people to have a different language for several components they might export. For 4.0 I think we want a single entry point, and if we want this goodness, surely we can add it to the XML annotation more cleanly, I've added it to the wiki page to track. Thanks, Michael. -- michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSOC] Multiline inputbar
On 27/06/11 12:14, Noel Power wrote: so I would not get overly hung up by this, we don't have to have exactly the same arrangement, I think a workable and useful first cut is as Kohei and I mentioned already oh and before I forget, I wouldn't even think about resizing by dragging with the mouse at least right now ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSOC] Multiline inputbar
On 27/06/11 09:24, Anurag Jain wrote: Hello Noel, Here I got some chance to play with MS Excel 2010 and I analyzed the behavior of inputbar. I'm sending an image here showing the desire behavior. The first figure in the image shows the normal behavior showing only a single line and keep on wrapping the content text on overflows.This is what has already been done in single line mode. 2: Second thing is to enable the button press. On button press as you can see, only two lines are shown and scrollbar shifts its position below the button (that is probably to make the UI consistent adjusting the button and scrollbar in double the height of the line. This actually does not affect the text output area, just makes things consistent).Scrollbar works same way scrolling single line at a time.This can be said as multiline mode. 3: The third thing is to make the inputbar re-sizable on the mouse drag. On hovering the down edge of the inputbar here the cursor changes and can be dragged to show the hidden contents (this also happens in units of single line height. Also here the scrollbar's thumb size changes depending on the height of the inputbar.) So if this is implemented in similar way it can be good UI enhancement to LO. As of now I'm trying to set the position of the scrollbar and button, making them appear at the right place i.e. after the inputbar. Also as of now I do not have any idea about the implementing the resizing of inputbar. As I've already sent the patch for fixing the width, height and border of the InputBarGroup and after i get the positions correctly we can start working on these improvements. so I would not get overly hung up by this, we don't have to have exactly the same arrangement, I think a workable and useful first cut is as Kohei and I mentioned already 1st pass - single line mode ( you have this already ) but you need to add a new button for switching the mode ( don't even worry about a scrollbar ) - multi-line mode, same as above but give a 'bigger' input area, maybe 5+ lines ( for the first pass I wouldn't even care about a scrollbar too much, just get it switching nicely, button placed properly etc. 2nd pass - single line mode as above - multi-line mode as above but with the scrollbar placed underneath the button after you get the above working then you could try and make it a bit sexier with adding the scrollbar in single line mode and some of the other behaviour thanks Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] patch for make to help in gbuild debugging
On Sat, 2011-06-25 at 15:44 -0500, Norbert Thiebaud wrote: > > I submitted the patch to the bug-make mailing list > > Note that, even if the patch is accepted by upstream, based on their > recent 'schedule', It won't probably be available in a 'realeased' > version until 2014 or something... so don't hold your breath. You know; the temptation to check-in and build our own gnumake is growing on me ;-) you know you want to (TM) ... IMHO there are a few nonsensical things that are done of utter pointlessness in there. It takes me only ~10 seconds to compile (and the same to configure (urk)) gnumake. My current incremental, no-op tail_build takes: real0m18.519s user0m17.679s sys 0m0.769s Which seems too slow (and it's set to get worse) - 500ms or more of that seems to be in verify_file_database() eg. which just wanders around banging on the L2 cache checking strings are still strings to no useful purpose ;-) but no doubt there is a lot more that we can do to get this improved. ATB, Michael. -- michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] opengrok - all code
Hi Cedric, Can you please remove "translations" module from the "all code" shourcut? I have to click that 50 times a day. :) Many thanks, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSOC][PATCH] Multiline inputbar
Hi Anurag On 26/06/11 18:23, Anurag Jain wrote: Hello Noel, On Fri, Jun 24, 2011 at 7:53 PM, Noel Power wrote: [...] I'm sending the fix patch here which calculates the height and width of the ScInputbarGroup and makes the border invisible. great, thanks for that, more comments about the patch below There is no class named as ScTextWindow forgive my typo, I meant ScTextWn I suggest this because it is intended when the gsoc code is initially integrated that it be configurable and for this reason it probably makes sense to preserve the original ScTextWindow class and distinguish it from your new implementation. This will make maintenance easier. So I guess there should not be any problem with the maintenance of code as I've not renamed any pre existing class and just inserted a new class i.e ScInputBarGroup. well, true you have created a new class but additionally you have modified the existing class ScTextWnd, I suspect you will need to modify that class even more which is why I suggest that you rename the current version of ScTextWnd ( e.g. the one with your modifications ) to ScSomeNewName and restore the old ScTextWnd class. That way the old class is available to swap in at runtime and all ( or nearly all ) your modifications are in new classes. Then next thing to concentrate on is getting the multi-line textbox functionality to work and to make that behaviour switchable. I believe Kohei suggested adding a button to the ScInputBarGroup window. So, you need to be able to detect the button click and switch the state of the bIsMultiLine flag that you have already added ( presumably for this purpose ) please do a grep for PushButton& SetClickHdl in sc for sample code for handling the button. Next hurdle which I'm trying to get through is getting the Scrollbar and Button at the right position after the Textbar ends. Does the function SetPosSizePixel() or SetPosPixel() in window.hxx can be used for getting them at the desired position. yes, you will need to set the position of the controls within the window manually by the methods you mention Or is there any other more modular way to decide the ordering of these items similar to InsertWindow() and InsetItem() methods used in ScInputWindow ? I don't think so, afaik the methods you mention are specific to a toolbar which has it's own custom layouting When you get a button click you will need to resize your InputBarGroupbox window based on the new state of the bIsMultiLine flag and of course increase the height in multiples of the calculated height of a single line. e.g. in Multiline mode the ScInputGroupBox height should be some multiple of the calculated singleline height ( maybe 10 as a default ? ) Of course the size of the ScMultiLineTxtWin (let's call it that for now but please rename it as you wish ) window needs to also be adjusted and everything resized. I would do this first before worrying about scrollbar behaviour. yes as soon as I get things placed in right place I'll be working on switching from single line to multiline mode on the button click. please just implement the button and the multiline mode switching for the moment, adding the scrollbar to the mix adds more complexity and I would prefer to get the core functionality working first. Then you can build on that existing functionality to add more 'features'. Of course if you get the button and multiline-mode switching working then by all means start looking at the scrollbar part. now, about the patch... a) so, like mentioned above probably better to not enable those scrollbar drawing bits for the moment b) Toolbox::Resize(), in line with the comments above about minimizing changes to the existing codebase by the multimode changes I'd prefer if the ScInputBarGroup class would take care of it's own resize. Currently how it's done doesn't make a whole lot of sense e.g. Toolbox::Resize manually calculates the size of the ScInputBarGroup, sets it's size then calls ScInputBarGroup::Resize, that just doesn't feel right. I think ScInputBarGroup::Resize should just calculate it's size ( taking whatever values from the parent window as needed ) c) at the moment ScInputBarGroup::Resize() is setting the aTextWindow's height to 22, I don't think the size of aTextWindow's height should be hardcoded to a number, looking in the code for ScTextWnd ( or whatever you rename it to be ) it already calculates the height ( single line height I guess ) I think it would make sense add a method to ScTextWndRenamedToSomething like 'GetSingleLineHeight' and then resize the ScInputBarGroup & ScTextWndRenamedToSomething based on the number of lines you want to display, e.g. 1 * ScTextWndRenamedToSomething.GetHeight() for single line mode, and 'N' * ScTextWndRenamedToSomething.GetHeight() for multiline mode. hope that makes sense :-) Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.
Re: [Libreoffice] minutes of tech steering call ...
Cor Nouws píše v Pá 24. 06. 2011 v 08:43 +0200: > plino wrote (24-06-11 02:03) > > BTW since only Betas can be installed in parallel with the stable build > > under Windows and that was not added to the 3.4.x branch (at least from my > > understanding) I guess Windows Beta testers will have to wait for 3.5.x, > > right? > > Well, I don't see any betas coming for the 3.4.x branch, so whether is > has been added or not, does not make sense. > I only can point to my favourite page: > http://wiki.documentfoundation.org/Installing_in_parallel It is well recommended to use daily builds from http://dev-builds.libreoffice.org/daily/. They include the very last fixes and can be installed in parallel with the announced builds. Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] fix broken image paths in help fdo#37509
Hi, Can someone please push this to 3-4. I pushed a slightly different version to master (image paths were changes in master). Thanks, Andras 0001-fix-broken-image-paths-in-help-fdo-37509.patch Description: application/mbox ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] minutes of tech steering call ...
Hi Cor, On Sat, 2011-06-25 at 23:52 +0200, Cor Nouws wrote: > And indeed, I see no reason why that would be a natural thing happening. > If there is a moment that we know: QA on this build is important, do > this ... that will help focussing :-) So :-) now is this moment. It is important to have QA guys running the daily builds for their day-to-day work / use-cases :-) I think this is the basic problem, a lack of communication around what is good to be testing, and a lack of willingness to test 'master' ( because it is too buggy ;-) combined with a hope that master gets less buggy as/when we release it. Anyhow - there are various psychological ways we can approach this, by having a different timetable for the QA team, that has a label marked "feature freeze" (ONO) - whatever it is that triggers you guys starting to do the QA, at a given date, and then the coder's feature freeze a bit later ;-) We can put the prefixes 'soft' and 'hard' on this to make it a bit clearer even if we want. Anyhow - I assume you didn't submit the talk, since Drew was pointing out the lack of papers, so I've just done that ;-) [snip] Title: Improving the Development / QA cycle Short Summary: A panel discussing how to better integrate the QA / Development cycle, timelines, freezes and all Abstract: Many proposals to improve quality of the product have been made, some of these revolve around scheduling and timing. Come hear a discussion about our current release process, how it works what 'time based' really means, and the impact that needs to have on our process. And hear about what can be done to improve it from various perspectives. I'd like to have: Cor Nouws, Rainer, Caolan, myself, Norbert, Petr Mladek, and a few more QA'ish types of our selection :-) [/snip] ATB, Michael. -- michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [GSoC] [rtfimport] 5th week
Hi, Fifth week starts here: http://cgit.freedesktop.org/~vmiklos/lo-gsoc/tree/README#n618 In short, it was about: - finished tables, including nested tables - sections - page sizes, margins - started headers/footers Miklos pgp1pA1HYE7Bi.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] l10n process for help content (WAS: [PATCH] Update help fdo#31652)
2011/6/27 Michael Meeks : > > On Sun, 2011-06-26 at 18:57 +0700, Korrawit Pruegsanusak wrote: >> On Fri, Jun 24, 2011 at 19:47, Caolán McNamara wrote: >> > Seems nuts to me that its better to keep translations of incorrect help >> > content in sync than to have at least some of them right, but *shrug*, >> > whatever's easiest to manage. >> >> Currently there are many help contents that obsolete or inaccurate. >> But wrt the string freeze, we couldn't release the fix of them >> (because they all must happen in master), and user have to wait for >> the next 3.x major release to have them correct, which is every >> too-long six months. > > Right - that is a pain, we'd like the stable branch to improve wrt. > translations too - but of course we don't want un-translated English > texts showing up either. > > I wonder if there is an analog of the patch situation, whereby we can > back-port a set of string translations to all languages from master ? The "master copy" of translations is with each l10n team and is not in git or Pootle. That means we can back-port or fix anything in git or Pootle, but translators can overwrite it with an older copy. So the real challenge it to have something fixed at the translators' master copy, which could be in Pootle, or a in a custom l10n system, or in files on translator's hard disk etc. Cheers, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] external LinLibertineG not available
On Mon, Jun 27, 2011 at 10:26:30AM +0100, Michael Meeks wrote: > > On Fri, 2011-06-24 at 17:48 +0200, Christian Lippka wrote: > > I'm doing a windows build, fetching > > 881af2b7dca9b8259abbca00bbbc004d-LinLibertineG-20110101.zip > > failed, looks like domain www.numbertext.org is expired. > > Which makes me wonder: why are we not mirroring these ourselves ? I > feel slightly nervous about the build downloading files from here, there > & everywhere :-) > > Thoughts ? Depends if it's part of LibreOffice or not. IMHO, every part of LibreOffice needed to produce a release should be available from a single source, managed by the Project's team itself. For now, 3 separate URLs are needed to produce packages with the options I have choosen : http://download.documentfoundation.org/libreoffice/src/ http://download.go-oo.org/src/ http://www.numbertext.org/linux/ The files under go-oo.org and numbertext.org should also be available from download.documentfoundation.org. -- Francois Tigeot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] l10n process for help content (WAS: [PATCH] Update help fdo#31652)
On Sun, 2011-06-26 at 18:57 +0700, Korrawit Pruegsanusak wrote: > On Fri, Jun 24, 2011 at 19:47, Caolán McNamara wrote: > > Seems nuts to me that its better to keep translations of incorrect help > > content in sync than to have at least some of them right, but *shrug*, > > whatever's easiest to manage. > > Currently there are many help contents that obsolete or inaccurate. > But wrt the string freeze, we couldn't release the fix of them > (because they all must happen in master), and user have to wait for > the next 3.x major release to have them correct, which is every > too-long six months. Right - that is a pain, we'd like the stable branch to improve wrt. translations too - but of course we don't want un-translated English texts showing up either. I wonder if there is an analog of the patch situation, whereby we can back-port a set of string translations to all languages from master ? ATB, Michael. -- michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] What is "important bug fixes" for bugfix release?
Hi there, On Sun, 2011-06-26 at 21:27 +0700, Korrawit Pruegsanusak wrote: > I wonder what are the criteria specifying whether a bug should be > fixed in which stable branch, if it affects all ? :-) it is basically down to needing a developer to care about the issue enough to propose the patch, and get the double review needed to have it arrive on the branch, > Such as, in my understanding, fdo#33149 is fixed in master after > branching -3-3 but before -3-4, so -3-4 has it but -3-3 not. Sounds likely. > I've found in wiki [1] that 3.x.y has "only important bug fixes ...", > but the point is: what is "important"? At this stage of the game that is mostly security bugs I think - unless you can motivate someone to back-port and test your fix. HTH, Michael. -- michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] external LinLibertineG not available
On Fri, 2011-06-24 at 17:48 +0200, Christian Lippka wrote: > I'm doing a windows build, fetching > > 881af2b7dca9b8259abbca00bbbc004d-LinLibertineG-20110101.zip > > failed, looks like domain www.numbertext.org is expired. Which makes me wonder: why are we not mirroring these ourselves ? I feel slightly nervous about the build downloading files from here, there & everywhere :-) Thoughts ? Michael. -- michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] WeLiket: Real-time Online With Your Friends
Hello, The WeLiket toolbar is a revolutionary new way to discuss your favorite items live and online with your friends. Get the free WeLiket toolbar now and start chatting with your best friends in a Live Show Room today! Kind regards, Select2gether Give the people you care about gift of real-time social interaction. Share the news about WeLiket with your friends and family now! Email Preferences If you wish to change your email address or unsubscribe from future email advertisements from Select2gether.com, please update your email preferences. We respect your privacy. For more information, please read Select2gether's privacy policy. <><><><><>___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH][PUSHED] impress: after adding a new animation, scroll down to it in the list.
2011/6/27 Radek Doulík
> Hi Luke,
>
> > @@ -542,6 +543,7 @@ void
> > CustomAnimationList::select( CustomAnimationEffectPtr pEffect, bool
> > bSelect
> > {
> > append( pEffect );
> > select( pEffect );
> > +MakeVisible( Last() );
>
> we don't need to call it here ^^^, as select( pEffect ); on the previous
> line recursively calls this function again and it is made visible from
> the loop above already. So it should be enough to add it to the loop.
>
Ah yes, of course!
I have updated your patch and pushed it.
Thanks very much :)
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] patch for fdo#38561: can't save pw protected file without pw
Hello Andras, > It's not clear to me why the functionality works in 3.3. Encryption > data is not cleared there, too. > > I only had a closer look at the xls export and we didn't use the EncryptionData in the export there, at least not to detect if the file is pw protected. There we used the SID_PASSWORD entry witch was cleared in both cases. I think it was the first step to some changes that we have in master where the pw code was changed in several places. Regards, Markus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH][PUSHED] impress: after adding a new animation, scroll down to it in the list.
Hi Luke,
> @@ -542,6 +543,7 @@ void
> CustomAnimationList::select( CustomAnimationEffectPtr pEffect, bool
> bSelect
> {
> append( pEffect );
> select( pEffect );
> +MakeVisible( Last() );
we don't need to call it here ^^^, as select( pEffect ); on the previous
line recursively calls this function again and it is made visible from
the loop above already. So it should be enough to add it to the loop.
I have updated your patch and pushed it.
Cheers
Radek
> }
> }
On Sun, 2011-06-26 at 22:27 +1200, Luke Symes wrote:
> Hi Radek,
>
> On Sat, Jun 25, 2011 at 3:35 AM, Radek Doulik wrote:
>
> At least I am not reaching the part you modified when adding
> custom
> animation thru custom animation pane (using the add button and
> custom
> animation dialog). If we move it to the loop, it will be
> reached always
> when selecting an entry - the select method is called
> recursively when
> adding new pEntry in:
>
>if( !pEntry && bSelect )
>{
>append( pEffect );
>select( pEffect );
>}
>
> I wonder how do you reach that part of code?
>
>
> Hmm. I think the code is incorrect here. That last if statement should
> really only be used if the effect wasn't in the list & needs to be
> added. But when I added the MakeVisible in the if statement, it made
> new animations be scrolled to, and I was doing it via add->custom
> animation dialog too. What do you think of my attached patch? Once we
> have found the given entry, we should select it and then we are done,
> aren't we?
>
>
> Kind regards,
>
>
> Luke.
--
Radek Doulík
Novell, Inc.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [GSOC] Multiline inputbar
Hello Noel, Here I got some chance to play with MS Excel 2010 and I analyzed the behavior of inputbar. I'm sending an image here showing the desire behavior. The first figure in the image shows the normal behavior showing only a single line and keep on wrapping the content text on overflows.This is what has already been done in single line mode. 2: Second thing is to enable the button press. On button press as you can see, only two lines are shown and scrollbar shifts its position below the button (that is probably to make the UI consistent adjusting the button and scrollbar in double the height of the line. This actually does not affect the text output area, just makes things consistent).Scrollbar works same way scrolling single line at a time.This can be said as multiline mode. 3: The third thing is to make the inputbar re-sizable on the mouse drag. On hovering the down edge of the inputbar here the cursor changes and can be dragged to show the hidden contents (this also happens in units of single line height. Also here the scrollbar's thumb size changes depending on the height of the inputbar.) So if this is implemented in similar way it can be good UI enhancement to LO. As of now I'm trying to set the position of the scrollbar and button, making them appear at the right place i.e. after the inputbar. Also as of now I do not have any idea about the implementing the resizing of inputbar. As I've already sent the patch for fixing the width, height and border of the InputBarGroup and after i get the positions correctly we can start working on these improvements. Thanks and regards -- Anurag Jain Final yr B.Tech CSE SASTRA University Thanjavur(T.N.)-613402 <>___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] A good Sunday to you all
Hi Drew, On Sun, 2011-06-26 at 11:33 -0400, drew wrote: > http://conference.libreoffice.org/submit-your-paper/ Thanks for your great work on this ;-) I'll add it to the next TSC agenda, hopefully we'll get some real thinking on that Thursday ... :-) Otherwise we're going to have lots of BoFs I think: I'd love to run a "where UNO fails" flame-fest :-) ATB, Michael. -- michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [PUSHED:master] Fix for Bug 37484 - On any animation change, current position in list is lost
Hi Luke, thanks for the fix! Pushed. Cheers Radek On Sun, 2011-06-26 at 22:23 +1200, Luke Symes wrote: > Hi Radek, > > On Sat, Jun 25, 2011 at 3:47 AM, Radek Doulik wrote: > I run into a crash on startup in that part. I quickly fixed > it, but it > might be better if you check that it plays nicely with your > new code. Or > maybe make the ScrollToAbsPos not crash when called with > unexpected > values, -1 for example. > > > Thanks for fixing this! You're right, I didn't test loading a blank > presentation... Your quick fix fits well with the rest of the code; > nFirstVis will never be -1 if there are entries in the > CustomAnimationList. I was sad that ScrollToAbsPos failed; it turns > out that it's due to there being no entries in the list (I had added a > check for negative scroll position values which would try to go to > scroll to the first entry). I have attached a patch for ScrollToAbsPos > that will check if there are entries in the list first, and if not > just return. Could you please review/commit this? > > > Kind regards, > > > Luke. -- Radek Doulík Novell, Inc. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] patch for fdo#38561: can't save pw protected file without pw
Hello, 2011/6/27 Markus Mohrhard : > Hello, > > this patch fixes the problem that we are unable to save a password protected > file without a password. The problem is that we don't clear the old > encryption data and copy them from the old ItemSet. We merge two ItemSets > there, and the information about encryption should always come from the > ItemSet filled during the file dialog. > > I think we should include this patch in the 3-4 branch. I think this patch > only applies to 3-4 but not to master, so if this patch is accepted I'll > write a second one for master and push it. > It's not clear to me why the functionality works in 3.3. Encryption data is not cleared there, too. Best regards, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
