Last night, after dropping a package from a control file, I was wondering why my package.install file for the remaining package seemed to be ignored (upstream installs a bunch of stuff that I don't want installed in the Debian package; the symptom was all that junk was making its way into the package). Turns out it comes down to the following logic in CDBS:

ifeq ($(words $(DEB_ALL_PACKAGES)),1)
        DEB_DESTDIR = $(CURDIR)/debian/$(strip $(DEB_ALL_PACKAGES))/
else
        DEB_DESTDIR = $(CURDIR)/debian/tmp/
endif

i.e. if there is only one package, then by default install in debian/package. Therefore whatever make install does is what you end up with in your package. Although I can see the reasoning behind this, it wasn't what I wanted since I need the package installed into a temporary location (i.e. debian/tmp) which then uses a .install file to pull out only those files I want. The solution is simple, override DEB_DESTDIR to $(CURDIR)/debian/tmp/ in rules.

I hope this saves someone the half hour or so I spent investigating why my install file was "corrupt"!

posted at: Tue, 05 Feb 2008 15:30 | in /linux/debian | permalink | add comment (0 others)

If you use Iceweasel and a website is complaining you don't have Firefox® (such as the Google toolbar installation page), download the user-agent switcher plugin and use it to import this specification. You can then "fake" being a plain-old Firefox® running on on Linux; the Iceweasel site provides one that fakes Firefox® on Windows XP should you need that.

posted at: Thu, 17 May 2007 11:56 | in /linux/debian | permalink | add comment (0 others)

There is a bit of an art to getting CDBS to build packages with Python extensions made with autotools, so hopefully this will help someone. This might be appropriate where you have a library which ships with some Python modules you wish to package.

The basic idea is to re-build separate trees for the various Python versions you wish to support, and then install these separate builds to the same place before creating the final package.

1. Firstly, add an XS line to the top of your control file with the Python versions to support, such as XS-Python-Version: >=2.3. Then get this into a variable in your rules file with pyversions

   PY_VERSIONS = $(shell pyversions --requested debian/control)
   

   You'll also want build dependencies on python-all-dev, python-central (>= 0.5).
2. Your Python package also needs to be setup with the correct variables so it has the right dependencies, etc, something like

   Package: python-package
   Architecture: any
   Section: python
   Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends}
   Provides: ${python:Provides}
   XB-Python-Version: ${python:Versions}
   Description: Python bindings for blah
    Description here
   

3. Now the magic is to get multiple builds for each version of Python requested. The first thing to do is add a configure/python-packagename target which will get called early in the package creation phase. In standard make we can make this target depend on "stamp" files for each version of python we need to support. For example

   configure/python-packagename:: $(addprefix configure-stamp-, $(PY_VERSIONS))
   

   which expands to something like

   configure/python-packagename:: configure-stamp-2.3 configure-stamp-2.4 configure-stamp-2.5
   

4. Now we make a implicit rule for anything called configure-stamp-% which will setup separate build directories for the different Python versions.

   configure-stamp-%:
           mkdir build-$*
           cd build-$* && PYTHON=`which $*` $(DEB_CONFIGURE_SCRIPT_ENV) \
               $(DEB_CONFIGURE_SCRIPT) \
                   $(DEB_CONFIGURE_NORMAL_ARGS) \
                   --disable-maintainer-mode \
                   $(cdbs_configure_flags) \
                   $(DEB_CONFIGURE_EXTRA_FLAGS) \
                   $(DEB_CONFIGURE_USER_FLAGS)
           touch $@
   

   You may want to tweak this, and it may be a bit fragile if CDBS decides to change the names of things.
5. Now we have our extra versions configured, we have to organise actually building them. Do the same thing to create some build stamps, and in the implicit build-stamp rule change to the appropriate build directory.

   build-stamp-%:
           make -C build-$*
           touch $@
   
   build/python-package:: $(addprefix build-stamp-, $(PY_VERSIONS))
   

6. Do the same thing for the install step -- hopefully what happens in this stage is that each build will put its shared libraries in /usr/lib/python2.*/site-packages/. Then it is a matter of putting them in python-package.install to be copied.

   install-stamp-%:
           make -C build-$* install DESTDIR=$(CURDIR)/debian/tmp
           touch $@
   
   install/python-package:: $(addprefix install-stamp-, $(PY_VERSIONS))
   

7. To setup the right variables, etc, you need to call dh_pycentral for your package on binary-install. See the Python Policy for details on what this will do, especially if you are shipping Python files which need to be pre-compiled.

   binary-install/python-package::
   	dh_pycentral
   

8. Finally, clean up by extending the clean rule.

   clean::
           -rm -rf $(addprefix build-, $(PY_VERSIONS))
           -rm -rf $(addprefix configure-stamp-, $(PY_VERSIONS))
           -rm -rf $(addprefix build-stamp-, $(PY_VERSIONS))
           -rm -rf $(addprefix install-stamp-, $(PY_VERSIONS))
   

Thanks to Sebastien Bacher, who I think came up with this scheme originally for gnome-menus.

posted at: Fri, 11 May 2007 13:34 | in /linux/debian | permalink | add comment (0 others)

There are some attempts to show Debian usage by architecture via mirror statistics. Dirk Eddelbuettel writes

Lastly, some concerns were raised about various biases from local mirrors, web caches, multiple installs and what have you. These are fair questions as they all affect how Debian is obtained, installed and updated. But for as long as we don't know why that should be different across architectures, this is not a concern for the question at hand. The concerns reflect uncertaintly about the absolute level of users, but barring additonal information (or hypotheses), they do not affect the distribution of users across architectures which is what this exercise is about in the first place.

I don't see how this can be right. For example, I use an IA64 desktop, so does one other person in my group, and we run two IA64 production servers (this isn't counting the many development boxes). These have all been pulled from apt-proxy on one machine which caches. So my updates at home on my PowerPC would be seen, but only one of the IA64 ones were (the first update to the apt-cache), even though relatively there are more users. So how can mirror statistics really show you anything?

I'd think they types of people running IA64 boxes will be at large institutions and generally updated via local mirrors somehow. They're also likely to have many boxes, rather than just one or two. So I'd seriously doubt the stats for IA64 mean much.

posted at: Tue, 08 Mar 2005 11:59 | in /linux/debian | permalink | add comment (0 others)

1. Scan through code to ensure that it does not clag in different code as a library, etc, that may be under a different license
2. lintian
3. linda
4. pbuilder

posted at: Mon, 21 Feb 2005 15:01 | in /linux/debian | permalink | add comment (0 others)