date:20010108

Re: tar -I incompatibility

2001-01-08 Thread Paul Eggert

> From: Goswin Brederlow <[EMAIL PROTECTED]>
> Date: 07 Jan 2001 23:00:59 +0100

> % tar -cIvvf bla.tar.bz2 bla
> tar: bla: Cannot stat: No such file or directory

That is indeed a bug.  Thanks for reporting it.  I'll fix it as follows:

   @@ -439,5 +434,5 @@ or a device.  *This* `tar' defaults to `

#define OPTION_STRING \
   -  "-01234567ABC:F:GIK:L:MN:OPRST:UV:WX:Zb:cdf:g:hijklmoprstuvwxz"
   +  "-01234567ABC:F:GI:K:L:MN:OPRST:UV:WX:Zb:cdf:g:hijklmoprstuvwxz"

static void

That should change your scenario to behave something like this instead:

   % tar -cIvvf bla.tar.bz2 bla
   tar: vvf: Cannot open: No such file or directory
   tar: Error is not recoverable: exiting now

which is a bit better (though admittedly not ideal).


> As I said before tar -I in its old useage should give one of several
> errors, but doesn't. Can't remeber the bug number, but its in the BTS.

Sorry, I don't quite follow you here.

> On the other hand, just changing the meaning or deleting the option
> will result in severe breakage in 3rd party software.

What 3rd party software do you have in mind?

Re: apt maintainers dead?

2001-01-08 Thread Alexander Koch

On Mon, 8 January 2001 04:15:10 +0100, Goswin Brederlow wrote:
>  > method will result in the immediate termination of public rsync
>  > access to our servers.
> 
> I think that is something to be discussed. As I said before, I expect
> the rsync + some features to produce less load than ftp or http.

Goswin, please ask someone who is granting anon rsync access
and why they fear it. You can wreck the server so easily...

Alexander

update-excuses addition (almost)

2001-01-08 Thread Anthony Towns

Hello world,

Since people seem to want more information about why "valid candidates"
aren't going in (which is quite sensible, just hard to provide), I've
tried adding some code that'll report what packages became uninstallable
when a package was attempted to be added to testing.

At the moment, this info is at the end of the update script's output, which
you can find at:

http://ftp-master.debian.org/~ajt/update_output.txt

So, for the package ampheatmine, say, update_excuses reports:

 * amphetamine 0.8.8-3 (currently 0.8.7-3) (low)
  + Maintainer: Joey Hess <[EMAIL PROTECTED]>
  + amphetamine is 50 days out of date!
  + valid candidate (will be installed unless it's dependent upon
other buggy pkgs)

and update_output.txt lists:

amphetamine: alpha: amphetamine amphetamine-data

meaning installing the updated amphetamine source package (removing all
amphetamine-based binary packages from woody and replacing them with all
the amphetamine-based binary packages in sid) results in the amphetamine
and amphetamine-data packages becoming uninstallable.

Looking at the amphetamine and amphetamine-data packages in sid/alpha,
we see they depend on libsdl1.1, about which update_excuses says:

 * libsdl1.1 1.1.6-3 (new) (low)
  + Maintainer: Fredrik Hallenberg <[EMAIL PROTECTED]>
  + libsdl1.1 is 13 days out of date!
  + libsdl1.1 (alpha arm i386 m68k powerpc sparc) is buggy (1 > 0)
  + not considered

The bug is a 25 day old grave bug that libsdl seems partially broken on
sparc.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

 ``Thanks to all avid pokers out there''
   -- linux.conf.au, 17-20 January 2001


pgpiXxI6QB4Pb.pgp
Description: PGP signature

Re: Bug#81397: [authorization] fails silently for normal users, cannot start server

2001-01-08 Thread John Galt

On Sat, 6 Jan 2001, Steve Langasek wrote:

SL>On Sun, 7 Jan 2001, Eray Ozkural (exa) wrote:
SL>
SL>> Hamish Moffatt wrote:
SL>> > There IS a debconf question about it.. it's not like it just does it to 
you
SL>> > without asking. Maybe the debconf priority of the question is too low if
SL>> > too many people are missing it.
SL>
SL>> Do you think this is also what prevented display managers (xdm, gdm, wings
SL>> are the ones that I tries) to function correctly?
SL>
SL>Branden diagnosed this bug correctly.  A bug in the X server *cannot* cause
SL>xdm/gdm authentication to fail, unless perhaps Branden has started diverting
SL>files at random.  (I'll let you check this if you like.  Personally, I have
SL>greater confidence in his integrity as a developer.)  The display manager
SL>starts the X server, not the other way around, which means that the X server
SL>has no control over the display manager's behavior; and the authentication
SL>failure you reported came from the display manager and PAM, /not/ from the X
SL>server.
SL>
SL>Is it possible you missed a debconf question that controls authentication for
SL>display managers when you upgraded?  Yes, but it certainly wasn't in the X
SL>packages.

It's in one of the xserver packages...-common, I think.

SL>Steve Langasek
SL>postmodern programmer
SL>
SL>
SL>

-- 
Pardon me, but you have obviously mistaken me for someone who gives a
damn.
email [EMAIL PROTECTED]

Re: [way OT] private emails

2001-01-08 Thread John Galt

On Sun, 7 Jan 2001, Branden Robinson wrote:

BR>On Sat, Jan 06, 2001 at 06:26:24PM -0600, Bud Rogers wrote:
BR>> It is spectacularly bad form to quote private email in a public forum,
BR>> but it is not illegal.  And it is spectacularly naive to count on the
BR>> privacy of anything you tell another human being in any medium,
BR>> electronic or otherwise, unless that other human being is a doctor, a
BR>> lawyer or a priest and thus bound by the ethics of their profession.
BR>
BR>AIUI, communications with spouses are privileged as well.

Well, you and Erai ARE arguing like husband and wife

BR>Followups to debian-legal?  :)
BR>
BR>

-- 
Pardon me, but you have obviously mistaken me for someone who gives a
damn.
email [EMAIL PROTECTED]

jabber field on db.debian.org?

2001-01-08 Thread Gerfried Fuchs

Hi!

 I was just wondering - there is this icq-field on
, which I have to say I'm not really happy with.
It's not the kind of thing that seems the right thing[tm] for Debian. I
would rather like to have a jabber field instead of that

 jabber, you might ask?  From the jabber.org FAQ: "Jabber is an
XML-based, open-source system and protocol for real-time messaging and
presence notification."  You might say: "Hey, that's the same as icq, so
why bother?"  But I say: "Hey, it's open-source, and that's what Debian
is all about, right?"  So, instead of supporting (and even encouraging
the developers!) the usage of a closed-source (but reverse engineered?)
protocol we should state once again what Debian is all about, right?

 I see that there might be problems due to the translation: Current
icq-field can't simply be turned into a jabber-field which would produce
some problems. On the other hand, another field might take lots of space
on the disk.

 So I thought a little about it and came up with the following:

-) The current field could be used for either one, and on display it
could be decided that it is a icq-field if it contains only of numbers.

-) Or, during a short period (say, 2 months or so?) both fields could be
there, and icq should really be dropped.

-) Finally, icq field could simply be dropped.

 Last point isn't really the best way to go - though there are currently
only 115 people using the icq field, according to Jason Gunthorpe,
including me.  And I think I'm not the only one of those people (at
least I know also that Othmar Pasteka would encourage this change).

 Jason said he won't decide - I really understand that.  But maybe if
some of the other 113 people that are currently using the icq field (or
also others, that might use the jabber field) could comment on this it
would be greatly encouraged to express your feelings :-)

 So, comments are welcome, Cc: from messages to the list NOT!
Alfie

ITP: mboxgrep -- Grep through mailboxes

2001-01-08 Thread Tollef Fog Heen

Package: wnpp
Severity: normal

I intend to package mboxgrep, a utility which greps mailboxes.

Description: Grep through mailboxes
 mboxgrep is a small utility that scans either standard Unix 
 mailboxes, Gnus nnml or nnmh mailboxes, or MH mailboxes, and 
 displays messages matching a basic, extended, or 
 Perl-compatible regular expression.

It can be downloaded from
http://public.srce.hr/~dspiljar/mboxgrep.html

and is under GPL.

-- 

Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.

package manager project ?

2001-01-08 Thread Tony Schonfeld $f5git$

I ve read in this list some ideas about a new package manager project for 
Debian.
Do you know if the Ability to install more than one version of a package 
simultaneously
is an idea working in progress for future Debian release ?

Many thanks per advance

Tony

ITP: doc-debian-ja -- Debian FAQ and other documents (Japanese)

2001-01-08 Thread SEKIDO Koichi

Package: doc-debian-ja
Severity: wishlist

I will package doc-debian-ja.

The output of `dpkg -I':

 new debian package, version 2.0.
 size 161570 bytes: control archive= 854 bytes.
 668 bytes,22 lines  control  
 879 bytes,21 lines   *  postinst #!/bin/sh
 599 bytes,21 lines   *  prerm#!/bin/sh
 Package: doc-debian-ja
 Version: 2.2.2.2
 Section: doc
 Priority: optional
 Architecture: all
 Suggests: doc-debian
 Installed-Size: 422
 Maintainer: SEKIDO Koichi <[EMAIL PROTECTED]>
 Description: Debian FAQ and other documents (Japanese)
  This package provides the Japanese version of Debian FAQ and other
  documents.
  .
  You will find:
* Debian Linux Manifesto,
* Constitution for the Debian Project,
* Debian GNU/Linux Social Contract,
* Debian Free Software Guidelines.
  .
  Additionally provided are:
* Debian GNU/Linux Frequently Asked Questions (FAQ),
* Debian Bug Tracking System documentation, and
* Introduction to the Debian mailing lists.

The copyright for the FAQ:

  Copyright (C) 1996-2000 by Software in the Public Interest

  Permission is granted to make and distribute verbatim copies of
  this document provided the copyright notice and this permission notice
  are preserved on all copies.

  Permission is granted to copy and distribute modified versions of
  this document under the conditions for verbatim copying, provided that
  the entire resulting derived work is distributed under the terms of
  a permission notice identical to this one.

  Permission is granted to copy and distribute translations of this
  document into another language, under the above conditions for
  modified versions, except that this permission notice may be included
  in translations approved by the Free Software Foundation instead of
  in the original English.

The copyright and license statement for the BTS docs:

copyright 1999 Darren O. Benham, 1994-7 Ian Jackson,
1997 nCipher Corporation Ltd, 1995 Steven Brenner.
Available under the GPL.

The copyright and license statement for the Debian JP BTS docs:

Debian JP bug tracking system copyright 1998 UKAI Fumitoshi, Debian
JP Project
Debian bug tracking system copyright 1994-1997 Ian Jackson,
copyright 1997 nCipher Corporation Ltd, copyright 1995 Steven
Brenner. Available under the GPL.

Since I am currently not a official Debian developer, I will
ask Yasuhiro TAKE <[EMAIL PROTECTED]> to be my sponsor.

--
SEKIDO Koichi <[EMAIL PROTECTED]>

Re: What is wrong with kde2.1 and unstable ?

2001-01-08 Thread Ulf Jaenicke-Roessler

Hi,

Ivan E. Moore II wrote:

> no clue...I don't use apt to upgrade. :)  Your not alone tho, there is a 
> existing bug report on this (#81365)...so any help you can give me to track
> down what's going on would be appreciated.  On all the boxes I have access
> to I use dselect to manage my package list so I do know that dselect can 
> handle
> whatever is going on.

It noticed that if you manually dpkg --purge all packages that task-kde
Conflicts: with, apt-get will work fine.

 Ulf

Re: (open)ssh-2.3.0p1 when??

2001-01-08 Thread Svante Signell

Damian M Gryski writes:
 > On Sun, 07 Jan 2001, Svante Signell wrote:
 > > Is openssh ever going to be upgraded? Latest unstable version is
 > > 2.2.0p1-1.1 from September? while the latest OpenBSD release is now
 > > 2.3.0p1! Maybe the package also should change name from ssh to openssh.
 > 
 >openssh 2.3.0p1 was installed into unstable (sid) on Dec 30.  If you
 >think you're tracking unstable, then you probably forgot to change
 >the distribution from 'woody' to 'sid' in /etc/apt/sources.list for
 >your non-us machine.
I am trackng unstable and finally (today) the new version was present
at unstable/non-US. Thanks!
 > 
 >Otherwise, wait another week and it should be moved into woody.
 > 
 >HTH,
 > 
 >Damian
 > 
 > -- 
 > Damian Gryski ==> [EMAIL PROTECTED] | Linux, the choice of a GNU generation
 > 512 pt Hacker Test score = 37% | 500 pt Nerd Test score = 56%
 >geek / linux zealot / coder / juggler
 > 
 > 
 > -- 
 > To UNSUBSCRIBE, email to [EMAIL PROTECTED]
 > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

ATTENTION! Well-Paid Job in the Internet!

2001-01-08 Thread Please Read IT Carefully!

Title: ATTENTION! The Well-Paid Job in the Internet!
We wish You a pleasant and successful day!In Russian Make money without leaving Your computer!If You show some interest and patience and understand as IT works, You can earn up to $100,000 and more!!! During the following 120 days - it depends only on You. DOES IT SEEMS TO BE IMPOSSIBLE?? Read this document to be sure there is no catch or deceit. If You are completely lazy - we beg Your pardon for the assumption!!!, then this is not for You!!! You'd better do something like surfing either clicking on banners or not doing anything at all.!!! If the offer hasn't interested You, we bring our apologies and it is not necessary to get angry - "Spam" has its expenses, just as radio and TV, but do not forget, that the first billionaire of the USA, Dale Carnegie said:"I'll better earn 1% as a result of the efforts of 100 men, than 100% as a result of my own efforts."RISE ON THE WAY TO THE FINANCIAL INDEPENDENCE AND FREEDOM!!!Welcome to the 6X6! It is difficult to believe but nevertheless it is like that! People get richer and richer! Some of them can't recover from the shock which had come together with a heap of crust banknotes even some months later. While the others deliberate and doubt, people that believed in Business System 6X6 bathe now in money!... In view of prompt rates of development of the Internet and electronic commerce the number of users of the "World Wide Web" grows with the great speed. There are more than 15,000 new people who join the Internet daily... Copyright © 2000 6x6 MLM Corporation. All rights reserved.Ladies and Gentlemen!
PLEASE READ THOUGHTFULLY AND ATTENTIVELY, TRYING NOT TO DISTRACT YOUR ATTENTION WITH EXTERNAL NOISES AND IRRITANTS, AND YOU'LL UNDERSTAND WHAT WILL MAKE YOU RATHER RICH AND FREE PEOPLE!!! It is difficult to believe but nevertheless it is like that! People get richer and richer! Some of them can't recover from the shock which had come together with a heap of crust banknotes even some months later. While the others deliberate and doubt, people that believed in Business System 6X6 bathe now in money! In a literal sense! Have You ever seen how the heap of the $5 bills under which the adult person entirelly finds room looks like?! It is 100 thousand dollars!!! Can You imagine how the heap of $1,000,000 which is earned by each third participant of the superprogram 6X6 looks like?! And what is the feeling when You, not getting troubled with work, start to receive envelopes with six dollars already on the second week and further the profit is much more! And eventually some months later You don't know how to get rid of the money! You even get a bit scary of this avalanches of the money!!! ALL THAT IT WILL NECESSARY TO DO - TO SEND THE ADVERTISING LETTERS VIA E-MAIL AND FROM TIME TO TIME TO CHECK YOUR MAILBOX OR TO GO TO THE BANK! YOU SHOULDN'T EVEN STRAIN THE BRAIN - THE SUPER COMPUTER BUSINESS SYSTEM 6X6 WILL MAKE EVERYTHING ITSELF!!!SINCE THE MOMENT YOU ENTER THIS BUSINESS YOUR PROFIT SNOWBALLS AND BY THE END OF 4TH MONTH YOU'LL GET AS MINIMUM $100,000. BUT IF YOU DON'T STOP THE RESULTS WILL BE ASTRONOMICAL - $1,000,000 FOR 1 YEAR"What is the secret of such dizzy success?" - You ask. This is because there is a new formula in the business system which provides all participants with 100%-s' success due to the account of such special factors which the human brain is simply not capable of grasping. Therefore this excellent program works! And it works brilliantly! This is a prodigy-system in which success is madly infectious! Hurry up to achieve the success too!!! TRY YOURSELF!!! &nbps;Have You ever wondered why the majority of people achieve nothing in life but only complain? This is because they are ready on a little in their life. They have a ready definitions on everything, but these definitions are formulated not by them and taken from the others. To have Your own opinion is a luxury and rarity. Those who are not afraid to try and work more than doubts very quickly appears at the top of the World! Yes, it is difficult to believe that it is possible to get rich so quickly, difficult to overcome the doubts and find Yourself suddenly fantastically rich. But believe if You will do it, it becomes Your blessing and Your dizzy success! You will not argue that You are worthy of big success and big richness, will You? And so it is vitally necessary for You to do this step to find the financial independence which will bring You co-operation with superprogram 6X6! Your time has come! "Pair words about the system..." - an interview with Igor Tichtchenkov, the founder of the business system - In view of prompt rates of development of the Internet and electronic commerce the number of users of the "World Wide Web" grows with the great speed. There are more than 15,000 new people who join the Internet daily. With the growth of number of the Internet's users the number of different types of business programs also grows. Every da

Re: Linux Progress Patch for Debian available!

2001-01-08 Thread Florian Hinzmann


On 03-Jan-2001 Paul Hedderly wrote:
> On Mon, Jan 01, 2001 at 11:37:17AM -0800, [EMAIL PROTECTED] wrote:

>> Who recalls a cddb access program designed for blind people where
>> cddb.com DENIED a certification because the program couldn't display a
>> graphical logo where the blind people could see it.
> 
> Presumably no blind person is allowed to use any cddb.com certified
> program then. Hmm :O)

Thats one of the reasons there is http://freedb.org/ now.


  bye
Florian
  
-- 
  Florian Hinzmann  private: [EMAIL PROTECTED]  
 Debian: [EMAIL PROTECTED]
PGP-Key fingerprint: DD 61 74 34 04 FB 8A BD  43 54 83 38 0C 82 EF B1

Re: State of Debian Jr.

2001-01-08 Thread Francesca

Hi all,
I'm the italian teacher interested using linux at school.
I write articles for a national school magazine about linux at school
and my next one I thought it could be about debian jr.
I'm studying in the mailing list your complex work on-line to make
debian junior a successful distribution, problems, difficulties..
See u soon
Francesca Campora

Re: tar -I incompatibility

2001-01-08 Thread Hamish Moffatt

On Mon, Jan 08, 2001 at 08:32:33AM +1100, Sam Couter wrote:
> My point is that the -I option *doesn't* mean "uncompress this file using
> bzip2" for anything other than GNU tar. Now that it doesn't mean that for
> GNU tar either, people are complaining. I think they probably shouldn't have
> been using -I to start with, at least not as a matter of habit or in scripts
> that might live for any decent length of time or have an application on any
> non-GNU system.

If we're expected to avoid any advanced features, why do the authors bother
to implement them?

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: bugs + rant + constructive criticism (long)

2001-01-08 Thread Florian Hinzmann

On 03-Jan-2001 Philip Brown wrote:

>> "Reply-to" is meant to send a message back to the person who wrote the
>> first one, not to someone they wrote the message to.
> 
> reply-to is meant to direct where you should send "replies to".

Reply-To is meant to direct where you should send "replies to"
if you want to send a private mail to the originator of the mail.

> And in the case of the debian mailing lists, you should "reply to" the
> list.

If you want to send to the list you should "reply to" the list only.
If you want to send a mail the the originator of a mail you are 
allowed to do that. And you may need to honour the Reply-To-Header to 
reach him.

  greetings
 Florian

-- 
  Florian Hinzmann  private: [EMAIL PROTECTED]  
 Debian: [EMAIL PROTECTED]
PGP-Key fingerprint: DD 61 74 34 04 FB 8A BD  43 54 83 38 0C 82 EF B1

Re: Compiling 2.0.38 kernel

2001-01-08 Thread Andrea Glorioso

> "Chris" == Chris L Mason <[EMAIL PROTECTED]> writes:

Chris> Hi Stefan,

Chris> Unfortunately, no, I'm still having trouble.  :( I might
Chris> wind up installing a fresh potato system on another
Chris> partition to see if it works in potato or not.  If not, I
Chris> guess I should file a bug report.

Just did it on a Potato box a week ago, no problems whatsoever.  Thought
you might wish to know.

Bye,

Andrea Glorioso





pgp98cJiKEdcS.pgp
Description: PGP signature

Re: our broken man package

2001-01-08 Thread Fabrizio Polacco

On Thu, Jan 04, 2001 at 09:04:50AM +, Lars Wirzenius wrote:
> Ethan Benson <[EMAIL PROTECTED]>:
> > OpenBSD took another tack on this problem and just did away with
> > cached man pages altogether.  (no suid or sgid man) 
> 
> They always re-format a manual page? This might be reasonable, actually.

and some of them filter all the pages through tbl even if only 1/6 of
them needs it.

> Groff is pretty fast, and most manual pages are short, so it shouldn't
> take too long even on older hardware.

but some are soo big. Bash and perl* are good examples.

> And, anyway, caching might be done in a cronjob: look at the pages in
> manpath every night, check which ones have been accessed since the past
> run, and format those. Then delete anything older than N days in the
> cache. When displaying, use the cached version only if it is newer than
> the source.

Lars, this is exactly the way it works today.
Apart from your strange idea to cache what has been accessed during the
day. As caching is done at access time, they are already cached! The
actual cron.daily removes them after 6 days. And the cached version is
used not only if it's newer then the source, but also if the you
specifyed the same preprocessor options.
This info is stored in the db. While makewhatis only collects
name+description, mandb also stores timestamp, formatting options and
type of file.

I'm planning to add caching not only for ascii formatted pages, but also
for html output (which is now available directly from groff). In this
case preformatting all pages would be interesting.

> On the other hand, we might want to copy the OpenBSD version instead
> of maintaining our own man. But I leave that to whoever maintains the
> packages.

I would prefere the man in plan9. It's the cleaner and simpler I've ever
seen.

fab
-- 
| [EMAIL PROTECTED][EMAIL PROTECTED]
| pgp: 6F7267F5   57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E
| [EMAIL PROTECTED] gsm: +358 (0)40 707 2468

Re: jabber field on db.debian.org?

2001-01-08 Thread Christian Surchi

On Mon, Jan 08, 2001 at 08:44:38AM +0100, Gerfried Fuchs wrote:
>  I was just wondering - there is this icq-field on
> , which I have to say I'm not really happy with.
> It's not the kind of thing that seems the right thing[tm] for Debian. I
> would rather like to have a jabber field instead of that

I second you idea. Jabber is an interesting free project and we could
help to spread it. 

Christian

-- 
Christian Surchi   |   [EMAIL PROTECTED]   |   [EMAIL PROTECTED]
FLUG: http://www.firenze.linux.it | Debian GNU/Linux: http://www.debian.org 
-> http://www.firenze.linux.it/~csurchi <--
The only "intuitive" interface is the nipple.  After that, it's all learned.

RFC Implementation of SGML/XML Proposal for LSB in Debian

2001-01-08 Thread Ardo van Rangelrooij


Below is an RFC for the implementation of the SGML/XML Proposal for the LSB
(version 0.3) in Debian.  I've send this to several mailing list to give it
broad attention, but please keep all the further discussion on debian-sgml.
All affected package maintainers please subscribe to debian-sgml.

The complete proposal can be found at

  http://dulug.duke.edu/~mark/debian/sgml/bischoff/

and there's some more related info at

  http://dulug.duke.edu/~mark/debian/sgml/

Please refer to the proposal for various terms used below.


0. Introduction

Currently, the SGML/XML related stuff is located under /usr/lib/sgml including
the super catalog (which is symlinked to /etc/sgml.catalog).

In the proposal this is split between /usr/share/sgml and /etc/sgml:

/etc/sgml/
Configuration files, including centralized catalogs.

It includes:
*.conf: generic configuration files
sgml-docbook.cat, tei.cat, ...: DTD-specific centralized catalogs
catalog: the super catalog

/usr/share/sgml/
Architecture-independent files used by SGML applications: Open
Catalogs (not the centralized ones), DTDs, entities, stylesheets,
and other declarative files, if any.

It is organized into DTD-specific subdirectories:
docbook/
tei/
html/
debiandoc/
...


1. Transition

The transition will consists of several steps:

 1. setting up the new structure while retaining the old one
 2. adapting all affected packages to use the new structure
 3. removing the old structure

In the first step each package with files under /usr/lib/sgml has to put the
these files under both /usr/share/sgml and /usr/lib/sgml.  This can be done
either by simply putting a copy under /usr/lib/sgml or by symlinking from
/usr/lib/sgml to /usr/share/sgml.  Since we're talking about only a few MBs
in size in total, the first solution is probably the easiest to achieve.

In the second step we have to adapt each SGML application to look under the
new structure for the SGML files.  This is the most challenging part.

The third step is simply removing from each affected package the files under
/usr/lib/sgml.


2. Support

The sgml-base package will provide support to maintain the centralized
catalogs and the super catalog by adapting `install-catalog`.  During the
transition both the old and the new structure (w.r.t. the catalogs) will be
supported.

There will be no support for maintaining the structures themselves.


3. Conclusion

The first thing to do is to have the sgml-base support in place.  I'll also
setup a web page with the type and status of all affected packages.  With type
is meant SGML application and/or DTD, stylesheet, etc.

After that we can start working on the transition itself.

-- 
Ardo van Rangelrooij
home email: [EMAIL PROTECTED]
home page:  http://www.debian.org/~ardo
PGP fp: 3B 1F 21 72 00 5C 3A 73  7F 72 DF D9 90 78 47 F9

Re: package pool and big Packages.gz file

2001-01-08 Thread Goswin Brederlow

> " " == Jason Gunthorpe <[EMAIL PROTECTED]> writes:

 > On 8 Jan 2001, Goswin Brederlow wrote:

>> I don't need to get a filelisting, apt-get tells me the
>> name. :)

 > You have missed the point, the presence of the ability to do
 > file listings prevents the adoption of rsync servers with high
 > connection limits.

Then that feature should be limited to non-recursive listings or
turned off. Or .listing files should be created that are just served.

>> > Reversed checksums (with a detached checksum file) is
>> something > someone should implement for debian-cd. You calud
>> even quite > reasonably do that totally using HTTP and not run
>> the risk of > rsync load at all.
>> 
>> At the moment the client calculates one roling checksum and
>> md5sum per block.

 > I know how rsync works, and it uses MD4.

Ups, then s/5/4/g.

>> Given a 650MB file, I don't want to know the hit/miss ratios
>> for the roling checksum and the md5sum. Must be realy bad.

 > The ratio is supposed to only scale with block size, so it
 > should be the same for big files and small files (ignoring the
 > increase in block size with file size).  The amount of time
 > expended doing this calculation is not trivial however.

Hmm, in the technical paper it says that it creates a 16 bit external
hash, each entry a linked list of items containing the full 32 Bit
rolling checksum (or the other 16 bit) and the md4sum.

So when you have more blocks, the hash will fill up. So you have more
hits on the first level and need to search a linked list. With a block
size of 1K a CD image has 10 items per hash entry, its 1000% full. The
time wasted alone to check the rolling checksum must be huge.

And with 65 rolling checksums for the image, theres a ~10/65536
chance chance of hitting the same checksum with differen md4sum, so
thats about 100 times per CD, just by pure chance.

If the images match, then its 65 times.

So the better the match, the more blocks you have, the more cpu it
takes. Of cause larger blocks take more time to compute a md4sum, but
you will have less blocks then.

 > For CD images the concern is of course available disk
 > bandwidth, reversed checksums eliminate that bottleneck.

That anyway. And ram.

MfG
Goswin

Re: Solving the compression dilema when rsync-ing Debian versions

2001-01-08 Thread Goswin Brederlow

> " " == Jason Gunthorpe <[EMAIL PROTECTED]> writes:

 > On 7 Jan 2001, Bdale Garbee wrote:

>> > gzip --rsyncable, aloready implemented, ask Rusty Russell.
>> 
>> I have a copy of Rusty's patch, but have not applied it since I
>> don't like diverging Debian packages from upstream this way.
>> Wichert, have you or Rusty or anyone taken this up with the
>> gzip upstream maintainer?

 > Has anyone checked out what the size hit is, and how well
 > ryncing debs like this performs in actual use? A study using
 > xdelta on rsyncable debs would be quite nice to see. I recall
 > that the results of xdelta on the uncompressed data were not
 > that great.

That might be a problem of xdelta, I heard its pretty inefective.

MfG
Goswin

Re: ITP: mboxgrep -- Grep through mailboxes

2001-01-08 Thread Stephane Bortzmeyer

On Monday 8 January 2001, at 9 h 5, the keyboard of Tollef Fog Heen 
<[EMAIL PROTECTED]> wrote:
 
> I intend to package mboxgrep, a utility which greps mailboxes.

BTW, we already have sgrep, which is fine for that purpose.

Re: Solving the compression dilema when rsync-ing Debian versions

2001-01-08 Thread Peter Eckersley

On Mon, Jan 08, 2001 at 08:27:53AM +1100, Sam Couter wrote:
> Otto Wyss <[EMAIL PROTECTED]> wrote:
> > 
> > So why not solve the compression problem at the root? Why not try to
> > change the compression in a way so it does produce a compressed result
> > with the same (or similar) difference rate as the source? 
> 
> Are you going to hack at *every* different kind of file format that you
> might ever want to rsync, to make it rsync friendly?
> 
> Surely it makes more sense to make rsync able to more efficiently deal with
> different formats easily.

I think you reach the right conclusion, but for the wrong reason.

Either you fix rsync for each of n file formats, or you fix n file formats
for rsync :)

The advantage of doing it in rsync-land is that you can do a better job; you
apply the inverse of the compression format at both ends, calculate the
differences, and re-apply compression (probably gzip rather than the original
algorithm, but it depends) to these.  Trying to hack compression algorithms to
fit rsync is in general a bad idea.  Rusty could probably get away with it for
gzip, because it is very simple - decompression of gzip is interpreting codes
like "repeat the 17 characters you saw 38 characters ago".

Other, more sophisticated algorithms, like bzip2 (go and read about the
Burrows-Wheeler Transform, it's amazing ;) would be much harder to hack in any
reasonable way.

--

|> |= -+- |= |>
|  |-  |  |- |\

Peter Eckersley
([EMAIL PROTECTED])
http://www.cs.mu.oz.au/~pde

for techno-leftie inspiration, take a look at
http://www.computerbank.org.au/

pgp8KT0vs0T0R.pgp
Description: PGP signature

Re: ITP: mboxgrep -- Grep through mailboxes

2001-01-08 Thread Guido Guenther

On Mon, Jan 08, 2001 at 01:27:24PM +0100, Stephane Bortzmeyer wrote:
> On Monday 8 January 2001, at 9 h 5, the keyboard of Tollef Fog Heen 
> <[EMAIL PROTECTED]> wrote:
>  
> > I intend to package mboxgrep, a utility which greps mailboxes.
> 
> BTW, we already have sgrep, which is fine for that purpose.
and grepmail...

Package: grepmail
Description: search mailboxes for mail matching an expression
 Grepmail looks for mail messages containing a pattern, and prints the
 resulting messages. It can handle compressed mailbox files, and can search
 the header or body of emails. Usage is very similar to grep.

 -- Guido

Re: ITP: mboxgrep -- Grep through mailboxes

2001-01-08 Thread Andreas Metzler

On Mon, Jan 08, 2001 at 02:32:02PM +0100, Guido Guenther wrote:
> On Mon, Jan 08, 2001 at 01:27:24PM +0100, Stephane Bortzmeyer wrote:
> > On Monday 8 January 2001, at 9 h 5, the keyboard of Tollef Fog Heen 
> > <[EMAIL PROTECTED]> wrote:
> >  
> > > I intend to package mboxgrep, a utility which greps mailboxes.
> > 
> > BTW, we already have sgrep, which is fine for that purpose.
> and grepmail...
> 
> Package: grepmail
> Description: search mailboxes for mail matching an expression
>  Grepmail looks for mail messages containing a pattern, and prints the
>  resulting messages. It can handle compressed mailbox files, and can search
>  the header or body of emails. Usage is very similar to grep.

Hello!
... which afaik only understands (zipped) mbox-format. Of course you
can use something like
"find ~/mail -type f | xargs grepmail pattern",
for Maildir (or mh).
  cu andreas

Re: Bug#81396: root shell fscked after upgrade to woody

2001-01-08 Thread Vince Mulhollon

The reason for installing ssh in this case was for troubleshooting,
although higher security would be a positive side effect.

He reports trouble from an unknown source, and telnetd is "involved".
Installing ssh would allow comparisons of the failure modes with different
network login clients.

If it failed with telnetd and worked with ssh, well then that would isolate
the problem to something related to telnetd.

If it failed with telnetd and failed with ssh, then the problem is probably
not the the telnetd package (although there are possibilites)

rsh could be used in a similar troubleshooting manner, although a side
effect of installing rsh would probably be lower security rather than
higher...

Some people ask why and/or complain Debian has more than 1 package that can
provide "Q" where Q is webserving or DHCPing, or BIND versions, or
whatever.  I think the ability to troubleshoot problems by trying alternate
programs is an excellent reason to have "multiple packages doing the same
thing".

Craig Sanders   

<[EMAIL PROTECTED]To: "Eray Ozkural (exa)" 
<[EMAIL PROTECTED]>,
au>  [EMAIL PROTECTED]  

 cc: (bcc: Vince 
Mulhollon/Brookfield/Norlight) 
01/06/2001   Fax to:

11:36 PM Subject: Bug#81396: root shell 
fscked after upgrade to woody   
Please  

respond to  

Craig   

Sanders;

Please  

respond to  

81396   

On Sun, Jan 07, 2001 at 04:38:10AM +0200, Eray Ozkural (exa) wrote:

> We use telnet here because this is a diverse university network; we
> can't force people to run ssh and any moron could go root on this
> machine if he really wanted to.

why not?

the most you'd have to do is put up a single web page with links to
local copies of ssh clients for various platforms...and optionally
replace telnetd with a script (or tcp-wrapper's "twist" capability)
which printed a message displaying the URL and advising the user to
install an ssh client. telnet problem solved with a minimum of user
support calls.

there's really no excuse for running (non-ssl) telnetd any more. good
free ssh clients are available for just about every operating system.

craig

--
craig sanders

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact
[EMAIL PROTECTED]

Re: Compiling 2.0.38 kernel

2001-01-08 Thread Chris L. Mason

On Mon, Jan 08, 2001 at 10:55:12AM +0100, Andrea Glorioso wrote:
> 
> Just did it on a Potato box a week ago, no problems whatsoever.  Thought
> you might wish to know.
> 

Okay, the problem seems to be with how mkdep is being compiled.  I managed
to get the kernel to compile by copying the mkdep.c file from 2.2.18 into
the 2.0.38/scripts directory.  Not nice, but it did the job.

Anyway, this might help others who need to compile old kernels, and
hopefully the problem will be fixed by gcc 2.95.3 final.

Chris

Re: Solving the compression dilema when rsync-ing Debian versions

2001-01-08 Thread Peter Eckersley

On Mon, Jan 08, 2001 at 11:58:26PM +1100, Peter Eckersley wrote:
> On Mon, Jan 08, 2001 at 08:27:53AM +1100, Sam Couter wrote:
> > Otto Wyss <[EMAIL PROTECTED]> wrote:
> > > 
> > > So why not solve the compression problem at the root? Why not try to
> > > change the compression in a way so it does produce a compressed result
> > > with the same (or similar) difference rate as the source? 
> > 
> > Are you going to hack at *every* different kind of file format that you
> > might ever want to rsync, to make it rsync friendly?
> > 
> > Surely it makes more sense to make rsync able to more efficiently deal with
> > different formats easily.
> 
> I think you reach the right conclusion, but for the wrong reason.
> 
> Either you fix rsync for each of n file formats, or you fix n file formats
> for rsync :)
> 
> The advantage of doing it in rsync-land is that you can do a better job; you
> apply the inverse of the compression format at both ends, calculate the
> differences, and re-apply compression (probably gzip rather than the original



That wasn't very clear of me, was it?  Gzip compression is fine for
transferring data on the wire.  At the other end, you still need to reuse the
original algorithm.  Re-applying compression is, of course, a potential
problem (as someone pointed out in another thread, even gzip is not in general
re-applicable).

So more correctly, an rsync module is better where it's possible...

> algorithm, but it depends) to these.  Trying to hack compression algorithms to
> fit rsync is in general a bad idea.  Rusty could probably get away with it for
> gzip, because it is very simple - decompression of gzip is interpreting codes
> like "repeat the 17 characters you saw 38 characters ago".

--
Peter Eckersley http://www.cs.mu.oz.au/~pde 
([EMAIL PROTECTED])  TLI:  http://www.computerbank.org.au
<~sig temporarily conservative pending divine intervention~>
GPG fingerprint: 30BF 6A78 2013 DCFA 5985  E255 9D31 4A9A 7574 65BC


pgp4KnkuuM3vN.pgp
Description: PGP signature

Developer Behavior

2001-01-08 Thread Vince Mulhollon

Some Eray quotes, one paragraph of advice for Eray, and a possibly useful
idea at the end for everyone.

"Non-regulation is a false claim"

"His actions are simply not tolerable"

"I'd be greatly surprised if anybody told me that developers have the right
to swear publicly in an outburst of adolescent frenzy."

"waiting for DAM approval, whenever that is supposed to happen"  (emphasis
on the "supposed to happen")


Your problem (our advantage?) is your lack of power to enforce your
demands.  Yes, someone publicly used naughty words against you, you think
their actions are not tolerable, you think our communication styles are
regulated (or should be), you think we don't have the right of free speech.
That's all very nice of you to let us know what you think, thank you (?).
But you have no power over us.  You can't fire the Xwindows maintainer,
because you don't send him a paycheck.  You can't censor the mailling list
because you aren't the moderator (there isn't one).  You attempt to
objectively state what happened, then in the same thought, shift to extreme
purely personal subjective opinions and wishes.   You've decided in a
fascist manner for us, what actions are intolerable, what speech is
acceptable, what policies are false, and how you're "above the law" and
able to quote private emails freely although everyone else isn't "above the
law".  You can't boss people around and tell them how to think if they are
volunteers in a freedom oriented group.  I would advise you not to push for
some kind of formal code of conduct, because with your luck, the new code
would be modified into something like "Debian will tar and feather anyone
who annoys more than x% of the developers", and it would seem in a few
short days you've managed to offend everyone from the Account Manager team
to the X maintainer.  Luckily for you, there are plenty of other people,
already in Debian, with poor social skills, so at least you can reasonably
request to be "grandfathered" in...  My own experience in these manners is
I've posted some stupid emails, sometimes because I've got the unique
ability to "invent" a good idea long after someone else implemented it, or
else I've just been plain ole stupid and in a hurry.  Regarding that, I
would say that true intelligence is learning from mistakes, which I'm
trying to do, and I suggest you do the same.


One possibly useful idea that could come out of this flamewar is an
"informal" code of conduct.  The model I'm thinking of is the ARRL amateur
radio operator's code.  It has about five sections, basically giving advice
on how not to be annoying as a ham radio operator.  It's informal in that
if you ignore it, they can't kick you out of anything, yet if you're a jerk
and publically ignore it, noone will have anything to do with you.

Something like this might (I stress might) be useful for Debian.  You could
even test people on their knowledge of the code in the new applicant
process.

Here's my start as an example of what I'm thinking of.

"Debian Developer Code of Conduct" by Vince

The goal of the Debian Code of Conduct is to improve the social skills of
Developers through a process of suggestion so that more effort can be
placed on working on code and less effort can be placed on flamewars.  In
short, the code will try to tell you how to be a help, not an annoyance.
The code is not a demand, but a really strong suggestion of what actions
helps the project and what actions hurt the project.

1) A Debian Developer is a freedom oriented volunteer, yet will try to act
and communicate in the most formal and professional manner they can, as if
they represented a conservative bank, not as if they represented a bunch of
drunks fighting at the bar.

2) A Debian Developer will RTFM, isolate the problem as much as possible,
and include as much evidence as possible, before filing a bug

3) A Debian Developer will acknowledge the diversity of skill levels of his
fellow developers and will try to help other developers learn, rather than
flaming them for their ignorance.

4) A Debian Developer will understand that computer languages have priority
over traditional languages, flaming someone for poor english (or German or
whatever) is in even more annoying and non-productive than flaming someone
over poor code.

5) A Debian Developer will never knowingly run a production server on
"unstable" and will never encourage a non-developer to run "unstable".

6) 

I have this feeling in about 1 hour someone's going to post a followup that
this idea was implemented way back in '92 and why don't I RTFM, but what
the heck, my excuse can always be that "great minds think alike", etc.

- Forwarded by Vince Mulhollon/Brookfield/Norlight on 01/08/2001 09:29
AM -

  
Eray Ozkural

Re: ITP: mboxgrep -- Grep through mailboxes

2001-01-08 Thread Aaron Lehmann

> Package: grepmail
> Description: search mailboxes for mail matching an expression
>  Grepmail looks for mail messages containing a pattern, and prints the
>  resulting messages. It can handle compressed mailbox files, and can search
>  the header or body of emails. Usage is very similar to grep.

Grepmail is very slow, and I wouldn't mind an alternative. I blame the
slowness on perl.

$ time grepmail test /dev/null
grepmail test /dev/null  0.38s user 0.04s system 100% cpu 0.418 total

Add that to the fact that perl has a 400ms overhead just to load when
not cached in RAM on my system. Perl had just been run at the time of
this test to gather this figure, but usually on the machine in
question it is not cached.

What this means is grepmail takes almost a second to start up. I won't
even go into its grepping speed.


pgpEVsDjZhbgD.pgp
Description: PGP signature

Re: Compiling 2.0.38 kernel

2001-01-08 Thread Petr Cech

On Mon, Jan 08, 2001 at 11:08:22AM -0500 , Chris L. Mason wrote:
> Anyway, this might help others who need to compile old kernels, and
> hopefully the problem will be fixed by gcc 2.95.3 final.

2.0.38 will probably not compile with gcc > 2.7.2.3 very well. You might
want to try gcc272
Petr Cech
-- 
Debian GNU/Linux maintainer - www.debian.{org,cz}
   [EMAIL PROTECTED]

 "Debian - 3 million penguins can't be wrong."

1 2 >

1 - 100 of 111 matches

Mail list logo