Debian Packaging

We are tying make an app to track progress of this effort. See more info at http://piratepad.ca/TlEP1VOwGF

If anyone interest to help out jump in, we need coding help.

Cedric has created this dependency graph http://people.debian.org/~boutil/diaspora/deps.pdf You can visually track the progress now - we need to make all the circles green!

We had to spend some extra effort working on an obsolete gem :( Can someone respond to this https://github.com/diaspora/diaspora/issues/3735 ? I requested the removal of this package on the same day it entered!

Capistrano-Ext has been dropped, should be good now. :)

Current documentation: http://wiki.debian.org/Diaspora/Packaging

Progress Bar: http://vps.aneesh.nl/diaspora.html

Awesome. I'd love to get the existing Debian packages copied over to our Ubuntu PPA as well. :)

Well personally I'd be happier just doing it the RVM way. IMHO forcing users to install all the Ruby gems to the system is a bit restrictive and to make installation easy for anyone we can pull the gems under the users RVM installation easily without having to touch the system Ruby.

(previous comment about Ubuntu PPA - Debian packaging team has chosen their path :))

bundler makes it easy install the gems using the system ruby without actually installing them system wide too, no need for RVM ;)

Yeah, that is an option too. But packaging all the gems for Ubuntu is imho a very slow process.

But of course the packaging of the gems effort is absolutely fabulous anyway - I'm sure the Debian community appreciates. Great work :)

@jasonrobinson once all gems are packaged from debian, you'll just need to pull the source and rebuild it to make it work on Ubuntu (you can just automate it too).

@praveenarimbrathodiyil yes that is true, but the problem is that gems change often so in order to have a release running using native gems the packaging effort would have to be always up to date very soon after the gems are bumped in Diaspora*. So personally I see that kind of risky and thus would prefer local installations either via bundler or by using rvm. But let's see how the debian gem porting progresses :) No time for the ubuntu packaging personally atm, maybe closer to summer..

@jasonrobinson yes, we do expect bumps on the way thanks to the volatile nature of gems, but we are determined to fix them when we encounter them.

We have covered/packaged 75% of gems required for diaspora. The remaining ones are a bit tougher, many are using rails for tests (they create some dummy rails project for tests and tests can't find config/database.yml) and very strongly tied to bundler (we remove bundler and rubygems and depend on apt to provide the correct dependencies). If anyone with rails knowledge can help us untangle the code from bundler - Bundler.require should be converted to require 'foo' in helper.rb, that would be awesome. Sam Ruby has already offered to help, but we are stuck with many gems so the more rails folks out these who can help, the better.

We were not actively packaging for some time and we had fallen behind on percentage. Now we are back to 75% again - http://people.debian.org/~praveen/diasbar/

Now and early version of diaspora package is available. You can follow the steps at https://wiki.debian.org/Diaspora and help test the package. Specifically I need help with keeping the versions in sync between diaspora and debian. Some gems already have newer versions in debian and it would be great if some of you here can help test federation when updating some important gems like rack-protection and roxml. There is also major version bumps for gems like twitter and omniauth-facebook which needs some testing help.

Diaspora package is available in debian experimental and diaspora-installer (which uses rubygems for dependencies) is available in unstable

http://tracker.debian.org/diaspora
http://tracker.debian.org/diaspora-installer

Need help in fixing one bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796979