Monthly Archives: July 2007

binNMU unsafe packages

In DebConf I’ve noticed a lintain error about some of my debian-hebrew packages. While fixing my own package, I’ve noticed a lot of other packages which have the same error.

During and after Debconf, I’ve started reporting these as bugs. The main reason for these bug are to provide the maintainer with patches to fix their debian/control.

While doing the patches and reports, I’ve stumbled on packages already binNMUed on some arches, which made them uninstallable. In a few cases I was able to provide a patch just before the package has been binNMUed.

Providing patches takes more time than just [mass-] reporting the bugs, but I believe it worth the trouble as it makes the maintainer’s life easier.

I’m following lintain.d.o for not-binnmuable-any-depends-any error and the not-binnmuable-any-depends-all / not-binnmuable-all-depends-any warnings to identify which packages are problematic. I’ve also asked to refine the not-binnmuable-any-depends-any check, to include check for binNMU unsafe packages with the old style dependency (“${Source-Version}”).

The change of the check will affect 1285 packages currently using the old style. These include some packages which are surely problematic (binary debug “-dbg” and development “-dev” packages).

So although this statement from the Release Team Meeting results is true:

* Automatic bin-NMUs have been of great use to shorten transitions. As most packages are now bin-NMUable, we will make further use of this tool for Lenny.

We still have some work to do to ease their life with the release work. Help will be appreciated.

1 Comment

Filed under Debian GNU/Linux, QA stuff

Bug triaging and version info

I’ve been doing a bug triage for Debian’s package for the last 3 weeks (3 more weeks to go). One of the important result I’m trying to achieve is get info about which bugs are still relevant, and to which version. It seems to me that our users (and some of our developers) don’t know how important is the version info, and how to use it.

People report (or update) bug without mentioning which version they use, and if they do, it isn’t recorded in the BTS due to not using the proper pseudo header.

So before doing the bug triage I went through most of bugs, to add them with the right version info. As most of these versions don’t exist in Debian any more (not even in Sarge), I’m sad to see users not updating their bug reports. Especially people who complain about the program crashing on startup, as it easy to notice when the “bug” doesn’t occur any more. I don’t expect users to update their bug reports on every new version of the package, but at least on major updates.

An annoying example is closing bugs without the version info, especially when it closed in unstable, but still relevant for testing and stable users. From the opposite direction, finding out that a bug closed in the version in stable, means it’s not relevant any more for the testing and unstable flavors.

For these reasons, I’ve been doing quit a few re-closing of bugs, in order to add version info. I’m fine with having to “clean up” after users, which I don’t expect to master the BTS options, but I do expect DDs to know this issue. I hoped Steinar‘s “BTS versioning explained” series would remind DDs to use versioning info.

Leave a comment

Filed under Debian GNU/Linux