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 #1 For 7 Sep 2000

Editor: Zack Brown

By Benedikt KöhlerRonan O'Sullivan  and  Zack Brown

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

Table Of Contents


Welcome to the first issue of Kernel Cousin Debian! This is also the first attempt at a group-authored Cousin. For more information about group-authored Cousins and how you can get involved, see the KC Debian home page. The hope is that by allowing folks to contribute as much or as little as they please, an easy entry/exit path exists for participation. We still need more authors. If you're interested, email Zack Brown.

For folks not familiar with Debian, it is one of the only Linux distributions developed in a truly distributed fashion. Each package has a maintainer somewhere on the net, and maintainers constantly come and go within the project. There is a project leader (currently Wichert Akkerman), duly elected in accordance with the laws set forth in the Debian Constitution (a rich and fascinating document, which other projects would do well to learn from).

Joey Hess writes the Debian Weekly News, and has since January 1999. For the latest updates on patches, security, and other important events, it is still the best Debian news source around. Hopefully KC Debian will provide a nice complement to it, giving folks a peek into the inner workings of the Debian development process.

Mailing List Stats For This Week

We looked at 346 posts in 1174K.

There were 172 different contributors. 71 posted more than once. 0 posted last week too.

The top posters of the week were:

1. Location Of Files For Personal .deb Packages

28 Aug 2000 - 3 Sep 2000 (11 posts) Subject: "location of non-debian deb package?"

Summary By Zack Brown

People: Nicolás LichtmaierMark BrownArthur Korn

Vincent Zweije wanted to create a package not intended for Debian proper (it had a very limited target audience, and would probably be replaced by an non-backwards-compatible upgrade). He asked if the proper location for the files from this package would be '/usr/local/index.html', '/usr/index.html', or where. It seemed to him that '/usr/local/index.html' would be the logical place, but Nicolás Lichtmaier replied, "A package should *never* touch /usr/local or /opt. It doesn't matter who created it. /usr/local is maintained by the sysdamin, the rest: by dpkg." Arthur Korn also replied to Vincent along the same lines, adding that the FHS (which was included in Debian policy) explicitly stated that the distribution should not touch '/usr/local/index.html'.

Vincent replied that as his package was non-Debian, i.e. was not part of the true distribution, it did seem to qualify as "locally installed software" as per the FHS. But Mark Brown replied, "People tend to read the "locally installed software" as "software the package manager doesn't know about"." This hadn't occurred to Vincent, and he agreed. End Of Thread (tm).

2. Rewriting The BTS Scripts

29 Aug 2000 - 30 Aug 2000 (7 posts) Subject: "Bug reports by maintainer"

Summary By Ronan O'Sullivan

People: Anthony TownsJames A. TreacyJosip RodinNicolás LichtmaierJulian Gilbey

Anthony Towns announced that while burning the midnight oil he updated the BTS CGI scripts which reside at He also added, " The main interesting thing is that it does bug-reports-by-maintainers, with a syntax like: Using email_address also works now, e.g." He added:

It should be no more than 12 hours out of date at any one time, I think. Ummm. Also supported is adding "&archive=yes" to look at closed bug reports against your packages, fwiw, and "&repeatmerged=no" to avoid seeing duplicate entries for merged bugreports. It also separates out forwarded bug reports like used to happen a year or so ago. too. All from the one program. Not sure if this design is likely to be stuck with or not. *shrug*.

Some "internal" links within the BTS will be a bit broken at the moment. Mostly it should work okay though, I think.

James A. Treacy added he also had modified /org/ to use instead of He went on, "using>email_address> also works now, e.g."

Julian Gilbey asked if this could be used to regenerate the static BTS pages, so they'd start working again, but James replied, "I believe the goal is to remove the static pages completely. Only a few more scripts need to be written." But Nicolás Lichtmaier objected that static pages allowed mirrors and caches, which would be stymied otherwise. Josip Rodin explained, "We don't have a good, fast system that is able to regenerate the static pages in a timely manner."

3. 'oregano' Licensing Question

28 Aug 2000 - 29 Aug 2000 (3 posts) Subject: "New package(s): oregano (and [ng-]spice?)"

Summary By Zack Brown

People: Arno W. PetersPeter S Galbraith

Hugo van der Merwe announced his intention to package 'oregano', a Gnome-based electronic engineering app. Peter S Galbraith gave a pointer to a message in the archive that said 'oregano' was not free software and wouldn't become free. But Hugo quoted a more recent email from Arno W. Peters, in which Arno had said, "We are working with professor Newton to change the license of Spice into one that does not conflict with GPL. This is still ongoing." End of thread.

4. Patent Questions About Compression Package

28 Aug 2000 - 29 Aug 2000 (5 posts) Archive Link: "Why is libtiff3g in main? It contains LZW compression code"

Summary By Ronan O'Sullivan

People: Ben GertzfieldDavid StarnerJosip Rodin

Ben Gertzfield had a private conversation with the GIMP tiff maintainer, which led him to believe that the tiff plugin did not contain any specific LZW compression code, and that all compression code was in the libtiff library itself, and furthermore, that recent libtiffs have LZW code disabled by default.

However upon further inspection of the '' in libtiff-3.5.4 Ben noticed that the compression file libtiff/tif_lzw.c wass included which contained copyright information. He continued, "The ncompress program is in non-free precisely because of this code; there's a nasty patent on LZW compression that's being enforced by Unisys."

Ben concluded by asking why libtiff3g was in main, and showed a list of the symbols in the libtiff.a library.

David Starner explained, "There is a nasty patent on compression - there is no patent on decompression." He went on to explain that the symbols in the libtiff.a library did not include the LZWEncode but did include LZWDecode (also used by common programs like 'gzip').

Josip Rodin also added that, "The people separated out `libtiff-lzw-compression-kit' code into a different tarball, see Current packages in potato (and woody) should be safe." He concluded on a jovial note, saying that LZW compression code had once been in 'libtiff', in 'main', and no one had caught it. Lucky the patent holders didn't notice...

5. Sources For Potato Security Fixes

29 Aug 2000 - 31 Aug 2000 (5 posts) Subject: "potato + updates"

Summary By Zack Brown

People: Wichert AkkermanEthan BensonMichael StoneMichael MeskesMatt Zimmerman

Michael Meskes asked where to find the proper 'sources.list' information for downloading Potato security fixes, including non-US fixes. Wichert Akkerman replied:

The README on already gives you that line.. I'm using these entries:

deb potato/updates main contrib non-free
deb-src potato/updates main contrib non-free

Ethan Benson added:

and here are the lines for non-US:

deb potato/non-US main contrib
deb-src potato/non-US main contrib

add non-free if desired.

(actually, Michael Stone writes to me that the above advice is not entirely correct. He says,

There is no such thing as a non-US security update; the non-US section in the URL is exactly the same as
. Thanks, Michael! -- Ed: [08 Sep 2000 17:30:00 -0800]

Matt Zimmerman suggested putting the complete list of sources on, and the thread ended.

6. Unwanted Debugging Messages In The Newer PostgreSQL Packages

30 Aug 2000 (6 posts) Subject: "Strange messages..."

Summary By Benedikt Köhler

People: Dale ScheetzJules BeanAshley ClarkRobert van der Meulen

Since his last upgrade to potato, Dale Scheetz got a lot of messages like the following and wanted to know what they meant.

DEBUG: --Relation pg_rules--

DEBUG: Pages 0: Changed 0, Reapped 0, Empty 0, New 0; Tup 0: Vac 0, Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 0, MaxLen 0; Re-using: Free/Avail. Space 0/0; EndEmpty/Avail. Pages 0/0. Elapsed 0/0 sec.

Robert van der Meulen, Jules Bean and Ashley Clark all answered that those messages were debugging messages from the newest PostgreSQL packages, which had changed from previous versions. Jules hinted "Probably you have one of the debug trace options on in your postgres config files (in /etc/postgresql)." Ashley added, "the behaviour of the config file has changed between two of the versions," and told Robert just to add PGDEBUG=0 to the /etc/postgresql/postmaster.init file to stop those messages, which seemed to have worked.

7. Status Of The BTS

30 Aug 2000 (3 posts) Subject: "CGI bug scripts"

Summary By Zack Brown

People: Julian GilbeyJames A. Treacy

Julian Gilbey pointed out that the BTS (Bug Tracking System) was very slow, and suggested migrating to mod_perl. He offered to help, and then replied to himself a minute later, adding, "I just looked at the load on master ( It's averaging around 8 or 9, and running top, I saw times when there were about 10 copies of {bug,pkg}report.cgi running simultaneously. I think that if the BTS is moving to dynamically generated pages only, mod_perl is going to be a necessity." James A. Treacy replied that it would be easy to set up, and he'd do it once his scripts had stablized.

8. Removing Version Numbers From Debian Releases?

30 Aug 2000 - 31 Aug 2000 (10 posts) Subject: "Crazy idea: removing version numbers from debian"

Summary By Benedikt Köhler

People: Thomas GuettlerWichert AkkermanVincent L. MulhollonEric SchwartzEray OzkuralBernd Eckenfels

Thomas Guettler suggested removing the version numbers (like Debian 2.2) from the releases of the Debian distribution. He stated that:

Redhat, Suse, Microsoft they need version numbers so that they can announce their great new release of their operating system. It is more or less marketing hype.

But Debian is different. It is a collection of several single application on top of Linux/Hurd. And we don't need the marketing hype of being able to announce a new version of Debian.

He added that a Debian package was either unstable or stable, and everyone should use the version that suited their needs.

Bernd Eckenfels replied that version numbers were useful, especially for Security Administrators, CD Manufacturers or people who wanted to refer to an older release (would slink be called "Old Stable"?). But he wasn't sure whether the whole Debian distribution needed a version number, or just the base section (this was FreeBSD's method). There was no reply to this, but Wichert Akkerman also replied to Thomas:

Won't work. Users demand a know really stable system, and with a dynamic system we can't guarantee the same stability as we can with a release that has been tested for a while without any updates which might mess up testing.

Also, having versioned released is something that CD vendors want to have. If we only had an ever changing semi-stable they could only sell snapshots, which means they can't produce a large number of CDs, costs will go up and they will switch to selling CDs of other distributions instead.

Vincent L. Mulhollon on the other hand approved of Thomas' idea. In his reply to Thomas' original post, his idea was to leave new packages in unstable until several days had passed without a Release Critical Bug, and then to upload it automatically to stable. If a Release Critical bug were discovered, the package would go automatically back to unstable. Users that wanted the latest version of a package could apt-get it from unstable, and users that wanted a stable but eventually older package would use the stable branch. But he admitted that "in theory this would complicate support because there would be so many "versions" of debian, yet developers survive with "daily" versions." Finally, he suggested, "the idea I like the best is no numbers, only named updates. And we'd have a goal for the name. Like the goal for "whiskey" release would be every package that needs it supports debconf, or the goal for "vodka" is every package supports kernel 2.4 and IPv6, or the goal for "scotch" is every package supports perl 5.6 or whatever."

Eric Schwartz was horrified by Vincent's suggestion. He said "Ack! Can you imagine what would happen under that system with a package whose bugs are not handled that quickly? The version in stable would be $foo, next week it's $foo.1, a week later it's $foo again because of a RC bug filed in week 1, another week passes and the bug is fixed, so it's $foo.1 again. Not to mention we'd have to start supporting downgrades as well as upgrades (although I'm a new developer, I'm fairly sure we don't do that)." He added that if a maintainer went on vacation, the package would go back to unstable if no one else had time to deal with bug reports.

Bernd Eckenfels also replied to Vincent. He thought that packages that moved too often between stable and unstable under Vincent's idea would be confusing and would break dependencies. He said that the current way to handle grave bugs of stable packages with updates was sufficient, but that maybe the unfixed packages should be pulled from the distribution, so that uninformed users wouldn't be installing them.

Another idea came from Eray Ozkural, who suggested (in reply to Thomas' original post), "perhaps indicate symbolically the usability level of the package in the binary format," but he too didn't approve of removing all version numbers, as this would require synchronizing the dependency graph globally, which in his opinion was impossible. But he added, "I have a lot of crazier ideas about distribution, release management and package classification so keep these mental inventions coming. :) This is exactly the place to discuss these."

Finally Thomas made a new proposal, that after the installation of a package, the system would prompt the user to see if the package was working, and after n positive feedbacks a package would be marked stable. There was no reply.

(ed. [Benedikt Köhler] I think this is indeed a very interesting idea to have the packages check their quality themselves, but I doubt this would be practicable at this point of time.)

9. Packaging Project Gutenberg?

2 Sep 2000 - 3 Sep 2000 (7 posts) Subject: "Project Gutenberg"

Summary By Benedikt Köhler

People: Craig SandersRobert D. HillRalf Treinen

Someone wanted to know if the work done by the Project Gutenberg should be made available via Debian's apt-get. It didn't seem like such a difficult thing to package, and he felt it would be great to be able to easily install all those free books.

Craig Sanders answered "personally, i think that a script which regularly downloaded the index of available texts, providing a searchable database, and capable of automatically fetching any one or more of them for you would be more useful." This way, he added, non-Debian users would profit from it, too.

Robert D. Hill, on the other side, pointed out:

Not all Project Gutenberg documents are DFSG free. They use a file called `SMALL PRINT' as a license document. There are currently several versions of `SMALL PRINT' in their archive. Ver.04.29.93, and Ver.03.08.92 require a royalty for commercial distribution. I believe I have seen versions that do not restrict commercial distribution, but I can't locate an example at the moment.

Most, if not all versions of `SMALL PRINT' include the following:

This PROJECT GUTENBERG-tm etext, like most PROJECT GUTENBERG- tm etexts, is a "public domain" work distributed by Professor Michael S. Hart through the Project Gutenberg Association at Carnegie-Mellon University (the "Project"). Among other things, this means that no one owns a United States copyright on or for this work, so the Project (and you!) can copy and distribute it in the United States without permission and without paying copyright royalties. Special rules, set forth below, apply if you wish to copy and distribute this etext under the Project's "PROJECT GUTENBERG" trademark.

DISTRIBUTION UNDER "PROJECT GUTENBERG-tm" You may distribute copies of this etext electronically, or by disk, book or any other medium if you either delete this "Small Print!" and all other references to Project Gutenberg, or:

(Followed by license conditions,including the royalty requirement.)

It appears that if the `SMALL PRINT' is deleted, the remainder of the document is DFSG free. However, there would be no copyright notice or license attached to that copy. I am not sure if it could be distributed in Debian without a copyright notice or license. I have copied this to debian-legal for an opinion on this.

Ralf Treinen had some more practical objections: The whole Project Gutenberg archives would take up much disk-space whereas the added value would be quite small, as downloading the texts from the Project Gutenberg homepage is quite easy.

Finally the original poster and Chris Gray both pointed to gutenbook, a GPLed tool to find and retrieve works from the project.

10. Debian Web Page Designed In MS Windows?

2 Sep 2000 - 3 Sep 2000 (15 posts) Subject: "Help on Debian Project - Need Me?"

Summary By Zack Brown

People: Ben CollinsColin WaltersMarcelo E. MagallonFranklin Belew

Kyle Lynch introduced himself and offered to help work on the Debian web site, although he was only proficient with Windows tools. Ben Collins replied, "Well, IMO, anything that goes on the Debian website better be created by free software. No offense, but if I start seeing "Made with Macromedia" or "Designed with Photoshop" on the website, there will be hell to pay :)" Colin Walters felt this was a bit much, and replied:

It seems very strict to require that everything on the website have been created with free software. Of course, their contributions shouldn't require proprietary software to *use*.

If someone wants to help, and is willing to put their contributions under a free license, why not let them?

I do agree that Debian should not be advertising proprietary software on the web pages.

Franklin Belew could see the headlines: 'Yeah, our distribution kicks ass but our web pages require Windows2k and X proprietary software programs to produce', but Marcelo E. Magallon stomped on the smoke with:

Brace yourself for impact: our logo was not created using free software. Even more, software packaged by us wasn't even involved, AFAICR.

Now that the logo exists, someone would probably be able to reproduce it using the Gimp or Octave or Perl or something like that. The person who actually created it didn't use any of that because he was more confortable using other tools in another environment. The question is not whether the final product, specifically graphics or templates, can be created using Debian, but whether the person *actually creating* it feels confortable enough with the tools provided.

No tool is inherently wrong for a given task, and this specially true when you are talking about graphics production. I know a guy who used to sketch portraits on his computer. Using a CAD program.

There was no reply.







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.