Re: Subversion 1.9.10/1.10.4 choke on non-ASCII resources on HP-UX

2019-04-30 Thread Branko Čibej 
On 30.04.2019 20:18, Osipov, Michael wrote:
> Hi folks,
>
> I am facing an issue a previously not had with 1.9.4 on another HP-UX
> machine. Installed a new one and compiled 1.10.4, does not work and
> downgraded to 1.9.10 same issue.
>
> Using HP-UX 11.31 with "aCC: HP C/aC++ B3910B A.06.29 [Oct 18 2016]".
>
> configure:
>> export PREFIX=/opt/ports
>> export LIBDIR=$PREFIX/lib/hpux32
>> export CC=/opt/aCC/bin/aCC
>> export CONFIGURE="./configure --prefix=$PREFIX --libdir=$LIBDIR"
>> export CPPFLAGS="-I$PREFIX/include"
>> export LDFLAGS="-L$LIBDIR"
>> $CONFIGURE --with-apr=$PREFIX --with-apr-util=$PREFIX --without-apxs
>> --without-berkeley-db --with-serf=$PREFIX --disable-nls
>
> Everything compiles fine besides that the portable object files cannot
> properly converted to machine objects:
>> bash-5.0# /opt/ports/bin/msgfmt -c -o subversion/po/zh_TW.mo
>> subversion/po/zh_TW.po
>> subversion/po/zh_TW.po: warning: Charset "UTF-8" is not supported.
>> msgfmt relies on iconv(),
>>  and iconv() does not support "UTF-8".
>>  Installing GNU libiconv and then
>> reinstalling GNU gettext
>>  would fix this problem.
>>  Continuing anyway.
>
> Therefore, I have disabled nls for now. (installed GNU libiconv,
> didn't make a change)

You'd most likely have to recompile (or at least relink) gettext to use
the GNU libiconv.

> All other deps have been compiled on the same machine with the most
> recent version. I have also run the utf8proc tests (swapped getline()
> for fgets()):

utf8proc doesn't convert between encodings, it just handles the Unicode
transformation forms. It's completely self-contained and doesn't use
libiconv.

>> bash-5.0# gmake check
>> gmake -C bench
>> gmake[1]: Entering directory
>> '/tmp/system-compile/apache/utf8proc/utf8proc-2.3.0-patched/bench'
>> gmake[1]: Nothing to be done for 'all'.
>> gmake[1]: Leaving directory
>> '/tmp/system-compile/apache/utf8proc/utf8proc-2.3.0-patched/bench'
>> test/normtest data/NormalizationTest.txt
>> line 42: Part0 # Specific cases
>> line 70: Part1 # Character by character test
>> checking line 1000...
>> checking line 2000...
>> checking line 3000...
>> checking line 4000...
>> checking line 5000...
>> checking line 6000...
>> checking line 7000...
>> checking line 8000...
>> checking line 9000...
>> checking line 1...
>> checking line 11000...
>> checking line 12000...
>> checking line 13000...
>> checking line 14000...
>> checking line 15000...
>> checking line 16000...
>> line 16969: Part2 # Canonical Order Test
>> checking line 17000...
>> checking line 18000...
>> line 18696: Part3 # PRI #29 Test
>> Passed tests after 18874 lines!
>> test/graphemetest data/GraphemeBreakTest.txt
>> checking line 100...
>> checking line 200...
>> checking line 300...
>> checking line 400...
>> checking line 500...
>> checking line 600...
>> Passed tests after 630 lines!
>> test/charwidth
>> Mismatches with system wcwidth (not necessarily errors):
>>    ... (positive widths for 135297 chars unknown to wcwidth) ...
>> Character-width tests SUCCEEDED.
>> test/misc
>> NFC "ṛ̇" -> "ṛ̇" vs. "ṛ̇"
>> NFD "ṛ̇" -> "ṛ̇" vs. "ṛ̇"
>> NFKC_Casefold "X⁥È­ᴬ" -> "xèa" vs. "xèa"
>> NFKC_Casefold "X⁥È­ᴬ" -> "x⁥èa" vs. "x⁥èa"
>> Unicode version: Makefile has 12.0.0, has API 12.0.0
>> Misc tests SUCCEEDED.
>> test/valid
>> Validity tests SUCCEEDED.
>> test/iterate
>> utf8proc_iterate tests SUCCEEDED, (673) tests passed.
>> test/case
>> More up-to-date than OS unicode tables for 2746 tests.
>> utf8proc case conversion tests SUCCEEDED.
>> test/custom
>> mapped "AaSbａ" -> "abssba"
>> map_custom tests SUCCEEDED.
>
> Here is the failure:
>> $ svn co https://deblndw011x.ad001.siemens.net/repos/svn/Playground
>> A    Playground/test1234
>> A    Playground/a
>> A    Playground/{U+043F}{U+0440}{U+0438}{U+0432}{U+0435}{U+0442}.txt
>> A    Playground/a/b.txt
>> svn: E155009: Failed to run the WC DB work queue associated with
>> '/net/home/osipovmi/Playground/a', work item 1 (file-install 16
>> {U+043F}{U+0440}{U+0438}{U+0432}{U+0435}{U+0442}.txt 1 0 1 1)
>> svn: E22: Safe data '/net/home/osipovmi/Playground/' was followed
>> by non-ASCII byte 208: unable to convert to/from UTF-8
>
> but SQLite works:
>> $ sqlite3 Playground/.svn/wc.db
>> SQLite version 3.28.0 2019-04-16 19:49:53
>> Enter ".help" for usage hints.
>> sqlite> select * from WORK_QUEUE;
>> 1|(file-install 16 привет.txt 1 0 1 1)
>> 2|(file-install a/b.txt 1 0 1 1)
>> sqlite> .quit
>
> The terminal and locale are fine though:
>> $ locale
>> LANG=de_DE.utf8
>> LC_CTYPE="de_DE.utf8"
>> LC_COLLATE="de_DE.utf8"
>> LC_MONETARY="de_DE.utf8"
>> LC_NUMERIC="de_DE.utf8"
>> LC_TIME="de_DE.utf8"
>> LC_MESSAGES="de_DE.utf8"
>> LC_ALL=

LC_ALL should probably not be empty. Could be that on HP-UX, the empty
value causes Subversion to use the default C (or POSIX) locale. Try setting

    LC_ALL="de_DE.utf8"; export

Subversion Exception svn_relpath_is_canonical in ra_loader.c

2019-04-30 Thread Eliot, Christopher 
I am not subscribed to this mailing list.  If you need to reach me, please CC 
me explicitly at christopher.el...@nagrastar.com

Running TortoiseSVN1.10 (r28148).

Accessing SVN repository as https://ndev-svn01/svn/...

TortoiseSVN had been running for a long time, I had done lots of things in it.
I right-clicked on a tag and selected "Mark for comparison"
I clicked on the trunk.
Can't recall if I clicked "compare URLs" or not.

Ooh.  This is repeatable.  I shut down TortoiseSVN complete and restarted it.
Performed the same sequence of events; I get this same exception when I click on
"compare URLs".  I reproduced it a couple of times.

I then selected the trunk and marked it for comparison, selected the tag, and
was able to to compare them just fine.

I then went back and repeated the original sequence of events and again got the
exception.

I'll look into updating TortoisSVN.
When I update to 1.12, it's unusable.  When I click on the directory for my 
project, I get a popup that just says "TortoisesSVN client has stopped working. 
 A problem caused the program to stop working correctly.  Please close the 
program."  It seems to be a problem with just this project; I can click down 
into other projects in the same repository.  I'll report that separately.

---
Subversion Exception!
---
Subversion encountered a serious problem.
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.
But please first search the mailing list archives for the error message
to avoid reporting the same problem repeatedly.
You can find the mailing list archives at
https://subversion.apache.org/mailing-lists.html

Subversion reported the following
(you can copy the content of this dialog
to the clipboard using Ctrl-C):

In file
'D:\Development\SVN\Releases\TortoiseSVN-1.10.0\ext\subversion\subversion\libsvn_ra\ra_loader.c'
line 629: assertion failed (svn_relpath_is_canonical(path))
---
OK

Topher Eliot
Product Owner, Nagrastar CAS Team
christopher.el...@nagrastar.com
+01 303 706-5766

Subversion 1.9.10/1.10.4 choke on non-ASCII resources on HP-UX

2019-04-30 Thread Osipov, Michael 

Hi folks,

I am facing an issue a previously not had with 1.9.4 on another HP-UX 
machine. Installed a new one and compiled 1.10.4, does not work and 
downgraded to 1.9.10 same issue.


Using HP-UX 11.31 with "aCC: HP C/aC++ B3910B A.06.29 [Oct 18 2016]".

configure:

export PREFIX=/opt/ports
export LIBDIR=$PREFIX/lib/hpux32
export CC=/opt/aCC/bin/aCC
export CONFIGURE="./configure --prefix=$PREFIX --libdir=$LIBDIR"
export CPPFLAGS="-I$PREFIX/include"
export LDFLAGS="-L$LIBDIR"
$CONFIGURE --with-apr=$PREFIX --with-apr-util=$PREFIX --without-apxs 
--without-berkeley-db --with-serf=$PREFIX --disable-nls


Everything compiles fine besides that the portable object files cannot 
properly converted to machine objects:

bash-5.0# /opt/ports/bin/msgfmt -c -o subversion/po/zh_TW.mo 
subversion/po/zh_TW.po
subversion/po/zh_TW.po: warning: Charset "UTF-8" is not supported. msgfmt 
relies on iconv(),
 and iconv() does not support "UTF-8".
 Installing GNU libiconv and then reinstalling 
GNU gettext
 would fix this problem.
 Continuing anyway.


Therefore, I have disabled nls for now. (installed GNU libiconv, didn't 
make a change)
All other deps have been compiled on the same machine with the most 
recent version. I have also run the utf8proc tests (swapped getline() 
for fgets()):

bash-5.0# gmake check
gmake -C bench
gmake[1]: Entering directory 
'/tmp/system-compile/apache/utf8proc/utf8proc-2.3.0-patched/bench'
gmake[1]: Nothing to be done for 'all'.
gmake[1]: Leaving directory 
'/tmp/system-compile/apache/utf8proc/utf8proc-2.3.0-patched/bench'
test/normtest data/NormalizationTest.txt
line 42: Part0 # Specific cases
line 70: Part1 # Character by character test
checking line 1000...
checking line 2000...
checking line 3000...
checking line 4000...
checking line 5000...
checking line 6000...
checking line 7000...
checking line 8000...
checking line 9000...
checking line 1...
checking line 11000...
checking line 12000...
checking line 13000...
checking line 14000...
checking line 15000...
checking line 16000...
line 16969: Part2 # Canonical Order Test
checking line 17000...
checking line 18000...
line 18696: Part3 # PRI #29 Test
Passed tests after 18874 lines!
test/graphemetest data/GraphemeBreakTest.txt
checking line 100...
checking line 200...
checking line 300...
checking line 400...
checking line 500...
checking line 600...
Passed tests after 630 lines!
test/charwidth
Mismatches with system wcwidth (not necessarily errors):
   ... (positive widths for 135297 chars unknown to wcwidth) ...
Character-width tests SUCCEEDED.
test/misc
NFC "ṛ̇" -> "ṛ̇" vs. "ṛ̇"
NFD "ṛ̇" -> "ṛ̇" vs. "ṛ̇"
NFKC_Casefold "X⁥È­ᴬ" -> "xèa" vs. "xèa"
NFKC_Casefold "X⁥È­ᴬ" -> "x⁥èa" vs. "x⁥èa"
Unicode version: Makefile has 12.0.0, has API 12.0.0
Misc tests SUCCEEDED.
test/valid
Validity tests SUCCEEDED.
test/iterate
utf8proc_iterate tests SUCCEEDED, (673) tests passed.
test/case
More up-to-date than OS unicode tables for 2746 tests.
utf8proc case conversion tests SUCCEEDED.
test/custom
mapped "AaSbａ" -> "abssba"
map_custom tests SUCCEEDED.


Here is the failure:

$ svn co https://deblndw011x.ad001.siemens.net/repos/svn/Playground
APlayground/test1234
APlayground/a
APlayground/{U+043F}{U+0440}{U+0438}{U+0432}{U+0435}{U+0442}.txt
APlayground/a/b.txt
svn: E155009: Failed to run the WC DB work queue associated with 
'/net/home/osipovmi/Playground/a', work item 1 (file-install 16 
{U+043F}{U+0440}{U+0438}{U+0432}{U+0435}{U+0442}.txt 1 0 1 1)
svn: E22: Safe data '/net/home/osipovmi/Playground/' was followed by 
non-ASCII byte 208: unable to convert to/from UTF-8


but SQLite works:

$ sqlite3 Playground/.svn/wc.db
SQLite version 3.28.0 2019-04-16 19:49:53
Enter ".help" for usage hints.
sqlite> select * from WORK_QUEUE;
1|(file-install 16 привет.txt 1 0 1 1)
2|(file-install a/b.txt 1 0 1 1)
sqlite> .quit


The terminal and locale are fine though:

$ locale
LANG=de_DE.utf8
LC_CTYPE="de_DE.utf8"
LC_COLLATE="de_DE.utf8"
LC_MONETARY="de_DE.utf8"
LC_NUMERIC="de_DE.utf8"
LC_TIME="de_DE.utf8"
LC_MESSAGES="de_DE.utf8"
LC_ALL=


as well as
> $ curl https://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt

gives me http://home.apache.org/~michaelo/term%20utf8.png

Where I can start digging now, to make this work again?

Regards,

Michael