Re: 1.7.20 release candidates up for testing/signing
On 18.03.2015 15:09, Stefan Sperling wrote: The 1.7.20 release is now up for testing/signing at https://dist.apache.org/repos/dist/dev/subversion Please add your signatures there. The anticipated release day is March 31. Note that libsvn_subr/mergeinfo-test 6 and 10 may have occasional failures (segfaults) due to a one-byte read past a string buffer (which cause a crash on OpenBSD and maybe on other platforms as well). This is not a regression from 1.7.19 where the problem already existed. I'm changing my vote to -1 because the copyright year is wrong. Fix (r1667941) nominated for backport. -- Brane
Re: Copyright year displayed by command-line tools
On Fri, Mar 20, 2015 at 08:34:00AM +0100, Branko Čibej wrote: I just noticed that we forgot to bump the displayed copyright year. Fixed in r1667941 and nominated for backport to 1.9.x, 1.8.x and 1.7.x. I also vetoed the 1.7.20 and 1.8.13 releases because of the wrong year ... we really shouldn't release with wrong legalese, and we already allowed 1.9.0-beta1 to slip through with that buglet. Sorry about not noticing this earlier, I realize we already have enough votes tor 1.7.20 and 1.8.13; but I really think we should pull these tarballs. -- Brane If we decide to pull these releases based on this problem, then I'm against making everyone re-run tests for this. Just allow people to diff the tarballs and submit a new signature based on that. Could we have a buildbot test for this kind of problem? Should our rat-report bot (which I can't seem to locate in the maze of buildbot right now) perhaps check for this?
Re: 1.8.13 release up for testing/signing
On 18.03.2015 15:04, Stefan Sperling wrote: The 1.8.13 release is now up for testing/signing at https://dist.apache.org/repos/dist/dev/subversion Please add your signatures there. The anticipated release day is March 31. Note that the 1.8.12 release was tagged and then skipped because of failures in diff_tests.py. These are resolved in 1.8.13. I'm changing my vote to -1 because the copyright year is wrong. Fix (r1667941) nominated for backport. -- Brane
Re: Copyright year displayed by command-line tools
On 20.03.2015 08:47, Stefan Sperling wrote: On Fri, Mar 20, 2015 at 08:34:00AM +0100, Branko Čibej wrote: I just noticed that we forgot to bump the displayed copyright year. Fixed in r1667941 and nominated for backport to 1.9.x, 1.8.x and 1.7.x. I also vetoed the 1.7.20 and 1.8.13 releases because of the wrong year ... we really shouldn't release with wrong legalese, and we already allowed 1.9.0-beta1 to slip through with that buglet. Sorry about not noticing this earlier, I realize we already have enough votes tor 1.7.20 and 1.8.13; but I really think we should pull these tarballs. -- Brane If we decide to pull these releases based on this problem, then I'm against making everyone re-run tests for this. Just allow people to diff the tarballs and submit a new signature based on that. Note that we do not make anyone tun tests in order to vote for a release; it's up to you to decide how thorough you want to be when validating a release. And yes, just diffing the tarballs against the previous version and confirming a one-character change is surely enough in this case. Could we have a buildbot test for this kind of problem? We can add tests to our test suite, that would be easiest, IMO. I'll have a go at that. Should our rat-report bot (which I can't seem to locate in the maze of buildbot right now) perhaps check for this? The RAT report builder is currently turned off because it was reporting spurious failures; either because of a bug in buildbot itself, or a problem with the slave VM. And the RAT slave didn't even build the sources. -- Brane
Re: 1.7.20 release candidates up for testing/signing
On Thu, Mar 19, 2015 at 07:40:41PM +0100, Johan Corveleyn wrote: Wait, did I say reproducible? Gah, I had it once, then reproduced it shortly after (it's still in my scrollback history), then sent this mail, and now I can't reproduce it anymore :-(. I've tried at least 20 more times ... This it not fun. What has changed between the fails and now? - Stopped Apache 2.4.12 which was still running (standalone, separate console window). Hmm... Perhaps there was a corrupt revision contents cache that got flushed by restarting Apache? Otherwise, no idea.
Copyright year displayed by command-line tools
I just noticed that we forgot to bump the displayed copyright year. Fixed in r1667941 and nominated for backport to 1.9.x, 1.8.x and 1.7.x. I also vetoed the 1.7.20 and 1.8.13 releases because of the wrong year ... we really shouldn't release with wrong legalese, and we already allowed 1.9.0-beta1 to slip through with that buglet. Sorry about not noticing this earlier, I realize we already have enough votes tor 1.7.20 and 1.8.13; but I really think we should pull these tarballs. -- Brane
Re: Copyright year displayed by command-line tools
On 20.03.2015 11:07, Greg Stein wrote: On Fri, Mar 20, 2015 at 4:28 AM, Branko Čibej br...@wandisco.com mailto:br...@wandisco.com wrote: ... IMO, we should either not display the year (which IIUC would violate ASF policy), or we should display the correct year. Anything else makes us look silly. Hmm? Policy is at: http://www.apache.org/legal/src-headers.html And that is what I see in a random sampling of our source. If I'm wrong about policy, then I propose we just change those lines from: Copyright (C) 2014 The Apache Software Foundation. Where are you seeing this? Output of 'svn --version', it's in subversion/libsvn_subr/version.c (and was in .../opt.c in 1.7). Been that way for decades. -- Brane
Re: 1.7.20 release candidates up for testing/signing
On Thu, Mar 19, 2015 at 7:42 PM, Philip Martin philip.mar...@wandisco.com wrote: Johan Corveleyn jcor...@gmail.com writes: TIME = 0.047000 svn: E160004: Corrupt node-revision '0.0.r9/882' svn: E160004: Missing id field in node-rev I don't see that on my Linux box. That's a complaint about the root node of r9, near the end of the file db/revs/0/0. On my Linux box the offset is 881 not 882, and the file ends: id: 0.0.r9/881 type: dir pred: 0.0.r8/0 count: 9 text: 9 796 72 72 0bbc6c909be39d253813928a4611c161 cpath: / copyroot: 0 / minfo-cnt: 1 0-1.0.t8-8 modify-dir false true /trunk 1-2.0.t8-8 modify-file true false /trunk/1 4-2.0.t8-8 modify-file true false /trunk/2 881 1018 Thanks for looking this up. Unfortunately, I can't verify the rev file, since I don't have it anymore, it has been overwritten by trying to reproduce it (g, should remember to backup leftover repositories and working copies after a failed test run, before trying to reproduce it). Whatever I try now, I can't reproduce it anymore :-(. On Fri, Mar 20, 2015 at 8:03 AM, Stefan Sperling s...@elego.de wrote: On Thu, Mar 19, 2015 at 07:40:41PM +0100, Johan Corveleyn wrote: Wait, did I say reproducible? Gah, I had it once, then reproduced it shortly after (it's still in my scrollback history), then sent this mail, and now I can't reproduce it anymore :-(. I've tried at least 20 more times ... This it not fun. What has changed between the fails and now? - Stopped Apache 2.4.12 which was still running (standalone, separate console window). Hmm... Perhaps there was a corrupt revision contents cache that got flushed by restarting Apache? Otherwise, no idea. Thanks for the suggestion, maybe something like that could be the cause. Not exactly a corrupt cache in Apache (because the test failure I had was with ra_svn), but perhaps a leftover corrupt repository on disk, still being locked by apache or ... something like that. Otherwise I don't see how an Apache process could interfere with an svnserve process. I do remember that, before I started the ra_svn tests, I did a short attempt with ra_serf against that particular Apache process (which I had just started then). That test run failed somewhere (because of a known issue of AVG Surf Shield interfering with serf (issue #4175 -- fixed in 1.8 but never backported to 1.7)), and I aborted it (Ctrl-C). After that I left Apache running, disabled AVG Surf Shield, and started a batch script that ran ra_local, ra_svn, ra_neon and ra_serf in sequence. So maybe, just maybe, that first aborted ra_serf run left something broken on disk that was later hit by the ra_svn test run (but not by the ra_local test run that ran first, and not by the ra_neon and ra_serf test runs that came later ???). Anyway, I'm going to leave it at that, and conclude this is some weird one-time local issue. I'll retest ra_svn once more tonight, and if successful I'll commit my signature tonight or tomorrow. -- Johan
Re: Copyright year displayed by command-line tools
hehe... I think it is time to kill that off, with extreme prejudice :-D On Fri, Mar 20, 2015 at 5:35 AM, Branko Čibej br...@wandisco.com wrote: On 20.03.2015 11:07, Greg Stein wrote: On Fri, Mar 20, 2015 at 4:28 AM, Branko Čibej br...@wandisco.com mailto:br...@wandisco.com wrote: ... IMO, we should either not display the year (which IIUC would violate ASF policy), or we should display the correct year. Anything else makes us look silly. Hmm? Policy is at: http://www.apache.org/legal/src-headers.html And that is what I see in a random sampling of our source. If I'm wrong about policy, then I propose we just change those lines from: Copyright (C) 2014 The Apache Software Foundation. Where are you seeing this? Output of 'svn --version', it's in subversion/libsvn_subr/version.c (and was in .../opt.c in 1.7). Been that way for decades. -- Brane
Re: Copyright year displayed by command-line tools
On 20.03.2015 11:07, Greg Stein wrote: On Fri, Mar 20, 2015 at 4:28 AM, Branko Čibej br...@wandisco.com mailto:br...@wandisco.com wrote: ... IMO, we should either not display the year (which IIUC would violate ASF policy), or we should display the correct year. Anything else makes us look silly. Hmm? Policy is at: http://www.apache.org/legal/src-headers.html Yes; we didn't bump the version numbers in NOTICE, either; and that's mentioned explicitly in that page. I just fixed that and proposed the backports ... and IMO NOTICE is an even stronger reason not to release as-is. Surely we should apply the same standards to our releases as that we regularly brainwash podlings about. -- Brane
Re: Copyright year displayed by command-line tools
Let me expand on that a bit ... let's not hold any releases for this, but let's talk to Danny and other peeps at the ASF. I believe we can clear out a few lines. Pointing to subversion.a.o is nice. We should be able to scorch the other 3 lines. On Fri, Mar 20, 2015 at 5:43 AM, Greg Stein gst...@gmail.com wrote: hehe... I think it is time to kill that off, with extreme prejudice :-D On Fri, Mar 20, 2015 at 5:35 AM, Branko Čibej br...@wandisco.com wrote: On 20.03.2015 11:07, Greg Stein wrote: On Fri, Mar 20, 2015 at 4:28 AM, Branko Čibej br...@wandisco.com mailto:br...@wandisco.com wrote: ... IMO, we should either not display the year (which IIUC would violate ASF policy), or we should display the correct year. Anything else makes us look silly. Hmm? Policy is at: http://www.apache.org/legal/src-headers.html And that is what I see in a random sampling of our source. If I'm wrong about policy, then I propose we just change those lines from: Copyright (C) 2014 The Apache Software Foundation. Where are you seeing this? Output of 'svn --version', it's in subversion/libsvn_subr/version.c (and was in .../opt.c in 1.7). Been that way for decades. -- Brane
Re: Copyright year displayed by command-line tools
On Fri, Mar 20, 2015 at 4:28 AM, Branko Čibej br...@wandisco.com wrote: ... IMO, we should either not display the year (which IIUC would violate ASF policy), or we should display the correct year. Anything else makes us look silly. Hmm? Policy is at: http://www.apache.org/legal/src-headers.html And that is what I see in a random sampling of our source. If I'm wrong about policy, then I propose we just change those lines from: Copyright (C) 2014 The Apache Software Foundation. Where are you seeing this? ... Cheers, -g
Re: Segfault in Perl bindings when commit touches a large number of files
On Wed, Mar 18, 2015 at 02:49:08PM +, Philip Martin wrote:
I also see that. Given that Perl has realloc'd some memory I suppose
it might be a reference counting bug in Subversion's XS code.
Or perhaps the bug might be this code in svn_types.swg:
%typemap(argout) unsigned char *result_digest {
/* FIXME: This code is clearly buggy. The return value of sv_newmortal()
is immediately overwritten by the return value
of svn_swig_pl_from_md5(). */
ST(argvi) = sv_newmortal();
ST(argvi++) = svn_swig_pl_from_md5($1);
}
#endif
Indeed. Reading through some Perl documentation, the original commit,
and svn_swig_pl_from_md5, I don't see why the svn_newmortal() call is
there. svn_swig_pl_from_md5 already makes its return value mortal, so
this is just allocating and overwriting a new SV*.
Removing this resolves the crash and reduces the amount of
(de)allocations.
Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy james...@debian.org
signature.asc
Description: Digital signature
Re: Copyright year displayed by command-line tools
Stefan Sperling s...@elego.de writes: Could we have a buildbot test for this kind of problem? Should our rat-report bot (which I can't seem to locate in the maze of buildbot right now) perhaps check for this? I have modified release.py to warn when NOTICE contains a date that is not current http://svn.apache.org/r1667990 -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: 1.8.13 release up for testing/signing
On Wed, Mar 18, 2015 at 3:04 PM, Stefan Sperling s...@elego.de wrote: The 1.8.13 release is now up for testing/signing at https://dist.apache.org/repos/dist/dev/subversion Please add your signatures there. The anticipated release day is March 31. Note that the 1.8.12 release was tagged and then skipped because of failures in diff_tests.py. These are resolved in 1.8.13. Summary: +1 to release Platform Ubuntu 14.04.1 x64, Linux 3.16.0-31-generic SMP Standard dependencies: APR 1.5.0 APR-Util 1.5.3 BDB 5.3.28 GCC 4.8.2 httpd 2.4.7, worker MPM JUnit 4.11 libmagic 5.14 libtool 2.4.2 neon 0.30.0 OpenJDK-7 7u51 OpenSSL 1.0.1f Perl 5.18.2 Python 2.7.5 Ruby 1.9.3 SQLite 3.8.2 Swig 2.0.11 zlib 1.2.8 Manually installed and in-tree dependencies: Serf 1.3.8 ctypesgen svn-r151 Verified: Tarball contents and signatures (fsfs, bdb) x (local, svnserve, serf) check-swig-py check-swig-pl check-swig-rb check-javahl check-ctypes-python ./get-deps.sh Results: All tests passed. GPG Signatures committed to the dist/dev/subversion repository.
Re: 1.8.13 release up for testing/signing
On 20.03.2015 08:25, Branko Čibej wrote: On 18.03.2015 15:04, Stefan Sperling wrote: The 1.8.13 release is now up for testing/signing at https://dist.apache.org/repos/dist/dev/subversion Please add your signatures there. The anticipated release day is March 31. Note that the 1.8.12 release was tagged and then skipped because of failures in diff_tests.py. These are resolved in 1.8.13. I'm changing my vote to -1 because the copyright year is wrong. Fix (r1667941) nominated for backport. I'm now convinced that we historically. don't care enough about the year in NOTICE and 'svn --version' to stop a release. Back to +1. -- Brane, soon to be in a superposition of -1 and +1 states
Re: Copyright year displayed by command-line tools
Branko Čibej wrote: I just fixed that and proposed the backports ... and IMO NOTICE is an even stronger reason not to release as-is. Surely we should apply the same standards to our releases as that we regularly brainwash podlings about. We should apply the same standards, yes. Is this issue a release-blocking violation of those standards? No, I don't think it is. I have voted +1 to backport the updates, but I stand by my +1 votes to release as is. The copyright year statement is a whole number approximation to a fuzzy quantity; as such it is inevitably subject to being inaccurate whenever any work is prepared for release near the beginning of a year. It would be better to say 2015 in this case, but not unconditionally wrong to say 2014. - Julian
Re: 1.7.20 release candidates up for testing/signing
On Wed, Mar 18, 2015 at 3:09 PM, Stefan Sperling s...@elego.de wrote: The 1.7.20 release is now up for testing/signing at https://dist.apache.org/repos/dist/dev/subversion Please add your signatures there. The anticipated release day is March 31. Note that libsvn_subr/mergeinfo-test 6 and 10 may have occasional failures (segfaults) due to a one-byte read past a string buffer (which cause a crash on OpenBSD and maybe on other platforms as well). This is not a regression from 1.7.19 where the problem already existed. Summary: +1 to release Platform Ubuntu 14.04.1 x64, Linux 3.16.0-31-generic SMP Standard dependencies: APR 1.5.0 APR-Util 1.5.3 BDB 5.3.28 GCC 4.8.2 httpd 2.4.7, worker MPM JUnit 4.11 libmagic 5.14 libtool 2.4.2 neon 0.30.0 OpenJDK-7 7u51 OpenSSL 1.0.1f Perl 5.18.2 Python 2.7.5 Ruby 1.9.3 SQLite 3.8.2 Swig 2.0.11 zlib 1.2.8 Manually installed and in-tree dependencies: Serf 0.7.2 ctypesgen svn-r151 Verified: Tarball contents and signatures (fsfs, bdb) x (local, svnserve, neon, serf) check-swig-py check-swig-pl check-javahl check-ctypes-python ./get-deps.sh Results: (known issue) Ruby tests failed to build due to unsupported Ruby version. All tests passed. GPG Signatures committed to the dist/dev/subversion repository. -- Stefan^2.
Re: JavaHL: Exceptions in LogMessageCallback.singleMessage should abort the log immediately
On 20.03.2015 13:34, Marc Strapetz wrote: On 16.03.2015 17:54, Bert Huijben wrote: -Original Message- From: Marc Strapetz [mailto:marc.strap...@syntevo.com] Sent: maandag 16 maart 2015 17:30 To: dev@subversion.apache.org Subject: JavaHL: Exceptions in LogMessageCallback.singleMessage should abort the log immediately If e.g. a RuntimeException is thrown in LogMessageCallback#singleMessage, it's not processed in LogMessageCallback::singleMessage and the log is continued nevertheless: (1) At line 77 in LogMessageCallback.cpp, there should be returned an appropriate error code. (2) After line 122, JNIUtil::isJavaExceptionThrown() should be called and there should be returned an appropriate error code. In both cases, the returned error code should result in stopping the low-level log; rethrowing the Exception in RemoteSession::getLog won't be necessary, as this can be established easily from within client code itself. This is a common problem that applies to almost all callbacks in JavaHL in = 1.9. A fix for this generic problem has been applied to trunk in r1664938 (further tweaks/extensions in 1664939,1664940,1664978,1664984). This introduces some behavior changes (such as the one you noted), so backporting needs discussion here. Thanks for starting the discussion ;-) As JavaHL was reworked significantly for Subversion 1.9, is there a possibility to get this change backported? Not to 1.8, I'm afraid; the differences are far too huge. Fixing this for 1.9.0 is possible, and I agree we should do it. -- Brane
RE: Copyright year displayed by command-line tools
Just a quick check, using the tag creation dates and what is in the file: 1.1.3 1.1.4 1.4.3 1.4.4 1.4.5 1.6.8 1.6.9 1.6.10 1.6.11 1.6.12 1.6.13 1.6.14 1.6.15 1.6.16 1.6.17 1.6.18 1.6.19 1.6.20 1.6.21 1.6.22 1.6.23 1.8.6 1.8.7 1.8.8 (I probably missed a few, as I didn't automate the matching... just the fetching) Were all released with a nonmatching date. I think 1.7 is the only release line where we actually directly updated the year on the branch, the year after release. (For 1.6.x we never updated anything) +1 on just releasing the releases as-is. Bert From: Greg Stein [mailto:gst...@gmail.com] Sent: vrijdag 20 maart 2015 09:58 To: Branko Čibej Cc: Subversion Development Subject: Re: Copyright year displayed by command-line tools Daniel Berlin stated many years ago that the years associated with copyright lines are meaningless. There is no reason to burn/re-roll just for that. The simple fact is that if you end up in court, then what is printed to the console has ZERO bearing (or what year is listed in a source file). The court will look at what/when changes *actually* happened. What we state is irrelevant. The commit logs are the important point. So given that, what is the purpose of displaying those years? *shrug* (which was basically his point) -0.9 to even thinking about burning tarballs for this reason. -g On Fri, Mar 20, 2015 at 2:34 AM, Branko Čibej br...@wandisco.com mailto:br...@wandisco.com wrote: I just noticed that we forgot to bump the displayed copyright year. Fixed in r1667941 and nominated for backport to 1.9.x, 1.8.x and 1.7.x. I also vetoed the 1.7.20 and 1.8.13 releases because of the wrong year ... we really shouldn't release with wrong legalese, and we already allowed 1.9.0-beta1 to slip through with that buglet. Sorry about not noticing this earlier, I realize we already have enough votes tor 1.7.20 and 1.8.13; but I really think we should pull these tarballs. -- Brane
Re: Copyright year displayed by command-line tools
On 2015-03-20 03:58:24 -0500, Greg Stein wrote: Daniel Berlin stated many years ago that the years associated with copyright lines are meaningless. There are lots of particular cases, depending on the country of publication, the year of publication, and so on. According to https://copyright.cornell.edu/resources/publicdomain.cfm (which lists all the rules for the U.S.), it appears that this was needed in the past, but this is no longer the case for the U.S. Other countries may have different rules. So, I think that it is still better to make the copyright notice correct. It may also be useful for the end user. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: Copyright year displayed by command-line tools
On 20.03.2015 14:31, Stefan Fuhrmann wrote:
On Fri, Mar 20, 2015 at 8:47 AM, Stefan Sperling s...@elego.de
mailto:s...@elego.de wrote:
On Fri, Mar 20, 2015 at 08:34:00AM +0100, Branko Čibej wrote:
I just noticed that we forgot to bump the displayed copyright year.
Fixed in r1667941 and nominated for backport to 1.9.x, 1.8.x and
1.7.x.
I also vetoed the 1.7.20 and 1.8.13 releases because of the
wrong year
... we really shouldn't release with wrong legalese, and we already
allowed 1.9.0-beta1 to slip through with that buglet.
Sorry about not noticing this earlier, I realize we already have
enough
votes tor 1.7.20 and 1.8.13; but I really think we should pull these
tarballs.
-- Brane
If we decide to pull these releases based on this problem, then I'm
against making everyone re-run tests for this. Just allow people to
diff the tarballs and submit a new signature based on that.
Could we have a buildbot test for this kind of problem?
Should our rat-report bot (which I can't seem to locate in the maze
of buildbot right now) perhaps check for this?
Yes, I think we should add a simple C test calling svn_version_extended.
If the year differs from the actual, FAIL. Have a grace period from Dec 15
to Jan 15. That test would act as a simple reminder.
I'd be happy to implement it.
Don't need a C test for that, just tweak the getopt tests. Haven't
committed this yet because we might end up removing the copyright blurb
altogether.
$ svn diff
Index: Makefile.in
===
--- Makefile.in (revision 1667950)
+++ Makefile.in (working copy)
@@ -556,6 +556,9 @@
if test $(PARALLEL) != ; then \
flags=--parallel $(PARALLEL) $$flags; \
fi;\
+ if test $(COPYRIGHT) != ; then \
+ flags=--copyright $(COPYRIGHT) $$flags;\
+ fi;\
if test $(LOG_TO_STDOUT) != ; then \
flags=--log-to-stdout $$flags; \
fi;\
Index: build/run_tests.py
===
--- build/run_tests.py (revision 1667950)
+++ build/run_tests.py (working copy)
@@ -30,7 +30,7 @@
[--list] [--milestone-filter=regex] [--mode-filter=type]
[--server-minor-version=version] [--http-proxy=host:port]
[--httpd-version=version]
-[--config-file=file] [--ssl-cert=file]
+[--copyright=year] [--config-file=file] [--ssl-cert=file]
[--exclusive-wc-locks] [--memcached-server=url:port]
abs_srcdir abs_builddir
prog ...
@@ -123,7 +123,8 @@
def __init__(self, abs_srcdir, abs_builddir, logfile, faillogfile,
base_url=None, fs_type=None, http_library=None,
server_minor_version=None, verbose=None,
- cleanup=None, enable_sasl=None, parallel=None, config_file=None,
+ cleanup=None, enable_sasl=None, parallel=None,
+ copyright_year=None, config_file=None,
fsfs_sharding=None, fsfs_packing=None,
list_tests=None, svn_bin=None, mode_filter=None,
milestone_filter=None, set_log_level=None, ssl_cert=None,
@@ -175,6 +176,7 @@
self.fsfs_packing = fsfs_packing
if fsfs_packing is not None and fsfs_sharding is None:
raise Exception('--fsfs-packing requires --fsfs-sharding')
+self.copyright_year = copyright_year
self.config_file = None
if config_file is not None:
self.config_file = os.path.abspath(config_file)
@@ -506,6 +508,8 @@
svntest.main.options.parallel = num_parallel
else:
svntest.main.options.parallel = svntest.main.default_num_threads
+if self.copyright_year is not None:
+ svntest.main.options.copyright_year = int(self.copyright_year)
if self.config_file is not None:
svntest.main.options.config_file = self.config_file
if self.verbose is not None:
@@ -721,7 +725,8 @@
'dump-load-cross-check',
'http-library=', 'server-minor-version=',
'fsfs-packing', 'fsfs-sharding=',
-'enable-sasl', 'parallel=', 'config-file=',
+'enable-sasl', 'parallel=', 'copyright=',
+'config-file=',
'log-to-stdout', 'list', 'milestone-filter=',
'mode-filter=', 'set-log-level=', 'ssl-cert=',
Re: Copyright year displayed by command-line tools
On 20.03.2015 16:04, Daniel Berlin wrote: The ASF doesn't require copyright lines, AFAIK. To whit: httpd has *none* in the their repository. Here's a random file: http://svn.apache.org/viewvc/httpd/httpd/trunk/server/apreq_module_cgi.c?view=markup Copyright lines are legally meaningless. In fact, you are usually worse often having them, because if you get them wrong, it hurts you legally (if you mislead someone into infringement through a wrong notice, that's a defense for them) , but if you do nothing, it doesn't. We're talking about two separate things here: * The contents of the NOTICE file; the ASF does, per current policy, require a copyright line there which includes the year. * The output of 'svn --version', 'svnadmin --version', etc, which has contained a copyright line for ages. We don't have copyright lines in file headers. I wouldn't mind removing the line from the version output; but as long as we have it, it should IMO be the equivalent to what we (must) have in NOTICE. -- Brane (I'm assuming you aren't distributing copies of subversion from before 1988 here :P ) Thankfully, no. :) -- Brane On Fri, Mar 20, 2015 at 3:47 AM, Greg Stein gst...@gmail.com mailto:gst...@gmail.com wrote: Let me expand on that a bit ... let's not hold any releases for this, but let's talk to Danny and other peeps at the ASF. I believe we can clear out a few lines. Pointing to subversion.a.o is nice. We should be able to scorch the other 3 lines. On Fri, Mar 20, 2015 at 5:43 AM, Greg Stein gst...@gmail.com mailto:gst...@gmail.com wrote: hehe... I think it is time to kill that off, with extreme prejudice :-D On Fri, Mar 20, 2015 at 5:35 AM, Branko Čibej br...@wandisco.com mailto:br...@wandisco.com wrote: On 20.03.2015 11:07, Greg Stein wrote: On Fri, Mar 20, 2015 at 4:28 AM, Branko Čibej br...@wandisco.com mailto:br...@wandisco.com mailto:br...@wandisco.com mailto:br...@wandisco.com wrote: ... IMO, we should either not display the year (which IIUC would violate ASF policy), or we should display the correct year. Anything else makes us look silly. Hmm? Policy is at: http://www.apache.org/legal/src-headers.html And that is what I see in a random sampling of our source. If I'm wrong about policy, then I propose we just change those lines from: Copyright (C) 2014 The Apache Software Foundation. Where are you seeing this? Output of 'svn --version', it's in subversion/libsvn_subr/version.c (and was in .../opt.c in 1.7). Been that way for decades. -- Brane
Re: JavaHL: Exceptions in LogMessageCallback.singleMessage should abort the log immediately
On 16.03.2015 17:54, Bert Huijben wrote: -Original Message- From: Marc Strapetz [mailto:marc.strap...@syntevo.com] Sent: maandag 16 maart 2015 17:30 To: dev@subversion.apache.org Subject: JavaHL: Exceptions in LogMessageCallback.singleMessage should abort the log immediately If e.g. a RuntimeException is thrown in LogMessageCallback#singleMessage, it's not processed in LogMessageCallback::singleMessage and the log is continued nevertheless: (1) At line 77 in LogMessageCallback.cpp, there should be returned an appropriate error code. (2) After line 122, JNIUtil::isJavaExceptionThrown() should be called and there should be returned an appropriate error code. In both cases, the returned error code should result in stopping the low-level log; rethrowing the Exception in RemoteSession::getLog won't be necessary, as this can be established easily from within client code itself. This is a common problem that applies to almost all callbacks in JavaHL in = 1.9. A fix for this generic problem has been applied to trunk in r1664938 (further tweaks/extensions in 1664939,1664940,1664978,1664984). This introduces some behavior changes (such as the one you noted), so backporting needs discussion here. Thanks for starting the discussion ;-) As JavaHL was reworked significantly for Subversion 1.9, is there a possibility to get this change backported? -Marc
Re: Copyright year displayed by command-line tools
On 20.03.2015 14:08, Bert Huijben wrote: Just a quick check, using the tag creation dates and what is in the file: 1.1.3 1.1.4 1.4.3 1.4.4 1.4.5 1.6.8 1.6.9 1.6.10 1.6.11 1.6.12 1.6.13 1.6.14 1.6.15 1.6.16 1.6.17 1.6.18 1.6.19 1.6.20 1.6.21 1.6.22 1.6.23 1.8.6 1.8.7 1.8.8 (I probably missed a few, as I didn't automate the matching... just the fetching) Were all released with a nonmatching date. I think 1.7 is the only release line where we actually directly updated the year on the branch, the year after release. (For 1.6.x we never updated anything) +1 on just releasing the releases as-is. And only 1.7 and 1.8 actually matter as far as the ASF is concerned. :) However, 1.8.[678] are good enough for me to change my mind. Again. -- Brane
Re: Copyright year displayed by command-line tools
On Fri, Mar 20, 2015 at 8:47 AM, Stefan Sperling s...@elego.de wrote: On Fri, Mar 20, 2015 at 08:34:00AM +0100, Branko Čibej wrote: I just noticed that we forgot to bump the displayed copyright year. Fixed in r1667941 and nominated for backport to 1.9.x, 1.8.x and 1.7.x. I also vetoed the 1.7.20 and 1.8.13 releases because of the wrong year ... we really shouldn't release with wrong legalese, and we already allowed 1.9.0-beta1 to slip through with that buglet. Sorry about not noticing this earlier, I realize we already have enough votes tor 1.7.20 and 1.8.13; but I really think we should pull these tarballs. -- Brane If we decide to pull these releases based on this problem, then I'm against making everyone re-run tests for this. Just allow people to diff the tarballs and submit a new signature based on that. Could we have a buildbot test for this kind of problem? Should our rat-report bot (which I can't seem to locate in the maze of buildbot right now) perhaps check for this? Yes, I think we should add a simple C test calling svn_version_extended. If the year differs from the actual, FAIL. Have a grace period from Dec 15 to Jan 15. That test would act as a simple reminder. I'd be happy to implement it. -- Stefan^2.
Re: Copyright year displayed by command-line tools
Branko Čibej wrote: Could we have a buildbot test for this kind of problem? Should our rat-report bot (which I can't seem to locate in the maze of buildbot right now) perhaps check for this? Yes, I think we should add a simple C test calling svn_version_extended. If the year differs from the actual, FAIL. Have a grace period from Dec 15 to Jan 15. That test would act as a simple reminder. Don't need a C test for that, just tweak the getopt tests. Haven't committed this yet because we might end up removing the copyright blurb altogether. I don't want the tests in our released packages to suddenly start failing when the calendar rolls over. Testing for this should be something we do as part of our develop and release process, not as part of the regression tests we ship. Philip has already committed a patch to the release scripts to check the date in the NOTICE file and warn if it's not the current year: http://svn.apache.org/r1667990 - Julian
Re: Handling non-reproducible test failures (was Re: 1.7.20 release candidates up for testing/signing)
On Fri, Mar 20, 2015 at 10:30 AM, Johan Corveleyn jcor...@gmail.com wrote: On Fri, Mar 20, 2015 at 9:42 AM, Johan Corveleyn jcor...@gmail.com wrote: ... Unfortunately, I can't verify the rev file, since I don't have it anymore, it has been overwritten by trying to reproduce it (g, should remember to backup leftover repositories and working copies after a failed test run, before trying to reproduce it). Whatever I try now, I can't reproduce it anymore :-(. I'm wondering if something can be improved in our test suite to help diagnosis of hard-to-reproduce test failures. When this happens, you typically wish you could analyse as much data as possible (i.e. the potentially corrupt repository, working copy, dump file, ... that was used in the test). Currently, I can think of three causes for losing this information: 1) You run a series of test runs in sequence from a script (ra_local, ra_svn, ra_serf), all using the same target directory for running the tests (R:\test in my case, where R: is a ram drive). If something fails in ra_svn, but succeeds in ra_serf, your broken test data is overwritten. 2) You don't know in advance that the failure will turn out to be non-reproducible. You can't believe your eyes, try to run it again to be sure, and lo and behold, the test succeeds (and the broken test data is overwritten), and succeeds ever since. 3) Your test data is on a RAM drive, and you reboot or something. Or you copy the data to a fixed disk afterwards, but lose a bit of information because last-modified timestamps of the copied files are reset by copying them between disks. For 1, maybe the outer script could detect that ra_svn had a failure, and stop there (does win-tests.py emit an exit code != 0 if there is a test failure? That would make it easy. Otherwise the outer script would have to parse the test summary output)? Another option is to let every separate test run (ra_local, ra_svn, ra_serf) use a distinct target test directory. But if you're running them on a RAM disk, theoretically you might need three times the storage (hm, maybe not, because --cleanup ensures that successful test data is cleaned up, so as long as you don't run the three ways in parallel, it should be fine). I guess I will do that already, and adjust my script accordingly. Addressing 2 seems harder. Can the second test execution, on encountering stale test data, put that data aside instead of overwriting it? Or maybe every test execution can use a unique naming pattern (with a timestamp or a pid) so it doesn't overwrite previous data? Both approaches would leak data from failed test runs of course, but that's more or less the point. OTOH, you don't know that stale test data is from a previous failed run, or from a successful run that did not use --cleanup. And 3, well, I already reboot as little as possible, so this is more just a point of attention. Maybe addressing all three at the same time could also be: after a failed test run, automatically zip the test data and copy it to a safe location (e.g. the user's home dir). Thoughts? I haven't thought too deeply about it but I think we should be able to extend the current repo / w/c cleanup infrastructure to copy the data away upon test failure. -- Stefan^2.
Re: Copyright year displayed by command-line tools
On Fri, Mar 20, 2015 at 2:44 PM, Branko Čibej br...@wandisco.com wrote: On 20.03.2015 14:33, Branko Čibej wrote: On 20.03.2015 14:31, Stefan Fuhrmann wrote: On Fri, Mar 20, 2015 at 8:47 AM, Stefan Sperling s...@elego.de mailto:s...@elego.de wrote: On Fri, Mar 20, 2015 at 08:34:00AM +0100, Branko Čibej wrote: I just noticed that we forgot to bump the displayed copyright year. Fixed in r1667941 and nominated for backport to 1.9.x, 1.8.x and 1.7.x. I also vetoed the 1.7.20 and 1.8.13 releases because of the wrong year ... we really shouldn't release with wrong legalese, and we already allowed 1.9.0-beta1 to slip through with that buglet. Sorry about not noticing this earlier, I realize we already have enough votes tor 1.7.20 and 1.8.13; but I really think we should pull these tarballs. -- Brane If we decide to pull these releases based on this problem, then I'm against making everyone re-run tests for this. Just allow people to diff the tarballs and submit a new signature based on that. Could we have a buildbot test for this kind of problem? Should our rat-report bot (which I can't seem to locate in the maze of buildbot right now) perhaps check for this? Yes, I think we should add a simple C test calling svn_version_extended. If the year differs from the actual, FAIL. Have a grace period from Dec 15 to Jan 15. That test would act as a simple reminder. I'd be happy to implement it. Don't need a C test for that, just tweak the getopt tests. Haven't committed this yet because we might end up removing the copyright blurb altogether. And anyway, I think Philip's r1667990 is a better solution. +/e/^/i//π/ for a new test. Yah, it's good. I'm fine with anything that prevents future incidents. -- Stefan^2.
Re: 1.7.20 release candidates up for testing/signing
Summary: +1 to release Platform: Linux (Debian/jessie) 64-bit Linux (Centos 6) 64-bit (swig-pl, swig-rb) Tested: (local, svn, svn/sasl, neon, serf) x (fsfs, fsfs/pack/shard, bdb) swig-pl, swig-py, swig-rb, ctypes-python javahl x (fsfs, bdb) swig-pl and swig-rb on Centos 6 as they do not build on Debian/jessie. Results: All tests passed. Local dependencies: apache2-dev : 2.4.10-9 libapr1-dev : 1.5.1-3 libaprutil1-dev : 1.5.4-1 libdb5.3-dev : 5.3.28-9 libsasl2-dev : 2.1.26.dfsg1-13 libsqlite3-dev : 3.8.7.1-1 python2.7-dev : 2.7.9-2 openjdk-7-jdk : 7u75-2.5.4-2 libneon27-dev : 0.30.1-1 serf : 1.3.x@2474 subversion-1.7.20.tar.bz2 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAABCAAGBQJVDF6LAAoJEHbXiOHtGlmckK0H/1GL928jtLgy3a/Fe224pCdg YJ75Fwqr97Cl0+98R6KbJopRmtdwRyM44e6n8pdjxvt6rQLODMUz9VECToUyqo5E a4LFcDoCfIwzg8ERB+lVjrIFZS7CCtGug+6GyHXVGGZ4wsoCjvqZDNUm+gK5grnK JQXn54BQOFWrLlqVnGZQFyzAVqTJRXbL0HOc+0BimvA2RXQoCnqki0+DIqLwxpAi qf5JWq8wG/8bFMBXU/0U8ziHMQJEBXctuU90ZMk5PJnrl/KUliWNAJx9SHS2FriJ b4jpxOl691tYThDUtzPIROrERteP3MJR66T8djJnCRDIogbKTYH41JKaq6vpWnQ= =x8KV -END PGP SIGNATURE- subversion-1.7.20.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAABCAAGBQJVDF6LAAoJEHbXiOHtGlmcBA8H/0YKWvKlXoejiNxUArakSlp1 NRmpcJMmOAFulJTHLRR4Fu/DBj+mH3+pBpJCPvqWETyflP0gXHIxIWiGe42r+BIR ces7Z5vZp1YayRgwpmiMwg770z03wsj8Rp1YH+g8ZouNWus3mO7+fq187li1ntuf gfPWlpSNzpociUeNK+68IHmUmTtPNsxO/R4KK3lllg5xlYYYMaFKFZU7WMUgD+LL G78/mE1Vj5NM3YPKCUYajK8wuSTm7hjYIYFA7WKYpX4tVbWNChNUVhBIIR7AvZkY EmnlCrMJwP5mlYq3lsGVdr199o6/MdWUv694n4WdPQX9lSXxdh0vZhmlfNn7p+s= =dVEY -END PGP SIGNATURE- -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: Copyright year displayed by command-line tools
On 20.03.2015 09:58, Greg Stein wrote: Daniel Berlin stated many years ago that the years associated with copyright lines are meaningless. There is no reason to burn/re-roll just for that. The simple fact is that if you end up in court, then what is printed to the console has ZERO bearing (or what year is listed in a source file). The court will look at what/when changes *actually* happened. What we state is irrelevant. The commit logs are the important point. So given that, what is the purpose of displaying those years? *shrug* (which was basically his point) -0.9 to even thinking about burning tarballs for this reason. IMO, we should either not display the year (which IIUC would violate ASF policy), or we should display the correct year. Anything else makes us look silly. If I'm wrong about policy, then I propose we just change those lines from: Copyright (C) 2014 The Apache Software Foundation. to Copyright The Apache Software Foundation. (since I believe the (C) is also redundant ... as it stands now, the whole thing is pronounced copyright copyright twothousandfourteen by the apache software foundation). On Fri, Mar 20, 2015 at 2:34 AM, Branko Čibej br...@wandisco.com mailto:br...@wandisco.com wrote: I just noticed that we forgot to bump the displayed copyright year. Fixed in r1667941 and nominated for backport to 1.9.x, 1.8.x and 1.7.x. I also vetoed the 1.7.20 and 1.8.13 releases because of the wrong year ... we really shouldn't release with wrong legalese, and we already allowed 1.9.0-beta1 to slip through with that buglet. s/vetoed/changed my vote to -1/ As Greg kindly reminded my privately, once can't actually veto a release. Sorry about not noticing this earlier, I realize we already have enough votes tor 1.7.20 and 1.8.13; but I really think we should pull these tarballs. -- Brane
Handling non-reproducible test failures (was Re: 1.7.20 release candidates up for testing/signing)
On Fri, Mar 20, 2015 at 9:42 AM, Johan Corveleyn jcor...@gmail.com wrote: ... Unfortunately, I can't verify the rev file, since I don't have it anymore, it has been overwritten by trying to reproduce it (g, should remember to backup leftover repositories and working copies after a failed test run, before trying to reproduce it). Whatever I try now, I can't reproduce it anymore :-(. I'm wondering if something can be improved in our test suite to help diagnosis of hard-to-reproduce test failures. When this happens, you typically wish you could analyse as much data as possible (i.e. the potentially corrupt repository, working copy, dump file, ... that was used in the test). Currently, I can think of three causes for losing this information: 1) You run a series of test runs in sequence from a script (ra_local, ra_svn, ra_serf), all using the same target directory for running the tests (R:\test in my case, where R: is a ram drive). If something fails in ra_svn, but succeeds in ra_serf, your broken test data is overwritten. 2) You don't know in advance that the failure will turn out to be non-reproducible. You can't believe your eyes, try to run it again to be sure, and lo and behold, the test succeeds (and the broken test data is overwritten), and succeeds ever since. 3) Your test data is on a RAM drive, and you reboot or something. Or you copy the data to a fixed disk afterwards, but lose a bit of information because last-modified timestamps of the copied files are reset by copying them between disks. For 1, maybe the outer script could detect that ra_svn had a failure, and stop there (does win-tests.py emit an exit code != 0 if there is a test failure? That would make it easy. Otherwise the outer script would have to parse the test summary output)? Another option is to let every separate test run (ra_local, ra_svn, ra_serf) use a distinct target test directory. But if you're running them on a RAM disk, theoretically you might need three times the storage (hm, maybe not, because --cleanup ensures that successful test data is cleaned up, so as long as you don't run the three ways in parallel, it should be fine). I guess I will do that already, and adjust my script accordingly. Addressing 2 seems harder. Can the second test execution, on encountering stale test data, put that data aside instead of overwriting it? Or maybe every test execution can use a unique naming pattern (with a timestamp or a pid) so it doesn't overwrite previous data? Both approaches would leak data from failed test runs of course, but that's more or less the point. OTOH, you don't know that stale test data is from a previous failed run, or from a successful run that did not use --cleanup. And 3, well, I already reboot as little as possible, so this is more just a point of attention. Maybe addressing all three at the same time could also be: after a failed test run, automatically zip the test data and copy it to a safe location (e.g. the user's home dir). Thoughts? -- Johan
Re: Copyright year displayed by command-line tools
On 20.03.2015 10:28, Branko Čibej wrote: On 20.03.2015 09:58, Greg Stein wrote: Daniel Berlin stated many years ago that the years associated with copyright lines are meaningless. There is no reason to burn/re-roll just for that. The simple fact is that if you end up in court, then what is printed to the console has ZERO bearing (or what year is listed in a source file). The court will look at what/when changes *actually* happened. What we state is irrelevant. The commit logs are the important point. So given that, what is the purpose of displaying those years? *shrug* (which was basically his point) -0.9 to even thinking about burning tarballs for this reason. IMO, we should either not display the year (which IIUC would violate ASF policy), or we should display the correct year. Anything else makes us look silly. If I'm wrong about policy, then I propose we just change those lines from: Copyright (C) 2014 The Apache Software Foundation. to Copyright The Apache Software Foundation. (since I believe the (C) is also redundant ... as it stands now, the whole thing is pronounced copyright copyright twothousandfourteen by the apache software foundation). I missed that our NOTICE file is out of date, too... -- Brane
Re: Copyright year displayed by command-line tools
On Fri, Mar 20, 2015 at 4:28 AM, Branko Čibej br...@wandisco.com wrote: ... IMO, we should either not display the year (which IIUC would violate ASF policy), or we should display the correct year. Anything else makes us look silly. Hmm? Policy is at: http://www.apache.org/legal/src-headers.html And that is what I see in a random sampling of our source. If I'm wrong about policy, then I propose we just change those lines from: Copyright (C) 2014 The Apache Software Foundation. Where are you seeing this? ... Cheers, -g
Re: JavaHL: Exceptions in LogMessageCallback.singleMessage should abort the log immediately
On 20.03.2015 13:59, Branko Čibej wrote: On 20.03.2015 13:34, Marc Strapetz wrote: On 16.03.2015 17:54, Bert Huijben wrote: -Original Message- From: Marc Strapetz [mailto:marc.strap...@syntevo.com] Sent: maandag 16 maart 2015 17:30 To: dev@subversion.apache.org Subject: JavaHL: Exceptions in LogMessageCallback.singleMessage should abort the log immediately If e.g. a RuntimeException is thrown in LogMessageCallback#singleMessage, it's not processed in LogMessageCallback::singleMessage and the log is continued nevertheless: (1) At line 77 in LogMessageCallback.cpp, there should be returned an appropriate error code. (2) After line 122, JNIUtil::isJavaExceptionThrown() should be called and there should be returned an appropriate error code. In both cases, the returned error code should result in stopping the low-level log; rethrowing the Exception in RemoteSession::getLog won't be necessary, as this can be established easily from within client code itself. This is a common problem that applies to almost all callbacks in JavaHL in = 1.9. A fix for this generic problem has been applied to trunk in r1664938 (further tweaks/extensions in 1664939,1664940,1664978,1664984). This introduces some behavior changes (such as the one you noted), so backporting needs discussion here. Thanks for starting the discussion ;-) As JavaHL was reworked significantly for Subversion 1.9, is there a possibility to get this change backported? Not to 1.8, I'm afraid; the differences are far too huge. Fixing this for 1.9.0 is possible, and I agree we should do it. On the topic of behaviour change ... I'd classify it as removal of obvious implementation bug. -- Brane
