Install amarok in Ubuntu without internet connection

One of blogwalker asked me how to install amarok in Ubuntu without internet connection. Actually for Ubuntu the need of internet is essential for upgrading libraries of add some program. You may replace the internet by having cd repositories. You could get the CD by contacting the Ubuntu.org or similar to it and asking them to send the repository in a dvd or cd. And you can have it for free. No delivery cost at all. I have tried it before. And I still have cd repo for Ubuntu 8.10.

The command for installing the amarok in Ubuntu is like this

sudo aptitude install amarok

And the Ubuntu will install the amarok and its dependencies by it self thru internet or repo cd.
Here are the amarok and its dependencies needed in Ubuntu 8.10.

amarok amarok-common{a} amarok-engine-xine{a} kdelibs-data{a} kdelibs4c2a{a} libarts1c2a{a}
libartsc0{a} libavahi-qt3-1{a} libfftw3-3{a} libifp4{a} libmodplug0c2{a} libmpcdec3{a}
libnjb5{a} libofa0{a} libruby1.8{a} libtunepimp5{a} libxcb-shape0{a} libxcb-shm0{a}
libxcb-xv0{a} libxine1{a} libxine1-bin{a} libxine1-console{a} libxine1-misc-plugins{a}
libxine1-x{a} libxvmc1{a} ruby{a} ruby1.8{a}

Oke let’s say that our friend here is not always having the internet all the time. He/she must download the amarok file first anyway. And he/she said that he/she already download the amarok in tar.gz file. So I figured it is the amarok source tar ball file. My friend beside the amarok file you have to make sure all the dependencies will meet like I mentioned above. Then you can install the amarok.

The step for installation are: (copy from wikiubuntu.com)

Packaging From Scratch

Requirements: build-essential, automake, gnupg, lintian, fakeroot, pbuilder, debhelper, dpatch, and dh-make. In this example we will be using the GNU hello program as our example. You can download the source tarball from ftp.gnu.org. For the purposes of this example, we will be using the ~/hello/ directory.

mkdir ~/hello
cd ~/hello
wget http://ftp.gnu.org/gnu/hello/hello-2.4.tar.gz

If you are packaging your own software, or the software is not available as a tar.gz file, you can create the required .tar.gz from an unpacked source directory with a command like the following:

mkdir hello-2.4
tar czf hello-2.4.tar.gz hello-2.4

For the purpose of this example, we will also compare our package (hello) to one that is already packaged in the Ubuntu repository (called hello-debhelper). For now, we will place it in the ubuntu directory so we can look at it later. This will unpack the source:

mkdir ubuntu
cd ubuntu
apt-get source hello-debhelper
cd ..

Unlike most apt-get commands, you do not need to have root privileges to get the source package, because it is downloaded to the current directory. In fact, it is recommended that you only use apt-get source as a regular user, because then you can edit files in the source package without needing root privileges. What the apt-get source command does is:

1. Download the source package. A source package commonly contains:
*

a .dsc file describing the package and giving md5sums for the source package,
*

an .orig.tar.gz file containing the source code from the author(s),
*

and a .diff.gz file containing the packaging (in the debian/ directory) and patches applied against the source code.
2. Untar the .orig.tar.gz file into the current directory.
3. Apply the unzipped .diff.gz to the unpacked source directory.

If you manually download the source package (.dsc, .orig.tar.gz, and .diff.gz files), you can unpack them in the same way apt-get source does by using dpkg-source as follows:

dpkg-source -x *.dsc

We want to recreate the above from scratch. The first thing you will need to do is make a copy of the original (sometimes called “upstream”) tarball in the following format: _.orig.tar.gz. This step does two things. First, it creates two copies of the source code. If you accidentally change or delete the working copy you can use the one you downloaded. Second, it is considered poor packaging practice to change the original source tarball unless absolutely necessary. See the section called “Common Mistakes” for reasons.

cp hello-2.4.tar.gz hello_2.4.orig.tar.gz
tar -xzvf hello_2.4.orig.tar.gz

Using an underscore (‘_’) between the package name (hello) and the version (2.4) in the orig.tar.gz, as opposed to a hyphen (‘-‘), is very important. The packaging tools look for a filename of this exact format, so if you get it wrong, the tools will incorrectly assume that there is no original source at all, and the package will be built as a Debian native package.

We now have a hello-2.4 directory containing the source files. Now we need to create the customary debian directory where all the packaging information is stored, allowing us to separate the packaging files from the application source files. We will let dh_make do the work for us:

cd hello-2.4
dh_make -e your.maintainer@address

dh_make will then ask you a series of questions about your package:

Type of package: single binary, multiple binary, library, kernel module or cdbs?
[s/m/l/k/b] s

Maintainer name : Your Name
Email-Address : your.maintainer@address
Date : Thu, 6 Apr 2006 10:07:19 -0700
Package Name : hello
Version : 2.4
License : blank
Type of Package : Single
Hit to confirm: Enter

Only run dh_make once. If you run it again after you do it the first time, it will not work properly. If you want to change it or made a mistake, remove the source directory and untar the upstream tarball afresh. Then you can migrate into the source directory and try again.

Running dh_make creates the basic files needed in debian/ and many template files (.ex) that may be needed. The Hello program is not very complicated, and as we have seen in the section called “Packaging From Scratch”, packaging it does not require much more than the basic files. Therefore, let us remove the .ex files:

cd debian
rm *.ex *.EX

For hello, some additional files from the debian directory will also be unnecessary:

*

README.Debian: Debian and Ubuntu end-user documentation file, sometimes simply named README. Not to be confused with README.source, which (if present) is documentation for those interested in modifying the source package.
*

dirs: Used by dh_installdirs to create needed directories.
*

docs: Used by dh_installdocs to install program documentation.
*

info: Used by dh_installinfo to install the info file.

Keep in mind that for most packages, these files are required. For more information on them, see the section called “dh_make example files”.

At this point, you should have only changelog, compat, control, copyright, and rules files in the debian directory.

changelog

The changelog file is, as its name implies, a listing of the changes made in each version. It has a specific format that gives the package name, version, distribution, changes, and who made the changes at a given time. If you have a GPG key, make sure to use the same name and email address in changelog as you have in your key. The following is a template changelog:

package (version) distribution; urgency=urgency

* change details
more change details
* even more change details

— maintainer name [two spaces] date

The format (especially of the date) is important. The date should be in RFC822 format, which can be obtained by using the command date -R. For convenience, the command dch may be used to edit changelog. It will update the date automatically.

Minor bullet points are indicated by a dash “-“, while major points use an asterisk “*”.

Here is a sample changelog file for hello:

hello (2.4-0ubuntu1) jaunty; urgency=low

* New upstream release with lots of bug fixes and feature improvements.

— Captain Packager Wed, 5 Jan 2009 22:38:49 -0700

Notice that the version has a -0ubuntu1 appended to it, this is the distro revision, used so that the packaging can be updated (to fix bugs for example) with new uploads within the same source release version.

Ubuntu and Debian have slightly different package versioning schemes to avoid conflicting packages with the same source version. If a Debian package has been changed in Ubuntu, it has ubuntuX (where X is the Ubuntu revision number) appended to the end of the Debian version. So if the Debian hello 2.4-1 package was changed by Ubuntu, the version string would be 2.4-1ubuntu1. If a package for the application does not exist in Debian, then the Debian revision is 0 (e.g., 2.4-0ubuntu1).

Now look at the changelog for the Ubuntu source package that we downloaded earlier:

less ../../ubuntu/hello-debhelper-2.2/debian/changelog

Notice that in this case the distribution is unstable (a Debian branch), because the Debian package has not been changed by Ubuntu. Remember to set the distribution to your target distribution release.

Consult Debian changelog Policy for more information.

control

The control file contains the information that the package manager (such as apt-get, synaptic, and adept) uses, build-time dependencies, maintainer information, and much more.

For the Ubuntu hello package, the control file looks something like:

Source: hello
Section: devel
Priority: optional
Maintainer: Ubuntu MOTU Developers
XSBC-Original-Maintainer: Captain Packager
Standards-Version: 3.7.3
Build-Depends: debhelper (>= 5)
Homepage: http://www.gnu.org/software/hello/

Package: hello
Architecture: any
Depends: ${shlibs:Depends}
Description: The classic greeting, and a good example
The GNU hello program produces a familiar, friendly greeting. It
allows non-programmers to use a classic computer science tool which
would otherwise be unavailable to them. Seriously, though: this is
an example of how to do a Debian package. It is the Debian version of
the GNU Project’s `hello world’ program (which is itself an example
for the GNU Project).

In Ubuntu we set the Maintainer field to a general address because anyone can change any package (this differs from Debian where changing packages is usually restricted to an individual or a team).

Edit control using the information above (making sure to provide your information for the XSBC-Original-Maintainer field).

The first paragraph gives information about the source package. Let us go through each line:

*

Source: This is the name of the source package.
*

Section: The apt repositories are split up into sections for ease of browsing and categorization of software.
*

Priority: This sets the importance of the package to users. It should be one of the following:
o

Required – packages that are essential for the system to work properly. If they are removed it is highly likely that your system will break in an unrecoverable way.
o

Important – minimal set of packages for a usable system. Removing these packages will not produce an unrecoverable breakage of your system, but they are generally considered important tools without which any Linux installation would be incomplete. Note: This does not include things like Emacs or even the X Window System.
o

Standard – Somewhat self explanatory.
o

Optional – in essence this category is for non-required packages, or the bulk of packages. However, these packages should not conflict with each other.
o

Extra – packages that may conflict with packages in one of the above categories. Also used for specialized packages that would only be useful to people who already know the purpose of the package.
*

Maintainer: The name of the package maintainer and their email address.
*

Standards-Version: The version of the Debian Policy to which the package adheres. An easy way to find the current version is apt-cache show debian-policy | grep Version .
*

Build-Depends: One of the most important fields and often the source of bugs, this line lists the binary packages (with versions if necessary) that need to be installed in order to create the binary package(s) from the source package. Packages that are essential are required by build-essential and do not need to be included in the Build-Depends line. Note, that you don’t need to list packages that are a part of build-essential. The list of build-essential packages can be found at /usr/share/doc/build-essential/list.
*

Homepage: A URL where more information on the software can be found.

The second paragraph is for the binary package that will be built from the source. If multiple binary packages are built from the source package, there should be one section for each one. Again, let us go through each line:

*

Package: The name for the binary package. Many times for simple programs (such as hello), the source and binary packages’ names are identical.
*

Architecture: The architectures for which the binary package(s) will be built. Examples are:
o

all – The source is not architecture-dependent. Programs that use Python or other interpreted languages would use this. The resulting binary package would end with _all.deb.
o

any – The source is architecture-dependent and should compile on all the supported architectures. There will be a .deb file for each architecture (_i386.deb for instance)
o

A subset of architectures (i386, amd64, ppc, etc.) can be listed to indicate that the source is architecture-dependent and does not work for all architectures supported by Ubuntu.
*

Depends: The list of packages that the binary package depends on for functionality. For hello, we see ${shlibs:Depends}, which is a variable that is used by dpkg-shlibdeps to add the shared library packages needed by the binaries to Depends:. See the dpkg-source(1) and dpkg-shlibdeps(1) man page for more information.
*

Recommends: Used for packages that are highly recommended and usually are installed with the package. Some package managers, most notably aptitude, automatically install Recommended packages.
*

Suggests: Used for packages that are similar or useful when this package is installed.
*

Conflicts: Used for packages that will conflict with this package. Both cannot be installed at the same time. If one is being installed, the other will be removed.
*

Description: Both short and long descriptions are used by package managers. Note that there is one space at the beginning of each line in the long description. More information on how to make a good description can be found at http://people.debian.org/~walters/descriptions.html

copyright

This file gives the copyright information. Generally, copyright information is found in the COPYING file in the program’s source directory. This file should include such information as the names of the author and the packager, the URL from which the source came, a Copyright line with the year and copyright holder, and the text of the copyright itself. An example template would be:

This package was debianized by {Your Name}
{Date}

It was downloaded from: {URL of webpage}

Upstream Author(s): {Name(s) and email address(es) of author(s)}

Copyright:
Copyright (C) {Year(s)} by {Author(s)} {Email address(es)}

License:

{Add licence text here. For GNU licences add the licence header
and a link to the appropriate file in /usr/share/common-licences.}

Packaging:
Copyright (C) {Year(s)} by {Your Name}
released under {the licence you choose for your packaging}

As one can imagine, hello is released under the GPL license. In this case it is easiest to just copy the copyright file from the Ubuntu package:

cp ../../ubuntu/hello-debhelper-2.2/debian/copyright .

Notice that the Ubuntu package’s copyright includes a license statement for the manual. It is important that all the files in the source be covered by a license statement.

More information, caveats and tips are available in the Copyright section.

rules

The last file we need to look at is rules. This does all the work for creating our package. It is a Makefile with targets to compile and install the application, then create the .deb file from the installed files. It also has a target to clean up all the build files so you end up with just a source package again.

Here is a simplified version of the rules file created by dh-make:

# REMOVE THIS LINE: For some reason, MoinMoin is eating shebang if it’s on the first line.
#!/usr/bin/make -f

package = hello

CC = gcc
CFLAGS = -g -Wall

ifeq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
CFLAGS += -O2
endif

#export DH_VERBOSE=1

clean:
dh_testdir
dh_clean
rm -f build
-$(MAKE) -i distclean

install: build
dh_clean
dh_installdirs
$(MAKE) prefix=$(CURDIR)/debian/$(package)/usr
mandir=$(CURDIR)/debian/$(package)/usr/share/man
infodir=$(CURDIR)/debian/$(package)/usr/share/info
install

build:
./configure –prefix=/usr
$(MAKE) CC=”$(CC)” CFLAGS=”$(CFLAGS)”
touch build

binary-indep: install
# There are no architecture-independent files to be uploaded
# generated by this package. If there were any they would be
# made here.

binary-arch: install
dh_testdir -a
dh_testroot -a
dh_installdocs -a NEWS
dh_installchangelogs -a ChangeLog
dh_strip -a
dh_compress -a
dh_fixperms -a
dh_installdeb -a
dh_shlibdeps -a
dh_gencontrol -a
dh_md5sums -a
dh_builddeb -a

binary: binary-indep binary-arch

.PHONY: binary binary-arch binary-indep clean checkroot

Let us go through this file in some detail. One of the first parts you will see is the declaration of some variables:

package = hello

CC = gcc
CFLAGS = -g -Wall

ifeq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
CFLAGS += -O2
endif

#export DH_VERBOSE=1

This section sets the flags for the compiler and also handles the noopt options for debugging.

Now look at the build rule:

build:
./configure –prefix=/usr
$(MAKE) CC=”$(CC)” CFLAGS=”$(CFLAGS)”
touch build

This rule runs ./configure with the proper prefix, runs make and creates a build file that is a timestamp of the build to prevent erroneous multiple compilations.

The next rule is clean, which runs make -i distclean and removes the files that are made during the package building.

clean:
dh_testdir
dh_clean
rm -f build
-$(MAKE) -i distclean

Next we see an empty binary-indep rule. Some packages create architecture-independent .debs if they do not contain files that are specific to the processor. Most Python or artwork packages would be examples of this, their packages end with _all.deb.

hello is a C program, so it compiles different code for each architecture. The packages will end with _i386.deb for 32-bit architectures, _amd64.deb for 64-bit architectures, _lpia.deb for MIDs, etc. For these architecture-dependent packages, binary-arch field is used:

binary-arch: install
dh_testdir -a
dh_testroot -a
dh_installdocs -a NEWS
dh_installchangelogs -a ChangeLog
dh_strip -a
dh_compress -a
dh_fixperms -a
dh_installdeb -a
dh_shlibdeps -a
dh_gencontrol -a
dh_md5sums -a
dh_builddeb -a

This is running a number of debhelper scripts which create our .deb packages. dh_testdir and dh_testroot make some sanity checks. dh_installdocs and dh_installchangelogs install files which you can specify in *.doc and *.changelog files. dh_strip will take debugging symbols out of the application files making them much smaller. dh_compress runs gzip on some documentation files. dh_shlibdeps adds library dependencies to the Depends: ${shlibs:Depends} field in debian/control. Finally dh_builddeb builds our .deb file. You do not have to worry too much about these scripts–they should create the packages without problems.

There is one other file, compat, which just contains a version number for the debhelper scripts. Occationally new versions of debhelper are released, the current version is 6 so you should set compat to 6. If it is set to an older version then the debhelper scripts will behave slightly differently.

postinst and prerm

The postinst and prerm files are examples of maintainer scripts. They are shell scripts that are executed after installation and before removal, respectively, of the package. In the case of the Ubuntuhello package, they are used to install (and remove) the info file. Go ahead and copy them into the current debian directory.

cp ../../ubuntu/hello-2.1.1/debian/postinst .
cp ../../ubuntu/hello-2.1.1/debian/prerm .

Building the Source Package

Perhaps more common than building the binary package locally is to do it through pbuilder after building the source package. Let’s move into the root of the extracted source (i.e. ~/hello/hello-2.4) where we build the source package using debuild along with a special option:

debuild -S

What the -S flag does is tell debuild to build a source package using another script, dpkg-buildpackage, together with fakeroot, which grants us fake root privileges while making the package. It will take the .orig.tar.gz file and produce a .diff.gz (the difference between the original tarball from the author and the directory we have created, debian/ and its contents) and a .dsc file that has the description and md5sums for the source package. The .dsc and *_source.changes (used for uploading the source package) files are signed using your GPG key.

If you do not have a gpg key set up you will get an error from debuild. You can either set up a gpg key or use the -us -uc keys with debuild to turn off signing. However, you will not be able to have your packages uploaded to Ubuntu without signing them. To make sure debuild finds the right gpg key you should set the DEBFULLNAME and DEBEMAIL environment variables (in your ~/.bashrc for instance) to the name and email address you use for your gpg key and in the debian/changelog. Some people have reported that they were unable to get debuild to find their gpg key properly, even after setting the above environment variables. To get around this you can give debuild the -k flag where is your gpg key ID.

With the source package now built, we can now use its .dsc file to build the corresponding binary package in a clean pbuilder environement:

sudo pbuilder build ../*.dsc

Using pbuilder to build the binary packages is very important. It ensures that the build dependencies are correct, because pbuilder provides only a minimal environment, so all the build-time dependencies are determined by the control file.

We can check the source package for common mistakes using lintian:

cd ..
lintian -Ivi *.dsc

Requirements for new Ubuntu packages

When a source package is uploaded to Ubuntu which does not yet exist in the archive, or builds a new binary package, it will be held in the NEW queue and has to be reviewed by an Ubuntu archive team member.

Packaging

*

Most importantly: see copyright and licensing information below.
* The source and binary packages should have a sane name: neither they should clutter the namespace (such as “editor”) nor should they have an entirely nonsensical name (such as “new-stuff-manager”).
*

debian/control and debian/rules should build packages with the right Architecture:, Build-Depends[-Indep]:, and rules target (binary-arch vs. binary-indep).
* Maintainer and init scripts should not excessively mess up the system.
*

A more comprehensive list of package checks is available from the Code Review page.

Other

*

The Debian NEW Reject FAQ lists some important special cases which mostly apply to Ubuntu as well (except that we consider the GFDL as free enough).
*

Process documentation: UbuntuDevelopment/NewPackages

Packaging With CDBS

CDBS is a set of Makefile includes that uses debhelper to make building and maintaining Debian packages even easier. It uses advanced features of Makefiles to abstract the build process, so rules files end up primarily as a series of include statements. It has many advantages:

*

It produces a short, readable, and efficient debian/rules
*

It automates debhelper use for you, so you do not have to worry about repetitive tasks
* It helps you focus on more important packaging problems, because it helps without limiting customization
* Its classes have been well tested, so you can avoid dirty hacks to solve common problems
*

Switching to CDBS is easy
* It is extendable

However if your package has an oddity about how it is built you may need to tackle some of the Makefile syntax to extend CDBS and tell it what is needed.

Using CDBS for Ubuntu packages is very easy, if the software you are packaging can be configured and built using the GNU autoconf tools (the “configure-make-make install” idiom). After adding cdbs to the Build-Depends in debian/control, a basic debian/rules file using CDBS can fit in 2 lines. For a simple C/C++ application with no extra rules, such as hello, debian/rules can look like this:

#!/usr/bin/make -f

include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/autotools.mk

That is all you need to build the program! CDBS handles installing and cleaning. You can then use the .install and .info files to tune your package with the usual debhelper functions in the various sections for debian/rules.

Sometimes the upstream author has hardwired non-standard defaults into the autoconf scripts. For example, a package may place man pages in /usr/share/man/. In this case, you can specify the correct path using the following:

DEB_CONFIGURE_MANDIR=/usr/share/man/

Another situation frequently encountered with configure scripts is that you need to specify certain configuration options provided by the software author. This is handled by substituting the appropriate option for the right side of a DEB_CONFIGURE_EXTRA_FLAGS assign statement like the following:

DEB_CONFIGURE_EXTRA_FLAGS = –enable-graphics –with-gsl=/usr

Here is the list of standard configure options that are always passed to configure:

–prefix=$(DEB_CONFIGURE_PREFIX)
–includedir=$(DEB_CONFIGURE_INCLUDEDIR)
–mandir=$(DEB_CONFIGURE_MANDIR)
–infodir=$(DEB_CONFIGURE_INFODIR)
–sysconfdir=$(DEB_CONFIGURE_SYSCONFDIR)
–localstatedir=$(DEB_CONFIGURE_LOCALSTATEDIR)
–libexecdir=$(DEB_CONFIGURE_LIBEXECDIR)

< <Include(PackagingGuide/Lists/CDBSModules, , from="StartEnglish", to="

Common Mistakes

dh_make Example Files

When you use dh_make to create the initial "debianization", example files for various tasks are created in the debian/ directory. The templates have a .ex extension. If you want to use one, rename it to remove the extension. If you do not need it, remove it to keep the debian/ directory clean.

Abusing {{{.dirs}}} files

Many packages wrongly use dh_installdirs and .dirs files to create directories. 99% of those cases are not necessary, since dh_install and .install files will automatically take care of creating directories. You only need to use dh_installdirs if your package needs to ship empty nonstandard directories, e. g. /etc/mypackage/plugins.d/.

Changing the Original Tarball

There are two types of source packages, native and non-native.

A native package is one that is specific to Ubuntu/Debian. It has the debian/ directory containing the packaging information and any changes to the source included in the tarball (usually _.tar.gz).

Non-native packages are more common. A non-native package splits the source package into a _.orig.tar.gz tarball that is identical (hopefully md5sum identical) to the source tarball downloaded from the project’s homepage and a .diff.gz file that contains all the differences (debian/ directory and patches) from the original source tarball. The following deals primarily with non-native packages.

Here is a list of potential problems that can occur if you change the original tarball:

1.

Reproducibility: If you take just the .diff.gz and .dsc, you or someone else has no means to reproduce the changes in the original tarball.
2.

Upgradeability: It is much easier to upgrade to a new upstream (from the author) version if the .orig.tar.gz is preserved and there is a clear separation between the upstream source and the changes made to produce the Ubuntu source package.
3.

Debian to Ubuntu Synchronization: Changing original tarballs makes it hard to automatically sync from Debian to Ubuntu. Normally, only the .diff.gz and .dsc files change within the same upstream version, since the .orig.tar.gz file is shared by all the Debian or Ubuntu revisions. It is much more difficult to sync if the md5sums of the .orig.tar.gz files are not the same.
4.

Usage of Revision Control for Debian package: If you use svn (and svn-buildpackage) or similar tools to handle your Debian package, you usually don’t store the original tarball inside. If someone else does a checkout, he’ll need to get the original tarball separately. Other revision control systems can be used to track only the packaging files (debian/, etc.) and not the whole source. However, if the .orig.tar.gz is not the same, then obviously problems can occur.
5.

Security tracking: Consider a situation where someone wants to introduce a backdoor, rootkit or other malicious item. If the original tarball is intact, it can be scanned easily through the .diff.gz to see if the person who modified the package attempted something evil. If the tarball has changed, however, you also need to check the differences between the tarball and the original source.
6.

The .diff.gz: The option to use the .diff.gz to reflect changes to the original tarball already exists, so it is easy to make changes without touching the original tarball.

It is acceptable to change the original tarball if one or more of the following hold true:

* It contains non-free parts that cannot be redistributed. Remove those parts, and note it in the packaging. Often such packages use “dfsg” (which stands for Debian Free Software Guidelines) in the package name and/or versioning to indicate that non-free parts have been removed.
*

The authors only provide bzip2ed source.
o

Just bunzip2 the .tar.bz2 and gzip -9 the resulting tar.
o

The md5sums of the .tar you provide and the original .tar must match!
o

Eventually provide a get-orig-source rule in debian/rules that does this conversion automatically.
* Directly imported from SVN
o

Provide get-orig-source in debian/rules.

The following are not reasons to change the original tarball:

* Wrong directory layout
*

Files need to be removed to keep the .diff.gz small (e.g., files created by autotools). Everything that needs to be deleted should be removed in the clean rule. Since the .diff.gz is created with diff -u, you will not see removed files in the .diff.gz.
*

Files need to be modified. Files that need to be modified should be changed in the .diff.gz, that is its purpose!
*

Wrong permissions on files. You can use debian/rules to do this.

Solutions

*

get-orig-source the target:

get-orig-source:
cd ..; wget http://somesite.org/stuff/somesoftware-4.2.tar.bz2
bzcat ../somesoftware-4.2.tar.bz2 | gzip -9fn -c – > ../somesoftware-4.2.tar.gz
ln -s somesoftware-4.2.tar.gz ../${DEB_SOURCE_PACKAGE}_4.2.orig.tar.gz

*

get-orig-source for zip files:

PACKAGE := $(shell dpkg-parsechangelog | sed -n ‘s/^Source: //p’)
VERSION := $(shell dpkg-parsechangelog | sed -ne ‘s/^Version: (.*)-.*/1/p’)

get-orig-source:
rm -rf $@
mkdir -p $@/$(PACKAGE)-$(VERSION)
cd $@ && wget http://somesite.org/stuff/somesoftware-$(VERSION).zip
unzip -o $@/somesoftware-$(VERSION).zip -d $@/$(PACKAGE)-$(VERSION)
cd $@ && tar -cf – $(PACKAGE)-$(VERSION) | gzip -9f – > ../../$(PACKAGE)_$(VERSION).orig.tar.gz
rm -r $@

*

another get-orig-source of the target:

get-orig-source:
cd .. && wget http://somesite.org/stuff/somesoftware-4.2.tar.bz2
tar xjf ../somesoftware-4.2.tar.bz2
rm ../somesoftware-4.2.tar.bz2
mv somesoftware-4.2 somesoftware-4.2.orig
tar -cf ../somesoftware-4.2.orig.tar somesoftware-4.2.orig
rm -fr somesoftware-4.2.orig
gzip -9fn ../somesoftware-4.2.orig.tar

(and maybe also provide the ../somesoftware_4.2.orig.tar.gz: get-orig-source rule, or list get-orig-source within .PHONY)
*

if you use a watch file, this can be:

# Path to the debian directory
DEBIAN_DIR := $(shell echo ${MAKEFILE_LIST} | awk ‘{print $$1}’ | xargs dirname )
UPSTREAM_VERSION ?=$(shell uscan –dehs | sed -n ‘s/.*(.*).*/1/p’)

get-orig-source:
cd ${DEBIAN_DIR}/.. && uscan –force-download
bzcat ../somesoftware-${UPSTREAM_VERSION}.tar.bz2 | gzip -9fn -c – >
${CURDIR}/${DEB_SOURCE_PACKAGE}_${UPSTREAM_VERSION}.orig.tar.gz

*

directly imported from cvs

CVSDATE+=22 May 2007
SW_VERSION+=4.2

TARFILE+=somesoftware_$(SW_VERSION)~cvs$(shell date -d “$(CVSDATE)” +%Y%m%d).orig.tar.gz
CVSHOME+=:pserver:anonymous@somesoftware.cvs.sourceforge.net:/cvsroot/somesoftware

get-orig-source::
cvs -d$(CVSHOME) login
cvs -d$(CVSHOME) export -D “$(CVSDATE)” somesoftware
tar czf $(CURDIR)/../$(TARFILE) $(CURDIR)/somesoftware
rm -rf $(CURDIR)/somesoftware

../$(TARFILE):: get-orig-source

Tips

*

Always remember to reference get-orig-source: in debian/rules when you need to repack the orig.tar.gz. Explaining why you repacked it and how others can verify your work.
*

It is always a good idea to contact upstream regarding issues with autoconf or directory layout (or old Free Software Foundation addresses in a COPYRIGHT file), etc. so that you can avoid having to patch the .diff.gz at a later date.
*

Older packages (from Debian Policy 3.3.8 or earlier) keep the information on repacking in debian/README.Debian-source. When updating an older package, it is acceptable to leave it here, but when upgrading or packaging new software debian/copyright is much preferred.
*

If a package already contains a debian/ directory, do not repackage it. Ask the author(s) to delete debian/ and provide a diff.gz instead. This makes it easier to review their work, and it separates packaging from program source.

Copyright Information

When dealing with copyright information of packages, the following points are critical, since they determine whether we are allowed at all to redistribute the package. Packages must not be accepted if any of these points is not fulfilled:

*

The upstream tarball must contain verbatim copies of all licenses that are used by the files in the tarball. References to URLs or paths to system files (such as /usr/share/common-licenses/) are not sufficient. The license(s) must accompany the source code.
* For all files it must be clear under which license they fall. Source code files should usually have a short comment at the top which points out the license.
*

Files shipped under the GPL must be in the ‘preferred form of modification’ format. This applies to some other free licenses like the MPL, too (but e. g. not to BSD). Negative examples are Flash animations (*.swf), most PostScript/PDF files, and automatically generated source code. The suspicious-source script in the ubuntu-dev-tools package helps to spot such files.
*

debian/copyright must list the primary copyright holders and all licenses (use pointers to /usr/share/common-licenses/ licenses included there), and declare which licenses apply to which parts of the package.
* Since there are now multiple versions of the GPL and LGPL, the copyright headers and files must be clear about which version(s) apply.

Common errors:

* Not shipping a copy of the LGPL when e. g. the build system is under LGPL, but the actual source is GPL
*

Shipping PDFs and other files without source like a LaTeX or OpenOffice document
*

Documentation is actually under GFDL, but debian/copyright does not mention it. As of gutsy, the GFDL is in /usr/share/common-licenses/, so a pointer there is sufficient for debian/copyright.
*

debian/copyright only mentions a license, but no copyright
*

The source files and/or debian/copyright are not clear about which files fall under which license
*

Source is shipped under “GPL 2 only”, while debian/copyright says “GPL 2 or later”
* GPLed packages link against OpenSSL (directly or indirectly)
*

Different copyright holders and different licenses not mentioned in debian/copyright. Please grep -ir copyright * your packages’ directories to make sure you got them all. In the case of large numbers of trivial copyright holders, not all need be mentioned (ask on IRC if you are in doubt), but all licenses must be listed.

The rule of thumb is: look at copyright definitions in the source code and accompanying COPYING/AUTHORS file, as well as all involved licenses. There is no such thing as a general rule of thumb to get it right because different licenses have different requirements for redistribution. While a public domain license may even state that you can do everything with the source code (which would mean that you need not put anything into debian/copyright and are even free to include your own may-be-distributed-in-CD-form-only-on-rainy-Saturdays license), other licenses may impose certain restrictions, such as having to include the copyright statement, credit the original authors or make clear if the source code is altered from its original form. Sometimes the involved licenses even conflict with each other (e.g. GPL and OpenSSL License), which means that the resulting binary package cannot be distributed.

There are six interesting things that are kept in Debian copyright, as follows:

1. Who created the package, and on which date s/he did that. This isn’t a legal requirement, but helps identify a person who may have a relation with upstream.
2.

The location from which the updated source can be downloaded, although a watch file and a get-orig-source target in debian/rules are recommended where possible.
3. Any licensing for the packaging. Ideally, this should be the same as for the package, unless the packaging was copied from another package with a more restrictive license.
4. The names of any upstream authors. This is mostly to give credit where it is due.
5. Identification of the copyright holder(s). These are the people ultimately responsible for the licensing of the work, although they may have granted the right to sublicense to other parties.
6.

Description of the license under which the work is being distributed. This is typically the full text of the license, but may be a shorter form for some common licenses (e.g. GPL, LGPL, BSD, Artistic License etc.). In such a case you can refer to the corresponding file in the /usr/share/common-licenses/ directory.

Note that items 5 and 6 are legal requirements.

Example 1: GPL

The GPL requires that its complete text be distributed along with GPL-licensed software (you can refer to /usr/share/common-licenses/GPL, which always exists on Debian/Ubuntu systems), in addition to information about the author(s) and a short disclaimer of warranty (which you should include in debian/copyright). For example:

License: GPL-2

Copyright (C)
.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA

X-Comment: On Debian GNU/Linux systems, the complete text of the GNU General
Public License can be found in the /usr/share/common-licenses/GPL file.

Please note that we use the new machine-readable copyright format here. Also, please note that upstream can choose to restrict a license to one specific version of the GPL, in which case you will need to modify the above text. Typically, such a restriction would be written in the source code files of a package, and you could simply copy it into debian/copyright.

Always ensure you are using the correct version of the license, be it GPL 2 or 3, or LGPL 2.0, 2.1 or 3. Use licensecheck to verify that the licenses of all files are consistent. Also, make sure that full copies of the licenses have been included by upstream, as it is not uncommon for the texts of LGPL and FDL to be missing.

Example 2: GPL with different GPL derived files from a different author

It is not uncommon for copyright notices to be written incorrectly, so always grep the word “copyright” to try and gather non-obvious information about a given project’s authorship. Then, be sure document the information in debian/copyright, as this file must include a list of all contributing authors and the files they modified. The typical format is as follows:

Files: src/foo.c:
Copyright: © 2004-2005 by Cracky Coder.
License: GPL-2

Files: src/bar.c:
Copyright: Based on foobar © 2001 by Harry Hacker.
License: GPL-2

For more details, see the documentation for the proposed machine-readable copyright format.

General advice

Combining GPL and another license will always make the combined work to be GPL or undistributable if the licenses conflict. What licenses can be combined can be found at http://www.gnu.org/licenses/license-list.html.

Usually you’ll need to list the different licenses as well in debian/copyright. A good way to do this, is to list files with a different license together with the license in question. Wether you’ll actually need to list the different licenses depends solely on the license involved.

What you don’t need to mention is licenses from libraries against which the package links. They are accompanied by their own copyright file and the package in question can never be installed w.o. the library in question. Of course there are exceptions which impose different restrictions, like the OpenSSL license which requires a disclaimer to be present in debian/copyright if it’s used (as in linked against) in a project. But these additional restriction mean, that the used library is incompatible with the GPL.

While usually most of the projects don’t have any legal issues, it’s very simple to introduce these with inaccurate copyright-files. Finally there is a rule of thumb: Better safe than sorry – be verbose and list everything which you are not sure if it should go into debian/copyright or not.

Try it. Or my friend if you still have trouble for it? I will build the deb file for you include the dependencies. Just contact me for further info.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.