— How to Build Raspbian Source Packages
— :Document created 2014-07-07 05:44:51 by pdwilso@gmail.com
How to Build Raspbian Source Packages
Overview
Using the instructions found in HowTo Build a Package from Source the Smart Way ./Build-Pkg-Smart-Way.pdf.tar.gz as a guide, we have performed the following steps:
Setup
1. Freshly installed Raspbian image on SD card
2. Edit /etc/apt/sources.list
sudo vi /etc/apt/sources.list
... to add the line ...
deb-src http://mirrordirector.raspbian.org/raspbian/ wheezy main contrib non-free rpi
... then save the file.
The resulting sources.list file on the Pi looked like this:
deb http://mirrordirector.raspbian.org/raspbian/ wheezy main contrib non-free rpi
deb-src http://mirrordirector.raspbian.org/raspbian/ wheezy main contrib non-free rpi
3. Run sudo apt-get update
4. Run sudo apt-get build-deps <packagename>
Note that these steps outlined above are mostly analogous to the steps outlined in the PDF file, except that we are concerning ourselves exclusively with what we can get from the raspbian repository. This is what we want — I.E. we do NOT want to have to seek upstream from Raspibian into the Debian package repositories - the only ones were interested in are those that have already been built for our platform/distro, and those that will be built for our platform / distro.
This approach presumes that all the Debian APT package manipulation and management commands will work using only Raspbian packages and repositories.
I am not going to detail the original steps given in the PDF here in the interest of readability of this document, however, at this point in the guide document, the author states clearly:
"Those are the last commands you should run as root before installing the DEB. All of the build commands should be run as normal user."
When we say "at this point in the procedure" we mean:
- Have added a source package repository to sources.list
- Have run 'sudo apt-get update' against the new repositories.
- Have installed build dependencies for package(s) to be built.
Also note that everything up to this point has been package-agnostic — that is,
- these steps need to be performed for all source package builds.
- The edit of the sources.list only needs to be done when a new source package repository is added.
- The apt-get build-deps operation should be performed each time a new source package is to be used — remember packages can be updated, and there are perhaps other configuration changes which could cause the package build dependencies to change.
Once the build dependencies are installed by root, the action shifts to the user account.
{* In this case, we're on a Vanilla Raspbian Raspberry Pi, so the user is 'pi' *}
Get the Source Code Package
As ordinary user we do the following
apt-get source <packagename>
Issue this command while the Current Working Directory (CWD) is set to the parent directory of the source tree that will be installed for the package we're going to build.
Note that <packagename> is the Debian APT package name of the package you want to build. I.E. NOT the file name. In this case, we're using package name 'xscreensaver' to install the screen hack sources. The version number of the package is appended to the package name when the package is retrieved from the repository.
Dependency on devscripts Pacakge
The next operation listed in the guide document did not work on the first try, and investigation of that problem uncovered a dependency that was not listed — the devscripts package, which contains the deb utilities, including debchange, the one suggested by the guide as a way to change the version number of the source package. If one wants to do this — and the rationale behind is not yet entirely clear to me, I admit — then you will need to have the devscripts package installed.
sudo apt-get install devscripts
Using debchange
Going to cover some specifics of using the debchange utility (from the devscripts package mentioned above) to change the Version of the installed source package; doing this here because it was not covered in the document we're using as a guide, and it's obscure enough information that it should probably be covered in a how-to of this nature...
The use of the command given in the Debian PDF document is
debchange -b -v N.N.Nc-N~bpoNN+N
... where the string N.N.Nc-N~bpoNN+N is the version to assign to the package going forward. Furthermore, the version string assigned by the example includes the version of the source package installed (N.N.Nc-N) conjoined to 'bpo' — which is a TLA for 'BackPOrt' — followed by what one might presume is a backport version number conformant to some backport numbering scheme ... by a '~' character.
Note that in the above paragraph, 'N' indicates one or more digits, a '.' indicates a literal period ('.'), and 'c' indicates an alpha-numeric character. These together make up the version string or version number string.
So. Reading the manual page for debchange (installed with devscripts package, above) we find that indeed this utility is — or can be — used to adjust the version numbering of source packages...
The manual page also shows the reason the name of the package is not mentioned in the command line to change the version number (something I'd been wondering about since I first read the how-to begin with). The reason is simple, and given in the second sentence of the first paragraph of the manual page:
debchange or its alias dch will add a new comment line to the Debian changelog in the current source tree. This command must be run from within that tree.
So - the only other argument given on the debchange command line is -b for which the manual page tells us:
--force-bad-version, -b
Force a version number to be less than the current one
(e.g., when backporting).
Choosing a New Version String
So it's the "backporting" process I don't understand, it seems. or the versioning of it. Backporting as a topic is beyond the scope of this document and I'm not going to try to cover it here. Or even use the word.
For instance, I can see how the author of the Debian How-To set the version number to an older, "bad" or 'backported' version, I'm just not clear on why the version was handled in this way....? I think what I may be looking for is a way to make my own, local branch of the code. That would give me a local package to maintain, and a way to maintain and document changes, additions, and deletions to and from the code.
Based on remarks made in the
serverfault.com thread
How should I create a local fork of a Debian Package?, we will proceed with the idea that using
debchange to induce a new version number of
<existingverstr>+0x0000.00.00 or some such will be sufficient to protect the system package system as well as provide some revision control for changes to the source package(s).
Look into using Git to manage Source Package sources?
2014-07-07 04:20:55
pdwilso@gmail.com
There is more to this - we haven't run the Debian Package Build Tools yet.**
Building the Source Package
The next step is (still as ordinary user, and within the Source Package directory):
dpkg-buildpackage -rfakeroot -us -uc
This command did not work, returning a failed dependency 'unable to build config.status' or something like that.
Continuing build process using make.
Building using Make
A number of warning regarding set but unused variables.
Also got:
/usr/include/gtk-2.0/gtk/gtkitemfactory.h:47:1: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
{* 2014-07-07 19:38:03 — material moved here from :Calendar:2014:07:07 *}
Ultimate Failure of Guiding Document
2014-07-07 18:59:07 — Directly quoting The Guiding Document below; this is the point at which the process ceased to work on the Raspberry Pi — the command shown below failed with minimal error reporting, and no real clue about how to proceed.
From The Guiding Document:
"Next, build the DEB:
dpkg-buildpackage -rfakeroot -us -uc
That last command may take a minute or an hour or three hours. It all depends on the size of the package and your own hardware."
That just didn't work. The dpkg-buildpackage operation ran for quite a long time, then failed without waring, complaining about some config.status file which apparently may or may not have existed in some file system at some time etc.
I believe the goal of this command is to build a the package binaries from the source code, then build a deb package from the binaries, which can be installed later. {* 2014-07-07 19:26:25 * NOTE: we have already successfully built the package using ./configure ; make from the command line. *}
The Guiding Document goes on to assume that there were no problems at all with their arcane command:
"Once the dpkg-buildpackage command finishes, you'll find the DEB(s) in your /home/XXXX/my_build/ directory and you can install them (as root) with:
cd /home/XXXX/my_build/
dpkg -i <packagename>_<version>_<architecture>.deb
It doesn't get much simpler than that."
.... well, it may not get much simpler than that, but it doesn't get much more dysfunctional than that, either, and we should all at this point know better than to sacrifice functionality to simplicity. That is, it may be dead simple, but that's not an advantage if it doesn't do anything — or worse, if it fails without explanation, as this did.
If one continues reading in The Guiding Document (which we almost didn't — should fix some stuff, there, you Debian Forum authors, you) we find that there is — directly subsequent to the above non-sequitur in The Guiding Document — a detailed and pointed discussion of a tool called "dh-make" which may run some other utility or script which may set some variable or perhaps create or alter some files which may or may not affect the build — it appears they are — tacitly — pointing the way to a solution to the unacknowledged problem which many users had to have experienced trying to follow The Guiding Document's earlier, flawed instructions.
We shall see.
2014-07-07 19:23:31
dpkg-buildpkg docsdh_make docs
Guiding Document Fail
Okay, this is where the guiding document completely fails to address the situation — there is no 'dh_make' command on the Rapsberry Pi vanilla Raspbian Latest — not even with devscripts already installed. We will do a system update for awhile, and come back to this later.
The most recent best clue is the manual page of something called "debhelper(1)" — apparently dh indicates 'debhelper' — and we can see that the debhelper command has command line options to build packages. More later.
dpkg-buildpackage.1.txt
According to the dpkg-buildpackage manual page, the parameters given for the failing dpkg-packagebuild command ( -rfakeroot -us -uc) have the following meanings:
-rfakeroot
-us
UnSigned; Do not gpg-sign the package build
-uc
Do not gpg-sign the .changes file
None of this really explains why the dpkg-buildpackage operation failed, and since the sources are already configured and building correctly using make we will leave the debugging of the the debian howto until later...
.png)
