Use sbuild to “automate” .deb package building

[Member Xecure]

Note: This explains how to build packages for Debian (and antiX) in a clean environment. I will not explain how to prepare a non-debian-ready source for building.

Usually, we need a clean environment to build our deb packages, so that we are sure that they can work on any machine running the same Debian/antiX Release and architecture as where we build. We could use virtual machines to set that clean environment, chroot into separate prepared partitions or compressed filesystems or directly use a specific machine for building all our packages. Here I will talk about how to use sbuild, a tool that helps you create clean environments for deb package building and automate building for different environments on the same computer.

INSTALLATION
1. Install the required packages_
sudo apt install --install-recommends sbuild schroot debootstrap

2. Add your user to sbuild group (use command below or use antiX user manager)
sudo sbuild-adduser $LOGNAME

3. Copy the example config file to you user folder (and edit it to add environment and build options and variables)
cp /usr/share/doc/sbuild/examples/example.sbuildrc $HOME/.sbuildrc
3.1 Consider changing some parameters, like:
build_arch_all=1; to build for all architectures (use -A for individual builds)

4. To use already downloaded packages (caching), optionally install apt-cacher-ng
sudo apt install apt-cacher-ng

5. Log out and log in so that group assigning (in 2) takes effect

SETTING CHROOT
We now prepare the environment and profiles that sbuild will use to build our packages. We will need to specify Debian release and objective architecture. Some examples:

Example 1: Create a chroot profile for Debian buster, amd64 architecture (on a amd64 system)
sudo sbuild-createchroot --include=eatmydata,ccache,gnupg,auto-apt-proxy buster /srv/chroot/buster-amd64-sbuild http://deb.debian.org/debian/

Example 2: Create a chroot profile for Debian buster, i386 architecture (specify architecture)
sudo sbuild-createchroot --arch=i386 --include=eatmydata,ccache,gnupg,auto-apt-proxy buster /srv/chroot/buster-i386-sbuild http://deb.debian.org/debian

Example 3: Create a chroot profile for Debian bullseye amd64 release (specify architecture)
sudo sbuild-createchroot --arch=amd64 --include=eatmydata,ccache,gnupg,auto-apt-proxy bullseye /srv/chroot/bullseye-amd64-sbuild http://deb.debian.org/debian/

Note: I believe we can also use sbuild to prepare to build packages for ARM on a amd64 system, but I have not tested this claim out (and don’t have hardware to test ARM based .deb packages).

BUILDING DEB PACKAGES
Finally, we can build our .deb packages. We will need the uncompressed source (with debian folder prepared) in a folder with the correct name format (<package-name>-<version>). Example with zzzFM package: zzzfm-1.0.7.
Outside this folder, we need the compressed original source code (format <package-name>_<version>.orig.tar.gz) and optionally the debian configuration package used for this package (format <package-name>_<version>.debian.tar.gz). You can create the compressed “original source code” compressing the source folder (with the debian folder) if you want, but you need to respect the name structure.
We can launch a terminal and change directory (navigate to) inside our source folder. We can then directly build for our desired (and already created) environment.

Example 1: Build a package for buster amd64, from a amd64 system (not specifying arch):
sudo sbuild -A -d buster

Example 2: Build a package for buster i386, from a amd64 system (specifying architecture and host):
sudo sbuild -A -d buster --host=i386 --arch=i386

Example 3: Build a package for bullseye amd64 specifying the output directory
sudo sbuild -A -d bullseye --host=amd64 --arch=amd64 --build-dir='/path/to/output/folder/'
Usually, the package will be built on the parent directory, except if we specify the build directory.
(I haven’t got this –build-dir option to work yet, if someone figures this out, please let me know)

MAINTENANCE
The chroot environment and profiles created with sbuild may need some maintenance. Some of the things we can do are:

A. We can see all chroot profiles created with:
schroot -l | grep sbuild

B. We can chroot into them (to perform whatever you want there) with
sudo sbuild-shell source:<chroot-profile>
Example: chroot into our buster amd64 chroot environment.
sudo sbuild-shell source:buster-amd64-sbuild

C. We can update the packagelists in case we changed something without the need to chroot with
sudo sbuild-update -udcar <chroot-profile>
Example: update packagelists for buster i386 chroot environment
sudo sbuild-update -udcar buster-amd64-sbuild

D. Making other modifications such as editing /etc/apt/sources.list or adding scripts inside the chroot is best done from outside the chroot session. In order to do this, leave the current chroot session open and start another terminal session. In the other terminal session, find the path used for the existing chroot session as follows.
schroot --info --all-sessions | grep Path
This should output exactly one line and should specify the path of the chroot session.

E. You may remove the chroot system if you no longer need it with:

sudo rm -r /srv/chroot/<chroot-profile>
sudo rm /etc/schroot/chroot.d/<chroot-profile>-* /etc/sbuild/chroot/<chroot-profile>

F. If at some point the chroot session gets stuck, we can force it to exit with
sudo schroot --end-session --all-sessions

• This topic was modified 2 years ago by Xecure. Reason: Correct formating

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Anonymous]

Helpful

Up

0

::

Was your “dialogbox 1.02” package produced in this manner?
a head-ups:
Its “open source” code cannot be browsed when visiting the gitlab project repository
(which may be grounds for deletion and/or account termination)
and, upon downloading, I met a “tar-1” file which defied unpacking.

[Member Xecure]

Helpful

Up

0

::

Anonymous wrote:

Its “open source” code cannot be browsed when visiting the gitlab project repository
(which may be grounds for deletion and/or account termination)

Oh. I didn’t know this about binaries. I will remove them and only update the git project source.

I used this method to build your slimski to bullseye, and to build all the packages I built till now, including latest badwolf and a connman-1.39 package I am testing with Moddit.

I will update the dialogbox source project and delete all binaries I have created until now to avoid this account termination possibility. I will wait a bit more for anticapitalista to download and update the latest dialogbox in the repos before deleting it and removing the “my packages” project.

• This reply was modified 2 years ago by Xecure. Reason: Add link to source

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Anonymous]

Helpful

Up

0

::

AFAIK, we can “get away with” placing small binaries there as long as the accompanying source code is present. For larger binaries, “git” is non-ideal so we’re supposed to (expected to?) use “Large File Service”: https://docs.gitlab.com/ee/topics/git/lfs/

[Member Xecure]

Helpful

Up

0

::

Sorry for the off-topic.

I was searching if it was possible to create a APT repo using gitlab-pages, and I found this Arch repo, and the binary files are stored in a gitlab.com for free. We can see the public repo here. I think the binary files are using LFS as skidoo pointed out. So this is a method to store binaries for free. I will continue to study this possibility.

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Author]

Posts