Translation(s): none


Diaspora packaging

This page will used to store available information and links which will help to build diaspora and its dependencies for Debian.

We hang out at #debian-diaspora (on OFTC), so come there if you have any questions. Regular meetings will take place every Saturday at 8:00pm IST; 14:30 hours GMT.

FAQ

  1. Why do you have to package diaspora? - https://github.com/celluloid/celluloid/issues/263#issuecomment-18096685

  2. What does packaging Diaspora for debian mean? - https://joindiaspora.com/posts/2077249

  3. Why do you have to package all the gems? Can't you use rvm? - https://www.loomio.org/discussions/1021#comment-24085

Current status

  1. ITP - 597093

  2. Dependency graph - http://people.debian.org/~boutil/diaspora/ (take the latest)

  3. Progressbar - http://vps.aneesh.nl/diaspora.html or http://people.debian.org/~praveen/diasbar/

  4. Status updates https://joindiaspora.com/tags/debian-diaspora

Note: Feel free to improve these steps/notes. Add links to more documentation when anything is not clear.

Step 0 - Introduction

Diaspora is written in Ruby language using Rails framework. Diaspora uses many existing ruby libraries and these libraries are distributed as gems. So we need to package all depending gems to package diaspora.

Though rubygems itself is a package familiar with ruby developers, we want to provide single method via debian tools (apt/synaptic/software center) for debian users, similar to software written in every other language, so they don't have to learn how each language community distributes their packages.

If you are familiar with C programming you would know the first line of most C programs,

#include <stdio.h>

stdio.h is provided by the standard C library (glibc in most GNU/Linux distributions). It provides functions like printf and scanf. Similarly in Ruby, libraries are included by a line like,

require 'rspec'

It means that particular Ruby program (.rb file) can now use functions provided by rspec library (similar to how you use printf and scanf functions in your C program).

Step 1 - Select a Gem

Choose a gem to package from latest pdf file from http://people.debian.org/~boutil/diaspora/ (it has a graph of all dependencies for diaspora). If it has a dependency select that first.

  1. Check if it is already packaged in debian. Search for the package from http://www.debian.org/distrib/packages#search_packages

  2. Check if it is already being worked on by someone else from http://wnpp.debian.net

    Note 1: Remember to select ITP from the list and give your gem name as project

    Note 2: Debian package names uses '-' instead of '_', prepended with ruby-, unless it is an application (in opposition with libraries, ex: cucumber, rake)


Step 2 - Build a debian package

  1. ITP - say you're going to package something

  2. Initial Build with gem2deb - try building it

    1. ruby tests - make sure you run the tests

      1. basic quilt - if you want to change any upstream files

    2. pbuilder - make sure it builds cleanly (to check it has correct build dependencies)

    3. Getting packages in NEW queue - when some dependencies are waiting to enter archive in NEW

  3. Get your package reviewed and uploaded
    1. gitorious - push the code into team repo (temporary till you get access to pkg-ruby-extras repo on alioth)

    2. upload to mentors - upload it to mentors for sponsors (we usually take directly from git, so this step is not directly required, but is good for you to learn as it applies to a new package in general, you'll need this when you want to upload a package outside this team)

    3. RFS - request a sponsor to upload your package to debian

    4. Importing the package to pkg-ruby-extras git repository

  4. Updating New upstream Release



Misc

  1. git and git-buildpackage commands

  2. building packages for experimental

  3. unsorted tips

  4. setting up an environment for building packages - especially a quick-start guide for the ruby folks who want to help with tests and don't want to bother much with packaging part

  5. how to deal with changes in source tarball itself outside of patch/quilt - say you want to take githhub tarball or you want to remove vendor directory