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

Editor: Zack Brown

By Eusebio C Rufian-ZilbermannJens MüllerSeth Cohn  and  Zack Brown

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

Table Of Contents


KC Debian needs more authors! If you're interested, check out the KC Debian homepage.

Mailing List Stats For This Week

We looked at 340 posts in 1185K.

There were 166 different contributors. 60 posted more than once. 0 posted last week too.

The top posters of the week were:

1. Samba Adjusts To Variable Win2K Protocols

12 Sep 2000 (3 posts) Archive Link: "Samba 2.0.5a dislikes Windows 2000 2.0.7 OK"

Summary By Jens Müller

People: Dean CarpenterWichert AkkermanAlec Smith

Dean Carpenter explained, "I have a nice stable slink system here, been running for a looong time, rock solid. NT 4.0 clients access it via samba 2.0.5a, and everything works." But now Windows 2000 didn't want to talk to samba 2.0.5a, whereas samba 2.0.7 worked fine. He asked which bug in 2.0.5a prevented it from talking to Win2k, and if it was safe to run 2.0.7 under slink.

Wichert Akkerman located the problem at Win2k's side, "which decided to use a slightly different protocol." As to using 2.0.7 under slink, he responded it "should be a matter of recompiling and installing I think."

Alec Smith replied:

Samba 2.0.7 will run fine on a Slink system. I've had the setup up and running since the original 2.0.7 release by the Samba Team last spring.

At best you'll need to download the Debian sources for Samba from the Potato arachives and recompile against Slink libraries. At worst you'll need the .tar.gz from and some time to tweak things.

There was no reply.

2. Using Standard Date Formats

13 Sep 2000 - 18 Sep 2000 (8 posts) Archive Link: "NM Page info."

Summary By Eusebio C Rufian-Zilbermann

People: David BrownPaul SlootmanLars Wirzenius

This thread started when David Brown noted that the dates in the New Maintainer pages were expressed in a confusing format, and provided a link to an example. He requested: "Would it be possible to post the dates in ISO date format YYYY-MM-DD" ?

Further in the thread, Paul Slootman supported the idea. "The great thing about the ISO date format yyyy-mm-dd is that it can be sorted easily (with correct results :-) "

Elsewhere, Lars Wirzenius said:

It is, of course, not unheard of for normal people (non-nerds) to interpret 2000-09-01 as the ninth of January, year two thousand. I've even in my old life as Linux Software Map maintainer seen people express dates as 01-2000-09. No, I didn't understand what they meant, either.

That's why in normal text it tends to be best to express dates using non-encoded formats, such as "September 1, 2000" or "01-SEP-2000". They don't sort very well, and they're language dependent, but in normal text that isn't very important - having fewer errors is. When sorting or mechanical interpretation is important, the ISO date format shines.

David continued in Issue #4, Section #6  (14 Sep 2000: Standard Date Format (part II)) with another example.

3. Mozilla SSL Support?

12 Sep 2000 (5 posts) Archive Link: "Mozilla PSM (https support)"

Summary By Jens Müller

People: Franklin BelewJoseph CarterJosip Rodin

Franklin Belew remarked that since the RSA code had been put in the public domain recently, the Personal Security Manager (which allowed SSL connections in Mozilla using the https protocol) had been put under the same license as Mozilla (i.e. the GPL and MPL). He emphasized several facts:

He asked if PSM could go into main, or if not into main, how he could build it "so that mozilla(noncrypto parts) goes in main, while mozilla-psm goes to non-us/main with minimum amount of manual work" . He also urged folks to keep the autobuilders in mind.

Joseph Carter replied that Netscape 4.75 was already in main. But Ruud de Rooij didn't think this was true, and Josip Rodin made clear that Netscape was in non-free/contrib.

Joseph also made a proposal in his posting: "You might consider building two copies of mozilla, but frankly I'm beginning to tire of this US/non-US crap with our packages. Wasn't someone going to have a look at the regulations or something? IIRC the policies were up for review in four months, but it's been longer than that by quite some measure."

There was no reply to that, but elsewhere, Franklin ended the thread with new information he had found, "The PSM is completely self-contained in the mozilla source tree, so all my previous problems are null and void" .

There was no reply.

4. MP3 Patents - Again

12 Sep 2000 - 19 Sep 2000 (8 posts) Archive Link: "mp3 encoding patents."

Summary By Jens Müller

People: Sean 'Shaleh' PerryRichard BraakmanSimon RichterJoseph CarterIngo Saitz

Viral wanted to know why MP3 encoders could not just be distributed from a non-US site, since policies in other countries were much more relaxed.

Sean 'Shaleh' Perry answered him, "the patents are held in Germany. This restricts us because most countries in Europe accept them."

(ed. [Jens Müller] That can't be wholly true, as I read in a German computer magazine that the Fraunhofer Society, which has created MP3, cannot enforce it's US Patent in Germany itself, only in the US, because algorithms are not patentable in Germany.)

Bart Schuller responded that there would be problems mirroring in any case, but that this patent problem wouldn't rule out hosting such programs in (and for) countries not allowing such patents.

He explained that math and software are not patentable in the Netherlands, and that other kinds of European patents had to be registered in the Netherlands, too, to be valid there. He said this was done in a kind of fast-track registration process. He couldn't answer the question of what would happen if a European patent conflicted with the local laws in the Netherlands, but thought it was an interesting question. He said he had searched for relevant patents in the Dutch Patent Database, but hadn't found any.

Richard Braakman explained his take on the legal situation in the Netherlands (though acknowledging he was not a lawyer), "The situation is a bit better than that. In the Netherlands, patents *don't apply* to computer programs (among other things). So the patents are valid, there's no conflict, they're just more limited in scope than in some other jurisdictions."

Simon Richter presented his view, "AFAIK the MP3 compression function isn't protected, the psychoacustic model they use is (represented by the tables). lame has its own psychacustic model, so it should be safe to use and package."

Joseph Carter responded and explained in a bit more detail the legal situation on patents. He said, "You might be right about that, but I wouldn't necessarily bet on that. A patent must include basic information about how the process works. AFAIK, theirs does but I do not recall to what extent they describe it. Usually you want to keep patents vague and generic so you have room to move around within your own design and still be covered by your own patent (and to prevent clones from being able to skirt your monopoly..)"

He presented his thoughts about the legal consequences on lame, "Iff their patent includes their psychacustic model in enough detail that it describes their model (only) and not lame's, lame could be freely uploaded to main."

Ingo Saitz was sceptical about that. He said the whole format seemed to be encumbered by patents and that Fraunhofer and Thomson even wanted to charge for the distribution of electronic music. He pointed to saying that MP3 decoding could also cause trouble. He closed, presenting his doubts that the patents were really applicable in the way the inventors claimed on the website.

5. Graph Of Debian GPG Keyring

14 Sep 2000 - 19 Sep 2000 (10 posts) Archive Link: "graphing the debian keyring"

Summary By Seth Cohn

People: Joey HessAndreas FuchsDamian M GryskiBen ArmstrongClay Crouch

Darxus posted new graphs he'd created of the Debian GPG keyring.

Joey Hess replied, " Nice. You should graph the pgp ring too. It should also be possible to merge the two graphs.."

Clay Crouch and Nicolas Lichtmaier both noticed from the graph that they weren't very well linked and asked for additional key exchanges. Clay is near Kansas City and Nicolas is in Buenos Aires.

Christoph Baumann noticed that his gpg key was missing. He'd signed it with his pgp key. Andrew Lenharth and Ben Armstrong noticed they had the same problem. Ben wondered if anyone was coming to Halifax, Nova Scotia soon, to help him out with it.

Darxus replied that Christoph Baumann he wasn't in the debian-keyring package yet, and that he hadn't graphed keys that were only signed by themselves.

He also noticed some odd traffic patterns on the web page, which seemed to have sudden jumps in popularity. Andreas Fuchs replied, "Three letters: DWN (-:" and Damian M Gryski added, " Debian Weekly News came out today. One of the articles mentioned the graph, with a link to the original post for more information."

6. Standard Date Format (part II)

14 Sep 2000 - 15 Sep 2000 (4 posts) Subject: "Dates again."

Summary By Eusebio C Rufian-Zilbermann

People: Chris BallDavid BrownSteve LambJosip Rodin

Continuing from Issue #4, Section #2  (13 Sep 2000: Using Standard Date Formats) , David Brown provided another example of confusing dates. This time it was a message by Chris Ball, in which Chris said, "I'm in the queue at the moment (9-7-00)." David said, "Here is a prime example of an ambiguous date. Is the 9 July, or 7 September?"

After a Y2K joke (with a point) "Yeah, but he's been in the queue for 100 years" , Chris Ball agreed: "I had this thought as I wrote the mail." and expressed his support for David's proposal to standardize on ISO dates. He went on, "with a large Europe/Americas mix there's the potential for a lot of confusion," and added, "Are there any real arguments for *not* changing to ISO?"

Josip Rodin added "Don't forget the many developers from other continents... who are probably confused even more with this date stuff :)"

7. Planning the Woody Installer

14 Sep 2000 - 18 Sep 2000 (35 posts) Archive Link: "woody Debian Installer plans"

Summary By Seth Cohn

People: Glenn McGrathMarcus BrinkmannDaniel BurrowsEnrique Robledo ArnuncioJosip RodinDaniel JacobowitzTorsten LandschoffNeal Walfield

Glenn McGrath wrote:

The debian installer team is currently planning how the next installer will work, documents describing these plans are at

One of the primary goals of the woody installer is that it will become very modular, and rely on debconf style configuration such modules. It is intended to be a fairly radical change from the current installer.

There has been a very long thread recently on debian-boot regarding how it should work, amoungst other things there has been a lot of interest in mass and automated installs.

If anyone has has strong opinions on the installer i would encourage them to checkout the documents and recent threads on debian-boot mailing list and discuss there thoughts on the debian-boot mailing list.

It would be good to get different viewpoints whilst it is still very much in the planning stage.

The 2 main subthreads that arose for discussion on debian-devel were Debian Hurd and Grub. Marcus Brinkmann started it out:

The documents are short on details and full of linuxisms, but this is probably to be expected.

It seems that a lot of those "modules" would need to be rewritten for the Hurd ("mounting" for example works different on the Hurd than under linux). It would be nice if you can keep this in mind.

Also, it always talks about lilo/silo. It would be nice if we could enter the 21st century and use GRUB. This also helps the Hurd of course, because it is the only boot loader we can use. (GRUB is under active development, and it is a great bootloader, with menus, file system support etc etc).

A post or two later, Daniel Burrows replied:

Grub is a much nicer bootloader than lilo; I switched to it to try the Hurd, but it's so much nicer (in fact) that I no longer install lilo on any system where I can replace it with Grub. Maybe lilo should be kept around for weird hardware that Grub doesn't support (is there any such hardware?), but Grub is really very superior in terms of interface and capabilities -- especially because it does filesystem lookups to find the OS kernel, so installing a new kernel (or moving your old one on the disk) doesn't cause your system to become unbootable if you forget to run LILO. And if you do somehow mess up you r system, you can use the Grub command line to fix your problem. Being able to type:

root (hd0,1)
kernel /boot/vmlinuz-2.2.16

and boot with your former kernel saves a LOT of fooling around with special bootdisks.

And did I mention that it's really nice? :)

Enrique Robledo Arnuncio wrote:

You forgot to say that you can find the paths using command line completion:

root (hd[TAB]
possible partitions are:

kernel /boot/[TAB] chain.b mbr.b
vmlinuz-2.2.17 boot.b

You can do that even on a fat partition!

This has been a really useful feature for me. I do not always remember the name of my old kernel files...

Most everyone agreed that lilo would remain in Debian, but possibly not as the default bootloader. Many praised Grub's options, and Josip Rodin explained how to make a grub boot disk:

Making a boot/install/rescue disk

# cd /boot/grub
# dd if=stage1 of=/dev/fd0 bs=512 count=1
# dd if=stage2 of=/dev/fd0 bs=512 seek=1

Reboot with that floppy and you get the grub prompt, which you can use to do everything.

Daniel Burrows added "it's possible to create a disk containing Grub and a linux kernel. You have to create a filesystem on the disk, copy the correct Grub files into /boot/grub on it, create a Grub bootsector, and copy the kernel over. I don't remember exactly how much space is left, but all of Grub is only about 70k on the floppy. Grub is fairly quick and quiet, but all that extra functionality saves a lot of trouble when something goes wrong."

Glenn McGrath wrote back on the Hurd questions:

The way modules will work is that they should only be called (or loaded) if needed, so its not a matter of disabling any modules, just only calling the modules you need, this is the key to shrinking the installer to 1 boot disk (with everything else being fetched as required). There may need to be hurd specific alternatives to some modules i guess.

How important is it for the Hurd to have a native installer?

Im sure the Hurd users would prefer to not have to depend on "foreign" kernels, but is it practical ?

The easiest path would be to install hurd packages from a linux based installer, i assume most utilities that the installer would use would need to be ported to the hurd, to do a native hurd installer. Some utilities the new installer will likely be based on are busybox, libdetect, libparted, slang.

Daniel Jacobowitz asked " Does this make sense? We run things in /target during the install! Think, for instance, PCMCIA, or postinsts. For instance, the PCMCIA drivers are often used -as an install method-. We install PCMCIA onto the target partition and start it during the install. That requires host kernel = target kernel. I'm not saying that couldn't change, but it would be a non-trivial redesign task."

Torsten Landschoff said

We should support Grub and make it the default but have lilo in there as fallback in case grub fails.

We will also need good testing before release then because I am not sure grub supports all the hardware that lilo supports yet (and lilo has by far more options - which will force me to continue using lilo :().

The question of whether or not you can install Hurd from Linux continued for some time. It seems you can format for Hurd, but an ext2fs extension patch for the kernel is needed for the ACL. Neal Walfield felt " The main problem is setting up translators under the hurd. At the moment, this cannot be done. Right now, we dump a tar onto the target and force the user to reboot to run ``native-install''. This program does the configuration: ie setting up the translators. "

Marcus Brinkmann on a native Hurd installer:

It is extremely important for our self confidence, but there are other reasons. Splitting the install like this complicates some things, as we have seen (configuring PCMCIA once for linux, to install, and once for the installed OS). There are features in the Hurd which are not easily supported under Linux (although there is a way to install Hurd translators from Linux, there is no official, maintained program to do that). The binaries are incompatible (at least for some time).

Also, it would create a dependency of the Hurd on current Linux developments. It has happened that Linux ext2 file systems could not be read by the Hurd because of new, unsupported features, for example. Although in this case there is an easy work around (and we have catched up anyway), this can happen again in unexpected ways. This is especially bad because we don't have enough manpower to follow all developments in all areas (a common problem for us is that people break compatibility faster than we can verify that it still works or not). Not relying on a different kernel makes the individual OS developments more independant.

Considering that the differences between Linux and Hurd are quite big, and we can profit from our own software in the installer and at the same time removing the dependency on Linux, I think it is the cleaner approach to keep it seperated.

But note that I am talking about the long term solution. If it turns out that the obstacles in creating the Linux bootstrapped install are low, we may settle for that initially.

8. Stripping An *.orig.tar.gz?

14 Sep 2000 (6 posts) Archive Link: "Stripping cygnus insight"

Summary By Jens Müller

People: Eray OzkuralTorsten LandschoffChristopher C. Chimelis

Eray Ozkural told us he had "almost stripped insight-5.0 from accompanying libs and in a relatively clean way" and that "the package may be available anytime soon" .

He said he wanted to strip it because otherwise the package would be undesirably huge. But he had some doubts, "I want to strip the .orig.tar.gz, too. That is I want to make it smaller because I don't want unused sources to be uploaded. Is that okay? Stripping goes lik this: rm -rf tcl tk itcl itk ..." and went on, "This would OTOH make it impossible to build the orig.tar.gz without my patches. So this corrupts the semantics of 'orig.tar.gz'. What should I do?" (He also asked for a policy on trying to avoid statically linked binary packages.)

Torsten Landschoff thought it would be ok to strip the .orig.tar.gz file. He asked "how much space the crap sucks?" He advised Eray to "Submit the patch upstream and ask if they can include it so one can build the package with itcl, tcl, tk etc. already installed." Eray explained:

It's not crap :) The thing is cygnus hacked them to conform to their many ports including cygwin. But it's their mistake to include it in a source dir of course. They must have made them into separate distributions. (I'm talking about insight BTW)

Takes over 20M uncompressed... I'll strip more than 1/4th of code, so it's a nice thing to do.

He agreed with Torsten on submitting the patch upstream, "Looks right to me, then they can perhaps provide a stripped version also. It looks as if you could build it stand-alone, but then they forgot about that and hardwired ../itcl in some places"

Torsten again asked if "perhaps someone can arrange that those changes migrate upstream and insight get's lose of this cruft?" He regretted that "we all have too little time :(" He couldn't believe that the 15 MB left in the source archive should all be source code; and went on to say that Cygnus should have known better than hardwiring ../itcl in some places (and (with a ";-))") that they perhaps should forward their macros to the autoconf creators).

Christopher C. Chimelis explained that "It includes the gdb 5.0 source, so that's where almost all of it goes :-)" . He further explained that insight was "really a RedHat project (which has been put into the charge of Cygnus now), thus explaining the tangled issue of hacked libs. From my readings on the mailing list, upstream plans on removing the dependence on those hacked libs very soon anyway."

Eray, of course, understood Christopher's joke immediately, "Yea, err in fact gdb5.0 _is_ insight, but we typically don't want a duplicate the whole binutils package for instance, and tcl/tk/itcl/itk/tix intl from gettext, etc..."

He went on in response to the idea of removing the dependencies on the hacked libraries:

That's good news, but debian version probably hitting sooner than theirs ;) After a major release (like 5.0) I'm sure that they've relaxed. It's a job done right BTW, I've used the gdb on cygwin and it's excellent. same debugger , graphical both on linux and windows. I don't know what we'd do without cygnus anyway

So they fork, we return to parent. :)

There were no replies.

9. Improperly Signed Uploads Accepted Into The Repository?

16 Sep 2000 - 17 Sep 2000 (4 posts) Archive Link: "why are improperly signed uploads accepted?"

Summary By Zack Brown

People: Robert BihlmeyerBen CollinsMichael Alan Dorman

Robert Bihlmeyer gave a link into the archives and said that the message "was signed by a GPG key with ID 6D85A41E, which is not in the debian keyring. Michael Alan Dorman, the maintainer, has a different key in the ring. (I could not find the key on the keyservers, either.)" He asked, "I was under the impression that uploads require a changes message signed by a key in debian-keyring for them to be accepted. Is this not the case, or was there an oversight somewhere?" Ben Collins replied, "Don't go by the debian-keyring package. It's not as up-to-date as the one that dinstall uses." And Michael Alan Dorman (the guy with the busted key) also said at one point:

The key currently on the keyring was created with a broken copy of gnupg.

When dinstall started dropping all my packages several weeks ago, I ended up talking with James, and put a new key in---he presumably just hasn't spun a new copy of the keyring package.

I did let him know I was no longer using the old key (as he requested), so I'm assuming the next keyring will just have my new key.

Now as to why has my old key---I'm not sure I can change that. I'll look, though.

10. Not Easy To Trust The Debian Folks...

18 Sep 2000 (1 post) Archive Link: "gpg trust"

Summary By Jens Müller

People: Bas Zoetekouw

Bas Zoetekouw asked, "Is there an easy way to set the trust value of all keys on the debian keyring? Of course, I could set the trust value for all individual keys, but that's not really nice."

Unfortunately, there was no reply. It would have been nice to find a solution for this problem, maybe using a script or something.

11. Authors Needed...

20 Sep 2000 (1 post) Archive Link: "More authors needed for Debian Kernel Cousin..."

Summary By Jens Müller

People: Seth Cohn

Seth Cohn told us that the new issue of the Kernel Cousin Debian was out and asked people to contribute, since it was an quite easy job. Unfortunately, there was no feedback.

(ed. [Jens Müller] The interest the debian-devel community shows for this work seems a bit little. I hope we find some more authors soon...)

12. How To Find A Maintainer?

20 Sep 2000 (3 posts) Archive Link: "No grouping or AND operator for `depends:' ?"

Summary By Jens Müller

People: Adrian BunkJules BeanPeter S Galbraith

Peter S Galbraith said he needed a Depends line that would accept any of several possibilities, like: "Depends: imagemagick|{file, libjpeg-progs}, perl5", but hadn't found such syntax in the manual. He asked if there was such syntax.

Adrian Bunk presented a workaround: "Depends: imagemagick | file, imagemagick | libjpeg-progs, perl5"

Jules Bean gave a similiar hint. His idea was:

imagemagick | (file & libjpeg-progs)


imagemagick | file, imagemagick | libjpeg-progs

There was no reply.

(ed. [Jens Müller] I think it would be quite a good idea to make lines like the one Peter asked for possible, since it is closer to how one has those dependencies in mind. It is better to let a computer do such conversion to conjunctive normal form, then to let it be done by a human. Errare humanum est.)

13. Verifying Installed Packages

21 Sep 2000 - 22 Sep 2000 (3 posts) Archive Link: "How to verify installed packages?"

Summary By Jens Müller

People: Svante SignellFranklin BelewEray Ozkural

Svante Signell wanted to know how to verify the integrity of an installed package. He said, "A counterpart to rpm -Va is wanted."

Franklin Belew proposed, "Maybe dpkg --audit, or debsums is what you want?"

Eray Ozkural responded, "Of course MD5 sums on a Debian system have been prepared such that many important files will have MD5's lacking, and naturally debsums will not be able to check them." He then described his own experience: "The thing is I'd accidentally wiped off some blocks (1mb) from my root partition on a multi-user Beowulf master system which I'm administrating. So, I was quite interested in finding out which files actually got their share from my incredible action. But life's frustrating, and I'm thinking of a bug report about the base system :) One day people will look and say "whoa this person has submitted tons of bug reports..." :) The worse part is that I track what's actually happening with each bugreport :) Isn't that what BTS is for? :)"

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.