diff options
| -rw-r--r-- | doc/devblog/day_15-17__Android_rebuild.mdwn | 67 | ||||
| -rw-r--r-- | doc/forum/Syncing_with_an_encrypted_remote_from_a_different_computer__63__/comment_3_7e71d355457d6b1a0391d4cdae6895e6._comment | 16 |
2 files changed, 83 insertions, 0 deletions
diff --git a/doc/devblog/day_15-17__Android_rebuild.mdwn b/doc/devblog/day_15-17__Android_rebuild.mdwn new file mode 100644 index 000000000..758e2d097 --- /dev/null +++ b/doc/devblog/day_15-17__Android_rebuild.mdwn @@ -0,0 +1,67 @@ +Made a release on Friday. But I had to rebuild the OSX and Linux standalone +builds today to fix a bug in them. + +Spent the past **three days** redoing the whole Android build environment. +I've been progressively moving from my first hacked up Android build env to +something more reproducible and sane. Finally I am at the point where I can +run a shell script (well, actually, 3 shell scripts) and get an Android +build chroot. It's still not immune to breaking when new versions of +haskell libs are uploaded, but this is much better, and should be +maintainable going forward. + +This is a good starting point for getting git-annex into the F-Droid app +store, or for trying to build with a newer version of the Android SDK and +NDK, to perhaps get it working on Android 4.3. (Eventually. I am so sick +of building Android stuff right now..) + +Friday was all spent struggling to get ghc-android to build. I had not built +it successfully since February. I finally did, +on Saturday, and I have made my own fork of it which builds using a +known-good snapshot of the current development version of ghc. Building +this in a Debian stable chroot means that there should be no possibility +that upstream changes will break the build again. + +With ghc built, I moved on to building all the haskell libs git-annex +needs. Unfortunately my build script for these also has stopped working +since I made it in April. I failed to pin every package at a defined +version, and things broke. + +So, I redid the build script, and updated all the haskell libs to the +newest versions while I was at it. I have decided not to pin the library +versions (at least until I find a foolproof way to do it), so this new +script will break in the future, but it should break in a way I can fix up +easily by just refreshing a patch. + +The new ghc-android build has a nice feature of at least being able to +compile Template Haskell code (though still not run it at compile time. +This made the patching needed in the Haskell libs quite a lot less. Offset +somewhat by me needing to make general fixes to lots of libs to build with +ghc head. Including some fun with `==#` changing its type from `Bool` to +`Int#`. In all, I think I removed around 2.5 thousand lines of patches! +(Only 6 thousand lines to go...) + +Today I improved ghc-android some more so it cross builds several C libraries +that are needed to build several haskell libraries needed for XMPP. +I had only ever built those once, and done it by hand, and very hackishly. +Now they all build automatically too. + +And, I put together a script that builds the debian stable chroot and +installs ghc-android. + +And, I hacked on the EvilSplicer (which is sadly still needed) to +work with the new ghc/yesod/etc. + +At this point, I have git-annex successfully building, including the APK! + +---- + +In a bored hour waiting for a compile, I also sped up `git annex add` +on OSX by I think a factor of 10. Using cryptohash for hash calculation +now, when external hash programs are not available. It's still a few +percentage points slower than external hash programs, or I'd use it by +default. + +---- + +This period of important drudgery was sponsored by an unknown bitcoin +user, and by Bradley Unterrheiner and Andreas Olsson. diff --git a/doc/forum/Syncing_with_an_encrypted_remote_from_a_different_computer__63__/comment_3_7e71d355457d6b1a0391d4cdae6895e6._comment b/doc/forum/Syncing_with_an_encrypted_remote_from_a_different_computer__63__/comment_3_7e71d355457d6b1a0391d4cdae6895e6._comment new file mode 100644 index 000000000..81de3fc45 --- /dev/null +++ b/doc/forum/Syncing_with_an_encrypted_remote_from_a_different_computer__63__/comment_3_7e71d355457d6b1a0391d4cdae6895e6._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="https://me.yahoo.com/a/FHnTlSBo1eCGJRwueeKeB6.RCaPbGMPr5jxx8A--#ce0d8" + nickname="Hamza" + subject="comment 3" + date="2013-09-23T00:34:24Z" + content=""" +I do not use the assistant I prefer command line but try adding an USB drive (last I used it it had the option) It should do the clone and init it check the resulting folder if it contains a .git/ folder you have a clone of your git repo. + +a) For manual cloning follow http://git-annex.branchable.com/walkthrough/adding_a_remote/ + +b) you need to keep syncing to the clone too. asistant should automatically sync to that repo. AFAIK asisstant detects when the usb repo is plugged and automatically syncs to it (again I do not use it but I seem to remember one of joey's talks showing that. YMMV) + +If you lose all your repos then you lose the keys to un encrypt files they are gone!, if you have a outdated repo you can get the files back using the key stored in it but without the directory structure. + +Correct workflow depends on how you use annex. I sync 3 computers with annex so if one dies I can clone the repo from another one. But if you are only using it on a single computer I would use a clone on an external usb drive that is always connected, so you have two clones one on the internal disk and one on the external disk so you can survive one of the drives crashing. +"""]] |