Backports

De ClissXXI.

(Différences entre les versions)
(Links)
(Annulation des modifications 6309)
 
(55 versions intermédiaires masquées)
Ligne 1 : Ligne 1 :
-
== Definition ==
+
A backport is a Debian package that is recompiled for an earlier version of the distribution. For example, there is a backport of the latest version of Postfix [http://backports.org/debian/pool/main/p/postfix/] that was compiled for ''Etch'', based on packages originally meant for ''Lenny''. Here's a HOWTO / tutorial to get started.
-
A backport is a Debian package that is recompiled for an earlier version of the distribution. For example, there is a backport from the latest version of KDE [http://debian-unofficial.org/backports.html] that was compiled for ''Sarge'', based on packages originally meant for ''Etch''.
+
Français/French: Un ''backport'', c'est un paquet Debian recompilé pour une version précédente de la distribution. Par exemple, il y a un backport de la dernière version de Postfix [http://backports.org/debian/pool/main/p/postfix/] compilé pour ''Etch'', à partir des paquets initialement prévue pour ''Lenny''. Voici un HOWTO / didacticiel pour mettre le pied à l'étrier. Le reste de la page sera en anglais.
-
Un ''backport'', c'est un paquet Debian recompilé pour une version précédente de la distribution. Par exemple, il y a un backport de la dernière version de KDE [http://debian-unofficial.org/backports.html] compilé pour ''Sarge'', à partir des paquets initialement prévue pour ''Etch''.
+
== Motives ==
-
== Motivations ==
+
You cannot just download the newer <code>.deb</code> from Debian 'testing' and install it :/
 +
* The system changes, and so do the dependencies (package versions, package names...)
 +
* Binary compatibility issues (see [http://autopackage.org/docs/devguide/ch07.html Autopackage Packagers Guide] and (FR)[[Compatibilité binaire]])
-
This recompilation is necessary for several reasons:
+
== Where to find backports ==
-
* The packages dependencies change so as to take the evolution of the rest of the system into account; in our case, we'll change those dependencies to use earlier versions.
+
-
* Binary compatibility issues (French: [[Compatibilité binaire]])
+
-
== Où trouver des backports ==
+
There are several repositories for different audiences.
 +
* backports for Debian Stable
 +
* Components not included in Debian for various reasons (patent threats, DMCA, etc.)
 +
Check the licenses, you might install non-free components.
-
[http://backports.org backports.org] est la référence en la matière.
+
Here's a few repositories:
 +
* [http://backports.org backports.org]: semi-official backports from Debian 'testing' to Debian 'stable' only
 +
* [http://debian-unofficial.org/backports.html Debian Unofficial]: has a few backports for components not admitted in Debian
 +
* [http://apt-get.org/ apt-get.org]: search engine, some of the repositories there are backports
 +
* [http://icedtea.beuc.net/]: Java OpenJDK+IcedTea 6 backport, with backported dependencies
-
Il y a également des dépôts de paquets plus spécialisés, mais ceux-ci ne sont pas toujours très attentifs aux licences, et vous pouvez récupérer des composants non-libres :/
 
-
[http://apt-get.org/ apt-get.org] fournit une liste de ces dépôts, à la fois ceux qui contiennent des composants non inclus dans Debian pour diverses raisons, et ceux qui fournissent des backports proprement dit.
+
This documentation covers backports.org in particular.
-
== Using backports.org ==
+
There are detailed [http://backports.org/dokuwiki/doku.php?id=instructions official instructions].
-
Add the following line in your <code>/etc/apt/sources.list</code>:
+
Note: it is not recommended to install all backports at once. Instead you should select only the packages that you need. Unlike in full Debian releases, each backport is tested individually, so they might conflict with each others - but they still use the same backported dependencies.
-
deb http://www.backports.org/debian sarge-backports main
+
-
Then install backported packages using:
+
== HOWTO backport? ==
-
aptitude -t sarge-backports install BackportedPackage
+
-
(Before, you had to configure ''pinning'' (packages priorities), but this is
+
=== pbuilder initial Lenny setup ===
-
[http://lists.backports.org/lurker/message/20060814.093117.ab4c6b26.en.html no longer necessary])
+
-
* [http://backports.org/dokuwiki/doku.php?id=instructions Official instructions]
+
apt-get install pbuilder cdebootstrap
 +
<pre>
 +
mkdir -p /usr/src/backports/lenny/debs
 +
(cd /usr/src/backports/lenny/debs && apt-ftparchive packages . | gzip > Packages.gz)
 +
pbuilder --create --basetgz /var/cache/pbuilder/base-lenny-bpo.tar.gz --distribution lenny \
 +
  --othermirror "deb http://security.debian.org/ lenny/updates main|deb file:///usr/src/backports/lenny/debs ./" \
 +
  --bindmounts /usr/src/backports/lenny/debs
 +
# to upgrade: pbuilder --update --basetgz /var/cache/pbuilder/base-lenny-bpo.tar.gz --bindmounts /usr/src/backports/lenny/debs
-
Note: it is not recommended to install all backports at once. Instead you should select only the packages that you need. Unlike in full, consistent Debian distros, each backport is tested individually against the Debian stable version, so they might conflict with each others - but they still share common backported dependencies.
+
pbuilder --login --basetgz /var/cache/pbuilder/base-lenny-bpo.tar.gz --bindmounts /usr/src/backports/lenny/debs --save-after-login
 +
echo "deb http://network/mirrors/debian-backports.org lenny-backports main" > /etc/apt/sources.list.d/bpo.list
 +
apt-get update
 +
apt-get --assume-yes --force-yes install debian-backports-keyring
 +
apt-get update
 +
exit
-
== backports.org GPG key ==
+
# TODO: --pbuildersatisfydepends doesn't work, why?
 +
#pdebuild --pbuilder cowbuilder --pbuildersatisfydepends /usr/lib/pbuilder/pbuilder-satisfydepends-experimental
 +
# Meanwhile we edit /etc/pbuilderrc manually
 +
PBUILDERSATISFYDEPENDSCMD=/usr/lib/pbuilder/pbuilder-satisfydepends-experimental
 +
</pre>
-
After <code>apt-get update</code>, I get:
+
Source packages location (or just use <code>dget</code>):
-
W: GPG error: http://localhost sarge-backports Release: Les signatures suivantes
+
<pre>
-
n'ont pas pu être vérifiées car la clé publique n'est pas disponible : NO_PUBKE Y EA8E8B2116BA136C
+
cat <<EOF > /etc/apt/sources.list.d/squeeze-src.list
 +
deb-src http://ftp.fr.debian.org/debian/ squeeze main
 +
EOF
 +
apt-get update
 +
</pre>
-
So I need to import that key from a keyserver:
+
=== Compilation ===
-
$ gpg --recv-keys EA8E8B2116BA136C
+
-
gpg: le porte-clés `/root/.gnupg/secring.gpg` a été créé
+
-
gpg: requête de la clé 16BA136C du serveur hkp subkeys.pgp.net
+
-
gpg: /root/.gnupg/trustdb.gpg: base de confiance créée
+
-
gpg: clé 16BA136C: clé publique « Backports.org Archive Key <ftp-master@backport s.org> » importée
+
-
gpg: aucune clé de confiance ultime n'a été trouvée
+
-
gpg:        Quantité totale traitée: 1
+
-
gpg:                      importée: 1
+
-
and tell apt about it:
+
Shell variables:
-
$ gpg --export EA8E8B2116BA136C | apt-key add -
+
<pre>
-
OK
+
export DEBEMAIL="beuc@beuc.net"
 +
export DEBFULLNAME="Sylvain Beucler"
 +
export EDITOR="emacs"
 +
</pre>
-
== HOWTO backport? ==
+
Update chroot'd subsystem:
 +
<pre>
 +
sudo pbuilder --update --basetgz /var/cache/pbuilder/base-lenny-bpo.tar.gz --bindmounts /usr/src/backports/lenny/debs
 +
</pre>
 +
 
 +
Edit the source package:
 +
<pre>
 +
apt-get source $PACKAGE
 +
cd $PACKAGE-*
 +
#sed -i -e "s/Uploaders:\(.*\)/Uploaders:\1, $DEBFULLNAME <$DEBEMAIL>/" debian/control
 +
# debian/control: add new field
 +
# Uploaders: Sylvain Beucler <beuc@beuc.net>
 +
dch --bpo
 +
# Document your changes
 +
</pre>
 +
 
 +
Try to compile (unlike pdebuild, you can inspect and fix errors when compilation fails):
 +
<pre>
 +
pbuilder --login --basetgz /var/cache/pbuilder/base-lenny-bpo.tar.gz --bindmounts /usr/src/backports/
 +
cd /usr/src/backports/$PACKAGE-*
 +
apt-get install pbuilder
 +
/usr/lib/pbuilder/pbuilder-satisfydepends-experimental --continue-fail
 +
apt-get install devscripts fakeroot
 +
debuild -nc  # don't clean so you can try to resume a failed compilation
 +
</pre>
 +
 
 +
When everything compiles, do it for real:
 +
<pre>
 +
pdebuild --debbuildopts '-sa' --buildresult /usr/src/backports/lenny/debs \
 +
  -- --basetgz /var/cache/pbuilder/base-lenny-bpo.tar.gz --bindmounts /usr/src/backports/lenny/debs
 +
 
 +
(cd /usr/src/backports/lenny/debs && apt-ftparchive packages . | gzip > Packages.gz)
 +
</pre>
 +
 
 +
=== Don't's ===
 +
 
 +
Don't <code>aptitude -t lenny-backports install debhelper</code> blindly.
 +
This will include new helper scripts that may be copied into your packages' postinst/prerm/etc.
 +
This is being [http://lists.backports.org/lurker/message/20060830.124936.32b7cb6f.en.html discussed].
 +
I had to stick to v4 when backporting evince.
 +
 
 +
Don't use <code>apt-src build</code>, since it doesn't care about sources packages, unless you configure <code>APT::Src::BuildCommand</code> accordingly (without the <code>-b</code> option for dpkg-buildpackage). Using <code>debuild -us -uc</code> directly worked well for me.
 +
 
 +
=== changelog ===
 +
 
 +
You now can use (since Lenny) the <code>--bpo</code> option to <code>dch</code>:
 +
dch --bpo
 +
 
 +
If you need to do it manually (e.g. because the new Debian version is not supported yet), you can use:
 +
yes | dch -D lenny-backports \
 +
  --newversion $(dpkg-parsechangelog | sed -ne 's,^Version: ,,p')~bpo50+1 \
 +
  --force-bad-version -- \
 +
  "Rebuild for Debian Backports <http://www.backports.org/>"
 +
 
 +
=== Upload ===
 +
 
 +
http://backports.org/dokuwiki/doku.php?id=contribute
 +
 
 +
Most commonly, upload your files (the contents of <code>repo/</code>) somewhere and post about it on backports-users@lists.backports.org. Make sure you included a description of what you did in the <code>debian/changelog</code>.
 +
 
 +
The page says: ''Our requirements aren't that high. You need to have a gpg key in the official Debian keyring.'' Don't get mistaken: only "Debian developpers" get their gpg keys in the keyring, and becoming one is a [https://nm.debian.org/ months-long process]. However you may find somebody on the list willing to upload your package.
 +
 
 +
Workflow:
 +
* Your package hits ''testing''. backports.org aims at providing a smooth transition between the current Debian ''stable'' release and the next one; they don't consider safe to use an ''unstable'' package because if may not enter the next stable (while a ''testing'' package should) [http://lists.backports.org/lurker/message/20060614.173239.0d83eace.en.html]. Fortunately there has been some [http://lists.backports.org/lurker/message/20060630.114154.8e80d282.en.html exceptions].
 +
* You backport the package.
 +
* You test the package. It takes time to upload a package to backports.org, so you'd better send a perfect package from the start.
 +
* You send the package to an authorized member (who will ''sponsor'' it), or you upload directly at ftp://backports.org if you have the privileges (requires being part of the Debian GPG keyring i.e. having the "Debian Developer" status)
 +
* If this is the first time your package is backported (or if your source package introduces new binary packages), it will appear at http://www.backports.org/debian/new.html , and wait for a manual review.  Norbert Tretkowski (nobse) or Alexander Wirt (formorer) will do so in a matter of days/weeks. eg: evince was accepted after 1 week, ettercap after 1 day - but I don't know the details.
 +
* Your package is send to an autobuilder. Your package will be rebuilt no matter what [http://lists.backports.org/lurker/message/20060902.131426.a3bad472.en.html].
 +
* Once the binary package is built, the build logs need to be checked by each buildd admin.
 +
* Then the binary package is published. There might be a delay between the availability of an architecture-independent .deb and an architecture-dependent .deb that is part of the same source package.
 +
 
 +
=== Manual configuration ===
 +
 
 +
(This is older documentation that does in greater details.)
-
Some general considerations:
+
If you want to backport for your own use, or if you're new to backports, this is for you: your packages may not work on other systems, but you have more flexibility to debug and fix errors.
-
=== Config ===
+
You need:
* debootstrap
* debootstrap
Ligne 66 : Ligne 158 :
  # Stable and backports repositories
  # Stable and backports repositories
  ##
  ##
-
  deb http://ftp.fr.debian.org/debian stable main
+
  deb http://ftp.fr.debian.org/debian etch main
-
  deb http://security.debian.org/debian-security stable/updates main
+
  deb http://security.debian.org/debian-security etch/updates main
-
  deb http://www.backports.org/debian/ sarge-backports main
+
  deb http://www.backports.org/debian/ etch-backports main
-
  deb-src http://ftp.fr.debian.org/debian stable main
+
  deb-src http://ftp.fr.debian.org/debian etch main
-
  deb-src http://security.debian.org/debian-security stable/updates main
+
  deb-src http://security.debian.org/debian-security etch/updates main
-
  deb-src http://backports.org/debian sarge-backports main
+
  deb-src http://backports.org/debian etch-backports main
   
   
  ##
  ##
Ligne 100 : Ligne 192 :
* Vital packages (apt-src, apt-ftparchive, dch):
* Vital packages (apt-src, apt-ftparchive, dch):
-
  aptitude install apt-src apt-utils devscripts
+
  aptitude install apt-src apt-utils devscripts fakeroot interdiff
-
* Environment variables for Debian tools, in my <code>~/.bash_profile</code> (TODO: not taken into account in my Sarge):
+
* Environment variables for Debian tools, in my <code>~/.bash_profile</code>:
  export DEBEMAIL="beuc@beuc.net"  
  export DEBEMAIL="beuc@beuc.net"  
  export DEBFULLNAME="Sylvain Beucler"
  export DEBFULLNAME="Sylvain Beucler"
Ligne 112 : Ligne 204 :
  DEBSIGN_SIGNLIKE="gpg"
  DEBSIGN_SIGNLIKE="gpg"
-
=== To search for a missing dependency ===
+
==== To search for a missing dependency ====
In a vanilla install, sarge and backports in sources.list:
In a vanilla install, sarge and backports in sources.list:
  aptitude search keyword # search package whose name contain 'keyword'
  aptitude search keyword # search package whose name contain 'keyword'
-
  apt-cache policy packagename # check what versions are available
+
  apt-cache policy packagename # check what versions are available (using sources.list)
 +
rmadison packagename # also check available versions (using [http://qa.debian.org/madison.php qa.debian.org])
-
=== Testing the build-deps ===
+
==== Testing the build-deps ====
  apt-get build-dep packagename
  apt-get build-dep packagename
Ligne 130 : Ligne 223 :
though it doesn't tell you whether the build _could_ be installed or not, nor which packages exactly are missing.
though it doesn't tell you whether the build _could_ be installed or not, nor which packages exactly are missing.
-
=== Making the newly built dependencies available to apt ===
+
==== Making the newly built dependencies available to apt ====
  cd /usr/src
  cd /usr/src
  mkdir repo
  mkdir repo
-
  \mv *-*~bpo.*.deb *-*~bpo.*.udeb *-*~bpo.*.changes *-*~bpo.*.diff.gz *-*~bpo.*.dsc repo/
+
  \mv *-*~bpo*+*.deb *-*~bpo*+*.udeb *-*~bpo*+*.changes *-*~bpo*+*.diff.gz *-*~bpo*+*.dsc repo/
  ln -f *.orig.tar.gz repo/
  ln -f *.orig.tar.gz repo/
  cd repo
  cd repo
Ligne 146 : Ligne 239 :
TODO: this doesn't support native packages (w/o .orig.tar.gz)
TODO: this doesn't support native packages (w/o .orig.tar.gz)
-
=== Don't's ===
+
==== Build the package ====
-
Don't <code>aptitude -t sarge-backports install debhelper</code> blindly.
+
You now can build your own backport package. Suppose you backport a package existing in testing branch and use /usr/src/repo as your working folder, after editing sources.list in previous section, you can get the source package by:
-
This will include new helper scripts that may be copied into your packages' postinst/prerm/etc.
+
-
This is being [http://lists.backports.org/lurker/message/20060830.124936.32b7cb6f.en.html discussed].
+
-
I had to stick to v4 when backporting evince.
+
-
Don't use <code>apt-src build</code>, since it doesn't care about sources packages, unless you configure <code>APT::Src::BuildCommand</code> accordingly (without the <code>-b</code> option for dpkg-buildpackage). Using <code>debuild -us -uc</code> directly worked well for me.
+
mkdir /usr/src/repo
 +
cd /usr/src/repo
 +
apt-src install PackageName
-
=== Upload ===
+
Change to the source directory and build the binary package:
-
http://backports.org/contribute.html
+
cd PackageName
 +
debuild
-
Most commonly, upload your files (the contents of <code>repo/</code>) somewhere and post about it on backports-users@lists.backports.org. Make sure you included a description of what you did in the <code>debian/changelog</code>.
+
If it goes smooth, you will get the new packages in /usr/src/repo
-
The page says: ''Our requirements aren't that high. You need to have a gpg key in the official Debian keyring.'' Don't get mistaken: only "Debian developpers" get their gpg keys in the keyring, and becoming one is a [https://nm.debian.org/ months-long process]. However it is very easy to find somebody on the list who will upload your package.
+
== What kinds of packages are accepted at backports.org? ==
-
== Workflow ==
+
The "contribute" page [http://backports.org/dokuwiki/doku.php?id=contribute] says:
 +
* Don’t backport minor version changes without any user visible changes or bugfixes
 +
* Please only upload package with a noteable userbase. User request for the package maybe an indicator.
 +
* Reconsider if the package can be installed directly from testing without any recompilation and handled via pinning
-
* Your package hits ''testing''. backports.org aims at providing a smooth transition between the current Debian ''stable'' release and the next one; they don't consider safe to use an ''unstable'' package because if may not enter the next stable (while a ''testing'' package should) [http://lists.backports.org/lurker/message/20060614.173239.0d83eace.en.html]. Fortunately there has been some [http://lists.backports.org/lurker/message/20060630.114154.8e80d282.en.html exceptions].
+
I would summarize it by:
-
* You backport the package.
+
* Packages need zero review/maintenance time from backports maintainers.
-
* You test the package. It takes time to upload a package to backports.org, so you'd better send a perfect package from the start.
+
 
-
* You send the package to an authorized member (who will ''sponsor'' it), or you upload directly at ftp://backports.org if you have the privileges (requires being part of the Debian GPG keyring)
+
I believe there's only 2 backports.org admin, and I let you image what it's like to get several backports to review each day - after a couple years.
-
* In any case, a binary package must be signed by a Debian developper. If your package is sponsored, it will probably be rebuilt. This rule is [http://lists.backports.org/lurker/message/20060902.131426.a3bad472.en.html strictly enforced], even if you had your GPG key signed and have been around for months.
+
 
-
* If this is the first time your package is backported, it will appear at http://www.backports.org/debian/new.html , and wait for a manual review.  Norbert Tretkowski (nobse) or Alexander Wirt (formorer) will do so in a matter of days/weeks. eg: evince was accepted after 1 week, ettercap after 1 day - but I don't know the details.
+
So make yourself trusworthy (become a Debian developper), prove that you won't let packages become outdated, work with the package maintainers and have them sponsor your backport, upload your backports to other places first so they can be tested (reference them to apt-get.org), etc.
-
* An autobuilder builds your package for other architectures if available.
+
== Test your backport ==
== Test your backport ==
Ligne 183 : Ligne 278 :
<code>debdiff</code> will also show you if you mistakenly introduced new files, and will <code>wdiff</code> <code>debian/control</code> (you need to install the <code>wdiff</code> package for that):
<code>debdiff</code> will also show you if you mistakenly introduced new files, and will <code>wdiff</code> <code>debian/control</code> (you need to install the <code>wdiff</code> package for that):
-
  aptitude download par2
+
  aptitude download par2/testing
  debdiff par2_0.4-8_i386.deb par2_0.4-8~bpo.1_i386.deb
  debdiff par2_0.4-8_i386.deb par2_0.4-8~bpo.1_i386.deb
-
Run <code>lintian</code> and <code>linda</code>, two packages test-suites, on your package. If you get errors, check whether they already existed in the original package, or if you introduced them yourself:
+
Run <code>lintian</code>, a package test suite. If you get errors, check whether they already existed in the original package, or if you introduced them yourself:
-
linda par2_0.4-8~bpo.1_i386.deb
+
-
linda par2_0.4-8_i386.deb
+
  lintian par2_0.4-8~bpo.1_i386.deb
  lintian par2_0.4-8~bpo.1_i386.deb
  lintian par2_0.4-8_i386.deb
  lintian par2_0.4-8_i386.deb
Ligne 212 : Ligne 305 :
  quit
  quit
-
The <code>keyword</code> line tells the BTS to only notify you about new releases. You can check the [http://www.debian.org/doc/developers-reference/ch-resources.en.html#s-pts-commands documentation] to see what other kinds of notification you can receive (bug reports, etc.).
+
The <code>keyword</code> line tells the BTS to only notify you about new releases. You can check the [http://www.debian.org/doc/manuals/developers-reference/resources.html#pts-commands documentation] to see what other kinds of notification you can receive (bug reports, etc.).
Ligne 223 : Ligne 316 :
Such tools should be adaptable for use with backports<->testing.
Such tools should be adaptable for use with backports<->testing.
 +
== Examples ==
 +
Here are a few sample backports made by Cliss XXI.
-
== Examples ==
+
Lenny backports:
 +
* [[Backport Git]]: pbuilder-based, from start to finish
 +
* [[Backport OpenJDK]]: idem., a bit more difficult with a backported build-dependency as well as a runtime dependency
 +
 
 +
Etch backports:
 +
* [[Backport FreeType]]: simple - the basics
 +
* [[Backport SDL_ttf]]: beware of compilation environment
 +
* [[Backport Gnash]]: pbuilder and satisfydepends-experimental
-
Here are a few sample backports made by Cliss XXI:
+
Sarge backports:
* [[Backport dar]]: simple
* [[Backport dar]]: simple
* [[Backport ettercap]]: more on decrypting version numbers
* [[Backport ettercap]]: more on decrypting version numbers
Ligne 234 : Ligne 336 :
* [[Backport hplip]]: dependencies and python policy
* [[Backport hplip]]: dependencies and python policy
* [[Backport GCJ]]: in progress, would be useful for OOo2 Base
* [[Backport GCJ]]: in progress, would be useful for OOo2 Base
 +
* [[Backport PHP5 DSA]]: just a security update
 +
 +
== Troubleshootings ==
 +
 +
After <code>apt-get update</code>, you get:
 +
W: GPG error: http://www.backports.org etch-backports Release: The following
 +
signatures couldn't be verified because the public key is not available:
 +
NO_PUBKEY EA8E8B2116BA136C
 +
 +
This means you didn't include the backports key, see instructions above.
== Links ==
== Links ==
Ligne 239 : Ligne 351 :
=== Documentation ===
=== Documentation ===
-
* A high-level HOWTO: [http://www.dannf.org/docs/backporting-debs.txt A Heuristic-based Process for Backporting Debs]
+
* [http://edseek.com/~jasonb/articles/pbuilder_backports/ Using pbuilder to backport Debian packages]: interesting and detailed document, abeilt a bit old (2006)
 +
* [http://www.dannf.org/docs/backporting-debs.txt A Heuristic-based Process for Backporting Debs]: a high-level HOWTO (with little technical details)
 +
* [http://lists.backports.org/lurker-bpo/message/20071121.083010.232e360c.en.html Re: gnuplot 4.2 backport]: instructions to rebuild backports that do not need adaptation, only recompilation
* [http://www.inittab.de/slides/backporting.pdf Slides] (in German :/) from backports.org founder. Even if you don't grasp German, have a look at the mentioned commands.
* [http://www.inittab.de/slides/backporting.pdf Slides] (in German :/) from backports.org founder. Even if you don't grasp German, have a look at the mentioned commands.
* [http://wiki.debian.org/Backports Backports - Debian Wiki]: some procedures to follow when uploading at backports.org. Policies are not explained, though.
* [http://wiki.debian.org/Backports Backports - Debian Wiki]: some procedures to follow when uploading at backports.org. Policies are not explained, though.
 +
* [http://debian.ethz.ch/pub/debian-backports/utils/Backport-HOWTO.html Backport HOWTO] (2004)
=== Tools ===
=== Tools ===
-
* [http://julien.danjou.info/article-apt-build.html apt-build]: this tool might ease backports. To dig out.
+
* [http://lists.backports.org/lurker-bpo/message/20090708.194846.0cc45f10.en.html Helper script for backport?]: various scripts that may help (TODO)
 +
** [http://www.eyrie.org/~eagle/software/scripts/ Russ' backport script]: simple Perl script to update changelog, run pbuilder, etc.
 +
* [https://wiki.ubuntu.com/PbuilderHowto PbuilderHowto]: check in particular the section about running a shell when the build fails
 +
* [http://julien.danjou.info/article-apt-build.html apt-build]: this tool might ease backports. To dig out. Beware that it tries to install the package by default (unlike <code>apt-src install</code>).
* [http://familiasanchez.net/~roberto/howtos/debcustomize Debian Package Customization HOWTO]: a backports is a form of customization
* [http://familiasanchez.net/~roberto/howtos/debcustomize Debian Package Customization HOWTO]: a backports is a form of customization
Ligne 250 : Ligne 368 :
* [http://www.backports.org/~formorer/ Package uploads]: who uploaded what at bpo
* [http://www.backports.org/~formorer/ Package uploads]: who uploaded what at bpo
-
* http://backports.buildd.net/: Backport's autobuilder homepage (if I got it right, it's the same than Debian experimental).
+
* http://backports.buildd.net/: Backport's autobuilder homepage (if I got it right, it's the same computer than Debian experimental).
 +
* [http://experimental.ftbfs.de/new/package.php?p=openoffice.org&suite=etch-bpo build logs]: (here for OOo) to check if your package was compiled for your architecture
=== Other pages at doc.cliss21.org ===
=== Other pages at doc.cliss21.org ===
Ligne 256 : Ligne 375 :
(French):
(French):
* [[Compatibilité binaire]]: pourquoi les exécutables d'une distribution ne fonctionnent pas sur une autre?
* [[Compatibilité binaire]]: pourquoi les exécutables d'une distribution ne fonctionnent pas sur une autre?
 +
 +
=== History ===
 +
 +
* Before 2006, extra ''pinning'' (packages priorities) configuration was needed, but this is [http://lists.backports.org/lurker/message/20060814.093117.ab4c6b26.en.html no longer necessary])
== Note ==
== Note ==
-
I put this documentation here because I'd rather publish it in a wiki where subscription or moderation is not required. Feel free to spread it though :)
+
As the only copyright holder of this documentation, and to avoid any troll, this documentation is dual-licensed GFDL and GNU GPL, current versions or later.
 +
 
 +
== TODO ==
 +
 
 +
There are new "rules" to take into accounts:
 +
* http://lists.backports.org/lurker-bpo/message/20070822.130811.d3674674.en.html
 +
 
 +
== Links ==
-
There're some bits of French left on this page, from the early version of the document. Feel free to translate those.
+
* [http://backports.buildd.net/index-i386.html buildd.net]: the computer that builds backports packages
 +
* [http://experimental.ftbfs.de/new/package.php?p=mercurial&suite=etch-bpo]: sample URL to check the build status of a package (here the Mercurial package recompiled for Etch)

Version actuelle en date du 6 juin 2014 à 16:38

A backport is a Debian package that is recompiled for an earlier version of the distribution. For example, there is a backport of the latest version of Postfix [1] that was compiled for Etch, based on packages originally meant for Lenny. Here's a HOWTO / tutorial to get started.

Français/French: Un backport, c'est un paquet Debian recompilé pour une version précédente de la distribution. Par exemple, il y a un backport de la dernière version de Postfix [2] compilé pour Etch, à partir des paquets initialement prévue pour Lenny. Voici un HOWTO / didacticiel pour mettre le pied à l'étrier. Le reste de la page sera en anglais.

Sommaire

Motives

You cannot just download the newer .deb from Debian 'testing' and install it :/

Where to find backports

There are several repositories for different audiences.

  • backports for Debian Stable
  • Components not included in Debian for various reasons (patent threats, DMCA, etc.)

Check the licenses, you might install non-free components.

Here's a few repositories:

  • backports.org: semi-official backports from Debian 'testing' to Debian 'stable' only
  • Debian Unofficial: has a few backports for components not admitted in Debian
  • apt-get.org: search engine, some of the repositories there are backports
  • [3]: Java OpenJDK+IcedTea 6 backport, with backported dependencies


This documentation covers backports.org in particular.

There are detailed official instructions.

Note: it is not recommended to install all backports at once. Instead you should select only the packages that you need. Unlike in full Debian releases, each backport is tested individually, so they might conflict with each others - but they still use the same backported dependencies.

HOWTO backport?

pbuilder initial Lenny setup

apt-get install pbuilder cdebootstrap
mkdir -p /usr/src/backports/lenny/debs
(cd /usr/src/backports/lenny/debs && apt-ftparchive packages . | gzip > Packages.gz)
pbuilder --create --basetgz /var/cache/pbuilder/base-lenny-bpo.tar.gz --distribution lenny \
  --othermirror "deb http://security.debian.org/ lenny/updates main|deb file:///usr/src/backports/lenny/debs ./" \
  --bindmounts /usr/src/backports/lenny/debs
# to upgrade: pbuilder --update --basetgz /var/cache/pbuilder/base-lenny-bpo.tar.gz --bindmounts /usr/src/backports/lenny/debs

pbuilder --login --basetgz /var/cache/pbuilder/base-lenny-bpo.tar.gz --bindmounts /usr/src/backports/lenny/debs --save-after-login
echo "deb http://network/mirrors/debian-backports.org lenny-backports main" > /etc/apt/sources.list.d/bpo.list
apt-get update
apt-get --assume-yes --force-yes install debian-backports-keyring
apt-get update
exit

# TODO: --pbuildersatisfydepends doesn't work, why?
#pdebuild --pbuilder cowbuilder --pbuildersatisfydepends /usr/lib/pbuilder/pbuilder-satisfydepends-experimental
# Meanwhile we edit /etc/pbuilderrc manually
PBUILDERSATISFYDEPENDSCMD=/usr/lib/pbuilder/pbuilder-satisfydepends-experimental

Source packages location (or just use dget):

cat <<EOF > /etc/apt/sources.list.d/squeeze-src.list
deb-src http://ftp.fr.debian.org/debian/ squeeze main
EOF
apt-get update

Compilation

Shell variables:

export DEBEMAIL="beuc@beuc.net" 
export DEBFULLNAME="Sylvain Beucler"
export EDITOR="emacs"

Update chroot'd subsystem:

sudo pbuilder --update --basetgz /var/cache/pbuilder/base-lenny-bpo.tar.gz --bindmounts /usr/src/backports/lenny/debs

Edit the source package:

apt-get source $PACKAGE
cd $PACKAGE-*
#sed -i -e "s/Uploaders:\(.*\)/Uploaders:\1, $DEBFULLNAME <$DEBEMAIL>/" debian/control
# debian/control: add new field
# Uploaders: Sylvain Beucler <beuc@beuc.net>
dch --bpo
# Document your changes

Try to compile (unlike pdebuild, you can inspect and fix errors when compilation fails):

pbuilder --login --basetgz /var/cache/pbuilder/base-lenny-bpo.tar.gz --bindmounts /usr/src/backports/
cd /usr/src/backports/$PACKAGE-*
apt-get install pbuilder
/usr/lib/pbuilder/pbuilder-satisfydepends-experimental --continue-fail
apt-get install devscripts fakeroot
debuild -nc  # don't clean so you can try to resume a failed compilation

When everything compiles, do it for real:

pdebuild --debbuildopts '-sa' --buildresult /usr/src/backports/lenny/debs \
  -- --basetgz /var/cache/pbuilder/base-lenny-bpo.tar.gz --bindmounts /usr/src/backports/lenny/debs

(cd /usr/src/backports/lenny/debs && apt-ftparchive packages . | gzip > Packages.gz)

Don't's

Don't aptitude -t lenny-backports install debhelper blindly. This will include new helper scripts that may be copied into your packages' postinst/prerm/etc. This is being discussed. I had to stick to v4 when backporting evince.

Don't use apt-src build, since it doesn't care about sources packages, unless you configure APT::Src::BuildCommand accordingly (without the -b option for dpkg-buildpackage). Using debuild -us -uc directly worked well for me.

changelog

You now can use (since Lenny) the --bpo option to dch:

dch --bpo

If you need to do it manually (e.g. because the new Debian version is not supported yet), you can use:

yes | dch -D lenny-backports \
  --newversion $(dpkg-parsechangelog | sed -ne 's,^Version: ,,p')~bpo50+1 \
  --force-bad-version -- \
  "Rebuild for Debian Backports <http://www.backports.org/>"

Upload

http://backports.org/dokuwiki/doku.php?id=contribute

Most commonly, upload your files (the contents of repo/) somewhere and post about it on backports-users@lists.backports.org. Make sure you included a description of what you did in the debian/changelog.

The page says: Our requirements aren't that high. You need to have a gpg key in the official Debian keyring. Don't get mistaken: only "Debian developpers" get their gpg keys in the keyring, and becoming one is a months-long process. However you may find somebody on the list willing to upload your package.

Workflow:

  • Your package hits testing. backports.org aims at providing a smooth transition between the current Debian stable release and the next one; they don't consider safe to use an unstable package because if may not enter the next stable (while a testing package should) [4]. Fortunately there has been some exceptions.
  • You backport the package.
  • You test the package. It takes time to upload a package to backports.org, so you'd better send a perfect package from the start.
  • You send the package to an authorized member (who will sponsor it), or you upload directly at ftp://backports.org if you have the privileges (requires being part of the Debian GPG keyring i.e. having the "Debian Developer" status)
  • If this is the first time your package is backported (or if your source package introduces new binary packages), it will appear at http://www.backports.org/debian/new.html , and wait for a manual review. Norbert Tretkowski (nobse) or Alexander Wirt (formorer) will do so in a matter of days/weeks. eg: evince was accepted after 1 week, ettercap after 1 day - but I don't know the details.
  • Your package is send to an autobuilder. Your package will be rebuilt no matter what [5].
  • Once the binary package is built, the build logs need to be checked by each buildd admin.
  • Then the binary package is published. There might be a delay between the availability of an architecture-independent .deb and an architecture-dependent .deb that is part of the same source package.

Manual configuration

(This is older documentation that does in greater details.)

If you want to backport for your own use, or if you're new to backports, this is for you: your packages may not work on other systems, but you have more flexibility to debug and fix errors.

You need:

  • debootstrap
  • basic compilation tools: aptitude install build-essential
  • sources.list:
##
# Stable and backports repositories
##
deb http://ftp.fr.debian.org/debian etch main
deb http://security.debian.org/debian-security etch/updates main
deb http://www.backports.org/debian/ etch-backports main
deb-src http://ftp.fr.debian.org/debian etch main
deb-src http://security.debian.org/debian-security etch/updates main
deb-src http://backports.org/debian etch-backports main

##
# Testing and unstable repositories
##

# Binaries - uncomment if you need to test 'aptitude install'
#deb http://ftp.fr.debian.org/debian testing main
#deb http://ftp.fr.debian.org/debian unstable main

# Sources - uncomment the one you're backporting from
#deb-src http://ftp.fr.debian.org/debian testing main
deb-src http://ftp.fr.debian.org/debian unstable main

##
# backports in progress
##
deb file:///usr/src/repo ./
  • /etc/apt/preferences:
Package: *
Pin: release a=testing
Pin-Priority: -1

Package: *
Pin: release a=unstable
Pin-Priority: -1
  • Vital packages (apt-src, apt-ftparchive, dch):
aptitude install apt-src apt-utils devscripts fakeroot interdiff
  • Environment variables for Debian tools, in my ~/.bash_profile:
export DEBEMAIL="beuc@beuc.net" 
export DEBFULLNAME="Sylvain Beucler"
export EDITOR="emacs"
  • debsign GPG configuration, if signing packages is needed, in my ~/.devscripts:
DEBSIGN_KEYID="81704B93"
DEBSIGN_PROGRAM="gpg --use-agent"
DEBSIGN_SIGNLIKE="gpg"

To search for a missing dependency

In a vanilla install, sarge and backports in sources.list:

aptitude search keyword # search package whose name contain 'keyword'
apt-cache policy packagename # check what versions are available (using sources.list)
rmadison packagename # also check available versions (using qa.debian.org)

Testing the build-deps

apt-get build-dep packagename

will download the missing dependencies, if available, and report the first missing one otherwise.

You can alter the build-dep during the creation of the backport, to test whether a modified dependencies list does the trick. apt-get build-dep uses the plain-text /var/lib/apt/lists/ftp.[mirror].debian.org_debian_dists_[distro]_[component]_source_Sources file. You can go quick&dirty and alter that file :) I do not know about a "clean" solution (like feeding apt-get build-dep directly with a debian/control file). You then can test your backported dependencies with:

apt-get -t sarge-backports build-dep packagename

You may also be interested in dpkg-checkbuilddeps: it reports packages that are not installed, though it doesn't tell you whether the build _could_ be installed or not, nor which packages exactly are missing.

Making the newly built dependencies available to apt

cd /usr/src
mkdir repo
\mv *-*~bpo*+*.deb *-*~bpo*+*.udeb *-*~bpo*+*.changes *-*~bpo*+*.diff.gz *-*~bpo*+*.dsc repo/
ln -f *.orig.tar.gz repo/
cd repo
apt-ftparchive packages . | gzip -c > Packages.gz
apt-ftparchive sources  . | gzip -c > Sources.gz
cd ..
#echo "deb file:///usr/src/repo ./" >> /etc/apt/sources.list

There's probably a cleaner way to do this using more comprehensive tools but that does the trick for now.

TODO: this doesn't support native packages (w/o .orig.tar.gz)

Build the package

You now can build your own backport package. Suppose you backport a package existing in testing branch and use /usr/src/repo as your working folder, after editing sources.list in previous section, you can get the source package by:

mkdir /usr/src/repo
cd /usr/src/repo 
apt-src install PackageName

Change to the source directory and build the binary package:

cd PackageName
debuild

If it goes smooth, you will get the new packages in /usr/src/repo

What kinds of packages are accepted at backports.org?

The "contribute" page [6] says:

  • Don’t backport minor version changes without any user visible changes or bugfixes
  • Please only upload package with a noteable userbase. User request for the package maybe an indicator.
  • Reconsider if the package can be installed directly from testing without any recompilation and handled via pinning

I would summarize it by:

  • Packages need zero review/maintenance time from backports maintainers.

I believe there's only 2 backports.org admin, and I let you image what it's like to get several backports to review each day - after a couple years.

So make yourself trusworthy (become a Debian developper), prove that you won't let packages become outdated, work with the package maintainers and have them sponsor your backport, upload your backports to other places first so they can be tested (reference them to apt-get.org), etc.

Test your backport

First, install and run your backport on a Stable system.

You can also check what changes you introduced using interdiff (from package patchutils):

gunzip par2cmdline_0.4-8.diff.gz
gunzip par2cmdline_0.4-8~bpo.1.diff.gz
interdiff par2cmdline_0.4-8.diff par2cmdline_0.4-8~bpo.1.diff | less

debdiff will also show you if you mistakenly introduced new files, and will wdiff debian/control (you need to install the wdiff package for that):

aptitude download par2/testing
debdiff par2_0.4-8_i386.deb par2_0.4-8~bpo.1_i386.deb

Run lintian, a package test suite. If you get errors, check whether they already existed in the original package, or if you introduced them yourself:

lintian par2_0.4-8~bpo.1_i386.deb
lintian par2_0.4-8_i386.deb

(if your source packages produces several binary packages, specify the .changes instead)

piuparts is another test suite that actually installs your packages in various ways (instead of inspecting its content), but I have to figure out how to use it accurately for backports.

Track your backported packages

After a while, there will be new versions of your backported package in Debian testing. In this case, either:

  • update your backport
  • tell backports-users@list.backports.org that you do not intend to do it (lack of time, not using the package anymore, etc.), but that it would be good if someone did

To be notified of new versions of the package automatically, the simplest way is to subscribe to the PTS (package tracking system). You can do so from the package developer package (eg. [7]).

Alternatively, you can send an e-mail to pts@qa.debian.org telling:

Subject: subscribe your_package your@mail.tld

keyword your_package your@mail.tld = upload-source
quit

The keyword line tells the BTS to only notify you about new releases. You can check the documentation to see what other kinds of notification you can receive (bug reports, etc.).


This script was recently advertised as a way to track the differences between Ubuntu and Debian packages.

MultiDistroTools also contains informations in this regard, generating reports like:

Such tools should be adaptable for use with backports<->testing.

Examples

Here are a few sample backports made by Cliss XXI.

Lenny backports:

  • Backport Git: pbuilder-based, from start to finish
  • Backport OpenJDK: idem., a bit more difficult with a backported build-dependency as well as a runtime dependency

Etch backports:

Sarge backports:

Troubleshootings

After apt-get update, you get:

W: GPG error: http://www.backports.org etch-backports Release: The following
signatures couldn't be verified because the public key is not available:
NO_PUBKEY EA8E8B2116BA136C

This means you didn't include the backports key, see instructions above.

Links

Documentation

Tools

Packages information

Other pages at doc.cliss21.org

(French):

History

  • Before 2006, extra pinning (packages priorities) configuration was needed, but this is no longer necessary)

Note

As the only copyright holder of this documentation, and to avoid any troll, this documentation is dual-licensed GFDL and GNU GPL, current versions or later.

TODO

There are new "rules" to take into accounts:

Links

  • buildd.net: the computer that builds backports packages
  • [8]: sample URL to check the build status of a package (here the Mercurial package recompiled for Etch)
Outils personnels