[l10n] Translation status report for trunk r1640276

Translation status report for trunk <at> r1640276

  lang   trans untrans   fuzzy     obs
    de    2868       2       0     489  +++++++++++++++++++++++++++++Uooooo
    es    2261     609     825     527  ++++++++++++++++++UUUUU~~~~~~~oooo
    fr    2564     306     512     113  ++++++++++++++++++++++UUU~~~~~o
    it    2121     749     949     340  ++++++++++++++++UUUUUU~~~~~~~~oo
    ja    2251     619     874     763  ++++++++++++++++++UUUU~~~~~~~~oooooo
    ko    2397     473     646     217  ++++++++++++++++++++UUUU~~~~~~o
    nb    2311     559     776     500  +++++++++++++++++++UUUU~~~~~~~oooo
    pl    2336     534     743     297  +++++++++++++++++++UUUU~~~~~~~oo
 pt_BR    2097     773     962     321  ++++++++++++++++UUUUUU~~~~~~~~oo
    sv    2727     143     309      79  +++++++++++++++++++++++++UU~~~
 zh_CN    2622     248     434      19  +++++++++++++++++++++++UUU~~~~
 zh_TW    2038     832     999     377  +++++++++++++++UUUUUUU~~~~~~~~oo

Greg Stein | 18 Nov 05:00 2014

Fwd: Code signing service now available

Do we want to begin signing our Windows releases?

It doesn't seem useful for our Java code, since end-users don't directly consume that stuff.

---------- Forwarded message ----------
From: Mark Thomas <markt <at> apache.org>
Date: Mon, Nov 17, 2014 at 6:30 AM
Subject: Code signing service now available
To: "infrastructure <at> apache.org" <infrastructure <at> apache.org>

The ASF Infrastructure team is pleased to announce the availability of a
new code signing service for Java, Windows and Android applications.
This service is available to any Apache project to use to sign their

After a great deal of research, we have chosen Symantec's Secure App
Service offering to provide code signing service. This allows us to
granularly permit access; and each PMC will have their own
certificate(s) for signing. The per-project nature of certificate
issuance allows us to revoke a signature without disrupting other projects.

This service will permit projects to sign artifacts either via a web GUI
or a SOAP API. In addition a Java client and an ant task for signing
have been written and a maven plugin is under development.

This service results in a 'pay for what you use' scenario, so PMCs are
asked to use the service responsibly. To that end, projects will have
access to a test environment to ensure that they have their process
working correctly before consuming actual credits.

Thus far, we've had two projects who have helped testing this and
working out process for which we are very grateful. Those projects,
Commons and Tomcat, have successfully released signed artifacts
recently. (Commons Daemon 1.0.15 and Tomcat 8.0.15)

Projects that wish to use this service should open an Infra JIRA ticket
under the Codesigning component.

If you have any questions about this new service then feel free to ask
them on the infrastructure mailing list. This week is also an
opportunity to discuss this new service face-to-face with the
Infrastructure Team at ApacheCon EU. Come along to one of the infra
presentations or find one of us during one of the breaks.

on behalf of the ASF Infrastructure Team

Fitzpatrick, Ben | 17 Nov 14:26 2014

GNOME keyring in Subclipse bug

Hi everyone,

This bug prevents use of GNOME keyring password caching by Subclipse:

There's been no news since 2012, and the issue is marked against the
1.7.0 milestone. Is it likely that there will be any progress on this?


Ben Fitzpatrick

Schmidt, Michael | 12 Nov 20:34 2014

[PATCH] issue #4527: notify start of exporting external

Please find attached a patch which provides the missing notification at the start of exporting externals. Since I’ve never before worked on subversion code, please review it especially carefully :) I apologize for possible blunt errors in advance.


This patch only fixes the missing notification of starting to export externals. It does not address the second part of issue #4527, which is the premature reset of the in_external flag in the case of nested externals, which also affects checkouts. To me it seems that the best option for fixing that issue would be to turn the bool flag into a counter which keeps track of the “stack deptch” of externals, but I am not totally sure about how this affects the ABI and whether there might be better ways of fixing this. Any comments/ideas? Since this is not really the same issue but more of a closely related issue, I can turn this into a second issue if this is preferred.



(Partially) Fix Issue #4527: Notify start of exporting external


* subversion/libsvn_client/externals.c

   (svn_client__export_externals): Send svn_wc_notify_update_external notification before handling external.






Attachment (export_externals_add_notification.patch): application/octet-stream, 1314 bytes
Schmidt, Michael | 12 Nov 11:40 2014

svn export does not announce fetching of externals

I have noticed that when I export something which contains externals, subversion only prints “Exported revision X” after fetching an external, in contrast to a checkout, where you get an announcement before fetching an external starts and where the message after fetching an external also explicitly states that an external was fetched. Here is the example of a simple checkout containing a folder A with a file test.txt and an svn:externals definition linking in this folder “A” under “A_External”:




A    checkout\A

A    checkout\A\test.txt

U   checkout


Hole externen Verweis nach »checkout\A_External«:

A    checkout\A_External\test.txt

Externer Verweis ausgecheckt, Revision 8.


Ausgecheckt, Revision 8.





A    export

A    export\A

A    export\A\test.txt

A    export\A_External

A    export\A_External\test.txt

Exportiert, Revision 8.

Exportiert, Revision 8.



Looking at the subversion sources, I found that there is code which should print a different message for the external in svn/notify.c, but it doesn’t get executed because svn_client__export_externals(…) (in libsvn_client/externals.c) never notifies the start of an external (by passing svn_wc_notify_update_external to the notify callback).


Is there any chance that this behavior will be fixed? I’d like to analyze some checkout log files for externals, and the current log makes it very hard to properly handle nested externals (not that I would hope to see them, but I’d prefer to have something that will just work in any case)…


Best regards,



Branko ─îibej | 12 Nov 08:42 2014

Builder svn-trunk-nightly is failing ...

... because it was apparently recently upgraded to libtool-2.4.3. Here's
the error from the log:

No such file or directory

This is because, in the latest version of libtool, config.guess is no
longer in .../share/libtool/config but in .../share/libtool/build-aux. I
don't know if this can be changed at build time; in any case, our
autogen.sh looks at the LIBTOOL_CONFIG environtment variable to find
that path (and, heh, I just recently had to fix that bit of autogen.sh).

Whoever is maintaining the nightly builder, please set LIBTOOL_CONFIG to
point to the build-aux directory.

-- Brane


[l10n] Translation status report for trunk r1638021

Translation status report for trunk <at> r1638021

  lang   trans untrans   fuzzy     obs
    de    2871       0       0     486  ++++++++++++++++++++++++++++++ooooo
    es    2264     607     826     527  ++++++++++++++++++UUUUU~~~~~~~oooo
    fr    2567     304     515     113  ++++++++++++++++++++++UUU~~~~~o
    it    2124     747     950     340  ++++++++++++++++UUUUUU~~~~~~~~oo
    ja    2254     617     875     763  ++++++++++++++++++UUUU~~~~~~~~oooooo
    ko    2400     471     647     217  ++++++++++++++++++++UUUU~~~~~~o
    nb    2314     557     777     500  +++++++++++++++++++UUUU~~~~~~~oooo
    pl    2339     532     744     297  +++++++++++++++++++UUUU~~~~~~~oo
 pt_BR    2100     771     963     321  ++++++++++++++++UUUUUU~~~~~~~~oo
    sv    2729     142     311      80  +++++++++++++++++++++++++UU~~~
 zh_CN    2625     246     437      19  +++++++++++++++++++++++UUU~~~~
 zh_TW    2041     830    1000     377  +++++++++++++++UUUUUUU~~~~~~~~oo

Matthias Ludwig | 8 Nov 01:32 2014

AW: failure of creating mutex file on pending delete

He there,

I don't have any clue oft he development of svn, nevertheless I try to make some assumptions. Please correct
me if I'm wrong.

I might obverved a problem:

I'm usging Apache mod_dav_svn 1.8.10 on windows 7.

In my apache error log files I found the errors:

(20014)Internal error: -Can't open file
'C:\\ServerData\\svn\\repos\\db\\rev-prop-atomics.mutex': access denied  
(20014)Internal error: Revprop caching for 'C:/ServerData/svn/repos/db' disabled because SHM
infrastructure for revprop caching failed to initialize.

They appear when I open TortoiseSvn-Repo-Browser (which means that a lot of request are send tot he server.
(maybe even parallel? I don't know)

The apache run under local System account. I've checked the file permissions on all repo-files for user
SYSTEM. Everything is ok.

Then I used "Process Monitor" from Sysinternals  to check the file access on the file above
I saw hundreds of failures of file creation, with the result "DELETE

20:08:43,2589409	httpd.exe	3728	CreateFile	C:\ServerData\svn\repos\db\rev-prop-atomics.mutex	DELETE
PENDING	Desired Access: Read Attributes, Delete, Disposition: Open, Options: Non-

Googling around I found out that an attempt to create a file with a "Pending Delete" can lead to an "access
denied" result. (e.g. http://stackoverflow.com/questions/3764072/c-win32-how-to-wait-for-a-pending-delete-to-complete)

Is there a relation to the error-Log-Message? The timing said so.

I suppose the create/lock/unlock/delete command on that file are used for synchronization.	
What are the performance costs of synchronization with the file? When I I see the error file creation
failure I get the feeling there is a performance loss there. The Tortoise-SVN-Repo browser in our setting
is quit slow. Is there a relation?
Maybe a named mutex of he Win32-API would be the better choice for synchonization because they are made for
that reason.

But as a said I dont know anyting oft he svn-development. I'm curious what the expert's say to my  observation.

Looking forward for any response.
Thank you.

Eric S. Raymond | 7 Nov 23:40 2014

SRC - simple revision control

Because the UI was directly inspired by Subversion, people here might
find my latest project of some interest.

			Simple Revision Control

The venerable RCS (Revsion Control System) has survived into the era
of distributed version control because it fills a niche: sometimes you
only *want* to track changes in single files at a time - for example,
if you have a directory full of documents with separate histories.

SRC (Simple Revision Control) is RCS, reloaded.  It remains
determinedly file-oriented and doesn't even track the committer of a
change (because that's always you), but incorporates the design and
user-interface lessons of modern systems.  It features sequential
revision numbers, lockless operation, embedded command help, and a
command set that will seem familiar to users of Subversion, Mercurial,
and Git.


		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

You [should] not examine legislation in the light of the benefits it will
convey if properly administered, but in the light of the wrongs it
would do and the harm it would cause if improperly administered
	-- Lyndon Johnson, former President of the U.S.

Stuart Rossiter | 7 Nov 14:05 2014

Pretty definite bug in 1.7.0 and beyond for JavaHL SVNClient propertyGet (legacy tigris package)


 [Not subscribed; please cc me.]

Posting directly here (rather than users) since I'm pretty sure of this.

org.tigris.subversion.javahl.SVNClient has a bug: propertyGet wraps a call to the same method for the Apache package equivalent, but doesn't handle nulls in the response, so the caller can never receive a null response (which it should do if the property doesn't exist).

public PropertyData propertyGet(String path, String name,
                                    Revision revision, Revision pegRevision)
            throws ClientException
            return new PropertyData(path, name,
                    new String(aSVNClient.propertyGet(path, name,
                        revision == null ? null : revision.toApache(),
                        pegRevision == null ? null : pegRevision.toApache())));
        catch (org.apache.subversion.javahl.ClientException ex)
            throw new ClientException(ex);

The String constructor throw a NullPointerException if the aSVNClient class returns null. (Not sure why the String constructor was used to copy an immutable string anyway, unless there are JNI-specific reasons.)

This bug has persisted since 1.7.0 (when the 'real' code switched to the Apache package, with the Tigris one as a legacy wrapper); I checked and it's still there in the current HEAD (r1600990).

To reproduce, just try to retrieve a non-existent property from an SVN-controlled file using the legacy Tigris package API.

If you need me to raise an issue from this let me know.



Stuart Rossiter

Research Fellow: EPSRC Care Life Cycle Project

Andreas Stieger | 6 Nov 23:04 2014

[PATCH] svnadmin delrevprop and setrevprop parameters


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