The Debian Hack Shop

Slow sunday afternoon? Choose a release goal and work on it!

Yesterday I focused on the goal-recommends issue: No unmet recommends relations inside main. I worked from 18:00 pm to 2:00am, aprox, and 31 bugs were closed.

15 Non Maintainer Uploads, closing 20 bugs:
* delo  (Closes: #378221, #414389, #416161, #452953)
* gpib  (Closes: #430998)
* php-net-smtp (Closes: #369273)
* rpc2 (Closes: #377829) (NMU Overriden by maintainer)
* rvm (Closes: #377410) (NMU Overriden by maintainer)
* smooth-themes (Closes: #379195)
* xmltex (Closes: #429564)
* acpitool (Closes: #436637)
* asciidoc (Closes: #452470)
* chasen (Closes: #363196, #452474)
* cl-screen-sbcl (Closes: #436641, #460444)
* cpufreqd (Closes: #436647)
* denemo (Closes: #439929)
* lacheck (Closes: #448911)
* sablevm (Closes: #346071)

Filed for removal, will close 3 bugs:
* digikamimageplugins-doc (Closes: #448904)
* free-java-sdk (Closes: #429306, #401492)

Orphaning uploads, closing 2 bugs:
* xcin2.3 (Closes: #276885)
* gnochm (Closes: #429304)

Packages only present in oldstable, closing 4 bugs:
* eagle-usb-utils (Closes: #448905)
* zd1211 (Closes: #378725)
* python-pysnmp4 (Closes: #377075)
* lessdisks-terminal (Closes: #361939)

Bugs marked fixed but never properly closed, closing 2 bugs:
* araneida (Closes: #436638)
* gtk2-engines-murrine (Closes: #430999)

That leaves a total of 4 bugs remaining to finish the release goal:
* 418319 php4-apd: Don’t build a php4-specific package because of php4’s removal (serious)
* 436650 syslinux: Please build (at least a subset of) syslinux for all arches
* 448890 bioperl: recommends packages not in main (pending, serious)
* 448921 openarena-data recommends unmet openarena (>= 0.7.1) | openarena-server (>= 0.7.1) (fixed in svn)

These don’t seem trivial to fix, anyone dares to step in?

OK, been quiet for a few days, at least on the blog, but in accordance with typical behaviour (for me at least) a quiet blog means a lot of things going on elsewhere. The smallest was a fix for deb-gview - combining a fix for opening files in the current working directory with a fix for the imminent dpkg 1.14.17 which modified the .changes file format a bit. That was relatively easy and I’ve uploaded 0.2.1 to unstable. gvfs hasn’t made testing yet so there’s no point in waiting for deb-gview to migrate before 0.2.1.
The largest change? Depends how you define large:

1. Large number of changes to package files - emdebian-tools 1.0.0
2. Large effect on Emdebian workload - dpkg 1.14.17

dpkg

dpkg bugs closed - emdebian-tools 1.0.0 pending - dpkg-shlibdeps is now able to look into directories containing libraries used by cross-built binaries provided that the right environment variable are set. Closes: # 453267. dpkg-buildpackage will set PKG_CONFIG_LIBDIR (but not override an existing value) in case of cross-compilation so that pkgconfig finds .pc files in the directory specific to the target architecture. Closes: # 439979.
These two changes will have a major effect on the overall workload required within Emdebian and give us a sane cross-building environment in Lenny which is ABSOLUTELY £$^£@&*! FANTASTIC. Currently, 1.14.17 is in experimental but I’ve installed it on my system for testing purposes so that I can complete emdebian-tools 1.0.0:

emdebian-tools 1.0.0

Now here, I’m making some progress. A bug has been bothering me for some time with how emdebian-tools needs a Debian primary mirror to calculate various dependency information and other apt cache stuff whilst taking into account the host architecture. Simon and I now think that we can do the dependency stuff with a continually updated dpkg-cross repository and I can use libcache-apt-perl for the rest. So whereas dpkg-cross might still exist into Lenny, it is looking like apt-cross might not - at least not as an application. However, I’m not taking that step with emdebian-tools just yet. In the meantime, I’m simply using debconf to replace the automated selection of a Debian Primary Mirror and passing that mirror to apt-cross - something I should probably have setup a while ago.
As well as that bug fix, I’ve added a check to emchain so that users are warned if they don’t actually need to run it, added the mirror support to the various scripts and removed the workarounds now fixed by dpkg.
‘dpkg-buildpackage -a‘ is usable for nearly all packages once you have dpkg-dev >= 1.14.7. emdebuild >= 1.0.0 is only necessary IF:

1. You want to modify/update Emdebian patches (not just apply them) - i.e. if you have commit access to Emdebian SVN.
2. You need the one remaining wrapper: ‘X-Build-Cross-Libtool: yes‘ which is my next main target. This is a package-specific problem and each incidence needs a package-specific solution via an appropriate patch. As such, the wrapper is likely to stay in place in emdebuild for some considerable time - at least until someone can rebuild the entire archive with a test that can identify which packages are still affected.
3. You want the build checks currently implemented by emdebuild but which I plan to spin out during the life of emdebian-tools 1.x. I want to standardise those build checks and abstract them into possibly a lintian-compatible check set.

Also, there should now be no need for any wrapper scripts that anyone may have devised to mangle LD_LIBRARY_PATH or PKG_CONFIG_LIBDIR - indeed,
explicit support for these within dpkg means that it is to be considered harmful from now on to touch these variables, except possibly in some specific corner cases.

I’m just a user and wordy blogger, and I find it fascinating to learn how bugs are dealt with in software projects like Debian.