squared99

Eureka!

After quite a bit of trial and error I finally got Trac 0.11 running on Dreamhost, using Python2.4 with subversion bindings and all.

My attempts were further complicated by the fact that I had already been using the Dreamhost subversion provided and had not installed my own.

For anyone else who may be having similar issues, here are the steps I took to get it going.

1. I set up subversion using the interface provided via the Dreamhost admin panel.

2. I setup Trac using the DreamyTrac scripts.

If all is fine you may be able to stop here believe it or not, but for me I ran into troubles with Dreamhost’s default Python install (Python2.3) and email workflow. Furthermore when I switched Trac to use Python2.4 I found out that Dreamhost hadn’t set up 2.4 with the subversion bindings. I switched back to 2.3 for awhile but found I was quite limited in what plug-ins etc I could install until I got it working with 2.4. blah blah blah, shutup and just tell us how what you did right?

3. I set up my own local Python version for 2.4 using virtualenv. But this still needs the subversion binding installed

4. I mostly followed the steps here at natmaster on installing SWIG and Subversion, replacing any reference to the default python directory with my virtualenv python directory

eg. $HOME/inst/bin/python2.4 instead of /usr/bin/python

Initially I got an error about needing to specify the apr directory, this can be specified on Dreamhost by adding the following configure options to those provided on natmaster.

–with-apr=/usr/local/dh/apache2/template/bin/apr-config –with-apr-util=/usr/local/dh/apache2/template/bin/apu-config

once that is done run the make commands as described on natmaster.

5. After all that is done, the libsvn and svn for python should be available in $HOME/packages/lib/svn-python/. I copied these into my site-packages folder for the python in my virtualenv.

eg. cp -rf $HOME/packages/lib/svn-python/ $HOME/inst/lib/python2.4/site-packages

6. Update your trac.cgi or trac.fcgi file to use the virtualenv python install. My trac.fcgi was found in $HOME/packages/share/trac/cgi-bin.

eg. change #!/usr/bin/python to #!/$HOME/inst/bin/python2.4

7. Done! At least in my case Trac was now properly running on Python2.4

I found a few tales on the web out there and ended up having to borrow bits and pieces from here and there, as well as adding a few of my own personal touches.

So I thought I would add my story, as it may help others in similar circumstances.

For the past couple months I have been working with Silverstripe and I have to say I am very impressed. Anyone looking for a new CMS should definitely check it out.

It allows both front-end and back-end customization. Meaning the admin of the CMS can be customized and added to.

I have used this approach to build the new Interact CMS system which is tied into the Interact APIs. This has allowed the creation of a slick and powerful digital content management system that can be used for both web and mobile. All the bells and whistles are there including mobile delivery, e-commerce, phone data, member management etc.

I’ve also used it used on typical website projects as the more traditional CMS. Again, it is very easy to get going with the template system and build something that is familiar from a CMS point of view for the client, but also flexible enough to be extended to the specific needs of the client.

Rather than forcing the client/user to adapt to the CMS, the CMS adapts to the user.

So I read this article on the NYT last week and meant to write about it right then and there, but as usual something distracted me and I continue to struggle to maintain my ‘at least once a month’ blog promise.

The premise of the article being that giving consumers choices and creating a competitive marketplace for Android apps is a bad thing, and that a closed system with one party controlling our digital rations is a good thing.

To this I say wha!?

Is there some sort of Stockholm Syndrome thing in the US in relation to the mobile industry.
Maybe it’s more like a technology blind spot.

Since the market has historically been dominated by carriers who controlled access to all services available via mobile it seems that just like the basic assumption that the sun revolves around the earth, (it’s obvious isnt it!?) that this how things are and always will be with mobile technology.
In fact, that is how they should be gosh darn it! I don’t want to hear this poppycock about open access, dumb pipes, etc.

So Apple comes along as the new guy, maintains this paradigm and all is right in the world. See, told you, this is how it is done!

We can trust Apple to be impartial about this, right?

But wait, what is this Android thing!? What do you mean it can be installed on more than one handset, gasp! even possibly on handsets it wasnt built for specifically. ewww, and you can buy “things” for it just anywhere. How vulgar, who knows where that app has been!

Newsflash NYT writer, if online news articles operated on those principles we’d all be going to one website to read your article and you’d have to hope it met all the proper criteria and was approved by the provider of the technology on which it would be viewed.

The biggest difference in iPhone Appstore vs Google Android is that Google isn’t necessarily looking to take a piece of the pie on every sale of an app or handset. They have a very very different approach than Apple and their iPhone strategy.

They are interested in getting something out there that can be ubiquitous fast. If that is propelled along by multiple points of access, appealing to different segments and tastes, as well as by cloned handsets then all the better for them and (in my opinion) the industry

ps. voeveo is one of those back-alley dealers where you will be able to get your Android fix.