Bug 220670

Summary:	devel/subversion: svn: E000022: Error converting entry in directory after 1.9.6 update
Product:	Ports & Packages	Reporter:	Stefan Eßer <se>
Component:	Individual Port(s)	Assignee:	Lev A. Serebryakov <lev>
Status:	Closed FIXED
Severity:	Affects Some People	CC:	lwhsu, rhurlin, robert.ayrapetyan
Priority:	---	Keywords:	needs-qa, regression
Version:	Latest	Flags:	bugzilla: maintainer-feedback? (lev)
Hardware:	Any
OS:	Any

Description Stefan Eßer freebsd_committer

2017-07-12 08:51:36 UTC

After the upgrade to svn 1.9.6, subversion is unable to update any files on my system (amd64, -CURRENT, ZFS).

Updating continues to work with svnlite (1.9.5).

It seems, that svn-1.9.6 tries to operate on garbage data, since all file names in the directory sub-tree used are in pure ASCII and the reported bytes do not look like part of a reasonable file name. 

But no conversion to UTF-8 should be performed, anyway, since the system has been using a UTF-8 locale for years.

As an example for the problem, I'm including a typescript of "svn up" of the devel/subversion port itself. All files are unchanged as checked out from the ports repository. (The problem first occured when I tried to update /usr/src and with the same invalid bytes being reported. This makes me believe, that the file subversion complains about is not in the directory (tree) being updated.)

Interesting detail: The data reported as invalid differs between LANG=en_US.UTF-8 vs. e.g. de_DE.UTF-8:

# cd /usr/ports/devel/subversion
# unset LC_CTYPE
# export LANG=en_US.UTF-8
# svn up
Updating '.':
svn: E000022: Error converting entry in directory '/usr/svn/ports/head/devel/subversion' to UTF-8
svn: E000022: Valid UTF-8 data
(hex:)
followed by invalid UTF-8 sequence
(hex: a8 73 76

# LANG=de_DE.UTF-8
# svn up
Aktualisiere ».«:
svn: E000022: Fehler beim Konvertieren eines Eintrags im Verzeichnis »/usr/svn/ports/head/devel/subversion« nach UTF-8
svn: E000022: Auf gültige UTF-8-Daten
(hex: 28)
folgte eine ungültige UTF-8-Sequenz
(hex: b6 7f)

But it does *not* change with LC_CTYPE, different from what I had expected:

# export LC_CTYPE=en_US.UTF-8
# svn up
Aktualisiere ».«:
svn: E000022: Fehler beim Konvertieren eines Eintrags im Verzeichnis »/usr/svn/ports/head/devel/subversion« nach UTF-8
svn: E000022: Auf gültige UTF-8-Daten
(hex: 28)
folgte eine ungültige UTF-8-Sequenz
(hex: b6 7f)

Comment 1 Stefan Eßer freebsd_committer

2017-07-12 10:54:10 UTC

I was able to build a working svn binary by first re-building devel/apr1.

My suspicion is, that the old apr library was linked against an older version of the C library, while SVN expected a library function with modified interface (due to the ino64 changes?). This could not be resolved by symbol versioning, when the svn binary was linked.

Anyway: It suffices to compile devel/apr1 and then devel/subversion to resolve the issue.

Perhaps the PORTREVISIOON of devel/apr1 should be incremented, since the same problem might affect any other program compiled after the ino64 changes and linked against apr1.

Comment 2 Stefan Eßer freebsd_committer

2017-07-12 10:59:57 UTC

I'm leaving the status at "in progress" since a solution is known, but not automatically applied on affected systems.

AFAICT, the problem does only affect binaries compiled after the ino64 change and linked against libraries that were built before that change (i.e. only -CURRENT).

But unless devel/apr1 is forcefully rebuilt (and subversion thereafter), the problem will also affect the centrally built subversion packages. (Not verified)

BTW: The hint that the cause of the problem was an old library came from Rainer Hurling (rhurlin at gwdg.de), who reported success after rebuilding all ports subversion depends upon.

Comment 3 Stefan Eßer freebsd_committer

2017-07-12 11:11:57 UTC

Just one remark regarding the package builder for -CURRENT:

As soon as the package builders are upgraded to a version of -CURRENT that contains the ino64 patch, all affected libraries with old call signature (pre-ino64) need to be rebuild, or they won't work in binaries compiled with ino64.

Comment 4 Rainer Hurling freebsd_committer

2017-07-12 12:39:03 UTC

As reported on the mailinglist, I had success with rebuilding all dependencies of devel/subversion:

portmaster serf-1.3.9_1 expat-2.2.1 gettext-runtime-0.19.8.1_1 apr-1.5.2.1.5.4_2 sqlite3-3.19.3_1 subversion-1.9.6


This does not clarify about the underlying reasons, but it works.

Comment 5 Kubilay Kocak freebsd_committer

2017-08-19 09:45:42 UTC

Confirming that rebuilding apr then subversion results in resolution of the reported issue on 12.0-CURRENT #8 r321504 (post ino64)

Given that issues like this tend to fall under the 'CURRENT is unsupported', and it doesn't appear that bumping PORTREVISION for either apr and/or subversion at this point can guarantee/force them to be rebuilt *by users*, I believe that resolution of this issue could happen via:

- An UPDATING entry for CURRENT users, describing the workaround, AND/OR
- A change which helps the package builders ensure they build the latest versions. A PORTREVISION bump of apr would do this

Comment 6 Kubilay Kocak freebsd_committer

2017-08-19 09:47:39 UTC

Previous comment was supposed to read "*cant* guarantee/force"

Comment 7 robert.ayrapetyan 2019-01-08 04:51:58 UTC

Got into same situation after upgrading from 11.2 to 12.0 today. Rebuilding devel/apr1 and devel/subversion resolved this issue. Thanks.

Comment 8 Li-Wen Hsu freebsd_committer

2020-06-17 08:28:28 UTC

This should be fixed by upgrading builder and subversion related ports.