When you want to use git on Debian its as easy as “apt-get install git-core”…… or is it? The version on the stable debian repositories (1.4.4) is very old. It lacks many of the features git users use on a regular basis. So how do you upgrade git? Well the simplest approach for getting the most recent version, for those that know how, is to wget the source, unpack, cd, configure, make, and make install. Takes about 5 minutes, and you’re up and running. But what if you don’t know how to compile, or you want to maintain package only install for your system, so upgrading and uninstalling will be easy? Where do you find a newer package?
Archive for July, 2008
In the previous part of this guide, we created an export script which produced an XML formatted output of the current versions of pages in your phpwiki installation. If you havn’t done that yet, please read the first part of this guide. Now we are going to take that file, and import it into Kete, maintaining as much as the information as possible. We’re going to cover system settings, topic types, extended fields, privacy controls and import synonyms. So lets get started.
(the following article and code applies only to phpwiki version 1.1.x and 1.2.x. Previous and future versions of this software use different methods of formatting and so will require changes to the scripts used here)
If you have a set of articles on a phpwiki that you can’t afford to lose, and want to move to Kete then theres a simple two part process you can follow to do just that. Over the next two blogs posts, I’m going to show you just how it’s done.
I was trying to install a gem on a client’s machine that I had previously been able to grab successfully, but it failed like this:
$ sudo gem install some_gem
Updating metadata for 475 gems from http://gems.rubyforge.org/
ERROR: could not find some_gem locally or in a repository
I thought perhaps rubyforge was unavailable, so I repeated the command. Still no luck. I did a web search and found a possible answer:
$ gem sources -a http://gems.github.com/ # adds metadata for the gems hosted by github
That actually didn’t do it either. Including github’s gems slowed things down when doing a gem install, so I decided to remove it from the sources list:
$ gem sources -r http://gems.github.com/ # drops github’s gems metadata
So I tried a “gem help sources” and discovered that I could clear the local cache like so:
$ sudo gem sources -c
*** Removed user source cache ***
*** Removed latest user source cache ***
*** Removed system source cache ***
*** Removed latest system source cache ***
Then I tried the gem install again:
$ sudo gem install some_gem
Bulk updating Gem source index for: http://gems.rubyforge.org/
Successfully installed some_gem
1 gem installed
Installing ri documentation for some_gem
Installing RDoc documentation for some_gem
Success! Hope this helps someone else.
When you upload a file using attachment_fu (http://github.com/technoweenie/attachment_fu), for the most part, the upload will work fine. But there are occasions that the mime type will return something that isn’t useful, such as application/octet-stream, application/x-download or a blank mime type. In these cases, it can refuse to upload a perfectly legit file. Allowing octet-stream and x-download to be uploaded, while possible, does create a certain security (permissions) issue. So how do you get around this without causing any more problems?
We at Katipo recently moved our software Kete to Github. But a few existing clients were still tied to the old SVN repository, so we had to find a way to keep the link between them so we could pull changes from git and commit them back to SVN. Using various sources from the web, we were able to do just that. Here’s how… (more…)