Bug 220670 - devel/subversion: svn: E000022: Error converting entry in directory after 1.9.6 update
Summary: devel/subversion: svn: E000022: Error converting entry in directory after 1.9...
Status: In Progress
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Lev A. Serebryakov
URL:
Keywords: needs-qa, regression
Depends on:
Blocks:
 
Reported: 2017-07-12 08:51 UTC by Stefan Esser
Modified: 2019-01-08 04:51 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (lev)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Esser 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 Esser 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 Esser 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 Esser 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 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 freebsd_triage 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 freebsd_triage 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.