rename obnoxiously and non-portably long bug report filename
This commit is contained in:
Joey Hess
parent
75204f5ae7
commit
a1f8d2919d
9 changed files with 0 additions and 0 deletions
|
|
@ -0,0 +1,13 @@
|
|||
[[!comment format=mdwn
|
||||
username="ga@2217a6e07239bc6b36af2a9134b2647fdebcabcd"
|
||||
nickname="ga"
|
||||
avatar="http://cdn.libravatar.org/avatar/d077d3b19ca11c2036b4870e4340c7d1"
|
||||
subject="Same error"
|
||||
date="2018-05-05T05:28:35Z"
|
||||
content="""
|
||||
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
|
||||
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 2"""
|
||||
date="2018-05-08T18:28:59Z"
|
||||
content="""
|
||||
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>
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
[[!comment format=mdwn
|
||||
username="ga@2217a6e07239bc6b36af2a9134b2647fdebcabcd"
|
||||
nickname="ga"
|
||||
avatar="http://cdn.libravatar.org/avatar/d077d3b19ca11c2036b4870e4340c7d1"
|
||||
subject="Arm processor on Synology device"
|
||||
date="2018-05-10T11:07:44Z"
|
||||
content="""
|
||||
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/
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,35 @@
|
|||
[[!comment format=mdwn
|
||||
username="ewen"
|
||||
avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
|
||||
subject="Synology NAS"
|
||||
date="2018-07-08T06:52:08Z"
|
||||
content="""
|
||||
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](http://ewen.mcneill.gen.nz/blog/entry/2017-05-28-git-annex-on-synology-ds216+/), 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:
|
||||
|
||||
<pre>
|
||||
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$
|
||||
</pre>
|
||||
|
||||
(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
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,57 @@
|
|||
[[!comment format=mdwn
|
||||
username="g@aaed65f19d6c3a2a18c33da828e66c7bb915e65a"
|
||||
nickname="g"
|
||||
avatar="http://cdn.libravatar.org/avatar/10470d6f8a18833e04dee17126d53372"
|
||||
subject="workaround: setting LC_ALL=C"
|
||||
date="2018-10-18T08:55:19Z"
|
||||
content="""
|
||||
I had a similar problem yesterday with the latest [x86-64 standalone build](https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-amd64.tar.gz), 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](http://git-annex.branchable.com/bugs/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/#comment-f9a93468be4a799e1e79e97941449d67) 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](https://askubuntu.com/questions/1081901/right-way-to-fix-assertion-in-loadlocale-c)
|
||||
|
||||
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
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 6"""
|
||||
date="2018-12-03T17:41:43Z"
|
||||
content="""
|
||||
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.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
[[!comment format=mdwn
|
||||
username="StéphaneGL"
|
||||
avatar="http://cdn.libravatar.org/avatar/a12e6e0852d5a1985b8684b17202561c"
|
||||
subject="comment 6"
|
||||
date="2018-12-03T18:22:10Z"
|
||||
content="""
|
||||
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.
|
||||
|
||||
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
[[!comment format=mdwn
|
||||
username="ga@2217a6e07239bc6b36af2a9134b2647fdebcabcd"
|
||||
nickname="ga"
|
||||
avatar="http://cdn.libravatar.org/avatar/d077d3b19ca11c2036b4870e4340c7d1"
|
||||
subject="Worked around"
|
||||
date="2018-12-19T21:09:43Z"
|
||||
content="""
|
||||
Setting LC_ALL=C appears to have worked around this for me.
|
||||
"""]]
|
||||
Loading…
Add table
Add a link
Reference in a new issue