XiVO packages with no sources

The gallifrey and skaro packaging-farm were updated with the 2.0.6 version of the packaging-farm that supports XiVO packages without sources and the documentation was updated accordingly. An unexpected bash behavior was identified and is being investigated.

XiVO packages with no source

The submit-xivo.sh command that is part of packaging-farm was improved to support the packages that have no source files such as pf-xivo and pf-xivo-backup.The changes were published as part of the 2.0.6 release of packaging-farm.The relevant part of the documentation (man submit-xivo.sh) explain how to use it:

       submit-xivo.sh - create a source package from XiVO repositories

       [DIRECTORY=] submit-xivo.sh

       [NOSOURCE=] submit-xivo.sh

       Some packages, such as pf-xivo or pf-xivo-backup do not have  a  corre-
       sponding  source.   They  only  exist as a debian package with no file.
       submit-xivo.sh(1) supports this special case with the NOSOURCE environ-
       ment  variable.  If  it is set and no DIRECTORY environment variable is
       set, it will submit a native debian package from the DEBIAN_GIT  direc-
       tory  matching  the  content  of the NOSOURCE environment variable. For

              NOSOURCE=pf-xivo submit-xivo.sh
              the  directory  name  within the DEBIAN_GIT repository where the
              package can be  found.   The  submit-xivo.sh  command  will  not
              attempt to locate a source in the SOURCE_GIT repository. It will
              submit a package that has the same name as the  content  of  the
              NOSOURCE=  variable.  For  instance NOSOURCE=pf-xivo will submit
              the pf-xivo package. The version number of the package is either
              the  one  found in the debian/changelog, if it contains the con-
              tent of the VERSION file found in the SOURCE_GIT repository. For
              instance  if  the  first  line  of the debian/changelog contains
              8:1.1.16~5 and the VERSION file contains 1.1.16 it won't be mod-
              ified.  However,  if  VERSION contains 1.1.17 a debian/changelog
              line will be  added,  preserving  the  epoch  and  will  contain

The /var/cache/packaging-farm/build/gallifrey/Makefile and /var/cache/packaging-farm/build/skaro/Makefile were updated to take advantage of this new feature as follows:

        # Submitted from the GIT debian repositories
        cd .. ; for package in pf-xivo pf-xivo-backup ; do packaging-farm NOSOURCE=$$dir submit ; done

bash -e behavior

The -e bash option is expected to end the script being run as soon as an error occurs. This is a convenient way to throw an exception from a nested function being run, should an irrecoverable error occur. However, the following code demonstrate that the -e option is sometime disabled:

 set -ex

  PS4=' ${FUNCNAME[0]}: $LINENO: '

  function f() {
      set -e
      echo $@

  ! f why does it display ? It should stop because of -e

The -e behavior is notoriously tricky and packaging-farm was written to use it only when it has a is predictable. A question was posted on stackoverflow to explain this specific case. The same question asked on irc.freenode.net#bash did not bring any answer.

skaro and gallifrey build

Guillaume asked for a shortcut to rebuild the full distribution after updating a given package for skaro. Instead of running:

packaging-farm DIRECTORY=confgen submit
packaging-farm ARCHITECTURES=i386 pf-xivo-confgen
packaging-farm skaro

the following rule was added to /var/cache/packaging-farm/build/skaro/Makefile

rebuild: update
        cd .. ;	packaging-farm skaro

so that it is possible to run

packaging-farm --cd skaro rebuild

to achieve the same result. There is some additional overhead because all newer packages will be rebuilt, not just the one of interest. That is, if someone updated asterisk since the last rebuild of skaro, it will also be rebuilt. It is believed that such a case is rare enough and does not warrant a special case. If it turns out to be wrong, an other, more specialized, shortcut can be added.

rebuilding packages and publishing repositories

       packaging-farm  allows  to  rebuild  the same version of a package. For
       instance, let say foo-1.2 was built and was made available,  either  as
       part  of  the package specific repository created with dpkg-scanpackage
       or as part of a meta package repository created with reprepro(1) A user
       then installs the package using

              apt-get update
              apt-get install foo

       At  this  point  in  time,  the  developer  of foo find a minor bug and
       rebuilds the package on packaging-farm  without  changing  the  version
       number.   packaging-farm  allows  the developer to do that, in the same
       way pbuilder or sbuild does. But that has an important consequence  for
       the  user  who installed the foo package. There now is a new version of
       the foo package that has exactly the same version as the  previous  one
       but  is  not really the same.  The user needs to re-install the package
       by explicitly asking for it as follows:

              apt-get update
              apt-get install --reinstall foo

       Such a behavior is extremely confusing for the casual user. This is why
       it  is  not recommended to advertise the packaging-farm repositories to
       the general public. The recommended method is to create a reprepro mir-
       ror  that  contains  a copy of the packaging-farm repository at a point
       where all package versions have been updated to reflect the  change  of
       the  packages.   The reprepro safeguard ( error : is already registered
       with different checksums! ) provides a simple way to  ensure  that  the
       repository  targeted for the public never publishes the same version of
       the package with different content twice.