Re: [PATCH] svnlook history --limit

[Andreas Stieger]

On 2024-07-24 13:35, zongganli(李宗淦) wrote:

We found a bug in svnlook history --limit.



Can you describe how this bug manifests itself?


It can not deal with the illegal input like "-1", as "apr_size_t"
could be unsigned.



Not having reviewed this in detail, but maybe we should make this similar to

https://svn.apache.org/viewvc/subversion/trunk/subversion/svn/svn.c?view=markup#l2309

Re: svn commit: r1918152 - /subversion/branches/1.14.x/STATUS

[Andreas Stieger]

On 2024-06-04 20:43, Daniel Sahlberg wrote:

Thanks Andreas for your work with checking the backports!

This one should be approved now that it has three votes. Would you
like to do the honors and move it under the Approved changes heading?



No problem, and moved in r1918156

Andreas

Re: Enhancement with Subversion

[Andreas Stieger]

On 10/13/22 15:32, Aynes Varghese via dev wrote:



  In simple terms, iam looking for custom html pages to be displayed
  based on the "error code for 400 and 408
  
"



https://httpd.apache.org/docs/2.4/custom-error.html


Andreas

Re: Assertion error

[Andreas Stieger]

Hello Simon,

On 11/9/20 10:17 AM, Simon Heffer wrote:

TortoiseSVN 1.11.1, Build 28492 - 64 Bit , 2019/01/08 21:40:39



Upgrade to 1.14.0 and try again.

Andreas

Re: is translate.a.o used?

[Andreas Stieger]

Hi Greg,

On 10/7/18 5:57 AM, Greg Stein wrote:
> I'm curious whether translate.apache.org 
> is being used (for the de.po file). The last activity on that site
> appears to be 2015 for the 1.9.0 release.

I am not using this service actively at this time. I found it
potentially useful for some activities, but it brings no improvements in
translating the shell command help output (and it's changes) relative to
po file editors or direct editing.

So it would not have any effect if the service was discontinued.

Andreas

JDK 10 removal of javah

[Andreas Stieger]

Hello,

I was made aware by our Java package maintainer of the fact that JDK 10
is removing the javah tool, after the deprecation from JDK 8. Our javahl
stuff no longer builds and apparently the functionality is in javac now.

JEP 313: Remove the Native-Header Generation Tool (javah)
http://openjdk.java.net/jeps/313

Was anyone looking at this?

Andreas

-- 
Andreas Stieger <astie...@suse.com>
Project Manager Security
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)

Re: library dependency information in status output (here: lz4)

[Andreas Stieger]

> LZ4_versionNumber() has existed since r120, so we could use that and the
> individual LZ4_VERSION_* defines instead.  Something like the below.
[...]

>From http://svn.apache.org/r1818807

-  Subversion uses LZ4 compression libary version 1.7.5 or above. Configure
+  Subversion uses LZ4 compression libary version r120 or above. Configure
[...]
-  
+
   If configure should use the version bundled with the sources, use:
 --with-lz4=internal
[...]
-  AC_MSG_ERROR([Subversion requires LZ4 >= 1.7.5, or use 
--with-lz4=internal])
+  AC_MSG_ERROR([Subversion requires LZ4 >= r120, or use 
--with-lz4=internal])
[...]
-if $PKG_CONFIG liblz4 --atleast-version=1.7.5; then
+if $PKG_CONFIG liblz4 --atleast-version=120 || $PKG_CONFIG liblz4 
--max-version=3; then


We call LZ4_compress_default which was not added until r129.

Andreas

Re: library dependency information in status output (here: lz4)

[Andreas Stieger]

> checking for lz4 library via pkg-config... yes
> 
> and build says:
> 
> subversion/libsvn_subr/compress_lz4.c:30:5: warning: "SVN_INTERNAL_LZ4" 

That is actually a side-effect of r1818662. Earlier versions of lz4 distributed 
a pkg-conf file with a Version relating to their svn revision. Your 131 is 
obviously not continuous with the later 1.7.5. I have not traced back which 
version is actually the minimum. Using LZ4_versionString() really does bump it 
to 1.7.5. I am not sure if this is desired? I have no particular issue with 
that.

Andreas

library dependency information in status output (here: lz4)

[Andreas Stieger]

Hello,

should we continue to add all linked dependencies (here: lz4) to the verbose 
version output, as the attached patch would do?

AndreasIndex: subversion/include/private/svn_subr_private.h
===
--- subversion/include/private/svn_subr_private.h	(revision 1818663)
+++ subversion/include/private/svn_subr_private.h	(working copy)
@@ -738,6 +738,12 @@ const char *svn_zlib__compiled_version(void);
 /* Return the zlib version we run against. */
 const char *svn_zlib__runtime_version(void);
 
+/* Return the lz4 version we compiled against. */
+const char *svn_lz4__compiled_version(void);
+
+/* Return the lz4 version we run against. */
+const char *svn_lz4__runtime_version(void);
+
 #ifdef __cplusplus
 }
 #endif /* __cplusplus */
Index: subversion/libsvn_subr/compress_lz4.c
===
--- subversion/libsvn_subr/compress_lz4.c	(revision 1818663)
+++ subversion/libsvn_subr/compress_lz4.c	(working copy)
@@ -126,3 +126,17 @@ svn__decompress_lz4(const void *data, apr_size_t l
 
   return SVN_NO_ERROR;
 }
+
+const char *
+svn_lz4__compiled_version(void)
+{
+  static const char lz4_version_str[] = LZ4_VERSION_STRING;
+
+  return lz4_version_str;
+}
+
+const char *
+svn_lz4__runtime_version(void)
+{
+  return LZ4_versionString();
+}
Index: subversion/libsvn_subr/sysinfo.c
===
--- subversion/libsvn_subr/sysinfo.c	(revision 1818663)
+++ subversion/libsvn_subr/sysinfo.c	(working copy)
@@ -127,7 +127,7 @@ const apr_array_header_t *
 svn_sysinfo__linked_libs(apr_pool_t *pool)
 {
   svn_version_ext_linked_lib_t *lib;
-  apr_array_header_t *array = apr_array_make(pool, 6, sizeof(*lib));
+  apr_array_header_t *array = apr_array_make(pool, 7, sizeof(*lib));
 
   lib = _ARRAY_PUSH(array, svn_version_ext_linked_lib_t);
   lib->name = "APR";
@@ -167,6 +167,11 @@ svn_sysinfo__linked_libs(apr_pool_t *pool)
   lib->compiled_version = apr_pstrdup(pool, svn_zlib__compiled_version());
   lib->runtime_version = apr_pstrdup(pool, svn_zlib__runtime_version());
 
+  lib = _ARRAY_PUSH(array, svn_version_ext_linked_lib_t);
+  lib->name = "LZ4";
+  lib->compiled_version = apr_pstrdup(pool, svn_lz4__compiled_version());
+  lib->runtime_version = apr_pstrdup(pool, svn_lz4__runtime_version());
+
   return array;
 }
 

Re: Giving 1.10 alpha more exposure to gather feedback

[Andreas Stieger]

Hi,


On 08/15/2017 11:57 AM, Johan Corveleyn wrote:
> Can we try to give 1.10 alpha3 a bit more exposure, in order to gather
> more feedback?

The openSUSE project has 1.10 alpha3 binaries ready for all current
openSUSE and SUSE Linux Enterprise distributions.

https://software.opensuse.org//download.html?project=home%3AAndreasStieger%3Abranches%3Adevel%3Atools%3Ascm%3Asvn=subversion

Andreas

Re: [PATCH] use SHA-2 hashes for releases

[Andreas Stieger]

Hello,

On 06/28/2017 07:42 AM, Daniel Shahaf wrote:
> Andreas Stieger wrote on Sat, 10 Jun 2017 12:24 +0200:
>> Found this laying around... maybe someone who previously made releases
>> could check it out.
> 
> Any news about this patch?  I have some pending tweaks to release.py and
> don't want to conflict.

No news.

> As I said about an earlier iteration: I think the main question is whether we
> want to provide both sha1 and sha2 hashes for a transition period.  I.e., do
> we try for compatibility or force people to switch over to sha2.

Those that may fail to change their "verification" from sha-1 to sha-2
may not have been very useful in any kind of verification in the first
place. So unless there is a technical reason (which I do not see) I
would just change it.

Andreas

-- 
Andreas Stieger <astie...@suse.com>
Project Manager Security
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)



signature.asc
Description: OpenPGP digital signature

[PATCH] use SHA-2 hashes for releases

[Andreas Stieger]

Hello,

Found this laying around... maybe someone who previously made releases
could check it out.

Obviously we could just as well use SHA-256. What do you think?

[[[

Use SHA-2 hashes for releases

* tools/dist/checksums.py: also check SHA-512 digest
* tools/dist/dist.sh: also generate SHA-512 digest
* tools/dist/download-release.sh: remove unused script
* tools/dist/release.py: switch to announcing SHA-512 digest
* tools/dist/templates/download.ezt,
  tools/dist/templates/rc-release-ann.ezt,
  tools/dist/templates/stable-release-ann.ezt: reference SHA-512 digests
  and HTTPS urls.

]]]


Andreas

-- 
Andreas Stieger <astie...@suse.com>
Project Manager Security
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)

Use SHA-2 hashes for releases

* tools/dist/checksums.py: also check SHA-512 digest
* tools/dist/dist.sh: also generate SHA-512 digest
* tools/dist/download-release.sh: remove unused script
* tools/dist/release.py: switch to announcing SHA-512 digest
* tools/dist/templates/download.ezt,
  tools/dist/templates/rc-release-ann.ezt,
  tools/dist/templates/stable-release-ann.ezt: reference SHA-512 digests
  and HTTPS urls.

Index: tools/dist/checksums.py
===
--- tools/dist/checksums.py	(revision 1798304)
+++ tools/dist/checksums.py	(working copy)
@@ -19,12 +19,14 @@
 # under the License.
 #
 #
-# Check MD5 and SHA1 signatures of files, using md5sums and/or
-# sha1sums as manifests.  Replaces the 'md5sum' and 'sha1sum' commands
+# Check MD5 and SHA-1 and SHA-2 signatures of files, using 
+# md5sums, sha1sums, and/or sha512sums as manifests
+# Replaces the 'md5sum', 'sha1sum', and 'sha512sums' commands
 # on systems that do not have them, such as Mac OS X or Windows.
 #
 # Usage: checksums.py [manifest]
-#   where "os.path.basename(manifest)" is either "md5sums" or "sha1sums"
+#   where "os.path.basename(manifest)" is either "md5sums", "sha1sums",
+#   "sha512sums"
 #
 # Tested with the following Python versions:
 #2.4   2.5   2.6   2.7   3.2
@@ -37,6 +39,7 @@ import sys
 try:
 from hashlib import md5
 from hashlib import sha1
+from hashlib import sha512
 except ImportError:
 from md5 import md5
 from sha import sha as sha1
@@ -67,9 +70,11 @@ def main(manipath):
 sink = Digester(md5)
 elif manifest == 'sha1sums':
 sink = Digester(sha1)
+elif manifest == 'sha512sums':
+sink = Digester(sha512)
 else:
 raise ValueError('The name of the digest manifest must be '
- "'md5sums' or 'sha1sums', not '%s'" % manifest)
+ "'md5sums', 'sha1sums', or 'sha512sums', not '%s'" % manifest)
 
 # No 'with' statement in Python 2.4 ...
 stream = None
Index: tools/dist/dist.sh
===
--- tools/dist/dist.sh	(revision 1798304)
+++ tools/dist/dist.sh	(working copy)
@@ -369,9 +369,10 @@ sign_file()
   fi
 }
 
-# allow md5sum and sha1sum tool names to be overridden
+# allow md5sum,sha1sum, and sha512sum tool names to be overridden
 [ -n "$MD5SUM" ] || MD5SUM=md5sum
 [ -n "$SHA1SUM" ] || SHA1SUM=sha1sum
+[ -n "$SHA512SUM" ] || SHA512SUM=sha512sum
 
 echo ""
 echo "Done:"
@@ -387,6 +388,12 @@ if [ -z "$ZIP" ]; then
 echo "sha1sums:"
 $SHA1SUM "$DISTNAME.tar.bz2" "$DISTNAME.tar.gz"
   fi
+  type $SHA512SUM > /dev/null 2>&1
+  if [ $? -eq 0 ]; then
+echo ""
+echo "sha512sums:"
+$SHA512SUM "$DISTNAME.tar.bz2" "$DISTNAME.tar.gz"
+  fi
 else
   ls -l "$DISTNAME.zip"
   sign_file $DISTNAME.zip
@@ -399,4 +406,10 @@ else
 echo "sha1sum:"
 $SHA1SUM "$DISTNAME.zip"
   fi
+  type $SHA512SUM > /dev/null 2>&1
+  if [ $? -eq 0 ]; then
+echo ""
+echo "sha512sum:"
+$SHA512SUM "$DISTNAME.zip"
+  fi
 fi
Index: tools/dist/download-release.sh
===
--- tools/dist/download-release.sh	(revision 1798304)
+++ tools/dist/download-release.sh	(nonexistent)
@@ -1,28 +0,0 @@
-#!/bin/bash
-#
-#
-# Licensed to the Apache Software Foundation (ASF) under one
-# or more contributor license agreements.  See the NOTICE file
-# distributed with this work for additional information
-# regarding copyright ownership.  The ASF licenses this file
-# to you under the Apache License, Version 2.0 (the
-# "License"); you may not use this file except in compliance
-# with the License.  You may obtain a copy of the License at
-#
-#   http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing,
-# software distributed under 

Re: On the subversion I have a question to confirm

[Andreas Stieger]

Hello, 

"shen...@snail.com" wrote:
> On the subversion I have a question to confirm， 
> that the historical version has been submitted inside, 
> whether by modifying the underlying file to modify the historical
> version of the content, hoping to help answer this question, thank you.

That does hardly make sense, but let me try:

History manipulation is subversion is not trivially possible. In fact, it is 
designed not to allow such modification.

You may dump and selectively load the history into a new repository. 
(dumpfilter)
Alternatively you may do the same, but create "corrected" revisions in place of 
the ones you want to remove. Note that subsequent loads may no longer apply 
from the svndump format, and that working copies may be invalidated should 
history change unexpectedly.

Andreas

Re: beta@ feedback mailing list?

[Andreas Stieger]

Daniel Shahaf wrote:
> One of the ideas that came up was to establish a dedicated mailing list
> for beta / pre-release feedback.  The thinking is that having a channel
> for advanced users to discuss 1.10-dev issues in — without noise from
> support requests or design discussions — might encourage more such
> discussion to happen.

I don't know that given the current volume on either dev@ or users@ would give 
way to a noise issue that would require a dedicated list for beta.

We already ask users to contact users@ for "build problems, configuration 
issues, etc, as well as usage questions." I think discussing beta release 
issues on users@ sounds perfectly reasonable to me, until such point where 
implementation details are being discussed.

users@: beta issues including building, configuration, usage, performance
dev@: implementation, patches, release management.

Andreas

Re: [PATCH] 1.10 Release notes and FAQ around SHA-1

[Andreas Stieger]

Hi,

On 08/05/17 10:46, Jacek Materna wrote:
>
> Install a pre-commit hook that will reject new instances against known
> collisions. While this will not guarantee protection from new
> collisions, we will keep the hook up-to date as new collisions are
> publicly released.
>
>
> The hook can be found
> here:https://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/reject-known-sha1-collisions.sh
>

I am not sure if this is suitable for a general audience, but I made
another hook that uses counter-cryptanalysis. It needs
https://github.com/cr-marcstevens/sha1collisiondetection/commit/5ee29e5e3e57015800f2eb6ced4cd28dd639e6dd


https://svn.apache.org/viewvc?view=revision=1794454
https://svn.apache.org/viewvc/subversion/trunk/tools/hook-scripts/reject-detected-sha1-collisions.sh?view=markup=1794454
https://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/reject-detected-sha1-collisions.sh

Have fun,
Andreas

more on detecting SHA-1 collisions

[Andreas Stieger]

Hello,

further on the topic of putting in place remediation for issues that
resulted from SHA-1 collisions (CVE-2005-4900), most recently
demonstrated by material posted on shattered.io, and observed as
recoverable repository corruption on the WebKit repository:

Improving on hooks:

First thanks all fixing specific cases not covered in the original
version. As documented, it checks for the known "PDF" prefix, but is
unable to detect new collisions generated using the same method.

Code exists that performs a more general approach:
https://github.com/cr-marcstevens/sha1collisiondetection
Packaged the CLI tool for openSUSE and SUSE Linux Enterprise Server
https://software.opensuse.org/package/sha1collisiondetection

It lacks reading from stdin atm, but it could be adopted into a more
advanced hook. Any takers?

As Mark noted in his blog post, this can have a considerable performance
impact. The library claims to do what it does at the cost of less than
2x cycles.

Let's talk about how this can be applied to code. Reading
libsvn_subr/checksum.c :: svn_checksum(), the library could be dropped
there, taking over for the apr_sha1_* calls, and erroring out on the
rare detected collision. This would prevent repository corruption for
all future collisions generated using the same attack.

Performance wise, this could be optimized to restrict this to
transaction write operations.

What is really interesting about this library is that it has a
"safe-hash" mode, where upon detection of just one side of the collision
a consistently different digest will be generated. Mapping to safe
non-colliding digest values is interesting, as it would allow continued
operation of the repository, possibly the working copy. However I
imagine that there will be a number of compatibility issues on the
client and dump protocols. These would trigger in cases of legitimate
storage of one side of a collision. Do you think that this is something
worth investigating?

Andreas

Re: [PATCH] reject-known-sha1-collisions.sh: shell language tweaks

[Andreas Stieger]

Hi,

Daniel Shahaf wrote:
> [[[
> * tools/hook-scripts/reject-known-sha1-collisions.sh
> Use a more portable syntax for the [(1) (test(1)) tool.
> Handle filenames with literal backslashes.
> ]]]

Thanks, r1784484.

Andreas

Re: Files with identical SHA1 breaks the repo

[Andreas Stieger]

Hi,

This hook script can prevent further corruptions through files based on
the known two 320 bytes prefixes.
https://svn.apache.org/r1784336

Andreas

Re: Files with identical SHA1 breaks the repo

[Andreas Stieger]

Hi,

"Stefan Hett" wrote:
> On 2/23/2017 9:02 PM, Øyvind A. Holm wrote:
> > This is the only known SHA-1 collision at the moment, but Google will
> > release the collision code in 90 days, so we can expect this not to last
> > forever.
> Reading up on that in an article on a German magazine [1] clarifies that 
> the effort to create that hash still quite large (6500 CPU years + 100 
> GPU years to calculate the collision). So this relativates the impact a bit.
> Certainly I'm not trying to say that the situation on SVN's side 
> should/could not be improved, though.
> 
> [1] 
> https://www.heise.de/newsticker/meldung/Todesstoss-Forscher-zerschmettern-SHA-1-3633589.html

An occurrence of this issue in a production repository with the published PDFs:
https://bugs.webkit.org/show_bug.cgi?id=168774#c29

Andreas

Re: [PATCH] use SHA-2 family hash for releases

[Andreas Stieger]

On 23/02/17 21:08, Andreas Stieger wrote:
After the alpha, the next release should go up with a SHA-2 family 
digest. 


And some cleanup patches, even though this does not currently seem to be 
part of the release pipeline:


sha-2-dist.patch
[[[
* tools/dist/dist.sh: also print SHA-512
]]]

sha-2-checksums-py.patch
[[[
* tools/dist/checksums.py: support SHA-512
]]]

sha-2-cleanup.patch
[[[
* tools/dist/download-release.sh: remove unused script
]]]

Andreas
Index: tools/dist/checksums.py
===
--- tools/dist/checksums.py	(revision 1784199)
+++ tools/dist/checksums.py	(working copy)
@@ -19,12 +19,14 @@
 # under the License.
 #
 #
-# Check MD5 and SHA1 signatures of files, using md5sums and/or
-# sha1sums as manifests.  Replaces the 'md5sum' and 'sha1sum' commands
+# Check MD5 and SHA-1 and SHA-2 signatures of files, using 
+# md5sums, sha1sums, and/or sha512sums as manifests
+# Replaces the 'md5sum', 'sha1sum', and 'sha512sums' commands
 # on systems that do not have them, such as Mac OS X or Windows.
 #
 # Usage: checksums.py [manifest]
-#   where "os.path.basename(manifest)" is either "md5sums" or "sha1sums"
+#   where "os.path.basename(manifest)" is either "md5sums", "sha1sums",
+#   "sha512sums"
 #
 # Tested with the following Python versions:
 #2.4   2.5   2.6   2.7   3.2
@@ -37,6 +39,7 @@ import sys
 try:
 from hashlib import md5
 from hashlib import sha1
+from hashlib import sha512
 except ImportError:
 from md5 import md5
 from sha import sha as sha1
@@ -67,9 +70,11 @@ def main(manipath):
 sink = Digester(md5)
 elif manifest == 'sha1sums':
 sink = Digester(sha1)
+elif manifest == 'sha512sums':
+sink = Digester(sha512)
 else:
 raise ValueError('The name of the digest manifest must be '
- "'md5sums' or 'sha1sums', not '%s'" % manifest)
+ "'md5sums', 'sha1sums', or 'sha512sums', not '%s'" % manifest)
 
 # No 'with' statement in Python 2.4 ...
 stream = None
Index: tools/dist/dist.sh
===
--- tools/dist/dist.sh	(revision 1784199)
+++ tools/dist/dist.sh	(working copy)
@@ -369,9 +369,10 @@ sign_file()
   fi
 }
 
-# allow md5sum and sha1sum tool names to be overridden
+# allow md5sum, sha1sum, and sha512sum tool names to be overridden
 [ -n "$MD5SUM" ] || MD5SUM=md5sum
 [ -n "$SHA1SUM" ] || SHA1SUM=sha1sum
+[ -n "$SHA512SUM" ] || SHA512SUM=sha512sum
 
 echo ""
 echo "Done:"
@@ -387,6 +388,12 @@ if [ -z "$ZIP" ]; then
 echo "sha1sums:"
 $SHA1SUM "$DISTNAME.tar.bz2" "$DISTNAME.tar.gz"
   fi
+  type $SHA512SUM > /dev/null 2>&1
+  if [ $? -eq 0 ]; then
+echo ""
+echo "sha512sums:"
+$SHA512SUM "$DISTNAME.tar.bz2" "$DISTNAME.tar.gz"
+  fi
 else
   ls -l "$DISTNAME.zip"
   sign_file $DISTNAME.zip
@@ -399,4 +406,10 @@ else
 echo "sha1sum:"
 $SHA1SUM "$DISTNAME.zip"
   fi
+  type $SHA512SUM > /dev/null 2>&1
+  if [ $? -eq 0 ]; then
+echo ""
+echo "sha512sum:"
+$SHA512SUM "$DISTNAME.zip"
+  fi
 fi
Index: tools/dist/download-release.sh
===
--- tools/dist/download-release.sh	(revision 1784199)
+++ tools/dist/download-release.sh	(nonexistent)
@@ -1,28 +0,0 @@
-#!/bin/bash
-#
-#
-# Licensed to the Apache Software Foundation (ASF) under one
-# or more contributor license agreements.  See the NOTICE file
-# distributed with this work for additional information
-# regarding copyright ownership.  The ASF licenses this file
-# to you under the Apache License, Version 2.0 (the
-# "License"); you may not use this file except in compliance
-# with the License.  You may obtain a copy of the License at
-#
-#   http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing,
-# software distributed under the License is distributed on an
-# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-# KIND, either express or implied.  See the License for the
-# specific language governing permissions and limitations
-# under the License.
-#
-#
-BASEURL=$1
-VERSION=$2
-wget -nc $BASEURL/{{md5,sha1}sums,svn_version.h.dist,subversion{-deps,}-$VERSION.{{zip,tar.bz2}{.asc,},tar.gz.asc}}
-bzip2 -dk subversion{-deps,}-$VERSION.tar.bz2
-gzip -9n subversion{-deps,}-$VERSION.tar
-md5sum -c md5sums
-sha1sum -c sha1sums

Property changes on: tools/dist/download-release.sh
___
Deleted: svn:eol-style
## -1 +0,0 ##
-native
\ No newline at end of property
Deleted: svn:executable
## -1 +0,0 ##
-*
\ No newline at end of property

[PATCH] use SHA-2 family hash for releases

[Andreas Stieger]

Hello,

After the alpha, the next release should go up with a SHA-2 family digest.

[[[
Use SHA-512 for releases

* tools/dist/release.py: generate SHA-512 digests

* tools/dist/templates/download.ezt
  tools/dist/templates/rc-release-ann.ezt
  tools/dist/templates/stable-release-ann.ezt: adjust text and variable

]]]

Andreas

Index: tools/dist/release.py
===
--- tools/dist/release.py	(revision 1784199)
+++ tools/dist/release.py	(working copy)
@@ -537,9 +537,9 @@ def roll_tarballs(args):
 
 shutil.move(filename, get_deploydir(args.base_dir))
 filename = os.path.join(get_deploydir(args.base_dir), filename)
-m = hashlib.sha1()
+m = hashlib.sha512()
 m.update(open(filename, 'r').read())
-open(filename + '.sha1', 'w').write(m.hexdigest())
+open(filename + '.sha512', 'w').write(m.hexdigest())
 
 shutil.move('svn_version.h.dist',
 get_deploydir(args.base_dir) + '/' + 'svn_version.h.dist'
@@ -758,39 +758,39 @@ def write_news(args):
 template.generate(sys.stdout, data)
 
 
-def get_sha1info(args, replace=False):
-'Return a list of sha1 info for the release'
+def get_sha512info(args, replace=False):
+'Return a list of sha512 info for the release'
 
 target = get_target(args)
 
-sha1s = glob.glob(os.path.join(target, 'subversion*-%s*.sha1' % args.version))
+sha512s = glob.glob(os.path.join(target, 'subversion*-%s*.sha512' % args.version))
 
 class info(object):
 pass
 
-sha1info = []
-for s in sha1s:
+sha512info = []
+for s in sha512s:
 i = info()
-# strip ".sha1"
-fname = os.path.basename(s)[:-5]
+# strip ".sha512"
+fname = os.path.basename(s)[:-7]
 if replace:
 # replace the version number with the [version] reference
 i.filename = Version.regex.sub('[version]', fname)
 else:
 i.filename = fname
-i.sha1 = open(s, 'r').read()
-sha1info.append(i)
+i.sha512 = open(s, 'r').read()
+sha512info.append(i)
 
-return sha1info
+return sha512info
 
 
 def write_announcement(args):
 'Write the release announcement.'
-sha1info = get_sha1info(args)
+sha512info = get_sha512info(args)
 siginfo = "\n".join(get_siginfo(args, True)) + "\n"
 
 data = { 'version'  : str(args.version),
- 'sha1info' : sha1info,
+ 'sha512info'   : sha512info,
  'siginfo'  : siginfo,
  'major-minor'  : args.version.branch,
  'major-minor-patch': args.version.base,
@@ -809,10 +809,10 @@ def write_announcement(args):
 
 def write_downloads(args):
 'Output the download section of the website.'
-sha1info = get_sha1info(args, replace=True)
+sha512info = get_sha512info(args, replace=True)
 
 data = { 'version'  : str(args.version),
- 'fileinfo' : sha1info,
+ 'fileinfo' : sha512info,
}
 
 template = ezt.Template(compress_whitespace = False)
Index: tools/dist/templates/download.ezt
===
--- tools/dist/templates/download.ezt	(revision 1784199)
+++ tools/dist/templates/download.ezt	(working copy)
@@ -2,12 +2,12 @@
 
 
   File
-  Checksum (SHA1)
+  Checksum (SHA-512)
   Signatures
 
 [for fileinfo]
   [fileinfo.filename]
-  [fileinfo.sha1]
+  [fileinfo.sha512]
   [http://www.apache.org/dist/subversion/[fileinfo.filename].asc;>PGP]
 [end]
 
Index: tools/dist/templates/rc-release-ann.ezt
===
--- tools/dist/templates/rc-release-ann.ezt	(revision 1784199)
+++ tools/dist/templates/rc-release-ann.ezt	(working copy)
@@ -3,9 +3,9 @@ Please choose the mirror closest to you by visitin
 
 http://subversion.apache.org/download.cgi#[anchor]
 
-The SHA1 checksums are:
+The SHA-512 checksums are:
 
-[for sha1info][sha1info.sha1] [sha1info.filename]
+[for sha512info][sha512info.sha512] [sha512info.filename]
 [end]
 PGP Signatures are available at:
 
Index: tools/dist/templates/stable-release-ann.ezt
===
--- tools/dist/templates/stable-release-ann.ezt	(revision 1784199)
+++ tools/dist/templates/stable-release-ann.ezt	(working copy)
@@ -3,9 +3,9 @@ Please choose the mirror closest to you by visitin
 
 http://subversion.apache.org/download.cgi#[anchor]
 
-The SHA1 checksums are:
+The SHA-512 checksums are:
 
-[for sha1info][sha1info.sha1] [sha1info.filename]
+[for sha512info][sha512info.sha512] [sha512info.filename]
 [end]
 PGP Signatures are available at:
 

Re: translations

[Andreas Stieger]

Hi,

> I just noticed we are already in Apache's Pootle:
> 
>https://translate.apache.org/projects/Subversion/
> 
> with German as the only translation language so far.

I set this up during my last translation round. 

> Are we using Pootle correctly and efficiently for the German 
> translation?

It worked sufficiently well for strings that have no special formatting 
requirements. It also worked well for out-of-band changes, e.g. merging items 
translated locally with those translated in Pootle.

For anything that includes non-trivial help output and special formatting, I 
found it to be cumbersome.

> What do we have to do, to start using it more fully?

Regular local scan of trunk, uploading it to Pootle, translating/review, and 
commit into source.
 
> For a first step, could we usefully do something like transmit the .pot 
> file to Pootle instead of checking it in to our source tree? Would that 
> be better?

You would not use the .pot but the .po, so as to not loose existing 
translations.
For other translations: setting them up in Pootle, I did not want to presume 
that other po maintainers would want to do that.

Pootle has automation opportunities of scanning the code base, have not 
explored.

Is that something we want to kick off for the next release?

Andreas

Re: translations

[Andreas Stieger]

On 04/02/17 17:13, Stefan Kueng wrote:

[...]I'm wondering about the translations of those strings.


Several points on this:

#1 Working with Pootle works well, both ways. There is just a bit of a 
coordination effort. That coordination needs to be figured out more 
urgently than the actual tool.


#2 Help output in UI strings.

This is A LOT of insane frustrating work. Every time the help output of 
a command changes even a little bit, the complete string needs to be 
re-checked. It needs to be adjusted for spacing and justification. And 
at that point you really need to walk the svn code history to adjust the 
translation, there is no way to get a stable community of translators on 
that level.


Note how you need to maintain the command line switches in several places?
* command line logic code
* subcommand help output
* translations of same
* (subversion book)
There are tools for keeping this stuff synchronized, e.g. autogen. That 
would then also compile into help, man, docbook, chm and whatnot.


Andreas

Re: Subversion Exception!

[Andreas Stieger]

Hi,

Alfred Ultsch wrote:
> In file
>   
> 'D:\Development\SVN\Releases\TortoiseSVN-1.9.3\ext\subversion\subversion\libsvn_client\cleanup.c'
>   line 227: assertion failed (svn_dirent_is_absolute(dir_abspath))

Upgrade to 1.9.4 and try again.

Andreas

Re: Localizing error messages

[Andreas Stieger]

Hi,

On 23/01/16 11:51, Stefan Fuhrmann wrote:

The topic has been brought up on IRC yesterday
but I've found wondering myself the same thing
in the past: What error messages should be
marked for localization?

In particular, most of the back-end libraries create
"stuff is horribly broken" error messages whose
specific contents is only meaningful to experts but
not to ordinary admins or client users. We are quite
inconsistent about the usage of _() in those libs and
I myself wasn't consistent about it either.

I suggest as a policy (in case that isn't already in
place) that error messages shall not be localized
id the user / admin cannot reasonable act on them.
Specifically, I suggest that all "data corrupted" error
messages become non-localized. If there is something
that a user can do about it (transient network failure),
higher levels should wrap the error appropriately.


I brought this up while updating translations. I do not really have 
anything to add to what you wrote other than proposing the guidelines 
that localisation should be on the UI, not on the internal implementation.


Andreas

Aw: Release announcement subject lines

[Andreas Stieger]

Hi,

Daniel Shahaf wrote:
> Perhaps the subject line of release announcements should indicate
> whether that release includes a security fix?

Desirable as from distribution point of view (if we didn't already know through 
private pre-disclosures) 

> For example:
> Subject: Apache Subversion 1.8.11 released [SECURITY]
> Subject: Apache Subversion 1.8.12 released

Good, alternatively, post the security announcements separately.

Andreas

Re: I have following problem

[Andreas Stieger]

Hello,

On 08/11/15 09:37, m...@camtek.com wrote:

Please take the time to report this on the Subversion mailing list

with as much information as possible about what

you were trying to do.



Instead of the above, you sent zero.


In file

'D:\Development\SVN\Releases\TortoiseSVN-1.7.13\ext\subversion\subversion\libsvn_subr\mergeinfo.c'

line 1152: assertion failed (IS_VALID_FORWARD_RANGE(second))



Update to the last compatible release in the 1.7.x branch: TortoiseSVN 
1.7.15 linking against Subverson 1.7.18

http://sourceforge.net/projects/tortoisesvn/files/1.7.15/Application/
.. and try again.

Bug reports against 1.7.x will no longer be accepted, please use 1.8.x 
or 1.9.x, the latest there is 1.9.2.


Andreas

bash completion for arguments to svn info --show-item

[Andreas Stieger]

Hello,

follow up to
http://colabti.org/irclogger/irclogger_log/svn-dev?date=2015-08-27#l30

[[[
* tools/client-side/bash_completion
  (_svn): Complete arguments to svn info --show-item
]]]

Andreas
Index: tools/client-side/bash_completion
===
--- tools/client-side/bash_completion	(revision 1698219)
+++ tools/client-side/bash_completion	(working copy)
@@ -183,6 +183,7 @@ _svn()
 	optsParam=$optsParam|--native-eol|-l|--limit|-c|--change
 	optsParam=$optsParam|--depth|--set-depth|--with-revprop
 	optsParam=$optsParam|--cl|--changelist|--accept|--show-revs
+	optsParam=$optsParam|--show-item
 
 	# svn:* and other (env SVN_BASH_*_PROPS) properties
 	local svnProps revProps allProps psCmds propCmds
@@ -504,6 +505,10 @@ _svn()
 
 	[[ $previous = '--show-revs' ]]  values='merged eligible'
 
+	[[ $previous = '--show-item' ]]  values=kind url relative-url \
+	  repos-root-url repos-uuid revision last-changed-revision ' \
+	  last-changed-date last-changed-author wc-root
+
 	if [[ $previous = '--username' ]] ; then
 	  values=$SVN_BASH_USERNAME
 	  if [[ $SVN_BASH_COMPL_EXT == *username* ]] ; then

issue 4587: Verifying multiple OpenPGP signatures on a release

[Andreas Stieger]

For issue 4587: Verifying multiple OpenPGP signatures on a release
The following splits and verifies all signatures:
csplit --elide-empty-files --prefix=sig --suffix-format=%0d2.asc  
subversion-1.9.0.tar.bz2.asc '/^-BEGIN PGP SIGNATURE-$/' '{*}'
for X in sig*.asc; do gpg --verify $X subversion-1.9.0.tar.bz2; done

The same could be done in awk.

In 2013 gpg was noted to not support multiple signatures if the signing keys 
differ in type/digest:
http://www.eyrie.org/~eagle/journal/2013-01/011.html

Andreas

[patch] Support modern network utilities for finding free ports for tests

[Andreas Stieger]

Hello,

GNU/Linux distributions are deprecating some legacy IP tools [1], moving
them to a -deprecated package: in this case netstat. Please review the
attached patch adding compatible support for it's functional successor
ss(8).

[[[
Support modern network utilities for finding free ports for tests

* subversion/tests/cmdline/davautocheck.sh:
  Check for presence of ss, netstat and fail if neither is found.
  Prefer ss to find a free port, fall back to netstat.
* subversion/tests/cmdline/svnserveautocheck.sh:
  Same, and augment $PATH to include /usr/{,local/}sbin.

]]]


[1] https://build.opensuse.org/request/show/308848

With kind regards,
Andreas Stieger
Index: subversion/tests/cmdline/davautocheck.sh
===
--- subversion/tests/cmdline/davautocheck.sh	(revision 1684476)
+++ subversion/tests/cmdline/davautocheck.sh	(working copy)
@@ -318,12 +318,18 @@ fi
 # Stop any previous instances, os we can re-use the port.
 if [ -x $STOPSCRIPT ]; then $STOPSCRIPT ; sleep 1; fi
 
+ss  /dev/null 21 || netstat  /dev/null 21 || fail unable to find ss or netstat required to find a free port
+
 HTTPD_PORT=3691
-while netstat -an | grep $HTTPD_PORT | grep 'LISTEN' /dev/null; do
+while \
+  (ss -ltn sport = :$HTTP_PORT 21 | grep :$HTTP_PORT  /dev/null ) \
+  || \
+  (netstat -an 21 | grep $HTTP_PORT | grep 'LISTEN'  /dev/null ) \
+  do
   HTTPD_PORT=$(( HTTPD_PORT + 1 ))
   if [ $HTTPD_PORT -eq 65536 ]; then
 # Most likely the loop condition is true regardless of $HTTPD_PORT
-fail netstat claims you have no free ports for httpd to listen on.
+fail ss/netstat claim you have no free ports for httpd to listen on.
   fi
 done
 HTTPD_ROOT=$ABS_BUILDDIR/subversion/tests/cmdline/httpd-$(date '+%Y%m%d-%H%M%S')
Index: subversion/tests/cmdline/svnserveautocheck.sh
===
--- subversion/tests/cmdline/svnserveautocheck.sh	(revision 1684476)
+++ subversion/tests/cmdline/svnserveautocheck.sh	(working copy)
@@ -95,9 +95,16 @@ random_port() {
 if type time  /dev/null ; then TIME_CMD() { time $@; } ; else TIME_CMD() { $@; } ; fi
 
 MAKE=${MAKE:-make}
+PATH=$PATH:/usr/sbin/:/usr/local/sbin/
 
+ss  /dev/null 21 || netstat  /dev/null 21 || fail unable to find ss or netstat required to find a free port
+
 SVNSERVE_PORT=$(random_port)
-while netstat -an | grep $SVNSERVE_PORT | grep 'LISTEN'; do
+while \
+  (ss -ltn sport = :$SVNSERVE_PORT 21 | grep :$SVNSERVE_PORT  /dev/null ) \
+  || \
+  (netstat -an 21 | grep $SVNSERVE_PORT | grep 'LISTEN'  /dev/null ) \
+  do
   SVNSERVE_PORT=$(random_port)
 done
 

Aw: Re: Changeset Signing

[Andreas Stieger]

Hi,

Branko Čibej wrote:
 On 08.06.2015 04:19, Ruchir Arya wrote:
  Hello everybody,
 
  I am new to SVN development. I have a question. Why is there no
  implementation of changeset signing in subversion? Suppose if the
  root/admin (who maintains repository) is not trustworthy,
 
 If your server administrator is not trustworthy, then no amount of
 signing is going to help. Anyone with direct access to the repository
 storage (which a server admin will have) can modify revision contents
 even if they're signed; no cryptographic signature is proof against attack.

Actually, this is *exactly* what a cryptographic signature is. Assuming Ruchir 
is not free from the influcences of other three letter tools implementing 
commit signatures, it is very likely that he is referring to committer supplied 
signatures which, will fail to validate upon subsequent manipulation of the 
repository history relevant to the signature. This is a separate problem from 
internal repository consistency checks.

To answer the initial question: This was not implemented because it is not an 
inherent problem of centralized version control systems, where the server is 
assumed to be under the control of a trusted as well as competent party. The 
trust anchor is the repository giving out access, rather than distributed 
repositories exchanging/distributing/propagating change. Rather the artefacts 
are expected to be signed in real-life applications.

Assuming a suitable function to map commits into signable data can be defined, 
changeset signing could be implemented with storage in revision properties. 
This would not even need to be part of the core functionality.

Andreas

Re: SVN Passwd | Authentication issue

[Andreas Stieger]

Hello,

On 21/04/15 18:37, Sivaram Iyer wrote:
 We use plan text passwd file for authentication of users on our SVN
 server. This was working fine until few days ago, then I had to add a
 few new users to the system, and during the process I accidentally
 deleted the passwd file, but managed to recreated the file with all the
 users in it. 
 
 Post the above change, the users are not able to interact with SVN, not
 able to perform any actions on the SVN servers (like Checkout / Commit
 /etc). I have restarted the svnserve daemon after recreating the passwd
 file, but users get the error: Unable to connect to repository at URL
 ... Authentication Failed. 
 
 We directly reach the repository over svn:// protocol, (no http/s), and
 this used to work fine for us, until the above change. 
 
 Any help, much appreciated. 

Please subscribe to and contact the users mailing list, see
http://subversion.apache.org/mailing-lists.html

Andreas

Re: wc-queries-test failures with SQLite 3.8.9

[Andreas Stieger]

Hi,

On 09/04/15 10:37, Bert Huijben wrote:
 On 09/04/15 10:04, Andreas Stieger wrote:
 
 I am getting the following test failures with 1.9.0-beta1 with the very 
 recently released SQLite 3.8.9. I have not yet investigated but will dump 
 the log anyway.
 
 [  875s] [050/110] 
 wc-queries-testFAILURE
 [...]
 [ 4950s] At least one test FAILED, checking 
 /home/abuild/rpmbuild/BUILD/subversion-1.9.0-beta1/tests.log
 [ 4950s] FAIL:  wc-queries-test 3: test query expectations
 [ 4950s] Summary of test results:
 [ 4950s]   2180 tests PASSED
 [ 4950s]   71 tests SKIPPED
 [ 4950s]   45 tests XFAILED (1 WORK-IN-PROGRESS)
 [ 4950s]   1 test FAILED
 [ 4950s] SUMMARY: Some tests failed.
 [ 4950s] 
 [ 4950s] Makefile:521: recipe for target 'check' failed
 [ 4950s] make: *** [check] Error 1
 [ 4950s] + cat fails.log
 [ 4950s] [[[
 [ 4950s] svn_tests: E26: STMT_SELECT_EXTERNALS_DEFINED: Uses externals 
 with only 1 index component: (wc_id=? )
 [ 4950s] SELECT local_relpath, def_local_relpath FROM externals WHERE (wc_id 
 = ?1 AND def_local_relpath = ?2)OR (wc_id = ?1 AND (((def_local_relpath) 
  (CASE (?2) WHEN '' THEN '' ELSE (?2) || '/' END)) AND ((def_local_relpath) 
  CASE (?2) WHEN '' THEN X'' ELSE (?2) || '0' END))) 
 [ 4950s] svn_tests: E200042: Additional errors:
 [ 4950s] svn_tests: E200035: |SEARCH TABLE externals USING COVERING INDEX 
 I_EXTERNALS_DEFINED (wc_id=?)
 [ 4950s] FAIL:  wc-queries-test 3: test query expectations
 [ 4950s] ]]]
 [ 4950s] 
 [ 4950s] + exit 1
 [ 4950s] error: Bad exit status from /var/tmp/rpm-tmp.oHqq5V (%check)
 
 This tells me that it started using the index in a less efficient way...
 Or more precisely a useless way. But as it is just the EXTERNALS table I
 don't think it will really affect end user performance in a measurable way.
 
 We should probably add a new record to the stats table to work around
 this query optimizer change.

I see that 1.8.x affected as well, and can confirm that r1672295 fixes
the test for both 1.8.x and 1.9.x, while not breaking anything. Maybe
propose a backport for previous releases too?

Andreas

wc-queries-test failures with SQLite 3.8.9

[Andreas Stieger]

Hello,

I am getting the following test failures with 1.9.0-beta1 with the very 
recently released SQLite 3.8.9. I have not yet investigated but will dump the 
log anyway.

[  875s] [050/110] 
wc-queries-testFAILURE
[...]
[ 4950s] At least one test FAILED, checking 
/home/abuild/rpmbuild/BUILD/subversion-1.9.0-beta1/tests.log
[ 4950s] FAIL:  wc-queries-test 3: test query expectations
[ 4950s] Summary of test results:
[ 4950s]   2180 tests PASSED
[ 4950s]   71 tests SKIPPED
[ 4950s]   45 tests XFAILED (1 WORK-IN-PROGRESS)
[ 4950s]   1 test FAILED
[ 4950s] SUMMARY: Some tests failed.
[ 4950s] 
[ 4950s] Makefile:521: recipe for target 'check' failed
[ 4950s] make: *** [check] Error 1
[ 4950s] + cat fails.log
[ 4950s] [[[
[ 4950s] svn_tests: E26: STMT_SELECT_EXTERNALS_DEFINED: Uses externals with 
only 1 index component: (wc_id=? )
[ 4950s] SELECT local_relpath, def_local_relpath FROM externals WHERE (wc_id = 
?1 AND def_local_relpath = ?2)OR (wc_id = ?1 AND (((def_local_relpath)  
(CASE (?2) WHEN '' THEN '' ELSE (?2) || '/' END)) AND ((def_local_relpath)  
CASE (?2) WHEN '' THEN X'' ELSE (?2) || '0' END))) 
[ 4950s] svn_tests: E200042: Additional errors:
[ 4950s] svn_tests: E200035: |SEARCH TABLE externals USING COVERING INDEX 
I_EXTERNALS_DEFINED (wc_id=?)
[ 4950s] FAIL:  wc-queries-test 3: test query expectations
[ 4950s] ]]]
[ 4950s] 
[ 4950s] + exit 1
[ 4950s] error: Bad exit status from /var/tmp/rpm-tmp.oHqq5V (%check)

Andreas

flushing caches upon repository replacement - was: Copy and Reduce the size of SVn repos

[Andreas Stieger]

Hello,

On 08/03/15 17:45, Branko Čibej wrote:
 And it bears repeating: If you replace a repository, please make sure to
 restart Apache and/or svnserve to clear stale caches.

Is there something that can be done in the code to take care of that?
Like watching the inode as {uuid,inode}-2-tuple and flush the caches if
it changes?

Andreas

Aw: Status of ctypes-python bindings

[Andreas Stieger]

Hi,

Branko Čibej wrote:
 I've been looking at the ctypes-based Python bindings. They're barely
 maintained; the only changes in the last two years seem to have been
 minor tweaks to make the tests run. I'm also not aware of anyone using
 them, or any packager bundling them.
 
 This was an interesting experiment, but I think it's time to face the
 fact that it failed.
 
 If there are no objections, I propose to remove the ctypes-based
 bindings from trunk (including all related configury and build system
 support) before creating the 1.9 branch.

openSUSE packages them in 1.8 but I am not aware of (people) users of this 
package, and I haven't seen other packages in the distribution using it. 
Somewhat indifferent.

Andreas

Aw: Re: svn commit: r1659397 - in /subversion/trunk: TODO build/ac-macros/swig.m4

[Andreas Stieger]

Hi,

 Gesendet: Donnerstag, 12. Februar 2015 um 21:59 Uhr
 Von: Branko Čibej br...@wandisco.com
 An: dev@subversion.apache.org
 Betreff: Re: svn commit: r1659397 - in /subversion/trunk: TODO 
 build/ac-macros/swig.m4

 On 12.02.2015 21:55, br...@apache.org wrote:
  Author: brane
  Date: Thu Feb 12 20:55:13 2015
  New Revision: 1659397
 
  URL: http://svn.apache.org/r1659397
  Log:
  Do not attempt to build bindings with Swig 3.0+. Current versions
  break the Python bindings.
 
 Heads up for the above; should be in CHANGES, probably. Several people
 have been trying to get our Python bindings to work with Swig 3.0.x,
 without success. Even though the Perl and Ruby bindings work at this
 point with 3.0.5 (at least, they compile and the tests pass), I think
 it's safer to tell people to use Swig 2.x for the time being, until the
 issues with 3.x are resolved.

You surely know that much of your direct code use is from distributions, not 
individuals who build from source. And in their development version there often 
simply isn't such a choice. I have SWIG 3.0.5 in my distribution development 
tree and it is only going forward. The swig project is working on the python 
regressions, and I will patch the svn or swig source to get it all to work. 
Would you not rather want to state that some items are not supported with SWIG 
3.0+ than erroring out altogether? (Which is incorrect by itself because the 
python regression did not occur between 3.0.0 and 3.0.2)

Andreas

[PATCH] Fix swig-py bindings with SWIG 3.0.4

[Andreas Stieger]

Hello,

 I saw build errors in the bindings with SWIG 3.0.4:
 ./subversion/bindings/swig/core.i:792: Error: Unknown SWIG preprocessor
 directive: The (if this is a block of target language code, delimit it
 with %{ and %})

And here is the missing part for proxy.swg for review...

[[[
Follow-up to 1655262,1658347: Fix for python bindings build with Swig 3.0.x

* subversion/bindings/swig/include/proxy.swg:
  Escape comments

Patch by: Dominique Leuenberger dims...@opensuse.org
Found by: me
]]]

AndreasIndex: subversion/bindings/swig/include/proxy.swg
===
--- subversion/bindings/swig/include/proxy.swg	(revision 1658942)
+++ subversion/bindings/swig/include/proxy.swg	(working copy)
@@ -83,13 +83,13 @@
 
 value = _swig_getattr(self, self.__class__, name)
 
-# If we got back a different object than we have, we need to copy all our
-# metadata into it, so that it looks identical
+%{# If we got back a different object than we have, we need to copy all our
+# metadata into it, so that it looks identical%}
 members = self.__dict__.get(_members)
 if members is not None:
   _copy_metadata_deep(value, members.get(name))
 
-# Verify that the new object is good
+%{# Verify that the new object is good}%
 _assert_valid_deep(value)
 
 return value
@@ -98,9 +98,9 @@
 Set an attribute on this object
 self.assert_valid()
 
-# Save a copy of the object, so that the garbage
+%{# Save a copy of the object, so that the garbage
 # collector won't kill the object while it's in
-# SWIG-land
+# SWIG-land%}
 self.__dict__.setdefault(_members,{})[name] = value
 
 return _swig_setattr(self, self.__class__, name, value)

Re: [PATCH] Fix build errors in bindings with SWIG 3.0.4

[Andreas Stieger]

On 28/01/15 15:09, Philip Martin wrote:
 Andreas Stieger andreas.stie...@gmx.de writes:
 
 I will look into that. The odd thing is when I remove the comments,
 check-swig-py trips over a svn_pool_create() call without arguments in
 proxy_apr.swg which looks wrong.
 
 That's python code, not C.  The function is defined earlier in the file
 and forwards to _core.svn_pool_create.  What error do you get?

When removing comments which throw SWIG 3.0.4 errors as this:

$ svn diff --cl swig -x-p
Index: subversion/bindings/swig/include/proxy.swg
===
--- subversion/bindings/swig/include/proxy.swg  (revision 1655671)
+++ subversion/bindings/swig/include/proxy.swg  (working copy)
@@ -83,13 +83,10 @@

 value = _swig_getattr(self, self.__class__, name)

-# If we got back a different object than we have, we need to copy
all our
-# metadata into it, so that it looks identical
 members = self.__dict__.get(_members)
 if members is not None:
   _copy_metadata_deep(value, members.get(name))

-# Verify that the new object is good
 _assert_valid_deep(value)

 return value
@@ -98,9 +95,6 @@
 Set an attribute on this object
 self.assert_valid()

-# Save a copy of the object, so that the garbage
-# collector won't kill the object while it's in
-# SWIG-land
 self.__dict__.setdefault(_members,{})[name] = value

 return _swig_setattr(self, self.__class__, name, value)
Index: subversion/bindings/swig/svn_delta.i
===
--- subversion/bindings/swig/svn_delta.i(revision 1655671)
+++ subversion/bindings/swig/svn_delta.i(working copy)
@@ -206,8 +206,6 @@ void _ops_get(int *num_ops, const svn_txdelta_op_t

 #ifdef SWIGPYTHON
 %pythoncode {
-# This function is for backwards compatibility only.
-# Use svn_txdelta_window_t.ops instead.
 svn_txdelta_window_t_ops_get = svn_txdelta_window_t._ops_get
 }
 #endif


I get the following error:

 $ nice make -j2 swig-py  nice make -j2 check-swig-py
 if [ LD_LIBRARY_PATH = DYLD_LIBRARY_PATH ]; then for d in 
 ~/subversion/subversion/bindings/swig/python/libsvn_swig_py 
 ~/subversion/subversion/bindings/swig/python/../../../libsvn_*; do if [ -n 
 $DYLD_LIBRARY_PATH ]; then LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$d/.libs; 
 else LD_LIBRARY_PATH=$d/.libs; fi; done; export LD_LIBRARY_PATH; fi; \
 cd ~/subversion/subversion/bindings/swig/python; \
   /usr/bin/python 
 ~/subversion/subversion/bindings/swig/python/tests/run_all.py
 Traceback (most recent call last):
   File ~/subversion/subversion/bindings/swig/python/tests/run_all.py, line 
 22, in module
 import mergeinfo, core, client, delta, checksum, pool, ra, wc, 
 repository, \
   File ~/subversion/subversion/bindings/swig/python/tests/mergeinfo.py, 
 line 22, in module
 from svn import core, repos, fs
   File ~/subversion/subversion/bindings/swig/python/svn/core.py, line 26, 
 in module
 from libsvn.core import *
   File ~/subversion/subversion/bindings/swig/python/libsvn/core.py, line 
 6386, in module
 svn_pool_create()
 TypeError: svn_pool_create() takes exactly 2 arguments (0 given)
 make: *** [check-swig-py] Error 1

Andreas

Re: [PATCH] Fix build errors in bindings with SWIG 3.0.4

[Andreas Stieger]

Hi,

On 29/01/15 16:05, Philip Martin wrote:
 Andreas Stieger andreas.stie...@gmx.de writes:
 
 When removing comments which throw SWIG 3.0.4 errors as this:
 
 What errors do you get if you leave the comments in?  We don't really
 want to delete the comments from our source code.  

 [  479s] ./subversion/bindings/swig/core.i:792: Error: Unknown SWIG 
 preprocessor directive: The (if this is a block of target language code, 
 delimit it with %{ and %})
 [  479s] ./subversion/bindings/swig/core.i:793: Error: Unknown SWIG 
 preprocessor directive: reference (if this is a block of target language 
 code, delimit it with %{ and %})
 [  479s] ./subversion/bindings/swig/core.i:794: Error: Unknown SWIG 
 preprocessor directive: references (if this is a block of target language 
 code, delimit it with %{ and %})
 [  479s] ./subversion/bindings/swig/core.i:795: Error: Unknown SWIG 
 preprocessor directive: keeping (if this is a block of target language code, 
 delimit it with %{ and %})
 [  479s] 
 /home/abuild/rpmbuild/BUILD/subversion-1.8.11/subversion/bindings/swig/include/proxy.swg:86:
  Error: Unknown SWIG preprocessor directive: If (if this is a block of target 
 language code, delimit it with %{ and %})
 [  479s] 
 /home/abuild/rpmbuild/BUILD/subversion-1.8.11/subversion/bindings/swig/include/proxy.swg:87:
  Error: Unknown SWIG preprocessor directive: metadata (if this is a block of 
 target language code, delimit it with %{ and %})
[...]

 Which version of Python are you using?

Seen with 2.7.9, 2.7.8, 2.7.7, 2.7.5, 2.6.8 when using SWIG 3.0.4, but
not SWIG 2.

Andreas

Re: [PATCH] Fix build errors in bindings with SWIG 3.0.4

[Andreas Stieger]

 Hi,

On 28/01/15 12:39, Bert Huijben wrote:
 I applied a patch similar to the first hunk in r1655262, as this file is 
 processed mostly as C code.
 
 I'm not sure about the other hunks. It looks like they could be processed as 
 python where the other syntax is preferred.

I will look into that. The odd thing is when I remove the comments,
check-swig-py trips over a svn_pool_create() call without arguments in
proxy_apr.swg which looks wrong.

http://svn.apache.org/viewvc/subversion/trunk/subversion/bindings/swig/include/proxy_apr.swg?revision=1573006view=markup#l214

Andreas

[PATCH] Fix build errors in bindings with SWIG 3.0.4

[Andreas Stieger]

Hello,

I saw build errors in the bindings with SWIG 3.0.4:
./subversion/bindings/swig/core.i:792: Error: Unknown SWIG preprocessor
directive: The (if this is a block of target language code, delimit it
with %{ and %})

The attached patch fixes the comment style issue in trunk and 1.8.x.

[[[
Fix build errors in bindings with SWIG 3.0.4

* subversion/bindings/swig/core.i
  (core_set_current_pool): Fix comment style.

* subversion/bindings/swig/include/proxy.swg
  (__getattr__,__setattr__): Same.

* subversion/bindings/swig/svn_delta.i
  (_ops_get): Same.
]]]

With kind regards,
Andreas Stieger
Index: subversion/bindings/swig/core.i
===
--- subversion/bindings/swig/core.i	(revision 1654697)
+++ subversion/bindings/swig/core.i	(working copy)
@@ -800,10 +800,11 @@ core_set_current_pool (apr_pool_t *pool)
 #endif
 
 #ifdef SWIGPYTHON
-# The auth baton depends on the providers, so we preserve a
-# reference to them inside the wrapper. This way, if all external
-# references to the providers are gone, they will still be alive,
-# keeping the baton valid.
+/* The auth baton depends on the providers, so we preserve a
+ * reference to them inside the wrapper. This way, if all external
+ * references to the providers are gone, they will still be alive,
+ * keeping the baton valid.
+ */
 %feature(pythonappend) svn_auth_open %{
   val.__dict__[_deps] = list(args[0])
 %}
Index: subversion/bindings/swig/include/proxy.swg
===
--- subversion/bindings/swig/include/proxy.swg	(revision 1654697)
+++ subversion/bindings/swig/include/proxy.swg	(working copy)
@@ -83,13 +83,14 @@
 
 value = _swig_getattr(self, self.__class__, name)
 
-# If we got back a different object than we have, we need to copy all our
-# metadata into it, so that it looks identical
+/* If we got back a different object than we have, we need to copy all our
+ * metadata into it, so that it looks identical
+ */
 members = self.__dict__.get(_members)
 if members is not None:
   _copy_metadata_deep(value, members.get(name))
 
-# Verify that the new object is good
+// Verify that the new object is good
 _assert_valid_deep(value)
 
 return value
@@ -98,9 +99,10 @@
 Set an attribute on this object
 self.assert_valid()
 
-# Save a copy of the object, so that the garbage
-# collector won't kill the object while it's in
-# SWIG-land
+/* Save a copy of the object, so that the garbage
+ * collector won't kill the object while it's in
+ * SWIG-land
+ */
 self.__dict__.setdefault(_members,{})[name] = value
 
 return _swig_setattr(self, self.__class__, name, value)
Index: subversion/bindings/swig/svn_delta.i
===
--- subversion/bindings/swig/svn_delta.i	(revision 1654697)
+++ subversion/bindings/swig/svn_delta.i	(working copy)
@@ -206,8 +206,9 @@ void _ops_get(int *num_ops, const svn_txdelta_op_t
 
 #ifdef SWIGPYTHON
 %pythoncode {
-# This function is for backwards compatibility only.
-# Use svn_txdelta_window_t.ops instead.
+/* This function is for backwards compatibility only.
+ * Use svn_txdelta_window_t.ops instead.
+ */
 svn_txdelta_window_t_ops_get = svn_txdelta_window_t._ops_get
 }
 #endif

Aw: Re: IndexError: list index out of range: [serf 1.3.8]

[Andreas Stieger]

Mohsin,

Mohsin mohsinchan...@gmail.com wrote:
 I am able to compile svn V 1.8.10 with serf 1.3.8 on solaris machine .

As you contacted users@, dev@ and the serf bug tracker (without searching it),
as per [1], would you summarize the solution details to the users mailing list
for the next person asking?

[1] http://www.catb.org/esr/faqs/smart-questions.html#followup

Andreas

[PATCH] Remove bashism in mailer.py test suite

[Andreas Stieger]

Hello,

I received the attached patch from a distribution package
user/contributor. This looks good to me and I would like to commit this?

[[[
Remove bashism in mailer.py test suite

* mailer/tests/mailer-init.sh
  Change echo -e to more portable printf

Patch by: Oleksandr Chumachenko led...@gmail.com
]]]

Andreas
[[[
Remove bashism in mailer.py test suite

* mailer/tests/mailer-init.sh
  Change echo -e to more portable printf

Patch by: Oleksandr Chumachenko led...@gmail.com

]]]

Index: tools/hook-scripts/mailer/tests/mailer-init.sh
===
--- tools/hook-scripts/mailer/tests/mailer-init.sh	(revision 1640778)
+++ tools/hook-scripts/mailer/tests/mailer-init.sh	(working copy)
@@ -101,7 +101,7 @@ echo change C6  dir6/file4
 svn commit -m copy dir, then make a change
 
 # add a binary file and set property to binary value
-echo -e \x00\x01\x02\x03\x04  file11
+printf \x00\x01\x02\x03\x04\n  file11
 svn add file11
 svn ps svn:mime-type application/octect-stream file11
 svn ps prop2 -F file11 file9 
@@ -108,7 +108,7 @@ svn ps prop2 -F file11 file9
 svn commit -m add binary file
 
 # change the binary file and set property to non binary value
-echo -e \x20\x01\x02\x20  file11
+printf \x20\x01\x02\x20\n  file11
 svn ps prop2 propval2 file9 
 svn commit -m change binary file
 

Re: Code signing service now available

[Andreas Stieger]

Hello,

On 18 Nov 2014, at 04:00, Greg Stein gst...@gmail.com wrote:

 Do we want to begin signing our Windows releases?

Isn't that only useful/supported for binaries and installers, releases of which 
are not done by this project?

Andreas

svn auth help text review

[Andreas Stieger]

Hi,

the svn help auth text reads as follows:

 Manage cached authentication credentials.\n
 usage: 1. svn auth [PATTERN ...]\n
 usage: 2. svn auth --remove PATTERN [PATTERN ...]\n
 \n
   With no arguments, list all cached authentication credentials.\n
   Authentication credentials include usernames, passwords,\n
   SSL certificates, and SSL client-certificate passphrases.\n

And fingerprints? Is that missing? r1573701 speaks about them.

   If PATTERN is specified, only list credentials with attributes matching 
 one\n
   or more patterns. With the --remove option, remove cached authentication\n
   credentials matching one or more patterns.\n

So that's an OR match for patterns given?

   If more than one pattern is specified credentials are considered only they\n
   match all specified patterns. 

That specifies an AND match, and is not how I read match_credential() in
auth_cmd.c. Could you clarify?

 Patterns are matched case-sensitively and may\n

r1573701 switched on case-insensitively for SSL hostnames and
fingerprints. Could you clarify?

Thanks,
Andreas

[PATCH] svn-bench help output

[Andreas Stieger]

Hello,

please review the attached patch for the svn-bench output. This file
probably started life as a copy of it's svn equivalent.


[[[
Apply equivalent change to r1522518 to svn-bench help output

* subversion/svn/help-cmd.c
  (svn_cl__help): No not show the version number in help output as
--version is provided. Name it Subversion benchmarking tool.

]]]

With kind regards,
Andreas Stieger
Index: subversion/svn-bench/help-cmd.c
===
--- subversion/svn-bench/help-cmd.c	(revision 1637176)
+++ subversion/svn-bench/help-cmd.c	(working copy)
@@ -45,10 +45,9 @@ svn_cl__help(apr_getopt_t *os,
 {
   svn_cl__opt_state_t *opt_state;
 
-  /* xgettext: the %s is for SVN_VER_NUMBER. */
-  char help_header_template[] =
+  char help_header[] =
   N_(usage: svn-bench subcommand [options] [args]\n
- Subversion command-line client, version %s.\n
+ Subversion benchmarking tool.\n
  Type 'svn-bench help subcommand' for help on a specific subcommand.\n
  Type 'svn-bench --version' to see the program version and RA modules\n
or 'svn-bench --version --quiet' to see just the version number.\n
@@ -63,9 +62,6 @@ svn_cl__help(apr_getopt_t *os,
   N_(Subversion is a tool for version control.\n
  For additional information, see http://subversion.apache.org/\n;);
 
-  char *help_header =
-apr_psprintf(pool, _(help_header_template), SVN_VER_NUMBER);
-
   const char *ra_desc_start
 = _(The following repository access (RA) modules are available:\n\n);
 

[PATCH] svnadmin delrevprop and setrevprop parameters

[Andreas Stieger]

Hello,

svnadmin help setrevprop in trunk is missing the NAME parameter. The
attached patch restores this, and also orders the parameters to match
the other subcommands.

[[[
Follow-up to r1631446, add missing NAME to svnadmin help setrevprop

* subversion/svnadmin/svnadmin.c
  (cmd_table): Restore previous order for delrevprop. For setrevprop,
same, and add missing NAME
]]]
Index: subversion/svnadmin/svnadmin.c
===
--- subversion/svnadmin/svnadmin.c	(revision 1637176)
+++ subversion/svnadmin/svnadmin.c	(working copy)
@@ -358,8 +358,8 @@ static const svn_opt_subcommand_desc2_t cmd_table[
 } },
 
   {delrevprop, subcommand_delrevprop, {0}, N_
-   (usage: 1. svnadmin delrevprop -r REVISION REPOS_PATH NAME\n
-   2. svnadmin delrevprop -t TXN REPOS_PATH NAME\n\n
+   (usage: 1. svnadmin delrevprop REPOS_PATH -r REVISION NAME\n
+   2. svnadmin delrevprop REPO_PATH -t TXN NAME\n\n
 1. Delete the property NAME on revision REVISION.\n\n
 Use --use-pre-revprop-change-hook/--use-post-revprop-change-hook to\n
 trigger the revision property-related hooks (for example, if you want\n
@@ -499,8 +499,8 @@ static const svn_opt_subcommand_desc2_t cmd_table[
{'r', svnadmin__bypass_hooks} },
 
   {setrevprop, subcommand_setrevprop, {0}, N_
-   (usage: 1. svnadmin setrevprop -r REVISION REPOS_PATH FILE\n
-   2. svnadmin setrevprop -t TXN REPOS_PATH FILE\n\n
+   (usage: 1. svnadmin setrevprop REPOS_PATH -r REVISION NAME FILE\n
+   2. svnadmin setrevprop REPOS_PATH -t TXN NAME FILE\n\n
 1. Set the property NAME on revision REVISION to the contents of FILE.\n\n
 Use --use-pre-revprop-change-hook/--use-post-revprop-change-hook to\n
 trigger the revision property-related hooks (for example, if you want\n

Re: Our website is broken

[Andreas Stieger]

Hi,

On 03/11/14 19:25, Ben Reser wrote:
 On 11/3/14 11:09 AM, Mark Phippard wrote:
 Assume it is just not for me, but our menu does not appear.

 http://subversion.apache.org

 Server-side includes not working I would guess?
 
 Working for me.

Depending on which back-end is hit, the content below is incorrectly
delivered. Corr: now always. I have first seen this late last week.

 body
 !--#include virtual=/site-banner.html --
 !--#include virtual=/site-nav.html --
 div id=site-content
 !--#include virtual=/site-notice.html --

Andreas

Re: No no-op changes

[Andreas Stieger]

 On 19 Sep 2014, at 15:49, Julian Foad julianf...@btopenworld.com wrote:
 
 Summary:
   * A no-op change is not a change.
   * Subversion should not report a no-op change as a change.
   * We should bear this in mind when designing and reviewing.
   * Fixes are needed in a few places.

These no-op change scenarios come to mind:
* partial repository replication via svnsync due to visibility
* empty revisions via svndumpfilter
* dumps with no-op changes would become invalid?

Andreas

Re: [PATCH] add missing Language description for gettext-0.19

[Andreas Stieger]

Hello,

On 03/06/14 13:46, Lars Wendler wrote:
 msgfmt from gettext-0.19 fails if a po file doesn't have a valid 
 Language section. -Language: \n +Language: zh_TW\n

This might be relevant:
https://lists.gnu.org/archive/html/bug-gettext/2014-06/msg7.html

gnu Apparently, 0.19 is a bit of brown bag release as it got a few
major
gnu issues (including [1]) and some silly mistakes in packaging.  So,
I plan
gnu to make a bug fix release this week.
gnu
gnu Distribution packagers are advised to import this package into your
gnu development tree only and wait for 0.19.1.
gnu
gnu [1]
https://lists.fedoraproject.org/pipermail/devel/2014-June/199539.html

Thanks for the patch, committed in r1599776 invoking the obvious fix
rule. All other po files are fine.

Regards,
Andreas

[PATCH] Fix xgettext warnings and incomplete format strings due to macros

[Andreas Stieger]

Hi,

Scanning the translations template file fails due to APR_UINT64_T_FMT
being used as is in format strings. This is from r1575628 (fsfs l2p
index), also from log-addressing branch, and r1595579 (sync of same to
FSX). While this works at execution time (modulo actually translating),
xgettext cannot handle that:

 make locale-gnu-pot
 Building subversion.pot...
 ../libsvn_fs_fs/index.c:597: warning: Although being used in a format string 
 position, the msgid is not a valid C format string. Reason: The string ends 
 in the middle of a directive.
 ../libsvn_fs_fs/index.c:657: warning: Although being used in a format string 
 position, the msgid is not a valid C format string. Reason: The string ends 
 in the middle of a directive.
 ../libsvn_fs_fs/cached_data.c:944: warning: Although being used in a format 
 string position, the msgid is not a valid C format string. Reason: The string 
 ends in the middle of a directive.
etc.

Please review the attached patch. It basically wraps the
APR_UINT64_T_FMT into a call to apr_psprintf. The introduction of a pool
parameter to some private functions seems necessary.

[[[
Fix xgettext warnings and incomplete format strings due to macros

* subversion/libsvn_fs_fs/cached_data.c
  (svn_fs_fs__check_rep): make xgettext friendly by printing the
   format string macro separately

* subversion/libsvn_fs_x/cached_data.c
  (svn_fs_x__check_rep): same

* subversion/libsvn_fs_fs/index.c
  (svn_fs_fs__l2p_index_create): same x2
  (l2p_page_info_copy,l2p_page_get_entry): same, and grow pool
   parameters to support it
  (l2p_page_info_access_func,get_l2p_page_info): update calls to
   l2p_page_info_copy to pass a pool
  (l2p_entry_access_func,l2p_index_lookup): update calls to
   l2p_page_get_entry to pass a pool

* subversion/libsvn_fs_x/index.c
  (svn_fs_x__l2p_index_create): make xgettext friendly by printing
   the format string macro separately
  (l2p_header_copy): same, and grow a pool parameter to support it
  (l2p_header_access_func,get_l2p_page_info): update calls to
   l2p_header_copy to pass a pool
]]]

With kind regards,
Andreas Stieger
Index: subversion/libsvn_fs_fs/cached_data.c
===
--- subversion/libsvn_fs_fs/cached_data.c	(revision 1598897)
+++ subversion/libsvn_fs_fs/cached_data.c	(working copy)
@@ -941,9 +941,10 @@ svn_fs_fs__check_rep(representation_t *rep,
   || entry-type  SVN_FS_FS__ITEM_TYPE_FILE_REP
   || entry-type  SVN_FS_FS__ITEM_TYPE_DIR_PROPS)
 return svn_error_createf(SVN_ERR_REPOS_CORRUPTED, NULL,
- _(No representation found at offset %s 
-   for item % APR_UINT64_T_FMT
-in revision %ld),
+ apr_psprintf(pool,
+   _(No representation found at offset %%s 
+ for item %%%s in revision %%ld),
+ APR_UINT64_T_FMT),
  apr_off_t_toa(pool, offset),
  rep-item_index, rep-revision);
 
Index: subversion/libsvn_fs_fs/index.c
===
--- subversion/libsvn_fs_fs/index.c	(revision 1598897)
+++ subversion/libsvn_fs_fs/index.c	(working copy)
@@ -594,8 +594,10 @@ svn_fs_fs__l2p_index_create(svn_fs_t *fs,
* The current implementation is limited to 2G entries per page. */
   if (ffd-l2p_page_size  APR_INT32_MAX)
 return svn_error_createf(SVN_ERR_FS_ITEM_INDEX_OVERFLOW , NULL,
-_(L2P index page size  % APR_UINT64_T_FMT
-   exceeds current limit of 2G entries),
+apr_psprintf(pool,
+  _(L2P index page size  %%%s 
+ exceeds current limit of 2G entries),
+APR_UINT64_T_FMT),
 ffd-l2p_page_size);
 
   /* start at the beginning of the source file */
@@ -654,9 +656,10 @@ svn_fs_fs__l2p_index_create(svn_fs_t *fs,
   /* store the mapping in our array */
   if (proto_entry.item_index  APR_INT32_MAX)
 return svn_error_createf(SVN_ERR_FS_ITEM_INDEX_OVERFLOW , NULL,
-_(Item index % APR_UINT64_T_FMT
-   too large in l2p proto index for
-   revision %ld),
+apr_psprintf(pool,
+  _(Item index %%%s too large 
+in l2p proto index for revision %%ld),
+APR_UINT64_T_FMT),
 proto_entry.item_index,
 revision + page_counts-nelts);
 
@@ -900,7 +903,8 @@ static svn_error_t *
 l2p_page_info_copy

Re: [PATCH] fix potentially undefined operation warning

[Andreas Stieger]

Hi,

 On 15 May 2014, at 15:49, Branko Čibej br...@wandisco.com wrote:
 
 Good catch, the result of these operations is indeed undefined, according to 
 the C standard.
 However, I don't know if your fix is correct ... the other interpretation is:
 
 foo(data, data + 1);
 ++data;
 
 The author of this code should have a look and decide which interpretation he 
 meant.

I think he has. Further, the call is to svn__base36toui64() which, if I read 
correctly, uses the pointer as a return, e.g. in this case it does not matter 
whether the first parameter was incremented. Never versions of gcc might detect 
this and not warn?

Andreas 

[PATCH] fix potentially undefined operation warning

[Andreas Stieger]

Hello,

I found a compiler warning in trunk on a potentially undefined operation
when using an increment operator on a variable referenced in the same
expression. This is on gcc 4.3.4, does not happen in gcc 4.7 and up.
Treated as an error in some build configurations.

subversion/libsvn_fs_fs/id.c: In function 'txn_id_parse':
subversion/libsvn_fs_fs/id.c:98: warning: operation on 'data' may be
undefined

subversion/libsvn_fs_fs/transaction.c: In function 'read_next_ids':
subversion/libsvn_fs_fs/transaction.c:1300: warning: operation on 'str'
may be undefined

subversion/libsvn_fs_x/transaction.c: In function 'read_next_ids':
subversion/libsvn_fs_x/transaction.c:1354: warning: operation on 'str'
may be undefined

The attached patch fixes this, please review.

[[[
Fix warnings for potentially undefined operation.

Some code uses increment operators on variables referenced in the same
operation. See fsfs-improvements branch (r1517479,1506545) and
fsfs-format-7 (r1453765)

* subversion/libsvn_fs_fs/id.c
  (txn_id_parse): increment data pointer in a separate statement
* subversion/libsvn_fs_fs/transaction.c
  (read_next_ids): increment str pointer in a separate statement
* subversion/libsvn_fs_x/transaction.c
  (read_next_ids): same
]]]

With kind regards,
Andreas Stieger
Index: subversion/libsvn_fs_fs/id.c
===
--- subversion/libsvn_fs_fs/id.c	(revision 1593690)
+++ subversion/libsvn_fs_fs/id.c	(working copy)
@@ -95,7 +95,8 @@ txn_id_parse(svn_fs_fs__id_part_t *txn_id,
   if (data == NULL)
 return FALSE;
   
-  txn_id-number = svn__base36toui64(data, ++data);
+  data++;  
+  txn_id-number = svn__base36toui64(data, data);
   return *data == '\0';
 }
 
Index: subversion/libsvn_fs_fs/transaction.c
===
--- subversion/libsvn_fs_fs/transaction.c	(revision 1593690)
+++ subversion/libsvn_fs_fs/transaction.c	(working copy)
@@ -1348,7 +1348,8 @@ read_next_ids(apr_uint64_t *node_id,
 return svn_error_create(SVN_ERR_FS_CORRUPT, NULL,
 _(next-id file corrupt));
 
-  *copy_id = svn__base36toui64(str, ++str);
+  str++;
+  *copy_id = svn__base36toui64(str, str);
   if (*str != '\n')
 return svn_error_create(SVN_ERR_FS_CORRUPT, NULL,
 _(next-id file corrupt));
Index: subversion/libsvn_fs_x/transaction.c
===
--- subversion/libsvn_fs_x/transaction.c	(revision 1593690)
+++ subversion/libsvn_fs_x/transaction.c	(working copy)
@@ -1352,7 +1352,8 @@ read_next_ids(apr_uint64_t *node_id,
 return svn_error_create(SVN_ERR_FS_CORRUPT, NULL,
 _(next-id file corrupt));
 
-  *copy_id = svn__base36toui64(str, ++str);
+  str++;
+  *copy_id = svn__base36toui64(str, str);
   if (*str != '\n')
 return svn_error_create(SVN_ERR_FS_CORRUPT, NULL,
 _(next-id file corrupt));

Re: 1.9.0-alpha2 up for testing/signing

[Andreas Stieger]

A good audience for these are distribution package maintainers and integrators. 
If you could bump all build dependencies to close to what you are planning (as 
in configure, INSTALL) that will be fab.

Andreas

 On 2 Apr 2014, at 12:15, Julian Foad julianf...@btopenworld.com wrote:
 
 Ivan Zhakov wrote:
 I didn't vote for 1.9.0-alpha2 because I believe that current trunk
 should not be released even with alpha label. [...]
 
 Hi, Ivan.
 
 I agree with some of what you say, but not all of it.
 
 The only big feature is fsfs7, but the past shows that users even
 didn't try Subversion on client before final release, so expecting
 that some sysadmin will try alpha on server doesn't make sense.
 
 It's true that users don't test alpha releases very much. I believe you 
 that sysadmins will test the server side even less. But I don't agree 
 that expecting that some sysadmin will try alpha on server doesn't make
 sense. If we don't release it, then nobody will try it; if we do 
 release it, then some sysadmin *might* try it.
 
 There must be at least 
 thousands of sysadmins running Subversion, some of whom will see the 
 alpha release. It's not totally unreasonable that some might test it.
 
 Even more I believe that fsfs7 stuff and log addressing stuff should
 be reverted from trunk and such significant fsfs format changes should
 be implemented in fsx to give users a choice: use stable and proven
 format or something really new and never tested.
 
 I agree users must always have the option of a server that's stable and 
 proven. I take your concern seriously, but I look at it in a different way. 
 You're proposing that users should have the following options:
 
   * experimental (1.9 FSX, lots of new stuff)
 
   * stable (1.9 FSFS, approximately same as 1.8, minor changes)
 
 Users already have a stable server: it's called 1.8, or 1.7 or whatever 
 version has been around for long enough to satisfy their definition of 
 stable.
 
 So another way of looking at the options that we can provide is:
 
   * experimental (1.9 FSX, lots of new stuff)
 
   * latest (1.9.0 FSFS, a balance between significant improvements and 
 reasonable stability)
 
   * very stable (1.8.x series, for now, until a year or so has passed and the 
 user then considers the 1.9.x series to be very stable)
 
 It seems that we're currently looking at the user's options that second way. 
 And that seems OK to me.
 
 - Julian
 

Re: 1.9.0-alpha2 up for testing/signing

[Andreas Stieger]

Hello,

On 02/04/14 17:06, Ben Reser wrote:
 On 4/2/14, 4:20 AM, Andreas Stieger wrote:
 A good audience for these are distribution package maintainers and 
 integrators. If you could bump all build dependencies to close to what you 
 are planning (as in configure, INSTALL) that will be fab.
 
 We did indeed do this with 1.9.0-alpha2.  It requires APR/APR-Util 1.3.x and
 Serf 1.3.4.

Yes, works fine with tests for my packages.

Andreas

Re: I'm getting 'make check' test failures with 1.7.14 1.7.16 releases ...

[Andreas Stieger]

Hi,

On 07/03/14 18:51, Alan Nexus wrote:
 Is anyone else getting them?

No. You have not told mentioned what the failures are. See
http://www.catb.org/esr/faqs/smart-questions.html

 Does anyone care that they work?

Yes. The full test suite is run successfully many times by project
contributors, downstream packagers and vendors as well as members of the
public. In fact, every release requires verification of release
artifacts and tests by several people on multiple platforms. You may be
running the tests incorrectly, or miss some required configuration. Some
pointers:
https://subversion.apache.org/docs/community-guide/building.html
https://svn.apache.org/repos/asf/subversion/trunk/subversion/tests/README
https://svn.apache.org/repos/asf/subversion/trunk/subversion/tests/cmdline/README

Your question on getting the test suite to work may be better suited for
the users@ list. https://subversion.apache.org/mailing-lists.html
If after getting a test suite to work in general you have specific test
failures that can be attributed to a concrete issue, please report back
with the source revision built, your configuration options, the build
commands used, the specific output and the contents of fails.log.

Have fun,
Andreas

[PATCH] Ensure full distribution description is printed in svn --version -v

[Andreas Stieger]

Hello,

found a string handling issue:
$ svn --version -v
[...]
  - openSUSE 12 (Mantis) [Linux 3.4.63-2.44-desktop]
[...] ^^^
This when lsb_release -a clearly contains:
Description:openSUSE 12.2 (i586)

Turns out stringbuf_split_key calculates the buffer length incorrectly,
causing the distribution name to be cut off after the length of the
label instead of the remaining string, in this case 11 characters. Patch
attached.

[[[
Ensure full distribution description is printed in svn --version -v

* subversion/libsvn_subr/sysinfo.c
  (stringbuf_split_key): fix buffer length calculation
]]]

With kind regards,
Andreas Stieger
Index: subversion/libsvn_subr/sysinfo.c
===
--- subversion/libsvn_subr/sysinfo.c	(revision 1544877)
+++ subversion/libsvn_subr/sysinfo.c	(working copy)
@@ -285,7 +285,7 @@ stringbuf_split_key(svn_stringbuf_t *buffer, char
   key = buffer-data;
   end = strchr(key, delim);
   *end = '\0';
-  buffer-len = 1 + end - key;
+  buffer-len -= 1 + end - key;
   buffer-data = end + 1;
   svn_stringbuf_strip_whitespace(buffer);
 

Re: [PATCH] initialize some variables in test to prevent -Wmaybe-uninitialized

[Andreas Stieger]

Hello,

thanks for review. I get the comments about this being a rather
unimportant warning as it's all test code, but still less warnings are
better. Updated patch with TRUE/FALSE attached.

[[[
* subversion/tests/libsvn_fs/fs-test.c
  (check_entry_present, check_entry_absent),
* subversion/tests/libsvn_fs_base/fs-base-test.c
  (check_entry_present, check_entry_absent, check_id_present,
  check_id_absent): initialize variable present to silence
  warning -Wmaybe-uninitialized
]]]

Andreas
Index: subversion/tests/libsvn_fs/fs-test.c
===
--- subversion/tests/libsvn_fs/fs-test.c	(revision 1543573)
+++ subversion/tests/libsvn_fs/fs-test.c	(working copy)
@@ -1020,7 +1020,7 @@ static svn_error_t *
 check_entry_present(svn_fs_root_t *root, const char *path,
 const char *name, apr_pool_t *pool)
 {
-  svn_boolean_t present;
+  svn_boolean_t present = FALSE;
   SVN_ERR(check_entry(root, path, name, present, pool));
 
   if (! present)
@@ -1037,7 +1037,7 @@ static svn_error_t *
 check_entry_absent(svn_fs_root_t *root, const char *path,
const char *name, apr_pool_t *pool)
 {
-  svn_boolean_t present;
+  svn_boolean_t present = TRUE;
   SVN_ERR(check_entry(root, path, name, present, pool));
 
   if (present)
Index: subversion/tests/libsvn_fs_base/fs-base-test.c
===
--- subversion/tests/libsvn_fs_base/fs-base-test.c	(revision 1543573)
+++ subversion/tests/libsvn_fs_base/fs-base-test.c	(working copy)
@@ -124,7 +124,7 @@ static svn_error_t *
 check_entry_present(svn_fs_root_t *root, const char *path,
 const char *name, apr_pool_t *pool)
 {
-  svn_boolean_t present;
+  svn_boolean_t present = FALSE;
   SVN_ERR(check_entry(root, path, name, present, pool));
 
   if (! present)
@@ -141,7 +141,7 @@ static svn_error_t *
 check_entry_absent(svn_fs_root_t *root, const char *path,
const char *name, apr_pool_t *pool)
 {
-  svn_boolean_t present;
+  svn_boolean_t present = TRUE;
   SVN_ERR(check_entry(root, path, name, present, pool));
 
   if (present)
@@ -213,7 +213,7 @@ check_id(svn_fs_t *fs, const svn_fs_id_t *id, svn_
 static svn_error_t *
 check_id_present(svn_fs_t *fs, const svn_fs_id_t *id, apr_pool_t *pool)
 {
-  svn_boolean_t present;
+  svn_boolean_t present = FALSE;
   SVN_ERR(check_id(fs, id, present, pool));
 
   if (! present)
@@ -233,7 +233,7 @@ check_id_present(svn_fs_t *fs, const svn_fs_id_t *
 static svn_error_t *
 check_id_absent(svn_fs_t *fs, const svn_fs_id_t *id, apr_pool_t *pool)
 {
-  svn_boolean_t present;
+  svn_boolean_t present = TRUE;
   SVN_ERR(check_id(fs, id, present, pool));
 
   if (present)

[PATCH] initialize some variables in test to prevent -Wmaybe-uninitialized

[Andreas Stieger]

Hello,

just noticed some warnings:
subversion/tests/libsvn_fs_base/fs-base-test.c:239:6: warning: 'present'
may be used uninitialized in this function [-Wmaybe-uninitialized] et
al. Initializing to boolean value that would fail the test if the
reference wasn't changed in called function at all.

[[[
* subversion/tests/libsvn_fs/fs-test.c
  (check_entry_present, check_entry_absent),
  subversion/tests/libsvn_fs_base/fs-base-test.c
  (check_entry_present, check_entry_absent, check_id_present,
  check_id_absent): initialize variable present to silence
  warning -Wmaybe-uninitialized
]]]

Andreas
Index: subversion/tests/libsvn_fs/fs-test.c
===
--- subversion/tests/libsvn_fs/fs-test.c	(revision 1542431)
+++ subversion/tests/libsvn_fs/fs-test.c	(working copy)
@@ -1020,7 +1020,7 @@ static svn_error_t *
 check_entry_present(svn_fs_root_t *root, const char *path,
 const char *name, apr_pool_t *pool)
 {
-  svn_boolean_t present;
+  svn_boolean_t present = false;
   SVN_ERR(check_entry(root, path, name, present, pool));
 
   if (! present)
@@ -1037,7 +1037,7 @@ static svn_error_t *
 check_entry_absent(svn_fs_root_t *root, const char *path,
const char *name, apr_pool_t *pool)
 {
-  svn_boolean_t present;
+  svn_boolean_t present = true;
   SVN_ERR(check_entry(root, path, name, present, pool));
 
   if (present)
Index: subversion/tests/libsvn_fs_base/fs-base-test.c
===
--- subversion/tests/libsvn_fs_base/fs-base-test.c	(revision 1542431)
+++ subversion/tests/libsvn_fs_base/fs-base-test.c	(working copy)
@@ -124,7 +124,7 @@ static svn_error_t *
 check_entry_present(svn_fs_root_t *root, const char *path,
 const char *name, apr_pool_t *pool)
 {
-  svn_boolean_t present;
+  svn_boolean_t present = false;
   SVN_ERR(check_entry(root, path, name, present, pool));
 
   if (! present)
@@ -141,7 +141,7 @@ static svn_error_t *
 check_entry_absent(svn_fs_root_t *root, const char *path,
const char *name, apr_pool_t *pool)
 {
-  svn_boolean_t present;
+  svn_boolean_t present = true;
   SVN_ERR(check_entry(root, path, name, present, pool));
 
   if (present)
@@ -213,7 +213,7 @@ check_id(svn_fs_t *fs, const svn_fs_id_t *id, svn_
 static svn_error_t *
 check_id_present(svn_fs_t *fs, const svn_fs_id_t *id, apr_pool_t *pool)
 {
-  svn_boolean_t present;
+  svn_boolean_t present = false;
   SVN_ERR(check_id(fs, id, present, pool));
 
   if (! present)
@@ -233,7 +233,7 @@ check_id_present(svn_fs_t *fs, const svn_fs_id_t *
 static svn_error_t *
 check_id_absent(svn_fs_t *fs, const svn_fs_id_t *id, apr_pool_t *pool)
 {
-  svn_boolean_t present;
+  svn_boolean_t present = true;
   SVN_ERR(check_id(fs, id, present, pool));
 
   if (present)

Re: 1.9.0 alpha

[Andreas Stieger]

Hello,

On 04/11/13 23:39, Ben Reser wrote:
 One of the things we discussed in Berlin was that we wanted to produce alphas
 off trunk so that users would have an earlier opportunity to provide feedback.
 
 Branko has been proding me for the past two weeks to get a 1.9.0 alpha 
 started.
  So to that end I'd like to suggest that next week we produce a 1.9.0-alpha1
 off trunk.

Isn't producing an alpha essentially just the same as pointing people
at a specific tarball made from a trunk revision that the project
considers worthy of testing? This already exists:
http://subversion.apache.org/source-code.html#nightlies
http://ci.apache.org/projects/subversion/nightlies/index.html
I don't suppose you want whole signing off dance?

This being a source based release, any alpha tester would already know
how to get and a build form a nightly tarball or source tree checkout.

So doesn't this just boil down to a project communication to the
intended audience outlining the state of development and inviting
specific testing and feedback from interested users? That is, unless you
also reach out to distribution package maintainers, binary vendors and
integrators who may produce (properly marked) binaries?

Also, mind you, if you produce an alpha you encourage feedback on it
while discouraging anything on changes later in trunk until you produce
another. How does this compare to test trunk@123 which has XZY, which
we call alphaN?

Andreas

localisation: status, migration to pootle

[Andreas Stieger]

Hello,

the aim of this e-mail is to look at the current status/workflow of l10n
for subversion, and propose the move to Apache's Pootle instance for
better tooling and the inclusion of potential translators.

Pootle is a web based localisation system. It works with po files and
offers web based editing and reviewing. I think the most important
benefit for our project would be the openness to translation suggestions
from irregular or first time contributors who might be facing a
non-trivial barrier to entry.[1]

Let's look at numbers fist:

Translation status report for trunk@r1509800

   lang   trans untrans   fuzzy obs
 --
 de2627  13  30 417  +~
 es2160 480 674 501  +++~~~
 fr2449 191 308  62  UU
 it2024 616 812 314  +Uoo
 ja2150 490 723 742  +++~~~oo
 ko2286 354 482 187  +~o
 nb2206 434 619 476  ~~
 pl2229 411 584 268  ~~oo
  pt_BR1993 647 822 301  +Uoo
 sv2601  39  72   0  U~
  zh_CN2461 179 241   2  +UU~~~
  zh_TW1934 706 867 358  UUooo


Only de, sv, zh_CN have been updated in 2013 and can be considered active.

I worked with asfinfra to get access to Apache's pootle instance[2]. The
translation project is configured and I have made a successful run of
changes back and forth. As such I am confident that po files can be
maintained in such a web based system. I would also like to note that
offline editing of po files in your favourite tool will work with this
process as well.

What I have yet to configure with asfinfra is regular scans of the trunk
code, and commits of added/updated/reviewed translations into svn.

I would like to hear from active translation maintainers if they are
happy to move their respective translations into Pootle and work on that
system. If so I am willing to coordinate the import, even if just for
trying it out. With sufficient support from active translation
maintainers we can bring all languages in.

I propose that suggesting new/changed translations remain open to
unauthenticated users and that the translation maintainers review these
suggestions. The hope is to attract translators from the casual level
up, and to recruit maintainers from the pool of contributors for
abandoned languages.

Please let me know your thoughts.

[1] https://subversion.apache.org/docs/community-guide/l10n.html
[2] https://translate.apache.org/projects/Subversion

With kind regards,
Andreas Stieger

Re: svn commit: r1498947 - /subversion/trunk/tools/dev/po-merge.py

[Andreas Stieger]

Hi There,

On 02/07/13 16:00, Dongsheng Song wrote:
 Today, when I merge zh_CN.po from trunk to 1.8.x, I had encounter the
 following error:

 $ python ../../../../trunk/tools/dev/po-merge.py 
 ../../../../trunk/subversion/po/zh_CN.po zh_CN.po
 Traceback (most recent call last):
 File ../../../../trunk/tools/dev/po-merge.py, line 196, in module
 main(sys.argv)
 File ../../../../trunk/tools/dev/po-merge.py, line 181, in main
 for m in msgstr:
 TypeError: 'NoneType' object is not iterable

 Then I found in the line 39-40 of po-merge.py return None as msgstr:

 if line.strip() == '' or line[:2] == '#~':
 return comments, None, None, None

 So we should not do iteration on msgstr without make sure msgstr is
 not None.

 This happened because zh_CN.po have msgmerged po comments like this:

 #~ msgid Uncommitted local addition, copy or move%s
 #~ msgstr 未提交的本地增加，复制或移动 %s

 As your judgement, this is not obvious fix, should I revert this
 commit ?

I cannot make sense of this change other than when malformed input files
are concerned. Your example ^#~ requires msgstr == None == msgid as
per the return of parse_translation(). That, then, means that comments
evaluates to true (has entries) for the break in line 153 not to trigger.

Can you give to input files (URl/revisions) that trigger this? So far
this is my best guess:

#SOMETHING
#~ msgid some msgid
#~ msgstr some msgstr

I agree that msgstr == None should not be iterated, however I don't see
how we get to this case.

Andreas

Re: [PATCH] make po-merge.py count fuzzy strings

[Andreas Stieger]

On 28/06/13 01:08, Daniel Shahaf wrote:
 Andreas Stieger wrote on Fri, Jun 28, 2013 at 00:09:39 +0100:
 make po-merge.py count fuzzy strings 
 Personally I would have done something like if c.startswith('#,') and
 'fuzzy' in c.split(', '): to match 'fuzzy' only as a whole word.

Good point. r1497857

Andreas

[PATCH] make po-merge.py count fuzzy strings

[Andreas Stieger]

Hello,

while merging some translation updates to the release branch I noticed that 
po-merge.py doesn't count strings marked as fuzzy.

[[[
make po-merge.py count fuzzy strings

* tools/dev/po-merge.py
  (main): count and print number of fuzzy strings
]]]

With kind regards,
Andreas Stieger

Index: tools/dev/po-merge.py
===
--- tools/dev/po-merge.py	(revision 1497603)
+++ tools/dev/po-merge.py	(working copy)
@@ -146,6 +146,7 @@ def main(argv):
 string_count = 0
 update_count = 0
 untranslated = 0
+fuzzy = 0
 while True:
 comments, msgid, msgid_plural, msgstr = parse_translation(infile)
 if not comments and msgid is None:
@@ -180,11 +181,15 @@ def main(argv):
 for m in msgstr:
 if m == '':
 untranslated += 1
+for c in comments:
+if c.startswith('#,') and 'fuzzy' in c:
+fuzzy += 1
 
 # We're done.  Tell the user what we did.
 print(('%d strings updated. '
+  '%d fuzzy strings. ' 
   '%d of %d strings are still untranslated (%.0f%%).' %
-  (update_count, untranslated, string_count,
+  (update_count, fuzzy, untranslated, string_count,
100.0 * untranslated / string_count)))
 
 if __name__ == '__main__':

Re: about the compression level in svndiff

[Andreas Stieger]

Hello,

On 15/04/13 23:14, Bo Chen wrote:
 SVN uses zlib to compress the new data in delta. By default, the
 compression level in the current implementation is 5, right? I am
 wondering what are differences by choosing different compression
 level? Is is a trade-off between compression rate and computational
 overhead?

Yes, obviously. Please read /usr/include/zlib.h, or anything about
compression levels?

#define Z_NO_COMPRESSION 0
#define Z_BEST_SPEED 1
#define Z_BEST_COMPRESSION   9
#define Z_DEFAULT_COMPRESSION  (-1)
[...]
1 gives best speed, 9 gives best compression, 0 gives no compression at all
(the input data is simply copied a block at a time).  Z_DEFAULT_COMPRESSION
requests a default compromise between speed and compression (currently
equivalent to level 6).

Andreas

Re: [PATCH] correct installation of mod_dontdothat

[Andreas Stieger]

On 06/03/13 19:50, Andreas Stieger wrote:
 The installation of mod_dontdothat was moved to make install-tools,
 however the trunk code tries to install with libtool which fails with
 the message: cannot install mod_dontdothat.la to a directory not ending
 in [...]/lib/apache2/modules

 The attached patch fixes this.

This change was committed by philip in r1454450.

Andreas

[PATCH] correct installation of mod_dontdothat

[Andreas Stieger]

Hello,

The installation of mod_dontdothat was moved to make install-tools,
however the trunk code tries to install with libtool which fails with
the message: cannot install mod_dontdothat.la to a directory not ending
in [...]/lib/apache2/modules

The attached patch fixes this. This was mentioned earlier here:
http://mail-archives.apache.org/mod_mbox/subversion-dev/201302.mbox/%3c87ip5yhlrd@ntlworld.com%3E

This can be seen working with an rpm package of the nightly trunk
tarballs here:
https://build.opensuse.org/package/show?package=subversionproject=home%3AAndreasStieger%3Asvn18

[[[
* build.conf
  (mod_dontdothat): install as apache module
]]]

Regards,
Andreas

Index: build.conf
===
--- build.conf	(revision 1453508)
+++ build.conf	(working copy)
@@ -383,7 +383,7 @@ type = apache-mod
 path = tools/server-side/mod_dontdothat
 nonlibs = mod_dav_svn apr aprutil
 libs = libsvn_subr xml
-install = tools
+install = apache-mod
 msvc-libs = libhttpd.lib
 
 # 

Re: [PATCH] make mergeinfo diagram column headings l10n friendly

[Andreas Stieger]

On 24/01/13 22:40, Julian Foad wrote:
 Reviewed.  +1.  The best thing is this patch will make it much easier
 to teach the code to adapt automatically to different column widths.

r1438400

Andreas

Re: [PATCH] make mergeinfo diagram column headings l10n friendly

[Andreas Stieger]

On 24/01/13 15:53, Ben Reser wrote:
 On Wed, Jan 23, 2013 at 4:43 PM, Branko Čibej br...@wandisco.com wrote:
 On 24.01.2013 00:42, Andreas Stieger wrote:
 Would something like this not be better?

 youngest common ancestor
 | last full merge
 | |tip of branch
 | || repository path

 2  6
 |  |
--| | branches/branch1
   / /
  / /
   ---| | trunk
   ||
   56
 +0 on this.

 The patch itself still makes translators deal with the position of the
 vertical bars. If we're going to change the layout, we may as well make
 it even easier for translators so that they don't have to worry about
 positioning, just translating the headings.
 +1 on this.

Based on that feedback, the updates patch will produce to the same
output, but with the column headings translated as separate strings.

Andreas

Index: subversion/svn/mergeinfo-cmd.c
===
--- subversion/svn/mergeinfo-cmd.c	(revision 1437751)
+++ subversion/svn/mergeinfo-cmd.c	(working copy)
@@ -162,12 +162,14 @@ mergeinfo_diagram(const char *yca_url,
 }
 
   /* Column headings */
-  SVN_ERR(svn_cmdline_fputs(
-_(youngest  last   repos.\n
-  commonfull tip ofpath of\n
-  ancestor  mergebranchbranch\n
-  \n),
-stdout, pool));
+  SVN_ERR(svn_cmdline_printf(pool,
+%s\n
+| %s\n
+| |%s\n
+| || %s\n
+\n,
+_(youngest common ancestor), _(last full merge),
+_(tip of branch), _(repository path)));
 
   /* Print the diagram, row by row */
   for (row = 0; row  ROWS; row++)

[PATCH] make mergeinfo diagram column headings l10n friendly

[Andreas Stieger]

Hello,

I found the following output of svn mergeinfo troublesome to localize.

youngest  last   repos.
commonfull tip ofpath of
ancestor  mergebranchbranch

2  6   
|  |   
   --| | branches/branch1
  / /  
 / /   
  ---| | trunk
  ||   
  56   

Would something like this not be better?

youngest common ancestor
| last full merge
| |tip of branch
| || repository path

2  6  
|  |  
   --| | branches/branch1
  / / 
 / /  
  ---| | trunk
  ||  
  56  

A patch to this effect is attached for consideration.

[[[
make mergeinfo diagram column headings l10n friendly

* subversion/svn/mergeinfo-cmd.c
  (mergeinfo_diagram): use one line per column heading and
   vertical lines, leaving room for l10n
]]]

Index: subversion/svn/mergeinfo-cmd.c
===
--- subversion/svn/mergeinfo-cmd.c	(revision 1437751)
+++ subversion/svn/mergeinfo-cmd.c	(working copy)
@@ -163,9 +163,10 @@ mergeinfo_diagram(const char *yca_url,
 
   /* Column headings */
   SVN_ERR(svn_cmdline_fputs(
-_(youngest  last   repos.\n
-  commonfull tip ofpath of\n
-  ancestor  mergebranchbranch\n
+_(youngest common ancestor\n
+  | last full merge\n
+  | |tip of branch\n
+  | || repository path\n
   \n),
 stdout, pool));
 

[PATCH] Make static string literal in svnserve message gettext friendly

[Andreas Stieger]

Hello,

[[[
Make static string literal in svnserve message gettext friendly

* subversion/svnserve/svnserve.c
  (svnserve__options): Remove use of nested macro for default port.
  Breaks scanner and cannot be printf'ed in a static definition of
  a apr_getopt_option_t[].
]]]

Regards,
Andreas
Index: subversion/svnserve/svnserve.c
===
--- subversion/svnserve/svnserve.c	(revision 1436546)
+++ subversion/svnserve/svnserve.c	(working copy)
@@ -169,11 +169,11 @@ static const apr_getopt_option_t svnserve__options
  N_(read configuration from file ARG)},
 {listen-port,   SVNSERVE_OPT_LISTEN_PORT, 1,
 #ifdef WIN32
- N_(listen port. The default port is  APR_STRINGIFY(SVN_RA_SVN_PORT) .\n
+ N_(listen port. The default port is 3690.\n
  
 [mode: daemon, service, listen-once])},
 #else
- N_(listen port. The default port is  APR_STRINGIFY(SVN_RA_SVN_PORT) .\n
+ N_(listen port. The default port is 3690.\n
  
 [mode: daemon, listen-once])},
 #endif

[patch] fix macro in a gettexted string

[Andreas Stieger]

Hello,

I found a macro in a gettexted string which breaks the scanner.

[[[
Fix spelling error in svnadmin message and make gettext-friendly

* subversion/svnadmin/svnadmin.c
  (sub_main) fix spelling, fix macro call breaking gettext
]]]


I would like to point out that the message contains SVN_VER_PATCH as
part of SVN_VER_NUM.
Cannot guarantee compatibility beyond the current running version (1.8.0)
Considering the compatibility and versioning scheme used for
repositories, any repository created with 1.8.x can actually be expected
to work with any other 1.8.x. I am not sure how this lines up with the
usage of svn_version__at_least which includes SVN_VER_PATCH and
compatible_version-patch in the comparison, and the message given to
the user.

Andreas

Index: subversion/svnadmin/svnadmin.c
===
--- subversion/svnadmin/svnadmin.c	(revision 1435158)
+++ subversion/svnadmin/svnadmin.c	(working copy)
@@ -2023,9 +2023,10 @@ sub_main(int argc, const char *argv[], apr_pool_t
   compatible_version-patch))
 {
   err = svn_error_createf(SVN_ERR_UNSUPPORTED_FEATURE, NULL,
-  _(Cannot guaranteed compatibility 
+  _(Cannot guarantee compatibility 
 beyond the current running version 
-( SVN_VER_NUM )));
+(%s)),
+  SVN_VER_NUM );
   return EXIT_ERROR(err);
 }
 

[PATCH] Combine conflict callback API error messages differing only by punctuation

[Andreas Stieger]

Hello,

[[[
Combine conflict callback API error messages differing only by punctuation

* subversion/libsvn_wc/conflicts.c
  (generate_propconflict,resolve_text_conflicts): Combine messages which
   differ only by punctuation, remove trailing period from another
]]]

Andreas
Index: subversion/libsvn_wc/conflicts.c
===
--- subversion/libsvn_wc/conflicts.c	(revision 1435158)
+++ subversion/libsvn_wc/conflicts.c	(working copy)
@@ -1386,7 +1386,7 @@ generate_propconflict(svn_boolean_t *conflict_rema
   *conflict_remains = TRUE;
   return svn_error_create(SVN_ERR_WC_CONFLICT_RESOLVER_FAILURE,
   NULL, _(Conflict callback violated API:
-   returned no results.));
+   returned no results));
 }
 
 
@@ -1428,7 +1428,7 @@ generate_propconflict(svn_boolean_t *conflict_rema
 return svn_error_create
 (SVN_ERR_WC_CONFLICT_RESOLVER_FAILURE,
  NULL, _(Conflict callback violated API:
-  returned no merged file.));
+  returned no merged file));
   else
 {
   svn_stringbuf_t *merged_stringbuf;
@@ -1713,8 +1713,8 @@ resolve_text_conflicts(svn_skel_t **work_items,
 scratch_pool));
   if (result == NULL)
 return svn_error_create(SVN_ERR_WC_CONFLICT_RESOLVER_FAILURE, NULL,
-_(Conflict callback violated API: 
-  returned no results));
+_(Conflict callback violated API:
+   returned no results));
 
   if (result-save_merged)
 {

[PATCH] Prevent false negative results of make check in Python tests

[Andreas Stieger]

Hello,

discussed on IRC, the patch below changes the test harness to prevent
some false negatives when running the test suite. Specifically, if a
python test initialisation returns in such a way that the test runner
doesn't know how to handle the result, change to code to return a
non-zero exit code like and, subsequently, have make check fail
correctly. Reproducible by using Python  2.5 or missing sqlite3 Python
bindings, exit triggered by
subversion/tests/cmdline/svntest/__init__.py. danielsh,breser hinted +1
for this on IRC.

[[[
Prevent false negative results of make check in Python tests

* build/run_tests.py
  (_run_py_test): exit non-zero like _run_c_test
]]]

With kind regards,
Andreas Stieger
Index: build/run_tests.py
===
--- build/run_tests.py	(revision 1420930)
+++ build/run_tests.py	(working copy)
@@ -434,7 +434,7 @@ class TestHarness:
  ('.py', 'U', imp.PY_SOURCE))
 except:
   print(Don't know what to do about  + progbase)
-  raise
+  sys.exit(1)
 
 import svntest.main
 

Re: svn diff command line tool bug

[Andreas Stieger]

Hello,


On 10/05/12 21:03, asdfasd asdfasdf wrote:
 svn.exe diff --revision 1:2 --summarize
 https://domain:port/svn/my_repo_name/plugins/myPluginName;

 A
 https://domain:port/svn/my_repo_name/plugins/myPluginName/myPluginName/file1.txt
 A
 https://domain:port/svn/my_repo_name/plugins/myPluginName/myPluginName/file2.txt
 
  A
 https://domain:port/svn/my_repo_name/plugins/myPluginName/myPluginName/fileN.txt
  

 myPluginName part included twice, which is wrong. I think this bug
 is happening because path /plugins appeared in the 2nd revision.

 However when I do 
  svn.exe diff --revision 2:3 --summarize
 https://domain:port/svn/my_repo_name/plugins/myPluginName;
 I am getting correct paths:
 A https://domain:port/svn/my_repo_name/plugins/myPluginName/fileA.txt
 A https://domain:port/svn/my_repo_name/plugins/myPluginName/fileB.txt
 
  A https://domain:port/svn/my_repo_name/plugins/myPluginName/fileZ.txt

This is not a bug. The first diff summary shows added files in a path.
The second one shows other files being added to another path. You may
have added files with the same content and names twice to different
paths and the diff summary shows the correct output for what was
actually done in the repository.

Andreas

Re: svn diff command line tool bug

[Andreas Stieger]

Hello,

On 11/05/12 19:06, Philip Martin wrote:
 Agreed.

 $ svnadmin create repo
 $ svn import -mm repo/format file://`pwd`/repo/A/f
 $ svn1.7 diff --summarize -r0:1 file://`pwd`/repo/A
 A   file:///home/pm/sw/subversion/obj/repo/A/A/f
 A   file:///home/pm/sw/subversion/obj/repo/A/A
 $ svn1.7 diff --summarize -r0:1 http://localhost:/obj/repo/A
 A   http://localhost:/obj/repo/A/A/f
 A   http://localhost:/obj/repo/A/A

 It's already fixed in 1.8:

 $ svn1.8 diff --summarize -r0:1 http://localhost:/obj/repo/A
 A   http://localhost:/obj/repo/A/f
 A   http://localhost:/obj/repo/A

Beat me to it. I was also able to reproduce with a similar script. The
OP's second email makes the problem more clear. The actual diff output
is not affected.

Andreas

[PATCH] fix Ruby 1.9 deprecation warning for Config, use RbConfig

[Andreas Stieger]

Hello,

[[[
 fix Ruby 1.9 deprecation warning for Config, use RbConfig
 * configure.ac
   replace Config with RbConfig
 *  build/ac-macros/swig.m4
  replace Config with RbConfig
]]]

The configure script reads the Ruby major and minor version to reject
configuring swig bindings for Ruby 1.9. It does this by accessing
Config::CONFIG which is deprecated in that release.

ruby -rrbconfig -e 'print Config::CONFIG.fetch(%q(MAJOR))'
ruby -rrbconfig -e 'print Config::CONFIG.fetch(%q(MINOR))'

So instead of meaningful message we get:

checking for Ruby major version... -e:1: Use RbConfig instead of
obsolete and deprecated Config.
checking for Ruby minor version... -e:1: Use RbConfig instead of
obsolete and deprecated Config.

The same warning is triggered when trying to configure SWIG_RB_COMPILE
and SWIG_RB_LINK, although that is moot as these are useless with Ruby
1.9 anyway for now. The following works with at least Ruby 1.8:

ruby -rrbconfig -e 'print Config::RbCONFIG.fetch(%q(MAJOR))'
ruby -rrbconfig -e 'print Config::RbCONFIG.fetch(%q(MINOR))'

This was found during work on the openSUSE package. Please review,
especially concerning backwards compatibility with Ruby versions older
than 1.8.

Andreas
Index: configure.ac
===
--- configure.ac	(revision 1337403)
+++ configure.ac	(working copy)
@@ -1184,12 +1184,12 @@ if test $RUBY != none; then
   AC_PATH_PROGS(RDOC, rdoc rdoc1.8 rdoc18, none)
 fi
 AC_CACHE_CHECK([for Ruby major version], [svn_cv_ruby_major],[
-svn_cv_ruby_major=`$RUBY -rrbconfig -e 'print Config::CONFIG.fetch(%q(MAJOR))'`
+svn_cv_ruby_major=`$RUBY -rrbconfig -e 'print RbConfig::CONFIG.fetch(%q(MAJOR))'`
 ])
 RUBY_MAJOR=$svn_cv_ruby_major
 
 AC_CACHE_CHECK([for Ruby minor version], [svn_cv_ruby_minor],[
-svn_cv_ruby_minor=`$RUBY -rrbconfig -e 'print Config::CONFIG.fetch(%q(MINOR))'`
+svn_cv_ruby_minor=`$RUBY -rrbconfig -e 'print RbConfig::CONFIG.fetch(%q(MINOR))'`
 ])
 RUBY_MINOR=$svn_cv_ruby_minor
 
Index: build/ac-macros/swig.m4
===
--- build/ac-macros/swig.m4	(revision 1337403)
+++ build/ac-macros/swig.m4	(working copy)
@@ -187,7 +187,7 @@ AC_DEFUN(SVN_FIND_SWIG,
 for var_name in arch archdir CC LDSHARED DLEXT LIBS LIBRUBYARG \
 rubyhdrdir sitedir sitelibdir sitearchdir libdir
 do
-  rbconfig_tmp=`$rbconfig print Config::CONFIG@:@'$var_name'@:@`
+  rbconfig_tmp=`$rbconfig print RbConfig::CONFIG@:@'$var_name'@:@`
   eval rbconfig_$var_name=\$rbconfig_tmp\
 done
 

[PATCH] Fix 61 German fuzzy strings

[Andreas Stieger]

Hello,

I corrected / translated some fuzzy German strings.

[[[
* subversion/po/de.po : Fix 61 fuzzy strings.
]]]

Regards,
Andreas Stieger
Index: subversion/po/de.po
===
--- subversion/po/de.po	(revision 1214015)
+++ subversion/po/de.po	(working copy)
@@ -236,9 +236,8 @@ msgid Invalid character in hex checksum
 msgstr Ungültiges Zeichen in der Hex-Prüfsumme gefunden
 
 #: ../include/svn_error_codes.h:220
-#, fuzzy
 msgid Unknown string value of token
-msgstr Unbekannter Status für Sperrbefehl
+msgstr Unbekannter Zeichenkettenwert für Sperrmarke
 
 #: ../include/svn_error_codes.h:226
 msgid No such XML tag attribute
@@ -303,9 +302,8 @@ msgid Unrecognized stream data
 msgstr Unbekannter Datenstrom
 
 #: ../include/svn_error_codes.h:294
-#, fuzzy
 msgid Stream doesn't support seeking
-msgstr Server unterstützt »edit pipelining« nicht
+msgstr Datenstrom unterstützt das Setzen der Position nicht
 
 #: ../include/svn_error_codes.h:300
 msgid Unknown svn_node_kind
@@ -480,9 +478,8 @@ msgid The specified node is not a symlink
 msgstr Der spezifizierte Knoten ist kein symbolischer Link
 
 #: ../include/svn_error_codes.h:503
-#, fuzzy
 msgid The specified path has an unexpected status
-msgstr Die angegebene Vergleichsoption wird nicht unterstützt
+msgstr Der angegebene Pfad hat einen unerwarteten Status
 
 #: ../include/svn_error_codes.h:508
 #, fuzzy
@@ -490,9 +487,8 @@ msgid The working copy needs to be upgraded
 msgstr Die Arbeitskopie fehlt
 
 #: ../include/svn_error_codes.h:513
-#, fuzzy
 msgid Previous operation was interrupted; run 'svn cleanup'
-msgstr Die Operation wurde unterbrochen
+msgstr Die vorhergehende Operation wurde unterbrochen; Starten Sie »svn cleanup«
 
 #: ../include/svn_error_codes.h:518
 msgid This operation can not be performed with just this depth.
@@ -883,9 +879,8 @@ msgid Server SSL certificate untrusted
 msgstr Server-SSL-Zertifikat ist nicht vertrauenswürdig
 
 #: ../include/svn_error_codes.h:986
-#, fuzzy
 msgid Initialization of the GSSAPI context failed
-msgstr Initialisierung der SSPI-Bibliothek schlug fehl
+msgstr Initialisierung des GSSAPI-Kontextes schlug fehl
 
 #: ../include/svn_error_codes.h:991
 msgid While handling serf response:
@@ -1052,9 +1047,8 @@ msgid A file external cannot overwrite an existin
 msgstr Ein externer Dateiverweis kann kein existierendes versioniertes Objekt überschreiben
 
 #: ../include/svn_error_codes.h:1182
-#, fuzzy
 msgid Invalid path component strip count specified
-msgstr Ungültige Revision angegeben
+msgstr Ungültige Anzahl der vom Pfad zu entfernenden Komponenten angegeben
 
 #: ../include/svn_error_codes.h:1187
 msgid Detected a cycle while processing the operation
@@ -1245,9 +1239,8 @@ msgid No external merge tool available
 msgstr Kein externes Werkzeug zum Zusammenführen verfügbar
 
 #: ../include/svn_error_codes.h:1396
-#, fuzzy
 msgid Failed processing one or more externals definitions
-msgstr »svn:externals«-Definitionen ignorieren
+msgstr Verarbeitung einer oder mehrerer »svn:externals«-Definitionen fehlgeschlagen
 
 #: ../include/svn_error_codes.h:1402
 msgid Assertion failure
@@ -1287,9 +1280,9 @@ msgstr »%s« endet mit einem reservierten Namen
 #: ../svn/export-cmd.c:91 ../svn/import-cmd.c:106 ../svn/resolve-cmd.c:106
 #: ../svn/resolved-cmd.c:76 ../svn/revert-cmd.c:77 ../svn/status-cmd.c:260
 #: ../svn/upgrade-cmd.c:72
-#, fuzzy, c-format
+#, c-format
 msgid '%s' is not a local path
-msgstr »%s« ist keine Datei
+msgstr »%s« ist kein lokaler Pfad
 
 #: ../libsvn_client/add.c:683 ../libsvn_ra/ra_loader.c:373
 #: ../libsvn_ra_serf/serf.c:366 ../libsvn_ra_serf/serf.c:482
@@ -1348,9 +1341,9 @@ msgid URL '%s' refers to a file, not a directory
 msgstr Die URL »%s« verweist auf eine Datei, nicht auf ein Verzeichnis
 
 #: ../libsvn_client/checkout.c:204
-#, fuzzy, c-format
+#, c-format
 msgid '%s' is already a working copy for a different URL; use 'svn update' to update it
-msgstr »%s« ist bereits eine Arbeitskopie für eine andere URL
+msgstr »%s« ist bereits eine Arbeitskopie für eine andere URL; Verwenden Sie »svn update« um sie zu aktualisieren
 
 #: ../libsvn_client/checkout.c:212
 #, c-format
@@ -1418,9 +1411,8 @@ msgid Error bumping revisions post-commit (detail
 msgstr Fehler beim Weiterschalten der Revisionen nach der Übertragung (Details folgen):
 
 #: ../libsvn_client/commit.c:968
-#, fuzzy
 msgid Are all targets part of the same working copy?
-msgstr Sind alle Ziele Teil derselben Arbeitskopie?
+msgstr Sind alle Ziele Teil der selben Arbeitskopie?
 
 #: ../libsvn_client/commit.c:1007
 msgid Cannot non-recursively commit a directory deletion of a directory with child nodes
@@ -1513,9 +1505,8 @@ msgid Path '%s' already exists, but is not a dire
 msgstr Pfad »%s« existiert bereits, ist aber kein Verzeichnis
 
 #: ../libsvn_client/copy.c:775
-#, fuzzy
 msgid Source and destination URLs appear not to all point to the same