Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Debian Traffic #27 For 16 Mar 2001

Editor: Zack Brown

By Prashanth Mundkur  and  Zack Brown

Debian Home Page | Weekly News | Social Contract | Constitution | Policy Manual | Developer's Reference | Documentation Project | debian-devel Archives

Table Of Contents


Want to help write KC Debian? See the KC Authorship page the KC Debian homepage, and the Thread Summary FAQ. Send any questions to the KCDevel mailing list.

Mailing List Stats For This Week

We looked at 423 posts in 1373K.

There were 167 different contributors. 74 posted more than once. 0 posted last week too.

The top posters of the week were:

1. Removing Perl as an Essential Package

1 Mar 2001 - 6 Mar 2001 (34 posts) Archive Link: "Perl essential ?"

Summary By Prashanth Mundkur

People: Glenn McGrathRichard BraakmanPaolo MolaroWichert Akkerman

Glenn McGrath questioned the Essential status of Perl in the Debian distribution: " From my count there are 24 essential binaries, totalling 6550kB of linux-i386 debs. Perl-base is one of them at 840kB, ~13% of total essential size. Would it be a good long term goal to remove perl from Esssential and rewrite these scripts for a posix compliant shell or in c. " He provided a list of essential binaries that depend on perl. Richard Braakman replied "The reason for perl-base being Essential is not that other Essential packages can use it. It's Essential so that packages can use it in maintainer scripts (postinst, preinst, etc)." Paolo Molaro added, " If you're really concerned about size, you should propose to rewrite all the other utilities in perl: that will save more disk-space and provide the same functionality at the same time. Read some papers about ETLinux for an example of using a scripting language in the implementations of system utilities in low disk space conditions. Search for "Perl power tools" for a pure perl implementation of most of the utilities in the essential packages:-)"

Later there was a discussion on the relative security of perl scripts and C and shell code. Ilya Martynov suggested that Perl's lack of buffer overflows and taint mode made it a more secure coding language. Wichert Akkerman responded "It's just as easy to write insecure perl scripts as it is to write insecure shell scripts. Tainting only protects you from a couple of mistakes, but not all. Secure programming is not a language feature, it is something a programmer must be aware of for every line of code he writes, and even more importantly when making the initial design. "

So far, needless to say, it seems unlikely that Perl will be replaced in Debian packaging and distribution infrastructure.

2. Smaller Packages Files

2 Mar 2001 - 9 Mar 2001 (27 posts) Archive Link: "How to make Packages file 50% smaller"

Summary By Prashanth Mundkur

People: Brian MayJoey HessOla Lundqvist

Brian May complained about the bandwidth cost of downloading large Packages files, and proposed removing the long package description field: " why not split the description into a separate file, so you only have to download it if you really want it? " There followed some discussion of the pros and cons of downloading descriptions on demand and upgrading offline. Joey Hess thought "I'd rather have a large wait at the start than turn every tool that uses extended descriptions into a crawling nighmare." Brian May countered "I would rather have a small delay whenever I look up package information, rather then pay to download large descriptions (up to once a day), which in all probability have not even changed since last time. "

Several liked the idea of using diffs. Ola Lundqvist proposed to " Use cvs/rcs or similar for the Packages (and ..-tiny) file. Apt-get (and similar) store the version of the file that they have fetched. It then fetches the Packages-diff-from-vernum file which is automaticly created by from cvs/rcs.." Brian May also pointed out "Also, separating the description might make it easier for languages other then English."

Eventually the thread petered out inconclusively.

3. Restricting Packages From Apt Sources

7 Mar 2001 - 9 Mar 2001 (24 posts) Archive Link: "Possibility of packaging JDK 1.3?"

Summary By Prashanth Mundkur

People: Bernd EckenfelsMatt ZimmermanAnthony Towns

A thread on apt-getting JDK 1.3 from blackdown and its mirrors eventually turned to specifying the particular packages an apt source was ``trusted'' for. As Bernd Eckenfels put it, "It is still a security problem that you are unable to limit the pachages apt will suck from a given source. It could even happen by accident that blackdown is putting some unstable libc on their server and BANG your system is hossed." Matt Zimmerman pointed out "It should be possible to prevent this using the pinning feature of the new apt (see apt_preferences(5)). You could list each package that you wish to have retrieved from the blackdown source, and pin any other packages from that source to priority -1."

Anthony Towns later provided a preview of apt 0.5, currently in unstable: "

With apt 0.5, you can be fairly detailed about how you trust sources (as someone said in another message) but only as long as you can rely on their Release file being correct

When Conectiva ported apt to RPM, they also added some crypto support, which is in the process of being extended and fiddled with (and forward ported to apt 0.5) and should hopefully allow you to have end-to-end security (from Debian direct to the user, rather than having to trust the mirrors and proxies in between), as well as the fine-grained security apt 0.5 provides.

" This week's Debian Weekly News has some more related information.

4. Archiving Historical Bug Reports

8 Mar 2001 - 10 Mar 2001 (9 posts) Archive Link: "Old BTS snapshot"

Summary By Zack Brown

People: Richard BraakmanJoey HessWichert AkkermanJason Henry Parker

Richard Braakman offered:

I still have a snapshot of the BTS web pages from July 1997. It contains many bugreports that have since expired, and it's from before the time that expired bugreports were archived.

Would anyone like to keep these records? It might be interesting to add them to the archived bugs section of the BTS, though that will require some scripting.

Joey Hess gasped in ecstatic joy, "Oh, oh. I, for one, would be very interested in doing that. Though I know nada about adminning the bts. Anyhow, I'd like to keep a copy if nothing else." Richard stuck them up at Joey snarfed it and replied:

So I have a script that generates .report and .status files that seem to be valid. I still need to make .log files, which will be .. interesting. Crazy, crazy format.

I also need to make it look at the existing bts, and skip bugs that are _still_ open after all these years. And make it set any remaining bugs from the old snapshot as all closed, with a note saying something like "This bug was fixed sometime between 1997 and 2000; data since 1997 was lost.". Then after some more checking they should be ready to drop into archive/ in the BTS.

Wichert Akkerman also put in, "More historic BTS data: I have a complete copy of the BTS spool from October 18, 1998. If anyone is interested I'll try uploading it to a Debian server (that's gonna be fun with a 56k modem..)" Joey replied, "That should be quite trivial to import into the archive. Just remove still-existant bugs, and mark all unclosed bugs as done.."

Elsewhere, Jason Henry Parker replied to Richard's initial archive:

Interestingly, the archive contains Neal Stephenson's bug report which he talks about in /In the Beginning was the Command Line/ (available at

It is bug #6518 and reports that /etc/ was missing /usr/X11R6/lib .

Joey replied:

Yep, and this bug and 7100 more are now available in the BTS.

This is still under beta test; we've hacked the bug view script to look in a second directory for the old bugs. They will be merged in with the real archive when we're sure they're ok, and then they'll start appearing on the indexes too.


Of course if anyone finds any more such old web archives, I can try to import them too. It's neat to see a bug as old as #563 (submitted in 1995!), I'd like to go back even further..

5. A GPLed Censorware-capable Package and the DFSG

8 Mar 2001 - 9 Mar 2001 (22 posts) Archive Link: "FilterProxy and DFSG-compliancy?"

Summary By Prashanth Mundkur

People: Bob McElrathDavid WhedonColin Watson

Kenneth Vestergaard Schmidt asked about the DFSG compliance of the license of FilterProxy, a web filtering package that was licensed under the GPL but had additional unusual conditions on its usage. The license file stated "This software is in an unfortunate position in that it can be relatively easily used to restrict freedom of information. I think that freedom of information is just as important as freedom to copy software. " and listed


FilterProxy is not intended to allow you to modify content and misrepresent it as the original. Any user of FilterProxy must first give consent for their content to be filtered, know that their content is being filtered, and be able to determine exactly how it was or will be filtered.

I am quite serious about this. In case that wasn't clear, you may not do the following things with FilterProxy:

*UNLESS* you have the express knowledge and consent of the person whose web content is being filtered.


David Whedon, while sympathetic to the views of the author of FilterProxy, thought this went against Section 6 ("No Discrimination Against Fields of Endeavor") of the DFSG: " The license must not restrict anyone from making use of the program in a specific field of endeavor. " And Colin Watson was irked by the conditions on FilterProxy: "What next? "You may not use this gcc to compile censorware programs?" "You may not compile things I disapprove of against this glibc?""

The author of the package in question, Bob McElrath, later joined in and explained the reasons for his conditions, stressing that essentially his primary goals was to ensure that viewers of filtered content were aware of the filtering taking place and had consented to it, and covering his legal bases in case the content that was filtered was modified and distributed without permission of the content's copyright owner. He also added: "

The "LICENSE" is properly not a part of the copyright. As it states in the my LICENSE:

    The GNU Public License does not cover usage, or content/data
    generated by a program covered by it.  From the GPL:  "Activities
    other than copying, distribution and modification are not covered by
    this License; they are outside its scope."
Copying is a separate activity from use. Copying is covered by the GPL. Usage is covered by my LICENSE.

" He eventually agreed to make a few changes in the phrasing he used, but was reconciled to his software being in the non-free section of Debian. " The DFSG was pointed out to me quite some time ago, and I agreed then that my license violated it, and it still does. I'm going to keep it that way if for no other reason than to possibly keep me from being sued."







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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.