Please describe the problem.

git annex version

sh: loadlocale.c:129: nl_intern_locale_data: Assertion `cnt < (sizeof (nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))' failed. Aborted

What steps will reproduce the problem?

git annex version

What version of git-annex are you using? On what operating system?

Synology NAS, 32-bit prebuilt version

wget https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-i386.tar.gz
--2018-04-08 04:26:29--  https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-i386.tar.gz
Resolving downloads.kitenet.net... 66.228.36.95, 2600:3c03::f03c:91ff:fe73:b0d2
Connecting to downloads.kitenet.net|66.228.36.95|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 60787901 (58M) [application/x-gzip]
Saving to: 'git-annex-standalone-i386.tar.gz'

100%[================================================================================================================================================================================================================================================>] 60,787,901  1.52MB/s   in 39s    

2018-04-08 04:27:09 (1.49 MB/s) - 'git-annex-standalone-i386.tar.gz' saved [60787901/60787901]

Please provide any additional information below.

# If you can, paste a complete transcript of the problem occurring here.
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log


# End of transcript or log.

Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)

RSS Atom

Same error

I'm getting the same error on my Synology device.

$ uname -a Linux xxxx 3.10.102 #15266 SMP Mon Mar 26 15:10:20 CST 2018 armv7l GNU/Linux synology_armada38x_ds216j

Comment by ga — Sat May 5 05:28:35 2018

Remove comment

comment 2

The synology NAS has a very old linux kernel IIRC, so you will probably have better luck with the tarball targeting ancient kernels, https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-i386-ancient.tar.gz

Comment by joey — Tue May 8 18:28:59 2018

Remove comment

Arm processor on Synology device

Unfortunately the processor is an Arm processor, so the ancient build you linked won't work:

$ grep model /proc/cpuinfo

model name : ARMv7 Processor rev 1 (v7l)

(I have a DS216j)

I see you have an outstanding issue about providing an ancient armel build, maybe that would help?

https://git-annex.branchable.com/todo/add_ancient_armel_build/

Comment by ga — Thu May 10 11:07:44 2018

Remove comment

Synology NAS

I can confirm I got the same error message trying the 2018-06-26 amd64 standalone build on a Synology DS216+ NAS (installed via the same instructions that I used last year, after creating the directory to allow the locale to be generated. But if I instead installed the i386-ancient version, and let that generate the locales, then that seems to work okay. Eg, I can then run git annex version to completion:

ewen@nas01:/volume1/thirdparty$ git annex version
git-annex version: 6.20180626-gb091dac
build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Testsuite
dependency versions: aws-0.17.1 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.7.0 persistent-sqlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5
key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external
operating system: linux i386
supported repository versions: 3 5 6
upgrade supported from repository versions: 0 1 2 3 4 5
ewen@nas01:/volume1/thirdparty$

(I haven't tried the non-archaic i386 version.)

Since the locales should be user space only, I'm assuming that the issue isn't "archaic kernel" -- although the Synology DS216+ NAS kernel is based on a fairly old version:

ewen@nas01:/volume1/thirdparty$ uname -a
Linux nas01 3.10.105 #23739 SMP Fri Jun 8 12:51:05 CST 2018 x86_64 GNU/Linux synology_braswell_216+II
ewen@nas01:/volume1/thirdparty$

but probably related to the libc version git-annex was compiled against, and the version of the tools being used to generate the locales.

I've not tested the new version much on the Synology DS216+ NAS, but I'm expecting that it should work now that "git annex version" works (and "git annex sync" works from another machine to it), with the i386 "archaic" build, the rest should work for my purposes (basically ssh remote).

Ewen

Comment by ewen — Sun Jul 8 06:52:08 2018

Remove comment

workaround: setting LC_ALL=C

I had a similar problem yesterday with the latest x86-64 standalone build, git-annex ver. 6.20180927-g897e5ba57

Short story

I solved this adding this to my .bashrc

export LC_ALL=C

Non so short story

I need the standalone version for I'm using an hosting service with ssh connection; it's just a "classic" LAMP hosting space, not a full VM, so I cannot install any package on it

In 2016 I was able to install the standalone git-annex version 6.20161231-gc8eeb17da, along with gitolite for access control, and all was working well until recently on one of my machines I upgraded to ver. 6.20180913-1 amd64: trying to get some content always failed with

  [2018-10-17 17:56:52.199123421] P2P > ERROR auth failed

  fd:19: hClose: resource vanished (Broken pipe)
  failed

After a brief search I found get over ssh fails with fd:19: hClose: resource vanished - comment 1 and decidet to upgrade git-annex server side

After upgrade I got the error reported in this bug report subject and after a quick research I found a similar report on askubuntu

The first thing I tried was

LC_ALL=C git annex version

and I the error "disappeared": bingo!

I realized that LC_ALL was unset in my gitolite user profile, so I added it to my .bashrc and now all is working (almost) fine.

Why almost?

Well: it's surely not related to git-annex but to my hosting server.

Every time I get some file from the remote on that hosting space I get an error

 ERROR: ld.so: object '/lib/security/hosting-securize.so' from /etc/ld.so.preload cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.

but fortunately it is ignored and the files are downloaded as expected

I still had no time to investigate why I get a ELFCLASS32 (I'm sure I installed the amd64 standalone)... but since it works I leave it as a background wishlist

The end

That's all, I hope this will help others with similar issues

Bye! Giovanni Biscuolo

Comment by g — Thu Oct 18 08:55:19 2018

Remove comment

comment 6

Same problem reported in another bug, the bug sumitter was using Ubuntu 14.04.5 LTS. Which also makes me think it's related to kernel version.

Comment by joey — Mon Dec 3 17:41:43 2018

Remove comment

comment 6

I had the same error message when trying to run the standalone, version 7.20181106, on my raspberry pi. For some reason, the stand-alone version of git-annex handles and compiles its own locales in

~/.cache/git-annex/locales/[SOME_DIRECTORY]/

For some unknown reason, the locale that git-annex compiled in that directory, namely en_GB.UTF-8 for me, was different from the one from my system, which is kept in /usr/lib/locales/. Every command that git-annex uses, even just rm, was systematically failing with error cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0])) after git-annex loaded its own locale instead of the system's (technically, after the runshell script exports LOCPATH=~/.cache/git-annex/locales/[SOME_DIRECTORY]/).

Solution I found: I erased the version that git-annex compiled and instead placed a symbolic link ~/.cache/git-annex/locales/[SOME_DIRECTORY]/en_GB.UTF-8 towards my system's locale in /usr/lib/locale/. Then LC_TIME was correctly defined and I got rid of the error `cnt < (sizeof (nl_value_type_LC_TIME) / sizeof (nl_value_type_LC_TIME[0]))'

Hope this helps.

It looks like the runshell script is doing something incorrect with the compilation of locales, but I'm not sure what.

Comment by StéphaneGL — Mon Dec 3 18:22:10 2018

Remove comment