Open mailing lists
Less than 2 months after using this mailing list I've started getting spam to the custom email address I used to post here. I think it's terrible practice to openly publish email addresses in easily harvestable form. I'll be /dev/nulling this address and unsubscribing. I hope you could reconsider that policy, Darren On Tue, Mar 13, 2012 at 10:05:52PM -0700, daz wrote: > On Tue, Mar 13, 2012 at 07:58:10AM -0500, Hyrum K Wright wrote: > > On Tue, Mar 13, 2012 at 5:45 AM, Philip Martin > > wrote: > > > s...@feb17.org writes: > > > > > >> A little more information on this. I have probably rebuilt svn about 20 > > >> times tonight from scratch, with > > Thanks to everyone who contributed useful clues on this. Using the current > code tree and rebuilding with different versions and combinations of > libraries I narrowed the problem down to the apr version. Either the build > of my earlier apr 1.3.9 or the version itself was the problem. The test > suite was super helpful and the explanation about XFAIL vs FAIL. I have a > build using apr 1.4.6 that passes all the tests it should pass and more > importantly actually works.It might be helpful to print a reminder at the > end of the default make step suggesting running the tests if this is a common > problem. There are a lot of dependencies and some of them seem to be a bit > finicky. > > Thanks! > Darren
Re: Open mailing lists
On Mon, Jun 18, 2012 at 06:14:30AM -0500, Hyrum K Wright wrote: > It should also be pointed out that a spammer could easily subscribe > directly to the list and get all the address information that way, > completely by passing any archives. > > For completeness, the ASF's public archive policy, which we adhere to, > is here: http://www.apache.org/foundation/public-archives.html > > Best, > -Hyrum At least that's a tiny bit more work for them to sign up for every email list serve in the world. Harvesting openly published email addresses is just too easy. They would ideally never appear anywhere in the first place so they couldn't be mirrored. I understand your constrants but I still think this is appalling from an engineering point of view and won't participate if it means leaving a please spam me trail behind me. Sorry, Darren > > On Mon, Jun 18, 2012 at 3:20 AM, Greg Stein wrote: > > Darren, > > > > Over a dozen sites mirror our archives, usually by grabbing our published > > mbox for the list. As a result, we cannot control how they publish the email > > addresses contained within. It is also important for those mboxes to retain > > the email addresses for archival purposes, and so those third-party systems > > can allow proper replies (hopefully, only by humans, but as you've > > discovered... they are not all perfect). > > > > Sorry for any inconvenience, but please don't blame us. We do try to respect > > your privacy in our own web archive system. > > > > Cheers, > > -g > > > > On Jun 18, 2012 5:10 AM, wrote: > >> > >> Less than 2 months after using this mailing list I've started getting spam > >> to the custom email address I used to post here. I think it's terrible > >> practice to openly publish email addresses in easily harvestable form. > >> I'll > >> be /dev/nulling this address and unsubscribing. I hope you could > >> reconsider > >> that policy, > >> > >> Darren > >> > >> On Tue, Mar 13, 2012 at 10:05:52PM -0700, daz wrote: > >> > On Tue, Mar 13, 2012 at 07:58:10AM -0500, Hyrum K Wright wrote: > >> > > On Tue, Mar 13, 2012 at 5:45 AM, Philip Martin > >> > > wrote: > >> > > > s...@feb17.org writes: > >> > > > > >> > > >> A little more information on this. I have probably rebuilt svn > >> > > >> about 20 times tonight from scratch, with > >> > > >> > Thanks to everyone who contributed useful clues on this. Using the > >> > current code tree and rebuilding with different versions and > >> > combinations of > >> > libraries I narrowed the problem down to the apr version. Either the > >> > build > >> > of my earlier apr 1.3.9 or the version itself was the problem. The test > >> > suite was super helpful and the explanation about XFAIL vs FAIL. I > >> > have a > >> > build using apr 1.4.6 that passes all the tests it should pass and more > >> > importantly actually works. It might be helpful to print a reminder at > >> > the end of the default make step suggesting running the tests if this is > >> > a > >> > common problem. There are a lot of dependencies and some of them seem > >> > to be > >> > a bit finicky. > >> > > >> > Thanks! > >> > Darren > > > > -- > > uberSVN: Apache Subversion Made Easy > http://www.uberSVN.com/
Re: Open mailing lists
Yes again sorry this is probably the wrong place to opine on this topic. I generally use disposable email addresses but accidentally used a permanent long term address at one point, otherwise I'd just have cut off the bleeding there. I don't think it's easy for everyone to generate lots of disposable addresses. If there's any way of nuking this page, it would be appreciated http://mail-archives.apache.org/mod_mbox/subversion-dev/201203.mbox/raw/%3c20120314050552.gm5...@clowder.feb17.org%3E It doesn't appear to have been replicated yet. I'm really sorry to disrupt the svn discussion. I've joined two open source mailing lists and been spammed as a result 100% of the time, so it's buyer beware. I think it would be wonderful if someone looked at the list serve infrastructure and made it safer. This feels like telnet circa 1995, Adieu and thanks for listening, Darren > Nearly all open-source projects rely on email communications, and most > are publicly archived in >1 places. > > You could use auto-expiring email addresses (for example, > address-$((1+$(date +%Y%m%d)))@domain) --- they are still valid but > pretty useless for spammers. > > > Sorry, > > > > Darren > > > > > > > > On Mon, Jun 18, 2012 at 3:20 AM, Greg Stein wrote: > > > > Darren, > > > > > > > > Over a dozen sites mirror our archives, usually by grabbing our > > > > published > > > > mbox for the list. As a result, we cannot control how they publish the > > > > email > > > > addresses contained within. It is also important for those mboxes to > > > > retain > > > > the email addresses for archival purposes, and so those third-party > > > > systems > > > > can allow proper replies (hopefully, only by humans, but as you've > > > > discovered... they are not all perfect). > > > > > > > > Sorry for any inconvenience, but please don't blame us. We do try to > > > > respect > > > > your privacy in our own web archive system. > > > > > > > > Cheers, > > > > -g > > > > > > > > On Jun 18, 2012 5:10 AM, wrote: > > > >> > > > >> Less than 2 months after using this mailing list I've started getting > > > >> spam > > > >> to the custom email address I used to post here. I think it's terrible > > > >> practice to openly publish email addresses in easily harvestable form. > > > >> I'll > > > >> be /dev/nulling this address and unsubscribing. I hope you could > > > >> reconsider > > > >> that policy, > > > >> > > > >> Darren > > > >> > > > >> On Tue, Mar 13, 2012 at 10:05:52PM -0700, daz wrote: > > > >> > On Tue, Mar 13, 2012 at 07:58:10AM -0500, Hyrum K Wright wrote: > > > >> > > On Tue, Mar 13, 2012 at 5:45 AM, Philip Martin > > > >> > > wrote: > > > >> > > > s...@feb17.org writes: > > > >> > > > > > > >> > > >> A little more information on this. I have probably rebuilt svn > > > >> > > >> about 20 times tonight from scratch, with > > > >> > > > > >> > Thanks to everyone who contributed useful clues on this. Using the > > > >> > current code tree and rebuilding with different versions and > > > >> > combinations of > > > >> > libraries I narrowed the problem down to the apr version. Either > > > >> > the build > > > >> > of my earlier apr 1.3.9 or the version itself was the problem. The > > > >> > test > > > >> > suite was super helpful and the explanation about XFAIL vs FAIL. I > > > >> > have a > > > >> > build using apr 1.4.6 that passes all the tests it should pass and > > > >> > more > > > >> > importantly actually works. It might be helpful to print a > > > >> > reminder at > > > >> > the end of the default make step suggesting running the tests if > > > >> > this is a > > > >> > common problem. There are a lot of dependencies and some of them > > > >> > seem to be > > > >> > a bit finicky. > > > >> > > > > >> > Thanks! > > > >> > Darren > > > > > > > > > > > > -- > > > > > > uberSVN: Apache Subversion Made Easy > > > http://www.uberSVN.com/
Segfault in SVN 1.7.4
I started having issues with svn a while back and it took me a while to realize it was segfaulting on the linux side. I've upgraded to 1.7.4 and the problem remains. I finally ran the operation with apache runnning in GDB and it's a strlen operation that fails. A lot of vars are optimized out so I didn't get much more information except that it appears to be trying to report a problem but then dying while reporting. OS: Linux clowder.feb17.org 2.6.38.8-32.fc15.x86_64 #1 SMP Mon Jun 13 19:49:05 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux Build details: $ ./configure --prefix=/tools/subersion-1.7.4 --with-apr=/tools/apr-1.3.9/ --with-apr-util=/tools/httpd-2.2.19-src/srclib/apr-util/ --with-apxs=/tools/httpd-2.2.19/bin/apxs --with-neon=/tools/neon-0.29.0 --with-sqlite=/tools/sqlite-3.7.10 --with-sasl=/tools/cyrus-sasl-2.1.25 No berkeley db. Because I wasn't using this repository too often, I don't know what initiated the unhappiness. It's possibly a file system change (it's running on secure linux and I suspect I had to move the repository due to disk failure so maybe a permissions issue). The repository passes checks, can be browsed just fine, but when I commit or create a simple folder (as in the traceback here), it crashes. Any help greatly appreciated and if there's something I can do to get better information to you, let me know, Sincerely, Darren Platt Traceback below. Starting program: /tools/httpd-2.2.19/bin/httpd -X -f /etc/httpd/conf/httpd.conf [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0x003be1126d9f in __strlen_sse42 () from /lib64/libc.so.6 Missing separate debuginfos, use: debuginfo-install expat-2.0.1-11.fc15.x86_64 glibc-2.14-2.x86_64 keyutils-libs-1.2-7.fc15.x86_64 krb5-libs-1.9-7.fc15.x86_64 libcom_err-1.41.14-2.fc15.x86_64 libselinux-2.0.99-4.fc15.x86_64 libuuid-2.19.1-1.2.fc15.x86_64 libxml2-devel-2.7.8-6.fc15.x86_64 nss-softokn-freebl-3.12.10-1.fc15.x86_64 openssl-1.0.0d-1.fc15.x86_64 zlib-1.2.5-3.fc15.x86_64 (gdb) (gdb) where #0 0x003be1126d9f in __strlen_sse42 () from /lib64/libc.so.6 #1 0x77ba0e71 in apr_vformatter (flush_func=0x77bab730 , vbuff=0x7fffddd0, fmt=0x758be937 "s", ap=0x7fffde38) at strings/apr_snprintf.c:974 #2 0x77bace16 in apr_pvsprintf (pool=0x83b588, fmt=, ap=) at memory/unix/apr_pools.c:1142 #3 0x77bad0b7 in apr_psprintf (p=, fmt=) at memory/unix/apr_pools.c:2049 #4 0x758aafd1 in representation_string (rep=0x82f390, format=, mutable_rep_truncated=, pool=0x83b588) at subversion/libsvn_fs_fs/fs_fs.c:2449 #5 0x758ae971 in svn_fs_fs__write_noderev (pool=0x83b588, include_mergeinfo=1, format=3, noderev=0x82f2a0, outfile=0x808528) at subversion/libsvn_fs_fs/fs_fs.c:2492 #6 svn_fs_fs__write_noderev (outfile=0x808528, noderev=0x82f2a0, format=3, include_mergeinfo=1, pool=0x83b588) at subversion/libsvn_fs_fs/fs_fs.c:2469 #7 0x758aec33 in svn_fs_fs__put_node_revision (fs=, id=, noderev=0x82f2a0, fresh_txn_root=1, pool=0x83b588) at subversion/libsvn_fs_fs/fs_fs.c:2559 #8 0x758b0e8a in create_new_txn_noderev_from_rev (pool=0x83b588, src=, txn_id=0x82f120 "33-23", fs=0x826500) at subversion/libsvn_fs_fs/fs_fs.c:4717 #9 svn_fs_fs__create_txn (txn_p=0x7fffe0f8, fs=0x826500, rev=33, pool=0x83b588) at subversion/libsvn_fs_fs/fs_fs.c:4892 #10 0x758b3c21 in svn_fs_fs__begin_txn (txn_p=0x7fffe0f8, fs=0x826500, rev=33, flags=2, pool=0x83b588) at subversion/libsvn_fs_fs/fs_fs.c:7585 #11 0x75cdaf66 in svn_repos_fs_begin_txn_for_commit2 (txn_p=0x7fffe0f8, repos=0x802048, rev=33, revprop_table=0x82ed58, pool=0x83b588) at subversion/libsvn_repos/fs-wrap.c:95 #12 0x75f02628 in dav_svn__create_txn (repos=0x82e7e0, ptxn_name=0x7fffe138, pool=0x83b588) at subversion/mod_dav_svn/activity.c:264 #13 0x75f07e55 in dav_svn__post_create_txn (resource=0x82e610, request_skel=, output=) at subversion/mod_dav_svn/posts/create_txn.c:45 #14 0x75f13332 in handle_post_request (output=0x83cab0, resource=0x82e610, r=0x83b600) at subversion/mod_dav_svn/repos.c:4433 #15 dav_svn__method_post (r=0x83b600) at subversion/mod_dav_svn/repos.c:4462 #16 0x004384e8 in ap_run_handler (r=0x83b600) at config.c:158 #17 0x0043894e in ap_invoke_handler (r=0x83b600) at config.c:376 #18 0x00445730 in ap_process_request (r=0x83b600) at http_request.c:282 #19 0x00442780 in ap_process_http_connection (c=0x7f25e0) at http_core.c:190 #20 0x0043eb08 in ap_run_process_connection (c=0x7f25e0) at connection.c:43 #21 0x00449baf in child_main (child_num_arg=) at prefork.c:667 #22 0x0044a290 in make_child (s=0x67c838, slot=0) at prefork.c:712 #23 0x0044a9ee in ap_mpm_run (_pconf=, plog=, s=0x67c838) at prefork.c:988 #24
Re: Segfault in SVN 1.7.4
: dup two strings, then compare PASS: lt-string-test 7: chopping a string PASS: lt-string-test 8: emptying a string PASS: lt-string-test 9: fill string with hashmarks PASS: lt-string-test 10: block initialization and growth PASS: lt-string-test 11: formatting strings from varargs PASS: lt-string-test 12: create string from file PASS: lt-string-test 13: find_char_backward; middle case PASS: lt-string-test 14: find_char_backward; 0 case PASS: lt-string-test 15: find_char_backward; strlen - 1 case PASS: lt-string-test 16: find_char_backward; len = 0 case PASS: lt-string-test 17: find_char_backward; no occurence case PASS: lt-string-test 18: check whitespace removal; common case PASS: lt-string-test 19: check whitespace removal; no whitespace case PASS: lt-string-test 20: check whitespace removal; all whitespace case PASS: lt-string-test 21: check that whitespace will be stripped correctly PASS: lt-string-test 22: compare stringbufs; different lengths PASS: lt-string-test 23: compare stringbufs; same length, different content END: string-test ELAPSED: string-test 0:00:00.070956 START: subst_translate-test PASS: lt-subst_translate-test 1: test svn_subst_translate_string2() PASS: lt-subst_translate-test 2: test svn_subst_translate_string2(encoding = NULL) PASS: lt-subst_translate-test 3: test repairing svn_subst_translate_string2() PASS: lt-subst_translate-test 4: test svn_subst_translate_cstring2() END: subst_translate-test ELAPSED: subst_translate-test 0:00:00.095711 START: target-test PASS: lt-target-test 1: test svn_path_condense_targets END: target-test ELAPSED: target-test 0:00:00.064927 START: time-test PASS: lt-time-test 1: test svn_time_to_cstring PASS: lt-time-test 2: test svn_time_from_cstring PASS: lt-time-test 3: test svn_time_from_cstring (old format) PASS: lt-time-test 4: test svn_time_[to/from]_cstring() invariant PASS: lt-time-test 5: test svn_parse_date END: time-test ELAPSED: time-test 0:00:00.068246 START: translate-test PASS: lt-translate-test 1: no conversions PASS: lt-translate-test 2: convert CRLF to CRLF PASS: lt-translate-test 3: convert LF to CRLF PASS: lt-translate-test 4: convert CR to CRLF PASS: lt-translate-test 5: convert mixed line endings to CRLF PASS: lt-translate-test 6: convert LF to LF PASS: lt-translate-test 7: convert CRLF to LF PASS: lt-translate-test 8: convert CR to LF PASS: lt-translate-test 9: convert mixed line endings to LF PASS: lt-translate-test 10: convert CRLF to CR PASS: lt-translate-test 11: convert LF to CR PASS: lt-translate-test 12: convert CR to CR PASS: lt-translate-test 13: convert mixed line endings to CR PASS: lt-translate-test 14: keep mixed line endings without repair flag PASS: lt-translate-test 15: expand author PASS: lt-translate-test 16: expand date PASS: lt-translate-test 17: expand author and date PASS: lt-translate-test 18: expand author and rev PASS: lt-translate-test 19: expand rev PASS: lt-translate-test 20: expand rev and url PASS: lt-translate-test 21: expand author, date, rev, and url PASS: lt-translate-test 22: lf_to_crlf; expand author PASS: lt-translate-test 23: mixed_to_lf; expand author and date PASS: lt-translate-test 24: crlf_to_cr; expand author and rev PASS: lt-translate-test 25: cr_to_crlf; expand rev PASS: lt-translate-test 26: cr_to_crlf; expand rev and url PASS: lt-translate-test 27: mixed_to_crlf; expand author, date, rev, and url PASS: lt-translate-test 28: unexpand author PASS: lt-translate-test 29: unexpand date PASS: lt-translate-test 30: unexpand author and date PASS: lt-translate-test 31: unexpand author and rev PASS: lt-translate-test 32: unexpand rev PASS: lt-translate-test 33: unexpand rev and url PASS: lt-translate-test 34: unexpand author, date, rev, and url PASS: lt-translate-test 35: lf_to_crlf; unexpand author PASS: lt-translate-test 36: mixed_to_lf; unexpand author and date PASS: lt-translate-test 37: crlf_to_cr; unexpand author and rev PASS: lt-translate-test 38: cr_to_crlf; unexpand rev PASS: lt-translate-test 39: cr_to_crlf; unexpand rev and url PASS: lt-translate-test 40: mixed_to_crlf; unexpand author, date, rev, url END: translate-test ELAPSED: translate-test 0:00:00.103340 START: tree-conflict-data-test PASS: lt-tree-conflict-data-test 1: deserialize tree conflict PASS: lt-tree-conflict-data-test 2: serialize tree conflict PASS: lt-tree-conflict-data-test 3: read and write tree conflicts END: tree-conflict-data-test ELAPSED: tree-conflict-data-test 0:00:00.208752 START: utf-test PASS: lt-utf-test 1: test is_valid/last_valid PASS: lt-utf-test 2: test last_valid/last_valid2 PASS: lt-utf-test 3: test svn_utf_cstring_to_utf8_ex2 PASS: lt-utf-test 4: test svn_utf_cstring_from_utf8_ex2 END: utf-test ELAPSED: utf-test 0:00:00.113076 START: window-test expected: f6fd44565e14c6e44b35292719deb77e actual: f6fd44565e14c6e44b35292719deb77e PASS: lt-window-test 1: txdelta stream and windows test END: window-test ELAPSED: window-test 0:00:00.066222 START: authz_tests.py CMD: svnadmin create svn-test-work/local_tmp/repos --bdb-txn-nosync CMD: svn import -m 'Log message for revision 1.' svn-test-work/local_tmp/greekfiles file:///tools/subversion-1.7.4-src/subversion/tests/cmdline/svn-test-work/local_tmp/repos --config-dir /tools/subversion-1.7.4-src/subversion/tests/cmdline/svn-test-work/local_tmp/config --password rayjandom --no-auth-cache --username jrandom CMD: /tools/subversion-1.7.4-src/subversion/svn/svn import -m 'Log message for revision 1.' svn-test-work/local_tmp/greekfiles file:///tools/subversion-1.7.4-src/subversion/tests/cmdline/svn-test-work/local_tmp/repos --config-dir /tools/subversion-1.7.4-src/subversion/tests/cmdline/svn-test-work/local_tmp/config --password rayjandom --no-auth-cache --username jrandom exited with 1 svn: E24: While reading representation offsets for node-revision '0.0.t0-0': svn: E24: Could not convert '%ld' into a number Traceback (most recent call last): File "./build/run_tests.py", line 626, in main() File "./build/run_tests.py", line 619, in main failed = th.run(args[2:]) File "./build/run_tests.py", line 142, in run failed = self._run_test(prog, cnt, len(list)) or failed File "./build/run_tests.py", line 508, in _run_test (LINE_LENGTH - len(test_info))) File "./build/run_tests.py", line 454, in _run_py_test test_selection=test_selection) File "/tools/subversion-1.7.4-src/subversion/tests/cmdline/svntest/main.py", line 1776, in execute_tests svntest.actions.setup_pristine_greek_repository() File "/tools/subversion-1.7.4-src/subversion/tests/cmdline/svntest/actions.py", line 75, in setup_pristine_greek_repository main.pristine_greek_repos_url) File "/tools/subversion-1.7.4-src/subversion/tests/cmdline/svntest/main.py", line 601, in run_svn *(_with_auth(_with_config_dir(varargs File "/tools/subversion-1.7.4-src/subversion/tests/cmdline/svntest/main.py", line 350, in run_command None, *varargs) File "/tools/subversion-1.7.4-src/subversion/tests/cmdline/svntest/main.py", line 526, in run_command_stdin raise Failure svntest.Failure
Re: Segfault in SVN 1.7.4
On Mon, Mar 12, 2012 at 08:30:42PM -0700, s...@feb17.org wrote: > > s...@feb17.org writes: > > > > > to realize it was segfaulting on the linux side. I've upgraded to > > > 1.7.4 and the problem remains. I finally ran the operation with > > > apache runnning in GDB and it's a strlen operation that fails. A lot > > > of vars are optimized out so I didn't get much more information except > > > that it appears to be trying to report a problem but then dying while > > > reporting. > > > A little more information on this. I have probably rebuilt svn about 20 times tonight from scratch, with latest source from repository, and after upgrading libtools, autoconf, apr etc. It failed the make check tests every time. I finally tried a minimal configure with just the packages needed to get it to build, e.g. ./configure --with-apr=/tools/apr --with-apr-util=/tools/httpd-2.2.19-src/srclib/apr-util/ --with-sqlite=/tools/sqlite-3.7.10 versus: ./configure --prefix=/tools/subersion-1.7.4 --with-apr=/tools/apr --with-apr-util=/tools/httpd-2.2.19-src/srclib/apr-util/ --with-apxs=/tools/httpd-2.2.19/bin/apxs --with-neon=/tools/neon-0.29.0 --with-sqlite=/tools/sqlite-3.7.10 --with-sasl=/tools/cyrus-sasl-2.1.25 and it seems to be passing its tests fine now (it's not very useful built this way, but that narrows down the problem). I'll add back in the extra packages tomorrow till I find which one is breaking things. Thanks for your patience and again if you have any ideas what is causing the problem, I'd be very happy to know. What started as a simple attempt to check in some code has cost a lot of time http://xkcd.com/349/ Darren
[l10n] Translation status report for trunk r1053795
Translation status report for tr...@r1053795 lang trans untrans fuzzy obs -- de2041 122 227 199 es1978 185 261 338 fr2128 35 60 41 it1827 336 460 162 ja1970 193 332 584 ko2016 147 176 179 nb2031 132 185 307 pl2063 100 134 82 pt_BR1792 371 478 157 sv1748 415 502 163 zh_CN2159 4 36 88 zh_TW1728 435 540 225
[l10n] Translation status report for trunk r1055292
Translation status report for tr...@r1055292 lang trans untrans fuzzy obs -- de2053 126 239 199 es1990 189 273 338 fr2141 38 75 41 it1839 340 472 162 ja1982 197 344 584 ko2027 152 187 179 nb2043 136 197 307 pl2075 104 146 82 pt_BR1803 376 489 157 sv1759 420 513 163 zh_CN2175 4 11 88 zh_TW1739 440 551 225
[l10n] Translation status report for trunk r1057984
X-Mailer: l10n-report.py r1055713 Reply-To: dev@subversion.apache.org Mail-Followup-To: dev@subversion.apache.org Auto-Submitted: auto-generated Translation status report for tr...@r1057984 lang trans untrans fuzzy obs -- de2051 126 239 201 es1988 189 273 340 fr2139 38 75 43 it1837 340 472 164 ja1980 197 344 586 ko2025 152 187 181 nb2041 136 197 309 pl2073 104 146 84 pt_BR1801 376 489 159 sv1757 420 513 165 zh_CN2173 4 11 90 zh_TW1737 440 551 227
Re: [l10n] Translation status report for trunk r1063133
Hello, ISTM that there is an issue since octobre because of the introduction of a macro SVN_CL__OPTION_CONTINUATION_INDENT in "svn/main.c". Now gettext extracts lines instead of paragraphs, #: ../svn/main.c:226 msgid "accept unknown SSL server certificates without\n" msgstr "" How am I expected to translate that? I'm not motivated to patch scatterred lines in order to reconstruct sentences and paragraph and then do a translation, so the French translation will stay as it is for now, till this issue is solved. Anythough on this, anyone? -- Fabien.
Re: [l10n] Translation status report for trunk r1063133
That's my fault. I didn't realize the effect of the #define on gettext's behavior. I'm more than happy to revert the change, which was made solely because it is apparently too difficult for us developers to keep indentation consistent (and I'm a stickler for that kind of thing). Reverted: Sending trunk/subversion/svn/main.c Transmitting file data . Committed revision 1063878. Thanks. It helped, I could translate something! -- Fabien.
