MEPIS Package Building Guide

From MEPIS Documentation Wiki

Jump to: navigation, search

This is a work in progress for the community to develop acceptable packaging guidelines to assist Warren in developing future MEPIS versions.

Contents

Setting The Environment

Environment (Essential)

Packaging For MEPIS Official Repository

  • Clean MEPIS standard environment – only Debian Stable and MEPIS repositories enabled. A clean VM (eg virtual-box environment) is a good substitute for a clean stand alone install.
  • If any portion of your OS environment has been upgraded to testing or unstable, you cannot build for standard MEPIS repositories
  • Due to legal considerations, no packages from the Debian-Multimedia repository can be installed, and the repository must be disabled.
  • Debian backports repository disabled – they are not always compatible with MEPIS

Packaging For MEPIS Community Repository (main non-free)

  • Clean MEPIS standard environment. A clean VM (eg virtual-box environment) is a good substitute for a clean stand alone install.
  • If any portion of your OS environment has been upgraded to testing or unstable, you cannot build for standard MEPIS repositories
  • Due to legal considerations, no packages from the Debian-Multimedia repository can be installed, and the repository must be disabled. For restricted packages - see section imemdiately below.
  • Debian backports repository disabled – they are not always compatible with MEPIS

Packaging For MEPIS Community Repository (restricted)

  • Clean MEPIS standard environment. A clean VM (eg virtual-box environment) is a good substitute for a clean stand alone install.
  • If any portion of your OS environment has been upgraded to testing or unstable, you cannot build for standard MEPIS repositories
  • Debian-Multimedia repository enabled – packages produced for restricted repos will be held on server outside US / other restricted countries.
  • Debian backports repository disabled – they are not always compatible with MEPIS

Environment (Recommended)

  • Clean separate install of MEPIS on a separate test / build partition
  • Where possible we would like package builders / testers / maintainers to be able to use both 32bit and 64bit architectures.
  • If your hardware is adequate, MEPIS installs in virtual machines are useful in compiling and testing packages.

Software (Essential)

  • Basic build packages for MEPIS 8.0:
apt-get install build-essential devscripts dh-make fakeroot autotools-dev xorg-dev libqt3-mt-dev kdelibs4-dev libqt3-compat-headers
  • Basic build packages for MEPIS 8.5:
apt-get install build-essential devscripts dh-make fakeroot autotools-dev xserver-xorg-dev libqt4-dev kdelibs5-dev
  • Basic build packages for MEPIS 11:
apt-get install build-essential devscripts dh-make fakeroot debhelper dpkg-dev pbuilder (actually, anything except build-essential should be listed in the package's build-depends. Debhelper should be listed there, the others are utilities and need not be.
  • Additional build recommended packages:
apt-get install autoconf automake automake1.7 automake1.9 gpc lintian cmake pbuilder aptitude cdbs quilt patchutils

Preconfiguration

  • Add in ~/.bashrc (a hidden text file in your home directory) these environment variables:
export DEBEMAIL=maintainer@mepiscommunity.org
export DEBFULLNAME="Your Name" (use your own name!)

These must be the same as used in creating your public/private keys in gpg or Kgpg.

These variables are used by "dch -i" and dh_make when creating debs.
  • Run in a konsole terminal as a regular user
source ~/.bashrc (~ is shorthand for your home directory)

You will also need to create a public/private key pair. This can be done in the terminal with gpg, or with a user-friendly frontend such as Kgpg, under Keys >> Generate Key Pair. Make sure not to lose your gpg password! You can also export your secret key under one version, then import into Kgpg in another install.

For more information on GPG, and a video tutorial, please see the GPG page.

Documentation

Recommended Reading

Debian Packaging Documentation – optional – but should be read along with this document. Gives insights into debian packaging procedures.

apt-get install debian-policy developers-reference
  • Debian-policy: the Policy includes explanations of the structure and contents of the Debian archive, several OS design issues, the Filesystem Hierarchy Standard (which says where each file and directory should be) etc. For you, the most important thing is that it describes requirements that each package must satisfy to be included in the distribution. (see /usr/share/doc/debian-policy/policy.html/index.html)
  • Developers-reference: for all matters not specifically about the technical details of packaging, like the structure of the archive, how to rename, orphan, pick up packages, how to do NMUs (Non-Maintainers Uploads), how to manage bugs, best packaging practices, when and where to upload etc. (see /usr/share/doc/developers-reference/index.en-us.iso-8859-1.html)

Recommended Reading – Web

Base Procedure – Packaging for Official MEPIS & Community Repos

Please also refer base procedure in Community Repository

Packager (part 1)

  1. Packager starts a thread (or if version update, adds to existing thread) in the News/Package Status forum - advising that they are assigned to building a new package / version update.
  2. Packager uses one of recommended methods (in this procedure) for creating debian package
  3. Following successful deb creation, Packager tests installing the created deb, and if successful, advises their Maintainer of the availability of the completed package - along with sending him/her the necessary files for the repository (the deb(s), dsc, diff, changes and source files).

NOTE: You have to submit the maintainer the ".changes" file for a given package as well as all the files listed in the "Files:" section withing the changes file. For 64 bits packages those files cannot be of the kind "_all.deb". See Special Notes

Maintainer (part 1)

  1. On receipt of advice from their packager, the Maintainer downloads the files from the link provided, virus scans them, installs them in a test environment (to ensure working), and if ready for testing, uploads them to the test repository.
  2. Once the package appears in test, the Maintainer contacts their Packager and advises him/her to post in the original ML thread that their package is available in the Test repository, and to request testing and feedback.

Testers

  1. Testers (from the community) install debs and commence thorough checking of application.
  2. Any errors / lack of functionality are noted
  3. Following full testing, feedback is given in the original thread on MEPIS Community forum.

Packager (part 2)

  1. Packager acts on Tester feedback.
  2. If package fails successful testing with errors or loss of functionality, errors are corrected by Packager, and files resubmitted for testing.
  3. If package passes testing with full functionality, Packager's duties are complete, and Maintainer arranges for final migration of Package from test to main repository.

Maintainer (Part 2)

Once package has passed testing and is declared ready for the repository,

  1. Package is either sent to Developer certified as correct and ready for MEPIS repositories , OR
  2. If only intended for Community repositories, package and source is purged from test repository and added to main repository.
  3. For Community repository packages, the Maintainer then adds the final post to the original MEPIS Community forum thread confirming that the package is available in the main repository.
  4. The Maintainer also either adds or edits the entry in the Community Packaging Section of the MEPIS Community website.
  5. The final step is to add a short 'news' entry on the Community Website that the package has been added to the Community Repository.

Developer

If the package is intended for the MEPIS main repository:

  1. Developer uploads package to official MEPIS repository and notifies Website Maintainer to update Community News section that new package in repo.

Versioning

  1. Be sure to reversion packages by simply adding :
    • mepis1 to the end of the debian version (for official MEPIS Repository) OR
    • mcr80+1 to the end of the debian version (for 8.0 Community Repository)
    • mcr85+1 to the end of the debian version (for 8.5 Community Repository)
    • mcr110+1 to the end of the debian version (for 11.0 Community Repository)
    • mcr115+1 to the end of the debian version (for packages that will only work with the upgraded KDE 4.6.5 in the experimental CR)
    • If you are packaging from scratch a previously unpackaged or new release of a package, give it a -0 version, as in 1.2.3-0mcr110+1. This ensures an "official" Debian -1 package will take priority if it appears later in the repo or in the official backports repository, depending on pinning and apt-preferences.
  2. If the version ends in debian1 or ubuntu1 etc, drop the debian or ubuntu minor version number.
  3. Be very careful not to increase the version number any more than you have to
  4. The number should be higher than the equivalent debian number and less than the most likely next debian number.
Example:
debian: 915resolution 0.53-1
mepis: 915resolution 0.53-1mepis1
next mepis: 915resolution 0.53-1mepis2
next debian: 915resolution 0.53-2
then mepis: 915resolution 0.53-2mepis1
Community versioning follows same pattern except mcr(mepis release)+ instead of mepis.
915resolution (0.53-1mcr85+1) for the MEPIS 8.5 CR, for example.

Recommended Package Creation Methods

Basic Package Creation Decision Tree

Attempt in the order shown.

1. Backporting From Upstream Debian. The package is in the Debian pool. A newer version is available but not for Debian Stable. In this case, get the Debian source for the newer version and change the maintainer and minor info to MEPIS. Also note that source code from Debian has been vetted for security and bugs more than the following sources, making it the first choice.

NOTE - unless you are a "debian wizard�? avoid using source from debian 'experimental'
  • a. Attempt to compile it in MEPIS. If this works, great. Time to test and publish.
  • b. Try to resolve compilation issues. If there are more than 2 levels of issues, this is doomed to failure. But if it works, great.
  • c. Try a newer, but not quite so new version from Debian that may be more compatible with MEPIS. Look in the Debian snapshots pool if you know exactly what change you're trying to avoid. Maybe even inspect the change that broke compatibility and attempt to reverse it in the MEPIS version of the latest Debian version.

2. Repackaging from Debian-Backports As a fallback, check the backports pool for a Debian Stable version. Again, change the maintainer and the minor version.

  • a. Attempt to compile.
  • b. If that fails, attempt to fix the issues, again only go 2 levels deep.
  • c. You can also find older package sources from upstream at snapshot.debian.org that are still more recent than the ones in Debian stable.

3. Backporting from Ubuntu If still no success, try an Ubuntu version. Source files can be found at packages.ubuntu.com. Be very very careful about introducing Debian incompatibilities. Libraries have often been renamed. Often you can find sources in a PPA or even a private Debian-compatible repository. If so, double check the licenses of the source to make sure it can be freely redistributed. Also, Ubuntu packages must be put in the correct Debian section: free, compat, or non-free, not the Ubuntu universe and multiverse sections.

4. Packaging from Bare Source Tarball If there is no Debian packaged good version, try creating a Debianized version from vanilla source. If there is an older Debianized version, try reusing its Debian directory.

5. For packages that are unusual and not normally maintained in Debian, alternately create an installation tree manually and then build the package with dpkg -b.

Details of Each Method

1 Backporting From Upstream Debian (Recommended Method)

NOTE: MEPIS community repository policy now requires that all packages be signed with your secret key. NOTE: A detailed example of this procedure can be found in Backport.

  1. Go to http://packages.debian.org and type the name of the package you want to backport into the "Keyword" text input box, and change the "Distribution" drop-down box to "any".
  2. Click the link for the version you want to backport. You can also peruse the Debian changelog to get an idea of what is different between the versions.
  3. On the right-hand side of the page there is a section titled "Links for <packagename>". Download the three files under the sub-heading "Download Source Package". There is normally an .orig.tar.gz, a diff.gz,(or a debian.tar.gz and orig.tar.bz2 set) and a dsc file. Sometimes there may not be a .diff.gz file if the package is a Debian native and not from an upstream source, but everything from here on out is still the same. To download the .dsc, you must right-click and select "Save As", as normally the browser will open .dsc files as a plain text file. Be careful! Often the directories for clicking to save and right-clicking to save as are different. Make sure all files are downloaded to the same folder. I usually use a folder in my /home/username/Source directory titled "DEB-packagename-version".
  4. Open a console and cd to the folder you downloaded to, or navigate to the folder using Konqueror and hit "F4" to open a console at that location.
  5. In the console, type "dpkg-source -x " and then hit the tab key. If there is only one .dsc file in the directory (as there should be), then the filename will be entered automatically. Hit enter to issue the command, and the source should be extracted and patched.
  6. Type "cd " and hit tab. The newly created folder's name should be automatically filled in. Hit enter to change to the source folder.
  7. Type dch -i into the terminal and hit enter. This will open a debian changelog editor in the console with the time/date stamp and your maintainer information already entered (as long as you exported as outlined above in "Setting the Environment"). The debian version of the package will have been incremented, so change it back to the version in the previous entry in the changelog and add the appropriate tag to the end, as follows:
    • MEPIS version: foo_1.1-1mepis1
      • Community version: foo_1.1-1mlrepo1
      • If it becomes official: foo_1.1-1mepis2
    • MEPIS version: foo_1.1-1mepis1
      • Community version: foo_1.2-1mlrepo1
      • If it becomes official: foo_1.2-1mepis1
    • MEPIS version: nonexistent
      • Community version: foo_1.1-1mlrepo1
      • If it becomes official: foo_1.1-1mepis1
  8. Change "unstable" or "testing" to "mepis". After the asterisk, type "Repackaged for MEPIS 7.0/8.0/8.5" (as appropriate). Hit Ctrl+X to begin to exit the debian changelog editor. Hit "y" to save changes. Then hit Enter to save the changes to the same file. This will return you to the command line prompt. This file may have to be edited more later, if anything must be changed in the code or /debian directory to get the package to build.
  9. Type cd debian into the console and hit enter to change to the Debian directory.
  10. Type kwrite control and hit enter to open the /debian/control file in Kwrite. You can use your preferred text editor instead of Kwrite. Watch for a "control.in" or "rules.in" files, you will have to edit those instead, since the build process will convert those to the final files.
  11. Add "XSBC-Original-" before the Maintainer, and make a new line above that that reads "Maintainer: yourDEBFULLNAME <yourDEBEMAIL>", replacing yourDEBFULLNAME and yourDEBEMAIL with the info you exported as outlined above in "Setting the Environment". Then, create a line after Uploaders: or (if there is no Uploaders: line, XSBC-Original-Maintainer:) that reads, Bugs: mailto: <yourDEBEMAIL>, again replacing yourDEBEMAIL with what you have exported in you "~/.bashrc" file (see "Setting the Environment"). Save and close the control file.
  12. Type cd .. into the console and hit enter to return to the source directory.
  13. Type dpkg-buildpackage -rfakeroot also add the option "-sa" to make sure the original source tarball is uploaded to the repository. If the same source tarball is already present in the repository, for example, you are building a mlrepo2 version, leave off the -sa. Most packages support compiling with parallel threading, that is, it will use more than one core on a multicore CPU for compiling. Some packages will error out during the compile with this enabled, and it does not help arch-independent script-based programs, such as pure Python or Perl. Also, most packages from Debian-Multimedia will do this automatically. To use this, add the option -jN to the build command, where N=number of cores you have plus 1. Hit <Enter> to begin building the package. SPECIAL NOTE 1 Lately upstream Debian has begun to create source files in the 3.0 "quilt" mode, which means you will start with a .dsc, a debian.tar.gz. and an orig.tar.bz2 source fileset. You will get a warning when you issue the package building command that an original source file tarball can't be found, but just continue on, and the correct sources for your package will be built anyway. SPECIAL NOTE 2 - if packaging 64b (assuming you or someone else has already built for 32b) substitute -B for -sa (refer special notes section for more explanation). If it errors out with a message about build dependencies not being satisfied, try to install them doing the following, and then issue the command again:
    • Type su into the console and hit enter
    • Type in your root password and hit enter
    • Type /usr/lib/pbuilder/pbuilder-satisfydepends (make sure you have installed pbuilder) This will install all build-dependencies listed in the /debian/control file, as long as they are in the repositories.

Note: Currently, Wheezy maintainers have started adding [linux-any] for build-deps that only apply to Linux builds, as opposed to the BSD and Hurd packages. However, the Squeeze and earlier versions of pbuilder don't understand this, and simply pass over the build-depend. Editing out those "linux-any" entries in the control file will fix the problem. Watch out for build-depends that only apply to non-Linux systems and edit those out, too. Note: In MEPIS 8, the default behavior of this command seems to be uninstall unused -dev packages at the same time it installs new ones. This makes it difficult to compile two programs at once, which is one use of a multi-core system. Installing aptitude, then issuing this command in a root terminal seems to fix this problem: aptitude keep-all

    • If this works, awesome! If something is not found, you may have to look into backporting a new version or even an entirely new package to meet the build-deps. Sometimes the same libraries are provided by different packages under stable and upstream Debian. If this is the case, edit the control file again with your preferred text editor to reflect the package names in the current MEPIS Debian base. After this is done, return to this step in the original package.
  1. After the packages have been built, you will be prompted to enter your GPG key passphrase to sign the ancillary packages. You can also sign packages at any time using the "debsign" command, which is provided by devscripts:
debsign *.changes

Debsign will try and sign the package with the system key assigned to the maintainer (your_name@mepiscommunity.org) You can also specify the key with the -k argument if necessary:

debsign -k <key ID>

This is handy if you have someone else build the packages on another architecture for you, since you can still sign their packages with your secret key.

  1. You should now have all the necessary .debs (and the source, diff or mlrepoX.tar.gz, changes, build files) in the top-level folder that contains the Debian source files. Install them as appropriate and test!
  2. Another option is to subscribe to the Sourceforge files RSS or the home page RSS feed of the program, so you know when a new version comes out, and what the changes/advantages are. If there are enough advantages to the new version, you can keep an eye on the Sid package page and wait for an upstream Debian release to repackage.

2. Repackaging from Debian Backports

  • Source packages are also found at http://packages.debian.org. Procedures are the same as in Step 1, except select Search on: "Source package names"

3. Backporting from Ubuntu Repository

Also, packages meant for Gnome may be using .svg icons, which won't display in KDE 3.5. Usually you can create an .xpm ASCII version of the icon and install it from the /debian directory. You are not allowed to install binary files, such as a .png, from that folder. The new dpkg-dev in Squeeze plus the quilt source format will allow binaries in the /debian directory if they are listed in a special file.

4. Packaging from Bare Source Tarball

  1. Download source file.
  2. Untar (extract) the source package to your normal test directory.
  3. Go to the unzipped directory and thoroughly read all provided documentation. Pay particular attention to README or INSTALL files. Ensure you install any dependent libs / dev files before starting to configure or compile.
  4. Test the package by locally installing using the basic:
    ./configure
    make
    make install (as root)
    Certain programs use other methods. Some already have a makefile and just require make, while others need you to first create a configure file with ./autogen.sh (look for this file), or cmake or "cmake ." (cmake period) Qt3 apps in MEPIS are configured with qmake, and that can combined with make: qmake&&make . Readme files for QT4 apps will also specify qmake, but in MEPIS the correct command is qmake-qt4 . An alternative method is to pass a flag to qmake: qmake QMAKE=qmake-qt4
  5. Make sure it is running properly and doesn't break anything in your system while it's running or installing. Pay attention to the configure output during configuration. Note any errors, or missing functionality.
  6. If package does not configure or make, note errors and correct problems until you can cleanly install and test.
  7. Remove the locally installed package using:
    make uninstall (as root)
    from the /test/program directory. Following this, run
    make clean
    or better -
    make distclean
    to clean up the build directory.
  8. After the testing is over, make notes of the configure procedures required, and extract a fresh copy of the source from the tarball. Enter the root of the source directory (which needs to be named with the program name and version; for example, newprogram-1.2.2) Open a terminal and enter
    dh_make -m -n --createorig (Please note that using these switches creates multiple deb files *if required* and will also create an original.tar.gz version of the source - i.e., it follows Debian recommended procedures).

From man:dh_make:

Single binary (s)

The package will generate a single binary .deb package. It is the standard case, so if you don't know what to do, choose this.

Multiple binary (m)

The package will generate multiple binary .deb packages from one source package. Choose this for larger packages that need to be split.

Library (l)

The package will generate at least two binaries. One library package containing just the lib in /usr/lib and another *-dev_*.deb package containing documentation and C headers.

Kernel module (k)

The package will generate a binary-all kernel module -source package for use with the make-kpkg command. It also generates a binary package for additional utilities, daemons, etc. that may come with the source.

cdbs (b)

The package will be built using the Common Debian Build System. CDBS provides a sane set of default rules upon which packages can build.

  1. You will get a display of what's going to be in the new folder, hit enter to proceed. A new /debian folder will be created.
  2. If earlier versions of the package are in the repos, it's often useful to get the source files per Step 1 and obtain the /debian folder from there. If it can not be reused outright with some editing of the versions and maintainer, it can be mined for package descriptions and possible configure tips.
  3. Manually edit the necessary files in the debian directory (where necessary). The most important files to take note of are the changelog, control, rules and copyright files. For further information on editing the files in the /debian directory, it is recommended to read on-line information from the Debian Women Wiki (see links in the early part of this document).
  4. If any unusual commands or flags were necessary to configure, compile, or install the package, they can be added to the rules file. There is a labeled section for each in the file.
  5. Now to configure, make and build deb. Run following command:
    debuild
    This will automatically run configure, make, and create the deb file. It will also run lintian (if installed) and list any errors.
  6. Test the completed package and upload to maintainer.
  1. Note: This method will create one large .deb file, which will contain the program, its header (-dev) files, documentation, and other parts. Standard Debian practice is to modify the rules and control file as to break these all out into separate debs. If a user tries to update a multi-part Debian package with a single .deb, it may fail. Workarounds include giving advice to completely remove the older parts of the program first, or adding "Conflicts/Replaces/Provides" lines in the control file:
Dependencies:  something, something, something
Conflicts:  package-dev, package-docs, others
Replaces:  package-dev, package-docs, others
Provides: package-dev, package-docs, others 

For example, let's say you are going to build a single .deb version of Pidgin 2.4.3. Through a little research, it can be found out that Pidgin used to be called Gaim, and searching for Gaim in Synaptic shows : gaim, gaim-data, and gaim-dev. If some one has those installed, we need to make sure they are replaced.

Conflicts: gaim, gaim-data, gaim-dev
Replaces: gaim, gaim-data, gaim-dev

Through a little more research (mainly by looking at the /debian/control file from the Debian sources), we can see that the stock backports repository version of Pidgin 2.3.1 has been split up into many packages: pidgin, pidgin-dev, pidgin-dbg, finch, finch-dev, libpurple0, libpurple-bin, libpurple-dev, all of which are going to be included in your single .deb version, so:

Conflicts: gaim, gaim-data, gaim-dev, pidgin, pidgin-dev, pidgin-dbg, finch, finch-dev, libpurple0, libpurple-bin, libpurple-dev
Replaces: gaim, gaim-data, gaim-dev, pidgin, pidgin-dev, pidgin-dbg, finch, finch-dev, libpurple0, libpurple-bin, libpurple-dev
Provides: pidgin-dev, pidgin-dbg, finch, finch-dev, libpurple0, libpurple-bin, libpurple-dev

Also, we can see there is an older single .deb version of 2.3.1 available from the first community repository. To make sure this and any other older versions of Pidgin get replaced, add "pidgin (=<2.4.2)" to the end of the Conflicts and Replaces lines.

Conflicts: gaim, gaim-data, gaim-dev, pidgin-data, pidgin-dev, pidgin-dbg, finch, finch-dev, libpurple0, libpurple-bin, libpurple-dev, pidgin (=<2.4.2)
Replaces: gaim, gaim-data, gaim-dev, pidgin-data, pidgin-dev, pidgin-dbg, finch, finch-dev, libpurple0, libpurple-bin, libpurple-dev, pidgin (=<2.4.2)
Provides: pidgin-dev, pidgin-data, finch, finch-dev, libpurple0, libpurple-bin, libpurple-dev

This should allow for upgrading from Gaim, plus older multipart and single .deb versions of Pidgin.

Special Notes - IMPORTANT

General

  1. The field "section" in the control file is compulsory. Using "unknown" as section name is not allowed. At present supported sections are: admin, comm, devel, doc, editors, electronics, embedded, games, gnome, graphics, hamradio, interpreters, kde, libs, libdevel, mail, math, misc, net, news, oldlibs, otherosfs, perl, python, science, shells, sound, tex, text, utils, web, x11. This allows the packages to be properly categorized when using Synaptic.

32b / 64b

  1. The ideal is for the package builder to create both 32b and 64b packages. When this is not possible, the 32b packager MUST find another package builder to compile the matching 64b package. It is also imperative if builds are split between 2 packagers - that same source and build method is used. Use debsign to sign the final results before uploading.
  2. 32b packages are always backported with dpkg-buildpackage -rfakeroot -sa for signed or dpkg-buildpackage -rfakeroot -us -uc -sa for unsigned. This creates all of the necessary packages for upload to the repo including source (packname_version.orig.tar.gz), .dsc and .changes files, and the appropriate deb files - including "all" deb files where used for both architectures- eg common data debs etc.
  3. 64b packages are always backported with dpkg-buildpackage -rfakeroot -B for signed or dpkg-buildpackage -rfakeroot -us -uc -B for unsigned. This creates only the architecture dependent (amd64) deb files + amd64.changes file for upload to the repo. The reason for not including source, .diff, .dsc (and "all" architecture files if applicable) is that these files would have already been created when compiling the 32b version. The repo cannot handle the same file twice. Note that the procedure also applies in reverse: you can start the first build in amd64 with the source command, and finish the 32bit using the '-B" argument.

Packages for multiple MEPIS releases

If you are building the same version of a package for more than one MEPIS version (e.g. libfoo3.1-1 for both 8.0 & 8.5), you must follow this procedure to avoid checksum conflicts in the repositories.

  1. Build the package normally for the oldest MEPIS version first. (mcr80+1, for example)
  2. When building for the later MEPIS version, start with the same source packages, but before building adjust the /debian/changelog file to show the build is for the newer MEPIS release, i.e. mcr85+1
  3. Build this version without the "-sa" like so: dpkg-buildpackage -rfakeroot for 32 bit and dpkg-buildpackage -rfakeroot -B for 64 bit so that you don't get new original source tarballs marked for upload, just the diffs and new .dsc file. You can still use the -j# switch for building with #-1 cores on a multicore machine. You can also discard the original source tarball after finishing both builds and testing successfully, since it will not be uploading into the repository.

Using LZMA compression

Though not allowed in Debian official packages, using the LZMA algorithm to compress the final deb files can usually result in significant reductions in size, generally up to 33% smaller, and sometimes even more. (Data packages consisting of mostly already compressed graphic files will see little additional compression.) This reduces bandwith loads on our servers and for our end users, especially those on dialup connections, and so far has proven problem-free. The files will take longer to compress on your end, but that's compress once, download and install many times. Enabling LZMA entails editing the /debian/rules file.

1. Look for a line in the rules file

dh_builddeb

and change it to

dh_builddeb -- -Z lzma

2. If there are instead lines such as

dh_builddeb -a
dh_builddeb -i

simply add the "-- -Z lzma" to the line, i.e. "dh_builddeb -a -- -Z lzma"

3. Often, you'll encounter a minimalist rules file containing something along the lines of

#!/usr/bin/make -f
%:
       dh $@

and possibly some other override sections.

These are becoming common in Sid. In that case, add some code to the end of the rules file:

override_dh_builddeb:
      dh_builddeb -- -Z lzma

Note that the indents are with tabs, not spaces.

4. If you have a CDBS (Common Debian Build System) rules file, identifiable by cdbs includes in the rules file or cdbs in the build-depends, add a line to the rules file, generally underneath the "includes" section:

DEB_DH_BUILDDEB_ARGS := -- -Z lzma

Special Note - Once you change the rules file make sure to reflect that in the "debian/changelog" file by putting in a new line after "Repackaged for MEPIS x.x" by hitting <Enter>, then indenting with two spaces and put another *. After that asterisk, put a space and then enter in "Modified rules file to compress deb (or debs when appropriate) using lzma"

Eventually Debian seems to be planning to switch over to xz compression by default, but some apt tools do not support it at the moment.


Compiling with Multiple Threads

If you have a multi-core processor, you may want to speed up the binary compilation by using all your cores, instead of the single default core. Some packages already have a bit of code in the debian/rules file to automatically do this. If not, just add the "-jX" flag to the package build command, where X=number of cores you wish to use, plus one. So for a dual core machine, the command would be:

dpkg-buildpackage -rfakeroot -us -uc -sa -d -j3

Note that some packages will not support parallel builds, or will fail with a mysterious error. Try building with only one thread to see if this fixes the error.

Upstream Python Applications

Python versions greater than Debian Lenny's 2.5.2 support a flag that is often called out in the rules file:

python setup.py --install-layout-deb

which will cause a build failure. Simply removing the "--install-layout-deb" will allow the build to succeed in most cases.

Uploading to Maintainer & Repo

  1. Packagers should discuss with their Maintainer to ascertain which method of upload works best in their pod. One method is for all packages to be zipped and uploaded to free filesharing site (eg Rapidshare / Filefront) and link emailed to Maintainer. This has the advantage of not clogging email. Recently, Google Docs has allowed the upload of any type of file, up to 1 GB total. This is fast, free, and easy to use. After the upload, right click the file name and choose who to share it with, get the link to share with someone such as your maintainer, then save your change, and send the copied link to your maintainer. To start, just click on Docs at the top of the gmail page.
  2. Maintainers MUST ensure that 32b packages (ie full set - source, dsc, diff, changes, debs) are uploaded to repo before 64b. It is OK to upload both 32b and 64b simultaneously - but definitely not 64b without the 32b.
Personal tools