Version mismatches between the system locale-archive and the glibc in the
bundle have been observed to cause git crashes.
Unfortunately, this causes locales to not be used in the linux standalone
bundle, as was the case until version 6.20160419.
glibc hardcodes the path to /usr/lib/locale/locale-archive and does not
let an environment variable cause a different locale-archive file to be used.
The only other option to include locales in the bundle would be to include
exploded locale definition directories in the bundle for a number of
locales, generated by localedef. But these take at least 300 kb per locale,
and there are a great many locales; it would be hundreds of megabytes to
include them all.
(Hmm, we could include localdef in the bundle, and check LANG in runshell
and compile the locale directories on the fly. This would need
/usr/share/i18n/ and /usr/lib/locale-archive to be included in the bundle.
It's.. doable.)
I know this is going to once again cause users of the bundle to complain
that eg, ls doesn't show their unicode filenames right. Better than strange
crashes though.
This prevents multiple versions of unix, from ghc and needed by newer
versions of some packages conflicting.
Had to update the bytestring and blaze-builder pins follow-on from this
change.
This is pretty complicated, but I have both "git-annex" and "git annex"
working both in the git bash shell even with git not added to path.
And, when git's added to path, both work from MS-DOS prompt window too.
I think that the webapp startup does still need git in path, so
instructions will keep saying to do that. But, users often disregard them,
and hopefully this will reduce support traffic.
Also, switched the wget from the cygwin one to the msys2 one, avoiding the
complication of needing to bundle any cygwin dlls.
Using msysgit with git-annex is no longer supported.
At the same time, I'm updating the rsync.exe in my downloads repository
with the one from msys2.
Note that rsync is currently still being ldded and installed in Git/cmd/
like the other cygwin programs. The ldd fails and this failure is ignored.
It would be better to special case it to go in Git/usr/bin/, so that the
user can't run rsync in a dos prompt window, which doesn't work, as it needs
additional libs. However, as far as git-annex running rsync running ssh,
it works ok in this location.
Removed the ssh.cmd and ssh-keygen.cmd; these are not needed with git for
windows. Keeping them would let ssh be run manually from a dos prompt
window, but that's not really a goal.
This is where these commands are installed by the new "git for windows".
Kept the old paths too, so msysgit will still work.
This was enough to get ssh and ssh-keygen working when run at the DOS
prompt with the new git for windows installed. However, for some reason,
rsync still fails to find ssh in path when that version of git is used.
I've tested all the dataenc to sandi conversions except Assistant.XMPP,
and all have unchanged behavior, including behavior on large unicode code
points.
This was introduced by commit 450ee53ab6
However, the same problem could affect other calls to programPath,
specifically some on the assistant. So, I fixed it at a deeper level.
/home/builder/.ghc/android-14/arm-linux-androideabi-4.8/bin/../lib/gcc/arm-linux-androideabi/4.8/../../../../arm-linux-androideabi/bin/ld: fatal error: -pie and -r are incompatible
I have a theory that something is deleting the .t directory
or it doesn't get made in the location tried.
The last test showed:
add: ("recordedInodeCache",Key {keyName = "e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77", keyBackendName = "SHA256E", keySize = Just 20, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing},"start")
("recordedInodeCache",Key {keyName = "e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77", keyBackendName = "SHA256E", keySize = Just 20, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing},"end")
("writeInodeCache",Key {keyName = "e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77", keyBackendName = "SHA256E", keySize = Just 20, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing},"start")
git-annex: c:\jenkins\workspace\msysgit-git-annex-assistant-test\git-annex\.t\repo\.git\annex\objects\6cd\e82\SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77\SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77.cache: openFile: does not exist (No such file or directory)
FAIL
add failed
So writeInodeCache is what's failing, and it seems to fail to write the file
despite having made the parent directory.
Without --pristine, cabal will update the package's cabal file if a newer
one is available in hackage. But that can break applying patches.
Especially since the new version from hackage can apparently have dos line
endings, while the version from the tarball doesn't.
This only includes dependencies from the git-annex.cabal file,
not dependencies of dependencies etc. I need some kind of automated system to
make sure I get all of those. TTBOMK, all of them are free software,
generally released under a BSD license.
Package versions match Debian jessie, except for a few differences
needed due to the different version of ghc pulling in a few buildin
packages with other versions.
Most of the patches were cherry-picked from past commits, since these are
older versions.
