rename files containing :

This is mostly to let the repo check out on windows w/o using cygwin's git.

But, bash completion is also crap with : , so ..

9 files changed, 111 insertions, 0 deletions

diff --git a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_1_625268287fe55e6f2254a6f31c637164._comment b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_1_625268287fe55e6f2254a6f31c637164._comment
new file mode 100644
index 000000000..b59365274
--- /dev/null
+++ b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_1_625268287fe55e6f2254a6f31c637164._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-09-23T16:00:38Z"
+ content="""
+This is entirely down to the libc used on the build system and included in
+the tarball.
+
+Currently the builds use unstable or testing because this lets me get new
+library-driven features like sha3 into the build (nearly) ASAP.
+
+It would be possible to switch to using Debian stable. But then I either
+lose new library-driven features in the builds, or I have to start
+installing haskell libraries from source on the build machines, which would
+be a lot of additional work compared to letting Debian maintain hundreds of
+haskell library packages for me.
+
+Then too, while I am pretty much committed to keeping git-annex building on
+Debian stable (which is actually a lot of work, up to several thousand
+lines of ifdefs, and prevents me from using newer ghc features which would
+make my code happier), Debian stable does itself have a habit of updating to a
+new libc release every couple of years. So no matter what, as long as libc
+keeps requiring slightly less ancient kernels for whatever reasons it does,
+everything isn't going to be supported forever.
+
+(OTOH, I'd expect that some enterprise level ancient distros might start to
+include enterprise level ancient builds of git-annex themselves some time soon?
+git-annex version 3, which is broadly compatible with current versions was
+released a full 4 years ago already. Linux 2.6.32 is only, er, 3 years
+older than that.)
+"""]]
diff --git a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_2_3ed7589687fe251066677ad5a01bbbb0._comment b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_2_3ed7589687fe251066677ad5a01bbbb0._comment
new file mode 100644
index 000000000..01f83a095
--- /dev/null
+++ b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_2_3ed7589687fe251066677ad5a01bbbb0._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-09-23T17:04:38Z"
+ content="""
+Actually, git-annex doesn't currently build on debian stable because it
+needs a newer version of optparse-applicative. The new version builds just
+fine on stable, so could easily be backported. I could probably get
+git-annex building with the old version of optparse-applicative, with
+sufficient ifdef pain, but a backport would be a nicer solution.
+"""]]
diff --git a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_2_557d428d2aa6bf8e5d435e7f5350f5c6._comment b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_2_557d428d2aa6bf8e5d435e7f5350f5c6._comment
new file mode 100644
index 000000000..179c70f58
--- /dev/null
+++ b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_2_557d428d2aa6bf8e5d435e7f5350f5c6._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="comment 2"
+ date="2015-09-23T16:36:08Z"
+ content="""
+Shouldn't it be possible reasonably easily to create env which would just use stock haskell-platform?  that one should provide all recent libraries you would need? and then just do that on e.g. debian stable
+"""]]
diff --git a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_4_641389c7c52fa4f624ae74b5d32a6b1c._comment b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_4_641389c7c52fa4f624ae74b5d32a6b1c._comment
new file mode 100644
index 000000000..83a01311c
--- /dev/null
+++ b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_4_641389c7c52fa4f624ae74b5d32a6b1c._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2015-09-23T17:14:14Z"
+ content="""
+It might be possible to use stackage to get a build of all libraries from
+the base haskell platform that are not too far out of date and don't break
+too often. There is currently no way to upgrade such a build to get newer
+version of libraries except for throwing the whole build tree away and
+building all libraries again. So, it would be a lot of CPU on an ongoing basis,
+or a source of unfixed security bugs. 
+
+And, I think it would not be entirely non-fragile. It's not exactly unheard
+of for a new version of a haskell library to accidentially break
+compatability with the old version of ghc which is generally unused in the
+haskell community outside of debian stable. Or, to need a newer version of
+some C library headers than is in stable, or ...
+"""]]
diff --git a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_5_8d5e7b7aa25a82e14611e0b852512adf._comment b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_5_8d5e7b7aa25a82e14611e0b852512adf._comment
new file mode 100644
index 000000000..d3662569c
--- /dev/null
+++ b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_5_8d5e7b7aa25a82e14611e0b852512adf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2015-09-23T17:35:51Z"
+ content="""
+I've added an "ancient" autobuild, which is run on Debian stable plus
+minimal backports (currently of optparse-applicative only).
+"""]]
diff --git a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_6_391d0ba1cbe59de8e0cca2c29085d9fd._comment b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_6_391d0ba1cbe59de8e0cca2c29085d9fd._comment
new file mode 100644
index 000000000..70f53ea04
--- /dev/null
+++ b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_6_391d0ba1cbe59de8e0cca2c29085d9fd._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="comment 6"
+ date="2015-09-23T17:57:43Z"
+ content="""
+so far we are not bottlenecked in CPU power, so if needed could setup some CPU-intensive rebuilding of such environments (e.g. in a docker) so we could may be even have some \"collection\" of previous environments laying around
+"""]]
diff --git a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_7_a72bed153e91e32ebd8944e5ee17c186._comment b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_7_a72bed153e91e32ebd8944e5ee17c186._comment
new file mode 100644
index 000000000..86043c49f
--- /dev/null
+++ b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_7_a72bed153e91e32ebd8944e5ee17c186._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2015-09-30T17:09:49Z"
+ content="""
+I got stack working to build git-annex over the weekend, and it's now the
+recommended way to build from source, since it avoids library churn issues
+and automates everything. Upgrades can also be made to happen by increasing
+the lts version in the stack.yaml file.
+
+So using that and the haskell platform would be a way to get an even more
+ancient distribution autobuilding. (But, I had to leave out xmpp and dbus
+support to make the stack recipe work everywhere, so I don't want to make
+the regular autobuilds built using stack.)
+"""]]
diff --git a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_8_be1d950835ee47774063e1335dd043e3._comment b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_8_be1d950835ee47774063e1335dd043e3._comment
new file mode 100644
index 000000000..218126f25
--- /dev/null
+++ b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_8_be1d950835ee47774063e1335dd043e3._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="standalone builds"
+ date="2015-10-08T16:35:10Z"
+ content="""
+Thanks Joey.  So the standalone builds you currently have will still be full featured builds, but where could we get those ones with limited functionality?  may be they could be automated and made available alongside with corresponding description (for older systems, without assistant functionalities such as X and Y)?
+"""]]
diff --git a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_9_805c0e3d4f3d0f3d4c1d4e6e9a5cf032._comment b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_9_805c0e3d4f3d0f3d4c1d4e6e9a5cf032._comment
new file mode 100644
index 000000000..c1d9a876e
--- /dev/null
+++ b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_9_805c0e3d4f3d0f3d4c1d4e6e9a5cf032._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="ah -- the 32bit build I guess"
+ date="2015-10-08T17:50:50Z"
+ content="""
+ah -- now I saw  the https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-i386-ancient.tar.gz which is I guess as ancient as it could get ;)  unfortunately \"was built without its test suite; not testing\" so can't test but let's see how it performs ;) 
+"""]]