Debian Traffic #25 For 2 Mar 2001

Want to help write KC Debian? See the KC Authorship page (../author.html) the KC Debian homepage (index.html) , and the Thread Summary FAQ (../summaryfaq.html) . Send any questions to the KCDevel mailing list. (mailto:kcdevel@zork.net)

1. OpenOffice Packaging Update

8 Feb 2001 - 25 Feb 2001 (11 posts) Subject: "OpenOffice packages?"

Summary By Prashanth Mundkur

People: Anthony Towns, , Adrian Bunk, Stephen Zander, Antti-Juhani Kaijanaho

There was some more discussion of packaging OpenOffice, last discussed in Issue #14, Section #4 (30 Nov 2000: Status of Open Office packaging) .Anthony Towns asked, " So, it seems we don't have StarOffice/OpenOffice packages yet in spite of three people ITPing it... Any of you care to fix this?" Adrian Bunk said he was having problems building it without JDK 1.2.2. When Anthony suggested using the version from blackdown.org to build, Stephen Zander pointed out that that Openffice would likely require the blackdown 1.2.2 Java Runtime Environment (JRE) to run, which is not DFSG free. Antti-Juhani Kaijanaho said Kaffe was too buggy and only provided JDK 1.1.

Alan Shutko and Jeffry Smith later commented that the JDK was only required for optional functionality, and that OpenOffice could be run without the JRE.

2. Debconf and Remote Package Configuration

16 Feb 2001 - 23 Feb 2001 (22 posts) Archive Link: "automating debconf"

Summary By Prashanth Mundkur

People: Craig Sanders, joey Hess, Joey Hess,

Craig Sanders requested a pipe feature for debconf, so that he could " use a for loop around a script which connects to a remote machine with ssh and either makes configuration changes or runs apt-get to upgrade/install/remove packages from the system." He needed this as " i've got several remote boxes which need this done to them so that i can script upgrades for important packages as security updates are released "

He later elaborated what he had in mind: "

one of the strengths of unix is that data & configuration details can be piped around and transformed and manipulated using the whole swag of unix text manipulation tools. plain-text configuration is a strength, not a weakness.

while some special-purpose database thingy would be good for those who like to work like that, a solution that allows generic piping of configuration data in and out of debconf would work just fine for the sysadmins out there who have years of experience in the traditional unix way of doing things. [...]

it would open up all sorts of possibilities too. e.g. copying configuration data from one machine to another could be as simple as something like:

debconf --extract postfix | ssh remote.hostname debconf --configure postfix

and if you needed to transform one particular variable to customise it for the remote machine:

debconf --extract postfix | \

        sed -e "s/localhostname/remotehostname/gi" | \

        ssh remote.hostname debconf --configure postfix

now you can wrap that in a for loop to configure many machines at once:

for i in $( cat hosts ) ; do

        debconf --extract postfix | \

                sed -e "s/localhostname/$i/gi" | \

                ssh $i debconf --configure postfix

done

this is the unix "small tools" approach to problem-solving in action. it works, and it works extremely well...it has worked extremely well for over 20 years. it's very flexible and it allows people to do common or "standard" things easily without sacrificing their ability to do unusual or oddball things that they need to do for some reason or other. it lends itself to customised automation tasks.

Joey Hess responded, " Well, what you're really running into is the missing third of debconf, the flexible backend database. You _should_ be able to point all these machines as a single master debconf database, or ship a database file onto them, or accomplish this in several other ways. "

Very soon thereafter, Joey Hess announced (http://lists.debian.org/debian-devel-0102/msg01152.html) that he was working on a backend database for debconf: "I've been writing a backend db for debconf, since nobody else will do it." and asked for comments on the config file format.

3. Cross-compiling as a Solution for m68k Build Problems

16 Feb 2001 - 23 Feb 2001 (28 posts) Archive Link: "m68k buildd presents significant problem for non-us and testing"

Summary By Prashanth Mundkur

People: Sam Hartman, Steve Langasek, Paul Slootman, Marcus Brinkmann,

Sam Hartman was upset with the time taken to build packages on m68k:

Looking at incoming/DONE on pandora, it looks as if m68k buildd has not built packages for non-us since January 10. This means that packages uploaded since January 10 with m68k support have not made it into testing. [...]

I believe this is unacceptably long. Non-us maintainers want their packages tested too; users who are running testing also depend on these packages.

More than that, if we are preparing for a freeze, waiting a month to start getting feedback on how a package interacts with testing will significantly decrease the quality of packages in the non-us section of the archive.

Steve Langasek proposed using cross-compilers for autobuilding: " all the heavy compiling work could be done on heavy-duty machines, regardless of architecture " . Paul Slootman pointed out a potential problem: " It's not that simple, because often, during the build of a package, an executable that was compiled just before is used in the build process, and such situations won't work."

The discussion continued in a later thread (http://lists.debian.org/debian-devel-0102/msg01354.html) , with opinions divided on the usefulness of the idea. Scott Dier pointed out the problem of tests for executable binaries during package build times. Marcus Brinkmann recounted his experiences:

Unfortunately, there can be very subtle issues (for example, one version of bash got the list of signals wrong, because it was using the build systems header files, not the host systems. You wouldn't notice this problem until after some later time).

However, packages can try to support cross building via dpkg-architecture, which provides all the necessary information to debian/rules. It would be nice if all Essential and Required packages could be cross build. [...]

I cross build glibc for the Hurd, and occasionally some other programs. Many Debian packages won't cross build, though.

During the course of the discussion, several folks came forward to offer more machines to reduce the load on the m68k build machines. Scott Dier offered a spare box, Pieter Schoenmakers came forward with an offer of two NeXt boxes, and Alain Schroeder said he was working on getting another box.

4. Packaging Policy on Build-Depends

24 Feb 2001 - 25 Feb 2001 (17 posts) Archive Link: "serious bugs because of missing build depends"

Summary By Prashanth Mundkur

People: Wichert Akkerman, Julian Gilbey, Bob Hilliard,

Peter Palfrader announced after some discussion on #debian-bugs that a serious bug should not be filed against a package due to the lack of a Build-Depends, since the Policy Manual (http://www.debian.org/doc/debian-policy/ch-relationships.html#s7.6) said this field may be defined; he added later that Bug #87510 was a proposal to make this field a requirement. Wichert Akkerman said that " a number of packages don't have build dependencies at all (everything they need is build-essential)" , but Julian Gilbey pointed out elsewhere that "perhaps lintian should warn if there is no Build-Depends(-Indep) line, seeing that most packages will need one (for debhelper, if nothing else)."

The Standards-Version field was then discussed, with Bob Hilliard pointing out the Policy was a bit vague on what "current policy" was: " Is it the version in stable, in testing, or in unstable? "

Julian Gilbey eventually announced " I'll post an announcement to -devel-announce when the rewritten policy is ready. "

Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.

1.	8 Feb 2001 - 25 Feb 2001	(11 posts)	OpenOffice Packaging Update
2.	16 Feb 2001 - 23 Feb 2001	(22 posts)	Debconf and Remote Package Configuration
3.	16 Feb 2001 - 23 Feb 2001	(28 posts)	Cross-compiling as a Solution for m68k Build Problems
4.	24 Feb 2001 - 25 Feb 2001	(17 posts)	Packaging Policy on Build-Depends

Debian Traffic #25 For 2 Mar 2001

Editor: Zack Brown

By Prashanth Mundkur