Re: autoup.sh v0.24 released (was Re: autoup.sh bug)

[Jason Gunthorpe]

On Tue, 21 Apr 1998, Craig Sanders wrote:

> > dpkg: regarding .../base/dpkg_1.4.0.22.deb containing dpkg, pre-dependency 
> > problem:
> >  dpkg pre-depends on libstdc++2.8
> >   libstdc++2.8 is not installed.

You know, we should really include libstdc++2.8 on the base disks if this
is now true. Is it safe yet to remove libg++? APT uses libdstc++2.8 btw.

Thanks,
Jason


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

Re: autoup.sh v0.25 released

[Craig Sanders]

BTW, i've also made some changes to my http://debian.vicnet.net.au/autoup 
site.

1.  updated autoup.tar.gz to have the latest versions of all the needed
packages.

2.  made it accessible as ftp://debian.vicnet.net.au/autoup (some people
requested this)

3.  made a debfiles/ directory which contains all the individual packages
in autoup.tar.gz for people who want to download them one at a time.


if anyone mirrors this then they should probably just exclude the
large binaries from their mirror and run the make-tarfiles.sh script
locallysaves mirroring 14mb of stuff which they should already have
in their local mirror.


craig

--
craig sanders


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

Re: autoup.sh v0.25 released

[Craig Sanders]

> I've just released version 0.24 which fixes this (and a few minor problems
> too).
> 
> v0.24: 1998-04-21 (Craig Sanders)
>  - added libstdc++, libslang0.99.34 (libc5), libslang0.99.38 (libc6),
>netbase, and netstd to the list of packages to install.
>  - changed 'unstable' to 'frozen' in various places.
>  - [EMAIL PROTECTED] reported that the downloading the files to
>/var/lib/dpkg/methods/ftp messes up the ftp method somehow.  changed
>TRY to /tmp/autoup.


make that 0.25. i forgot to disable the debugging stuff before releasing
it.


v0.25: 1998-04-21 (Craig Sanders)
 - remembered to disable debugging stuff so that the script actually 
does something.


craig

--
craig sanders


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

Re: Intent to package: debian-keyring

[Dale Scheetz]

On 20 Apr 1998, Manoj Srivastava wrote:

> Hi,
> >>"Dale" == Dale Scheetz <[EMAIL PROTECTED]> writes:
> 
> 
> Dale> The desire is to create a distribution that installs in the
> Dale> smallest disk space possible. I saw that requirement as being a
> Dale> smaller one than the functionality requirement, and thus
> Dale> "violated" the letter of the policy, while being certain that I
> Dale> was supporting the best product I could build.
> 
>   Why did you not try to change the ``letter'' of the policy, so
>  that it would make things easier for people who may have a
>  similar situation in the future? You saw a flaw in the policy, you
>  choose rather than to mend this, to ignore policy and worked around
>  it, leaving policy broken, at least in some cases.

I saw no flaw. I interpreted my behavior as being within policy.

> 
> >> Why do you say that the policy is intractable? Policy did change
> >> wrt the ldconfig issue. It could have been faster, but the whole
> >> debate was clouded by statements and counter statements for the
> >> longest time.
> >> 
> Dale> Exactly. During that whole debate period we had maintainers who
> Dale> "flouted" policy by making their packages functional? I don't
> Dale> see it that way.
> 
>   No, policy can be broken, or unclear, or not yet
>  specified. While policy is being formulated, affected packages
>  may indeed do their own thing. What I do not like is statements like
>  "As far as breaking policy, Go right ahead." with no effort ebing
>  made to bring policy in conformace to correct behaviour.
> 
Again, your interpretation is somewhat different than mine. I was
supporting a request for an exemption to the single maintainer rule. As we
already have packages that are maintained in this fashion, I saw no
problem with another exemption.

> Dale> We are again seeing this from very differnt perspectives. I see
> Dale> the intractibility as coming from statements that insist that
> Dale> what is writen in the Policy Statement can not be deviated from
> Dale> in the smallest degree.
> 
>   If policy is right, that is a good thing. If policy is wrong,
>  it should be corrected.  And then followed to the letter ;-) You
>  can't just say, well, we all know policy is broken, so there is no
>  point in following it.
>
It is my continuing feeling that no limited policy statement can ever be
written to be "right" in every case that it is to be applied. What I am
looking for is either an attitude or an explicit statement in the Policy
Statement, that, under conditions of necessity, there exists the
possibility of exemptions to any "rule" in the Policy Statement. Without
this attitude we are going to continue to have these fruitless
discussions.
 
> Dale> My real point was that folks who make the rules often don't
> Dale> consider those who will be forced to live under them. I probably
> Dale> should make it clear that I have no evidence that this is the
> Dale> case here. I was making a generalization.
> 
>   I try help make the rules. I am governed by the same
>  rules. This is not a case of bloated washington fat cats who are
>  totally out of touch with their constituency. We do not have rule
>  maker drones versus toiling developer here. We are all in the same
>  boat. Singing the ``internationale'' is not quite justified ;-)
> 
This is one of those that I don't see anything to comment about...

>   Every bit of the policy applies to all my packages just as
>  much as it does to yours.

Equality of application is always good. 
> 
>   manoj
> -- 
>  Better than a thousand pointless words is one saying to the point on
>  hearing which one finds peace. 100

We seem to have exhausted the limit some time ago ;-)

Peace,

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (850) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


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

Re: /tmp exploits

[Nicolás Lichtmaier]

>   I think we should stay away from delibrate non-compliance,
>  even for laudable goals such as these. An experimental non-conformant
>  libc (which I can install on a test system) is not something I shall
>  object to.

 Why not doing this: Each program when started, whe libc is initialized
check for the existance of a file /etc/debug. If this file is present, a
debug flag is set and any check that we want to add is effective. Or maybe
with an environmen variable...


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

some intents to package

[Hamish Moffatt]

I have taken over xpdf and should have xpdf-i (with support for encrypted
PDF files) upload to non-US soon. Thanks to Dirk for his help.

I also want to package gEDA, which is some electronics design software,
GNU EDA. So far they have a schematic editor running. It uses on gtk+.



Hamish
-- 
Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
CCs of replies from mailing lists are welcome.   http://hamish.home.ml.org


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

interest in xfstt package

[Stephen Carpenter]

-BEGIN PGP SIGNED MESSAGE-

About 10 mins ago I posted a message to the debian-user list
in a discussion of this package xfstt.
The reason being that the package needs some work and I also
have noticed it on the list of "Packages needing a new maintainer"
That is why I am writting you now (and cc:ing debian-devel because
I would like to get some more opinions on this)
I fount xfstt a while back anbd love it...I think what it does
is great (even if it is limited by the moronic copyrights
on most fonts :( )
I am interested in volunteering some of my time and
giving back to the Linux (and more specifically now debian) 
community, and am wondering if possibly you might think
xfstt would make a good package to start with since
I have never workerd on a package before.
Yes I have read all of the documentation, the policy manual and
all of that on the web page...and looked over a few
times the packageing manual (need to play with it some more :) )
I am a little afraid of this...im unsure of my abilities
I have fooled around with C for about 4 or 5 years and done
some C++...playe dwith shell scripts and perl
I admit I am unsure of what this will involve and the amount
of work it requires...
but one of the main reasons I use linu xin the first place is I 
want to learn...so I supose thats not entirely bad
so im wondering what you (and others on debian-devel) think
does this package seem like a bit much for a first package?
if not...what do I do next (yes I read all of the info 
on how to get started but...that confused me just a bit...
course thats probbaly just me :) )
- -Steve


-BEGIN PGP SIGNATURE-
Version: 2.6.3a
Charset: noconv

iQCVAwUBNTwBgnxvn0zebBV9AQEQBAQAjIQ7J9+eAkjrst306IslakRy0r39L+qX
LqK+Ge1SnFBpa/U8yC0w5M57Qixlr5V05721GOcMh39AuS8tZwZzXpXD3J7WAsJo
6wbWdLMFE9B2CJjB4/FQ0NicnfWO5+PvXvhujWPJZS0ZLKX67XEuM3v02QjynDY0
nzPaAd8jAWk=
=n9FW
-END PGP SIGNATURE-


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

Re: interest in xfstt package

[Branden Robinson]

On Mon, Apr 20, 1998 at 10:16:29PM -0400, Stephen Carpenter wrote:

> About 10 mins ago I posted a message to the debian-user list in a
> discussion of this package xfstt.  The reason being that the package
> needs some work and I also have noticed it on the list of "Packages
> needing a new maintainer" That is why I am writting you now (and
> cc:ing debian-devel because I would like to get some more opinions
> on this) I fount xfstt a while back anbd love it...I think what it
> does is great (even if it is limited by the moronic copyrights on
> most fonts :( ) I am interested in volunteering some of my time and
> giving back to the Linux (and more specifically now debian) community,
> and am wondering if possibly you might think xfstt would make a good
> package to start with since I have never workerd on a package before.
> Yes I have read all of the documentation, the policy manual and all
> of that on the web page...and looked over a few times the packageing
> manual (need to play with it some more :) ) I am a little afraid of
> this...im unsure of my abilities I have fooled around with C for
> about 4 or 5 years and done some C++...playe dwith shell scripts and
> perl I admit I am unsure of what this will involve and the amount of
> work it requires... but one of the main reasons I use linu xin the
> first place is I want to learn...so I supose thats not entirely bad
> so im wondering what you (and others on debian-devel) think does this
> package seem like a bit much for a first package? if not...what do I
> do next (yes I read all of the info on how to get started but...that
> confused me just a bit... course thats probbaly just me :) )

Well, I'd like to invite you to join, or at least be in contact with, the X
Strike Force  and me in
particular.  I'd like to learn more about xfstt and what I can do to make
sure it integrates smoothly with X.

After hamm is released I'm going to be re-engineering XFree86 a bit.  An
xserver-common package will be created, and xbase will be further
segregated.  I know it's a terrible thing to break X into even more binary
packages, but I think things like xfs and xdm need to be split off,
especially as they are targets for replacement on some systems.

-- 
G. Branden Robinson |  Somebody once asked me if I thought sex
Purdue University   |  was dirty.  I said, "It is if you're
[EMAIL PROTECTED]  |  doing it right."
http://www.ecn.purdue.edu/~branden/ |  -- Woody Allen


pgpcd6Qfo13K7.pgp
Description: PGP signature

Re: bzip2 X

[Mark W. Eichin]

In fact, it has been mentioned (on tar-forum, I believe) that gzip
(the program) will eventually include the bzip2 algorithm...

But in the meantime, it makes sense for dpkg-source to deal (ideally,
by having a set of original files and an explicit map [*not* a general
purpose shell script] of how to unpack them to produce the "orig"
sources.  This map *could* be an extension of the .dsc file, right?)


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

Re: Intent to package: debian-keyring

[Manoj Srivastava]

Hi,

Well, to take a different tack, what is the point of a policy
 document at all when anyone can say "well, my package is an
 exception and need not comply to policy."?  If one may take that
 stance, I see no point in having a policy document in the first
 place. 

manoj
 Why have the rules in the first place? (As usual, my random sig
 generator has come up with something apropos; though I disagree with
 it) 
-- 
 Sometime, you've gotta break the rules.
Manoj Srivastava  <[EMAIL PROTECTED]> 
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


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

Re: interest in xfstt package

[Stephen Carpenter]

-BEGIN PGP SIGNED MESSAGE-

I have seen a few messages about your "X Strike Force"
I find it interesting. Right now I kno wvery little about X but...
as I said...one of the main reasons I am interested in doing any of 
this is that I want to learn
Not knowing much about X is one of the things that holds me back
with xfstt butI guess one has to start somewhere
(and xfstt seems pretty stable and good so that should give
me time to learn the source code and learn about X
since th e most urgent problem I see is the documemntation)
- -Steve


On Mon, 20 Apr 1998, Branden Robinson wrote:

> On Mon, Apr 20, 1998 at 10:16:29PM -0400, Stephen Carpenter wrote:
> 
> > About 10 mins ago I posted a message to the debian-user list in a
> > discussion of this package xfstt.  The reason being that the package
> > needs some work and I also have noticed it on the list of "Packages
> > needing a new maintainer" That is why I am writting you now (and
> > cc:ing debian-devel because I would like to get some more opinions
> > on this) I fount xfstt a while back anbd love it...I think what it
> > does is great (even if it is limited by the moronic copyrights on
> > most fonts :( ) I am interested in volunteering some of my time and
> > giving back to the Linux (and more specifically now debian) community,
> > and am wondering if possibly you might think xfstt would make a good
> > package to start with since I have never workerd on a package before.
> > Yes I have read all of the documentation, the policy manual and all
> > of that on the web page...and looked over a few times the packageing
> > manual (need to play with it some more :) ) I am a little afraid of
> > this...im unsure of my abilities I have fooled around with C for
> > about 4 or 5 years and done some C++...playe dwith shell scripts and
> > perl I admit I am unsure of what this will involve and the amount of
> > work it requires... but one of the main reasons I use linu xin the
> > first place is I want to learn...so I supose thats not entirely bad
> > so im wondering what you (and others on debian-devel) think does this
> > package seem like a bit much for a first package? if not...what do I
> > do next (yes I read all of the info on how to get started but...that
> > confused me just a bit... course thats probbaly just me :) )
> 
> Well, I'd like to invite you to join, or at least be in contact with, the X
> Strike Force  and me in
> particular.  I'd like to learn more about xfstt and what I can do to make
> sure it integrates smoothly with X.
> 
> After hamm is released I'm going to be re-engineering XFree86 a bit.  An
> xserver-common package will be created, and xbase will be further
> segregated.  I know it's a terrible thing to break X into even more binary
> packages, but I think things like xfs and xdm need to be split off,
> especially as they are targets for replacement on some systems.
> 
> -- 
> G. Branden Robinson |  Somebody once asked me if I thought sex
> Purdue University   |  was dirty.  I said, "It is if you're
> [EMAIL PROTECTED]  |  doing it right."
> http://www.ecn.purdue.edu/~branden/ |  -- Woody Allen
> 

-BEGIN PGP SIGNATURE-
Version: 2.6.3a
Charset: noconv

iQCVAwUBNTwY0Hxvn0zebBV9AQES2AQAmOFzwGabCcuC1mznqVa6i9NsEXHdeRxG
d47ARwdqyuLUCc5gF9bXflD1BwgKFfY0fQdajDbIdOKJ5xBSwLNr41yL5FBt3OMq
PcrYBHhOl4AWYPdTQF+MF3XZbjUiUOTBkyhsarBKP9qqEVauXWM5RPl270CJBVQy
oJwSp5C5F8U=
=aMQM
-END PGP SIGNATURE-


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

weird utmp/perl problem

[B. Bell]

Okay, I've got a strange problem here.  I'm trying to build a .deb, using
the devscripts tools and dpkg-dev...
I get a utmp error when I try to build:

<
$ build
no utmp entry available, using value of LOGNAME ("brad") at
/usr/lib/dpkg/controllib.pl line 16.


okay, not a disaster, there, but sometimes it eventually dies anyway,
because it can't find LOGNAME either, or the uid of some process...?

at first I thought maybe the problem was caused by the utmp
incompatibility between libc5 and libc6, even though I have a 100% hamm
system, and I even tried deleting utmp and wtmp and rebooting.
that didn't work, so I don't believe utmp is really the problem,
especially since this is the only place I've ever gotten a utmp-related 
error.

so, I look at the source of the error in /usr/lib/dpkg/controllib.pl

<<
if (defined ($ENV{'LOGNAME'})) {
if (!defined (getlogin ())) { 
warn (sprintf ('no utmp entry available, using value of LOGNAME
("%s")', $ENV{'LOGNAME'})); 
} else {
<<

now I'm suspicious, so I write a test script using my two-bit perl skills:

<<
#!/usr/bin/perl -w

if (defined (getlogin ())) {
warn (sprintf ('no utmp entry available'));
} else {
warn (sprintf ('utmp entry is ("%s")',
getlogin()));
}
<<

and run it:

<<
$./testutmp
utmp entry is ("brad") at ./test line 6.
<<

can anybody give me some help as to why this script works, but
/usr/lib/dpkg/controllib.pl fails?

thanks,
brad




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

Re: /tmp exploits

[Guy Maor]

I agree with Manoj here.

Modifying libc to catch common security goals is a laudable goal, but
such a libc should go to experimental.


Guy


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

Re: [sara@ora.com: NPR show on open source]

[Guy Maor]

Douglas Bates <[EMAIL PROTECTED]> writes:

> Make that
>   http://www.npr.org/ramfiles/980417.totn.02.ram
> if you just want the last hour.  The Free Software segment is the
> second part of that hour.

It starts 27:20 minutes in.


Guy


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

Re: binary-CD exceeds 650 MB -- any solution?

[Guy Maor]

The sizes are:
62997   contrib/binary-i386
326744  main/binary-i386
65237   non-free/binary-i386
31849   main/disks-i386
86526   contrib/source
690239  main/source
148075  non-free/source

Since the official CD doesn't include non-free, there won't be a
problem for this release.  All the binaries and some of the source go
on one CD, and the rest of the source on the other.  The total (w/o
non-free) is 1198355, so we still fit in 2.

Of course, there will have to be more CDs for the other archs.  We
would probably provide the official source+i386 set (2 CDs) and then
the official m68k, sparc, CDs etc.


Guy


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

Re: /etc/group lossage

[Guy Maor]

Martin Schulze <[EMAIL PROTECTED]> writes:

> msqld will only modify /etc/group when the needed group is missing.

I don't have msqld installed, so msqld might be doing the correct
thing.  It's fine to add the group with 'groupadd -g 36 msql', but you
definitely shouldn't modify the file directly.


Guy


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

Re: weird utmp/perl problem

[Guy Maor]

It's just a silly bug.  It calls that code from some scripts which
have fd0 dup'd elsewhere, so isatty(0) is false and getlogin() fails.


Guy


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

Re: /etc/passwd : which software does support this ?

[Guy Maor]

Remco Blaakmeer <[EMAIL PROTECTED]> writes:

> If shadow-login is the only program that supports these fields, they are
> useless. If a user had a value "pri=5", he would only have to do something
> like
> echo 'command' | at now
> to get 'command' executed at normal priority.

Yes, it's not very effective.  It's meant to be used with restricted
shells like rbash I guess.


Guy


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

Re: Intent to package: debian-keyring

[Jim]

In the message identified by <[EMAIL PROTECTED]>, Dale Scheetz <[EMAIL 
PROTECTED]> wrote:
> Thank you. That was the point I was so poorly trying to make. No
> denigration was intended (just a bit of jealousy at not having any spare
> time myself)

I'm not a developer, but I see how the debian IRC channel generally operates.
I am there quite a bit, helping new people and sometimes reporting bugs & etc.

If you haven't been there watching, you probably need to check your 
characterization of the folks there being there because they have, in
your words, "spare time". Reason: it still smacks of your opinion that
it isn't used to do real work, that the ONLY REASON why debian developers
are there is to _use up_ their "spare time".

Go there. Watch. Then express your opinion. Or don't (but if you
choose this, then you have only your guesses to go on; no facts.)


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

Re: /tmp exploits

[Carey Evans]

Ian Jackson <[EMAIL PROTECTED]> writes:

> We should modify our libc so that opening a file in /tmp or /var/tmp -
> determined by simple string comparison of the filename passed to
> open(2) - fails if O_CREAT is specified without O_EXCL.

You also need to check whether the current directory is /tmp, or a
symlink to it (like /usr/tmp).  A simpler way would be to check
against a umask like ((st_mode & 01007) == 01007) for the parent
directory.  There's probably a race condition here, though.

> We should do this in slink.  That way almost any program with a /tmp
> security hole will stop working straight away and _have_ to be fixed.

How about something like fakeroot?  Anyone who wants to test /tmp
programs can start the window manager and/or shells with it, and
identify problems quickly, although not in setuid programs.

It might be nice to have an option to fix the problem as well, by
adding O_EXCL, for when you *have* to use something which has a bug.

-- 
 Carey Evans  http://home.clear.net.nz/pages/c.evans/

"[UNIX] appears to have the inside track on being the replacement for
  CP/M on the largest microcomputers (e.g. those based on 68000...)"


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

intent to package: mayko xmap

[Joey Hess]

I'm going to package up a map viewer for X called mayko xmap, plus some
sample maps. http://www.mayko.com/ .

(I sort of hate to package this, becuase it is binary-only, libc5[1], uses 
motif, and is non-free. Many strikes against it. On the plus side, it 
works well, is easy to use, and was a lot easier to get working than any 
other mapping software I could find for linux, most of which wouldn't even
build.)

-- 
see shy jo
[1] The maintainers promise this will change soon, and source code might
become available as well.


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

Re: bzip2 for source packages?

[Brederlow]

James Troup <[EMAIL PROTECTED]> writes:

> Michael Alan Dorman <[EMAIL PROTECTED]> writes:
> 
> > Might I suggest that using it for source packaging would be
> > appropriate, though?
> 
> By recompressing things in bzip2, you lose the ability to use pristine
> upstream source (since the vast majority of source stills comes in
> .tar.gz form).

You would just use gzip for those. Same with sources that don't
compress well with bzip2 or with sources, which maintainer don't like
bzip2.

Nobody should be forced to use it and nobody should be forced not to
use it.

> Having said that, I'm a lot less opposed to this idea than I am to the
> idea of using bzip2 for debs.

Good. :)

May the Source be with you.
Mrvn


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

Re: bzip2 for source packages?

[Brederlow]

Michael Alan Dorman <[EMAIL PROTECTED]> writes:

> James Troup <[EMAIL PROTECTED]> writes:
> > Michael Alan Dorman <[EMAIL PROTECTED]> writes:
> > > Might I suggest that using it for source packaging would be
> > > appropriate, though?
> > By recompressing things in bzip2, you lose the ability to use pristine
> > upstream source (since the vast majority of source stills comes in
> > .tar.gz form).
> 
> That's a good point, one I hadn't thought of.

What about pristine upstream sources that use bzip2?

They aren't common, but I already seen some sources as bzip2.

> > Having said that, I'm a lot less opposed to this idea than I am to the
> > idea of using bzip2 for debs.

> Well, perhaps it would be nice to have it as an option for things
> where either we can't use pristine source anyway, or those rare, but
> often meaningful, occasions where it's supported upstream (linux
> kernel, maybe xfree one day...).

> Besides, considering the glacial pace of dpkg development, you won't
> have to take a decided stance any time soon. :-)

If gzip is made to recognise bzip2 it wouldnt need any change in any
other programm. The dpkg would directly work with it.

> Mike.

May the Source be with you.
Mrvn


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

Re: interest in xfstt package

[Mark Baker]

On Mon, Apr 20, 1998 at 10:24:33PM -0500, Branden Robinson wrote:

> After hamm is released I'm going to be re-engineering XFree86 a bit.  An
> xserver-common package will be created,

I understand that will be necessary (or at least highly desirable) in future
anyway, since new releases of XFree86 will have a single server binary with
loadable modules for the different drivers.


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

Re: Intent to package: debian-keyring

[Dale Scheetz]

On 20 Apr 1998, Manoj Srivastava wrote:

> Hi,
> 
>   Well, to take a different tack, what is the point of a policy
>  document at all when anyone can say "well, my package is an
>  exception and need not comply to policy."?  If one may take that
>  stance, I see no point in having a policy document in the first
>  place. 

To take the same tack, what is the point of a policy document that is so
rigid that noone can say "My package needs an exception to this policy."?
If one may take this stance, I see no point in trying to build a
distribution in the first place.

> 
>   manoj
>  Why have the rules in the first place? (As usual, my random sig
>  generator has come up with something apropos; though I disagree with
>  it) 
> -- 
>  Sometime, you've gotta break the rules.

This is the clearest statement defining our differences on this issue. I,
of course, agree with the above statement ;-)

Luck,

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (850) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


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

Re: binary-CD exceeds 650 MB -- any solution?

[Avery Pennarun]

On Tue, Apr 21, 1998 at 12:01:32AM -0700, Guy Maor wrote:

> The sizes are:
> 62997   contrib/binary-i386
> 326744  main/binary-i386
> 65237   non-free/binary-i386
> 31849   main/disks-i386
> 86526   contrib/source
> 690239  main/source
> 148075  non-free/source
> 
> Since the official CD doesn't include non-free, there won't be a
> problem for this release.  All the binaries and some of the source go
> on one CD, and the rest of the source on the other.  The total (w/o
> non-free) is 1198355, so we still fit in 2.

Don't forget:

222758  hamm/binary-all
14893   contrib/binary-all
52066   non-free/binary-all

And:

31849   hamm/disks-i386

If we include just the binaries from main and contrib, along with the
disks-i386 directory, we seem to get 659241 kbytes.  I can never quite
remember whether a CD contains 640 or 650 million bytes or megabytes, but
this is TIGHT on space.  Shoving disks-i386 off to a different CD is
probably sufficient to clear it up, though.

Have fun,

Avery


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

Re: binary-CD exceeds 650 MB -- any solution?

[Marcelo E. Magallon]

On Tue, 21 Apr 1998, Avery Pennarun wrote:

> If we include just the binaries from main and contrib, along
> with the disks-i386 directory, we seem to get 659241 kbytes.  I
> can never quite remember whether a CD contains 640 or 650
> million bytes or megabytes, but this is TIGHT on space. 
> Shoving disks-i386 off to a different CD is probably sufficient
> to clear it up, though. 

A few days ago I burned a CD with:

* hamm/main/binary-i386
* hamm/main/binary-all
* hamm/contrib/binary-i386
* hamm/contrib/binary-all
* hamm/main/disks-i386
* hamm/indices
* hamm/doc
+ linux/kernel/v2.1/linux*2.1.90*.bz2
+ linux/kernel/v2.1/patch*2.1.9[1-6]*.bz2

I stripped everything not compressed that has compressed
counterpart (Packages vs Packages.gz) and everything
architechture specific leaving only i386 (for example,
Packages*-alpha*). I'm sure I'm missing something here. The point
is, all this fitted on 620 MB. I didn't include tools, which
should go on the official CD.

I'm not sure how much data fits on a disc, I mean, if one makes
an image that's 649 MB, will that fit? I've read there are a few
seconds (like 5s, roughly 800 kB) on the initial part of the disc
that are not usable, but I don't know if that's already counted
on the 650 MB figure.


Marcelo


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

Intent to package libggi-dynamic

[Charles Briscoe-Smith]

(I mentioned this before, but at the end of another thread which you
probably didn't read...)

I intend to package libggi-dynamic, a 2d graphics library which provides
a common front-end for doing 2d drawing via KGI, svgalib, xlib, aalib
and others, or several at once.

-- 
Charles Briscoe-Smith
White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4>
PGP public keyprint: 74 68 AB 2E 1C 60 22 94  B8 21 2D 01 DE 66 13 E2


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

Re: /tmp exploits

[Riku Voipio]

On Mon, Apr 20, 1998 at 11:47:20PM -0700, Guy Maor wrote:

> Modifying libc to catch common security goals is a laudable goal, but
> such a libc should go to experimental.

Why change libc? Isn't there a kernel patch that makes /tmp safe? Why isn't
no-one using it?

-- 
Joh 3:16


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

Re: I have a pppd connection problem.

[Carlos Barros]

On Mon, 20 Apr 1998, Szomor Attila wrote:

  > --ppp not replacing existing default route to eth0[0.0.0.0]
  > --Cannot determine ethernet address for proxy ARP
  > I do not have idea what is a solution if you know it please send me an
  > e-mail.
  > 
  > /etc/ppp/options
  >   asyncmap 0
  >   crtscts
  >   lock
  >   modem
  >   noipdefault
  >   proxyarp


Try adding defaultroute to this file.

Bye
Carlos Barros.


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

debian cd creators

[Andreas Jellinghaus]

is there a list for cd-creators ?
i think we need one. topics
 - mirror file (if you only want to create a cdrom)
 - createing cdroms
 - improved check scripts, to make sure that all md5sums are ok,
   the Packages (and *.gz files !) are up-to-date
 - putting non-free on cdroms.
 ...

the debian official cd image with main+contrib is fine for me,
and debian should not create a cdrom with non-free. but other people
will do, and one goal of the list is, that these people can help each
other. 

if lists.debian.org could create and host it - fine.
but it could also be on a different machine, no problem.

andreas
currently rewriting debian-cd into a nicer makefile.


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

Re: debian cd creators

[Martin Schulze]

On Tue, Apr 21, 1998 at 04:55:28PM +0200, Andreas Jellinghaus wrote:
> is there a list for cd-creators ?

Does anything speak against [EMAIL PROTECTED]

  debian-cd@lists.debian.org

  Description : This list is used to make announcements to cd
   vendors.
  Moderated   : yes
  Subscription: open

Regards,

Joey

-- 
  / Martin Schulze  *  [EMAIL PROTECTED]  *  26129 Oldenburg /
 / http://home.pages.de/~joey/
/  Unable to locate coffee, operator halted.  -- Stefan Farsch  /


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

Re: /tmp exploits

[bear]

> On Mon, Apr 20, 1998 at 11:47:20PM -0700, Guy Maor wrote:
>> Modifying libc to catch common security goals is a laudable goal, but
>> such a libc should go to experimental.

This may be a stupid question, but *what* /tmp exploit are we trying
to fix? 

I ask solely because /tmp should already have some special attributes
set.  Is this exploit something which is already solved by existing
permission flags?  Is it something that could be solved by a new
permission flag?  

How about this is as second proposal:  modify libc, ext2fs and chattr
to support a new extended attribute:

 chattr +X

This flag is only meaningful for directories.  (The same bit could be
used for other purposes for files; perhaps we could reuse an existing 
bit?)

If this is set, its immediate children will force O_EXCL if O_CREAT is 
set.  This is slightly different from the first proposal, since "broken"
code would still work *unless* an entry with the same name already 
existed. 

Since you aren't using a string comparison all of the problems associated
with it disappear.  You could even walk the tree and set this bit on
*every* directory.  Since it's controlled by a standard mechanism, it's
easy to write wrapper functions, when necessary, for suitably privileged
users.

Finally, since there is a workaround (chattr(); broken(); chattr();)
we can reasonably define this bit to apply to *all* users, including
root.  If you don't want it at all, don't set the bit.  If you do want
it but have broken applications, use wrappers.

Bear Giles
[EMAIL PROTECTED]


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

Debian GNU/Linux: Best of the Web! (fwd)

[James A . Treacy]

For those few of you who don't read http://slashdot.org, the
Mining Co has posted their Linux "Best of the Net" site awards.
Debian was number 1. I'd never heard of this company before,
but am not adverse to any good publicity for Debian.
The awards page is at http://linux.miningco.com/library/awards/blapr98.htm

Three cheers for Debian.

Jay Treacy

P.S. There are more improvements in store for our web pages. Time
is the only thing keeping them from being implemented yesterday.
Stay tuned.

- Forwarded message from Aron Hsiao, your Linux guide! -

>From [EMAIL PROTECTED]  Mon Apr 20 13:57:51 1998
Delivered-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Date: Mon, 20 Apr 1998 11:34:49 -0600
From: "Aron Hsiao, your Linux guide!" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Organization: The Mining Company
X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.1.90 i586)
To: [EMAIL PROTECTED]
Subject: Debian GNU/Linux: Best of the Web!
X-UIDL: 08d1a14cec76f5ff411347f37bb07283

Hello!

There are good sites within the Linux community, there are great sites
within the Linux community, and there are absolutely _invaluable_
sites within the Linux community.

Your site has made the cut - The Mining Co., one of the most popular
destinations on the Internet, is pleased to present you with our
'Best of the Net' award through our child site, Focus On Linux.
The Mining Co. can be found at http://www.miningco.com; Focus On Linux
can be found at http://linux.miningco.com.

Of the many, many hundreds of Linux sites we index, spanning some
thirty-five community-oriented site categories, a total of ten
(10) sites will receive the "Best of the Net" award, placing your site
without question in the top 1% of Linux sites on the Internet. Our
Best of the Net award is given semiannually, once at the end of April
and once at the end of October.

Please accept this award as a thank you for an excellent contribution
to the Linux community and to the open-source/free software
movement. If you choose to display this award on your site, it would
be appreciated if you would link the award back to us at The Mining
Co. using the following (or similar) code:

http://linux.miningco.com";>

Or, if you prefer not to host the attached image locally:

http://linux.miningco.com";>http://linux.miningco.com/library/graphics/1998/bon_apr.gif";
width=83 height=72 alt="The Mining Co.: Focus on Linux 'Best of
the Net' award." border=0>

Once again, congratulations on an excellent Linux community resource!

Best Wishes,
Aron Hsiao
The Mining Co. Guide to Focus on Linux

--
These opinions are mine and no-one else's.

## ## ##   ## ##   ## ##   ##  Linux/SMP 2.1.90 used here.
##   ##   ###  ## ##   ##  ## ##   Linux: Choice of a GNU
Generation!
##   ##   ## # ## ##   ##   ###
##   ##   ##  ### ##   ##  ## ##   The Mining Company digs Linux:
## ## ##   ## ### ##   ##  http://linux.miningco.com

[image/gif is not supported, skipping...]

- End of forwarded message from Aron Hsiao, your Linux guide! -


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

package : how to execute a post-install script

[Julien Ortega]

I am making a package with deb-make for squid (the original package is
good but i want it to install in /usr/local/squid and not /usr/bin;
/usr/etc ... )

My package install squid, add a script in init.d but i want it, to
create the cache directory whith nobody rights and launch squid -z,
this, only if this directory dont exist.

so i have to execute a script after the installation.
how can i do ? 
-- 
Julien Ortega -- EXTERN
e-mail: [EMAIL PROTECTED]


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

Re: package : how to execute a post-install script

[Martin Schulze]

On Tue, Apr 21, 1998 at 05:24:57PM +0200, Julien Ortega wrote:
> I am making a package with deb-make for squid (the original package is
> good but i want it to install in /usr/local/squid and not /usr/bin;
> /usr/etc ... )
> 
> My package install squid, add a script in init.d but i want it, to
> create the cache directory whith nobody rights and launch squid -z,
> this, only if this directory dont exist.
> 
> so i have to execute a script after the installation.
> how can i do ? 
> -- 

that's debian/postinst which installs into debian/tmp/DEBIAN/postinst.

I thought deb-make installs dummy scripts.

Regards,

Joey

-- 
  / Martin Schulze  *  [EMAIL PROTECTED]  *  26129 Oldenburg /
 / http://home.pages.de/~joey/
/  Unable to locate coffee, operator halted.  -- Stefan Farsch  /


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

master status

[m*]

mark from novare here!

we determined last night that the disk where the dist archive resides is
bad and must be replaced.

i will have that drive replaced and restored as soon as possible so we
can get the
Project back on track.

again sorry for the delay, but we actually had two disks ( Micropolis
9GBs ) that
failed with one of those being the backup. very unfortunate as well as
unnerving.

anyway, that is the current status and i will update you as soon as
possible as i am off
to purchase a new 9GB this morning!

thanks!

m*


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

Re: binary-CD exceeds 650 MB -- any solution?

[Andreas Jellinghaus]

>What are the plans for the official CD?

main + contrib fit on one cdrom. so i propose
to use the official cdrom as long as possible.

people (not debian) should then create a third cdrom with
non-free source + binaries (parts), and maybe other stuff
(kde, netscape, whatever you want to include).

this solution should be fine for everybody.

for discussion, writing scripts/Makefiles, helping each other,
we should have a seperate list. several broken cd's 
(e.g. packages != packages.gz) are a good reason to write
checking programs. pointing to the official cdrom is the best solution
for most people, but not for everybody.

at least i could also need a smarter mirror script :
it should keep symlinks inside the mirror as symlinks,
but for symlinks pointing to something excluded from mirroring,
it should download the file. this way i could burn a complete hamm...

andreas


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

Re: weird utmp/perl problem

[Karl M. Hegbloom]

> "Guy" == Guy Maor <[EMAIL PROTECTED]> writes:

Guy> It's just a silly bug.  It calls that code from some scripts
Guy> which have fd0 dup'd elsewhere, so isatty(0) is false and
Guy> getlogin() fails.

 Will someone please fix it?  It's really annoying.  Is it in the bug
sys?


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

Re: `Usenix-88-lexic.pdf': Paper refered to in gcc texinfo manual.

[Karl M. Hegbloom]

> "jdassen" == jdassen  <[EMAIL PROTECTED]> writes:

jdassen> On Sat, Apr 18, 1998 at 09:45:27AM -0700, Karl
jdassen> M. Hegbloom wrote:
>> It is currently, but not for too much longer, sitting in:
>> http://www.inetarena.com/~karlheg/Public/Usenix-88-lexic.pdf
>> 
>> Please let me know if you've got a home for it, so I'll know
>> when I can remove the file from the http directory.

jdassen> You can make it availble through http on master.

 Ok, I will do that when `master' is repaired.


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

Intent to package: ras, qvwm, descent

[Falk Hueffner]

Hello,

I intend to apply as a maintainer (as soon as I find somebody to scan
my passport ;) and package:

- ras (http://dspace.dial.pipex.com/nc/)

Ras is a small utility that adds m extra files to a set of n files,
such that the contents of the n original files can be regenerated from
any n of the n+m original files and extra files. It is useful for
transporting large files with floppies.

It is released under the GPL and would go to slink/main/utils.

The package is fairly easy and nearly finished.

- qvwm (http://www-masuda.is.s.u-tokyo.ac.jp/~kourai/qvwm/qvwm-e.html)

Qvwm is a window manager with look and feel similar to Windows 95, but 
with the common functions known from fvwm2 like a pager,
SmartPlacement, EdgeResistance etc.

It's license is not quite clear and that would have do be resolved
before the package could be included in Debian. I have contacted the
author about that.

Packaging will be a bit more tricky, since I need to find a solution
for the menu-method.

- Descent (http://www.muppetlabs.com/linux/descent/,
   http://wouters.www.cistron.nl/ggi/ggi-descent.html)

Descent is a commercial 3D game, to which the source has been
released. You still need datafiles from the original game, though; the 
situation is similar to quake.

There are currently two ports for Linux, one of them for ggi and one
with multiple display targets; I will wait for the libggi package, I
think, since that is a cleaner solution IMHO.

It would go to slink/non-free/games.


Falk


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

Re: bzip2 X

[Brederlow]

Bdale Garbee <[EMAIL PROTECTED]> writes:

> In article <[EMAIL PROTECTED]> you wrote:
> 
> : Hmm... it's actually probably a good idea to bzip2 the X sources.
> : They're monstrous.
> 
> Probably a good idea.  However...
> 
> The right way to handle this is for someone to broach the subject of using
> compressors other than gzip for source packages over on debian-policy.  At
> the same time, take up the issue with the dpkg maintainers since dpkg-source
> will need to be updated.
> 
> As maintainer of gzip for Debian, I do not agree that having gzip fork a 
> bzip2 when it sees a bzip2 magic number is a good idea.  If we want to 
> support 
> multiple compression engines, I believe this should be handled in dpkg-source.

Changing dpkg* to support bzip2 (or other packers) would be a good
thing, but haveing gzip know about bzip2 would be far nicer, much
easier (and less risk of bugs) and much more general.

Fonts for X could be stored as bz2 instead of gz, man-pages could be
bz2. Many other static data could be bz2. Wherever static data is
stored as gz, bz2 could be used. Much more programms than dpkg would
benefit from that and for people with fast cpus with little
harddrives, it would be real handy.

I want to have bzip2 for everydays use and not just for installing or
unpacking debian sources and I want it as transparent as possible. I
wrote a little wraper that can distinguish between the packers and
then chooses the appropriate one. Because its a wraper its slow and
generaly I dislike wrapers, but it also works great and is done
fast. Its not agood solution, so thats why I asked here about
integrating bzip2 support into gzip. Integrating it into dpkg* just
wouldn't cut it.

May the Source be with you.
Mrvn


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

RE: deb + tar + bzip2 suggestion

[Patrick Ouellette]

Sorry for the late reply - catching up.

IMHO speed is always relevant, and so is memory usage.  This is the trap
Micro$oft
and Apple have fallen into.  Just because the hardware is capable of running
faster
is no excuse for sloppy coding.  I'm not saying everything should be written
in assembly
language and optimized, but horsepower is not a substitute either.

Pat

> -Original Message-
> From: Brederlow [mailto:[EMAIL PROTECTED]
> Sent: Saturday, April 18, 1998 10:48 AM
> To: [EMAIL PROTECTED]
> Cc: Stephan Kulow; debian-devel@lists.debian.org
> Subject: Re: deb + tar + bzip2 suggestion
>
>
> Christophe Broult <[EMAIL PROTECTED]> writes:
>
> > Stephan Kulow <[EMAIL PROTECTED]> writes:
> ...
> > > BTW: tar can handle bz2 files. you can use
> --use-compress-program=bzip2.
> >
> > That option isn't working properly with bzip2 but hopefully bzip2 is
> > now supported by tar ie
> >
> > tar cIf
> > tar xIf
> > tar tIf
> >
> > [EMAIL PROTECTED]:~ $ tar --help | grep zip
> >   -I, --bzip2, --bunzip2 filter the archive through bzip2
> >   -z, --gzip, --ungzip   filter the archive through gzip
> > [EMAIL PROTECTED]:~ $
> >
> > >
> > > Greets, Stephan
>
> -z filter through gzip, bzip, bzip2 as appropriate
>
> That would be a nice thing. If tar would behave like that, one could
> make gzip or bzip2 deb files depending on once likeing. With todays
> Computers (486+) the speed isn't that relevant and on slow computers
> and installation takes ages anyway, so you normaly start it and do
> something else in parallel.
>
> May the Source be with you.
>   Mrvn
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
> [EMAIL PROTECTED]
>
>


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

Re: first proposal for a new maintainer policy

[Manoj Srivastava]

Hi.

Philip> Does that satisfy both sides ?

This satisfies me. Indeed, this has been my position all the
 while, but evidently the joys of the fray and the intellectual
 stimulation offered by the flow of reason has been a feast for my
 soul, and, added to my evident inability to coherently and fluently
 put forth my opinions in a convincing fashion has led to much of the
 conglagration on these lists.

manoj
 Who would not go as far as his rand sig generator

>>"Phil" == Philip Hands <[EMAIL PROTECTED]> writes:

Phil> I've been keeping an eye on this discussion, and find myself
Phil> smiling at the slightly disingenuous way that the two sides have
Phil> been characterising the opposing view.

Phil> When described by the opposition, the two views come out as:
Phil>   A:  Policy is just for fun, and can be ignored on a whim.
Phil>   B:  Policy is more important than life, and any infringement should be
Phil>   punishable by expulsion from the project, or preferably death.

;-)

Phil> Now clearly, these are not the views that are actually held by
Phil> either side, which seem to come out as something closer to:
Phil>   A:  Policy should be adhered to, except where (in the
Phil>   maintainers opinion) it would be more appropriate to
Phil>   something else (on technical grounds)
Phil>   B:  Policy should be correct and up to date, in which case
Phil>   there should be no reason to allow exceptions, because
Phil>   things that are justified exceptions should be included in
Phil>   policy.

Phil> Is that fair ?  < donning flame proof armor ;-) >

Close enough (I would be in favour of amending policy to be in
 line with correct behaviour too).

Phil> These are not nearly as far apart as you guys are making out,
Phil> and could be combined to say something like:

Phil>   Policy should be adhered to.

Phil>   In cases where the policy conflicts with what they consider to
Phil>   be best for their package, they can chose to ignore policy, as
Phil>   long as they also attempt to have policy changed by discussing
Phil>   it on debian-policy.

Phil>   If this discussion results in a change in policy, well and good.

Phil>   If the discussion concludes that they were wrong, they must
Phil>   fix the bug that they have introduced into their package by
Phil>   ignoring policy.

Phil>   While the discussion is under way on debian-devel, there is
Phil>   little point submitting bug reports pointing out the policy
Phil>   violation, unless that violation results in behaviour that
Phil>   could damage a user's system if they installed the package.

Phil>   In any case, if a maintainer insists on uploading buggy
Phil>   packages, against the consensus of the Debian developers,
Phil>   various sanctions, up to and including expulsion from the
Phil>   project are always available.

Phil> Of course, if the policy included a:

Phil>   ``Policy may by ignored while the clause in question is under
Phil>   discussion''
Phil> clause, then the policy could also a have a
Phil>   ``Policy MUST be obeyed at all times''
Phil> clause, since the exclusion would be in the policy ;-)

Phil> Does that satisfy both sides ?

-- 
 "Government is not reason; it is not eloquence; it is force!  It is a
 dangerous servant and a terrible master." George Washington
Manoj Srivastava  <[EMAIL PROTECTED]> 
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


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

Re: deb + tar + bzip2 suggestion

[Erv Walter]

In article <[EMAIL PROTECTED]> you wrote:
> Sorry for the late reply - catching up.

> IMHO speed is always relevant, and so is memory usage.  This is the trap
> Micro$oft
> and Apple have fallen into.  Just because the hardware is capable of running
> faster
> is no excuse for sloppy coding.  I'm not saying everything should be written
> in assembly
> language and optimized, but horsepower is not a substitute either.

Memory usage is important, but the useage time is short in this
sense.  Speed is important too, but the extra 30 seconds it takes to
uncompress somethis is made up for in this case by the 5 minutes saved 
in downloading.  This, of course, is only true if you have a slow link 
to the internet, but I think that that is true for a majority of
people.

Erv

-- 
Graduate Student[EMAIL PROTECTED]
Department of Chemistry   [EMAIL PROTECTED]
Univ of Wisconsin-Madison   [EMAIL PROTECTED]
   

I wouldn't be caught dead with a necrophiliac.
 -- tagline 1.00 by xopy


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

Re: bzip2 X

[Mark W. Eichin]

> Fonts for X could be stored as bz2 instead of gz, man-pages could be
> bz2. 

No, that's actually not true.  Changing how gzip-the-program behaves
would have no effect on X font handling.

Fonts are stored gzipped because there is a fast, free-enough-for-X,
zlib implementation.  (The server hasn't forked a decompression
program since X11R2 or so... when the inline zcat code was added.)
Around X11R6 I added zlib font decompression to the upstream sources
(X Consortium and XFree) which is why we have it now.  In order to
move to bzip2, you'd have to (1) come up with a library implementation
that was free-enough [GPL isn't, of course; you could probably use the
license already on zlib] (2) wasn't the amazing memory hog that the
current bzip2 programs are (3) didn't annoy people by being slow.
(zlib is actually par with zcat, or maybe a little faster, I forget.
Not a really noticeable hit in any case.)

I'd have to check the code and see if it figures out the compression
by magic number or by file extension.  I'm *pretty* sure it does the
latter.  If you changed it to handle magic numbers instead, then you
could just have a script that an end user could run that recompresses
the fonts but leaves them in the same file names (after all, if the
machine is fast enough to use bzip2 on the fly, it's fast enough to do
the bulk conversion relatively quickly :-)

_Mark_ <[EMAIL PROTECTED]>
The Herd of Kittens
Debian Package Maintainer


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

Re: Intent to package: debian-keyring

[Manoj Srivastava]

Hi,
>>"Dale" == Dale Scheetz <[EMAIL PROTECTED]> writes:

Dale> On 20 Apr 1998, Manoj Srivastava wrote:
>> Hi,
>> 
>> Well, to take a different tack, what is the point of a policy
>> document at all when anyone can say "well, my package is an
>> exception and need not comply to policy."?  If one may take that
>> stance, I see no point in having a policy document in the first
>> place.

Dale> To take the same tack, what is the point of a policy document
Dale> that is so rigid that noone can say "My package needs an
Dale> exception to this policy."? If one may take this stance, I see
Dale> no point in trying to build a distribution in the first place.

OOOh, Some thing I can agree with ;-) The policy can never
 be rigid; it is up to the policy to conform to correct
 behaviour. There should be well defined processes to initiate a
 change in policy (I thought such procedures already exist). 

The difference here is that one has to convince a number of
 other people (generally, the people interested in policy hang out in
 debian-policy); so it means that one may not arbitarily decide that
 they shall ship a package that is non-free into main since their
 package is an exception to the DFSG. I think discussion on something
 as important as the policy document is not undesirable. 

It also means that a lone developer can't shanghai policy
 ;-). If the policy manager gets too rigid, the developers can impeach
 him/her 9if we ratify the constituition).

Policy can never become a rigid unchanging document; and any
 flaws or exceptions should be included in the policy as soon as
 possible. 

I do not think that the solution to a flaw in the policy
 should be to ignore policy. I think the solution should be to fix
 policy.

Oh, when I say policy, I mean the loose heirarchy of documents
 that constitute the rules by which we construct packages (including
 the DFSG, the www standard, the emacsen policy, etc)

manoj
-- 
 If a person (a) is poorly, (b) receives treatment intended to make
 him better, and (c) gets better, then no power of reasoning known to
 medical science can convince him that it may not have been the
 treatment that restored his health. Sir Peter Medawar, The Art of the
 Soluble
Manoj Srivastava  <[EMAIL PROTECTED]> 
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


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

Re: Debian GNU/Linux: Best of the Web! (fwd)

[G John Lapeyre]

On Tue, 21 Apr 1998, James A.Treacy wrote:

> For those few of you who don't read http://slashdot.org, the
> Mining Co has posted their Linux "Best of the Net" site awards.
> Debian was number 1. I'd never heard of this company before,
> but am not adverse to any good publicity for Debian.
> The awards page is at http://linux.miningco.com/library/awards/blapr98.htm

Looks like they've put a good deal of effort into their site. I
don't know who made the ratings(has good taste, I imagine) ...  but notice
Debian is the #1 site, while no other distribution made the top 10. 

John Lapeyre <[EMAIL PROTECTED]>
Tucson,AZ http://www.physics.arizona.edu/~lapeyre


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

Re: first proposal for a new maintainer policy

[Dale Scheetz]

On 21 Apr 1998, Manoj Srivastava wrote:

> Hi.
> 
> Philip> Does that satisfy both sides ?
> 
>   This satisfies me. Indeed, this has been my position all the
>  while, but evidently the joys of the fray and the intellectual
>  stimulation offered by the flow of reason has been a feast for my
>  soul, and, added to my evident inability to coherently and fluently
>  put forth my opinions in a convincing fashion has led to much of the
>  conglagration on these lists.

Manoj,

Thank you for putting this back on development. I would never have seen it
otherwise.

BTW, you didn't conflagrate all by yourself ;-)

> Phil> Now clearly, these are not the views that are actually held by
> Phil> either side, which seem to come out as something closer to:
> Phil>   A:  Policy should be adhered to, except where (in the
> Phil>   maintainers opinion) it would be more appropriate to
> Phil>   something else (on technical grounds)
> Phil>   B:  Policy should be correct and up to date, in which case
> Phil>   there should be no reason to allow exceptions, because
> Phil>   things that are justified exceptions should be included in
> Phil>   policy.
> 
> Phil> Is that fair ?  < donning flame proof armor ;-) >

Sure!

> 
>   Close enough (I would be in favour of amending policy to be in
>  line with correct behaviour too).
> 
> Phil> These are not nearly as far apart as you guys are making out,
> Phil> and could be combined to say something like:
> 
> Phil>   Policy should be adhered to.
> 
> Phil>   In cases where the policy conflicts with what they consider to
> Phil>   be best for their package, they can chose to ignore policy, as
> Phil>   long as they also attempt to have policy changed by discussing
> Phil>   it on debian-policy.
> 
> Phil>   If this discussion results in a change in policy, well and good.
> 
> Phil>   If the discussion concludes that they were wrong, they must
> Phil>   fix the bug that they have introduced into their package by
> Phil>   ignoring policy.
> 
> Phil>   While the discussion is under way on debian-devel, there is
> Phil>   little point submitting bug reports pointing out the policy
> Phil>   violation, unless that violation results in behaviour that
> Phil>   could damage a user's system if they installed the package.
> 
> Phil>   In any case, if a maintainer insists on uploading buggy
> Phil>   packages, against the consensus of the Debian developers,
> Phil>   various sanctions, up to and including expulsion from the
> Phil>   project are always available.
> 
> Phil> Of course, if the policy included a:
> 
> Phil>   ``Policy may by ignored while the clause in question is under
> Phil>   discussion''
> Phil> clause, then the policy could also a have a
> Phil>   ``Policy MUST be obeyed at all times''
> Phil> clause, since the exclusion would be in the policy ;-)
> 
> Phil> Does that satisfy both sides ?

Well, we are at least moving in the right direction ;-)

First, some things that I think haven't been said yet (if that is
possible).

The Policy Statement is a, now not so recent, attempt at writing down the
Debian Policy that, up until then, was known to the developers by "shared
knowledge". The Policy Statement was made necessary as a result of an
enlarged development community, in order to insure that the previously
"shared knowledge" would be available to all.

It should be understood that, as a written document which governs how we
do development, this Statement will be under constant modification. In
recognition of this fact, the Policy Group should provide a well defined
method for putting a proposal before the Policy Group that does not
involve becoming a member of the group.

And finally, there are two classes of "bug" in the Policy Statement, only
one of which was been under discusion. We have spoken reams about those
items in the Policy Statement that are "broken", while ignoring the other
sort of problem: the one where policy doesn't say anything about the
issue.

With the above in mind, I would like to see the first sentance:

Policy should be adhered to.

expanded into a more descriptive and somewhat less restrictive statement,
like:

The Policy Statement contained herein defines the details of a properly
constructed Debian package. When it becomes necessary for a particular
package to behave counter to policy, the package maintainer should suggest
that the Policy Statement be modified to reflect the special needs of the
package.


I might also add:

When the Policy Statement does not say anything, or is unclear about a
particular issue, maintainers may ask the Policy Group for clarification.  

This is actually probably going to be shared between the Policy Group and
the "Technical Committee", which is why I didn't include it outright.


In addition, I would like to see policy items identified with some
severity levels. Something like:

criticalViolations of these policies will result in packages that
either don't work, 

Re: first proposal for a new maintainer policy

[Manoj Srivastava]

Hi,

What is this policy group you are talking about? AFAIK, there
 is no such beast; there is just an public, open mailing list, which
 is more and less than a formal Policy group.

The mailing list was formed to reduce clutter on the devel
 list, which is rapidly becoming a catch-all of everything (I
 routinely see -user questions on -devel, which I am far less likely
 to answer than the same question on -user).

I would strongly urge anyone who is interested in what goes
 into the Policy manual to keep an eye on that mailing list; I
 personally priritize -policy higher than -devel, as the former has
 postings of more interest to me.

Since this is rteally a meta discussion, I think it is right
 to discuss this on both -policy and -devel, vefore anyone accuses me
 of gratuitous cross-posting.

manoj
-- 
 Let me play with it first and I'll tell you what it is later. Miles Davis
Manoj Srivastava  <[EMAIL PROTECTED]> 
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


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

Re: bzip2 X

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:
: fast. Its not agood solution, so thats why I asked here about
: integrating bzip2 support into gzip. 

Points well taken.  You're just asking in the wrong place.  You should take
this up with the gzip upstream maintainer.  It is not a Debian packaging 
issue, it is a request for a fundamental change in the functionality provided
by gzip.  If bzip2 algorithm support were to show up in a future gzip release
I'd be as happy as the next guy. 

If the gzip upstream maintainer doesn't fold in bzip2, then the right solution
is for this to be handled by applications like dpkg-source... not by having 
the Debian gzip functionality diverge from the FSF gzip.

Bdale


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

Nice stuff to package: Open C++

[Yann Dirson]

Open C++ is a toolkit providing a meta-programming-level above C++.  It
has a Xerox copyright which seems to make it DFSG-free.

Home page (with online ref. manual): 

http://www.softlab.is.tsukuba.ac.jp/~chiba/openc++.html

It would probably be nice to get this one into slink...

-- 
Yann Dirson  <[EMAIL PROTECTED]>  | Stop making M$-Bill richer & richer,
alt-email: <[EMAIL PROTECTED]>  | support Debian GNU/Linux:
debian-email:   <[EMAIL PROTECTED]>  | more powerful, more stable !
http://www.a2points.com/homepage/3475232 | Check 


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

Re: Debian GNU/Linux: Best of the Web! (fwd)

[Nicolás Lichtmaier]

On Tue, Apr 21, 1998 at 11:33:49AM -0400, James A.Treacy wrote:
> For those few of you who don't read http://slashdot.org, the
> Mining Co has posted their Linux "Best of the Net" site awards.
> Debian was number 1. I'd never heard of this company before,
> but am not adverse to any good publicity for Debian.
> The awards page is at http://linux.miningco.com/library/awards/blapr98.htm
> 
> Three cheers for Debian.

 Are we really that good?? =)


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

Re: Lists archives outside debian.org

[Martin Schulze]

On Thu, Apr 16, 1998 at 12:58:08PM +0200, [EMAIL PROTECTED] wrote:
> There now appear to be a few search sites that cover a lot of mailing
> lists:
>
>   http://www.reference.com/
> and
>   http://www.findmail.com/
>
> Both already have many major linux lists (like [EMAIL PROTECTED])
> (for reference.com: search mailing list directory for "Linux"; for
> findmail.com: see
>
> http://www.findmail.com/lists/Computers/Operating%20Systems/Linux/), 
> but neither archives the Debian lists.
> 
> I think it would be useful to archive the Debian lists there too (in
> addition to our www.debian.org archive).

Do others have an oppinion on it, too, or is it just Ray and Marco?

Regards,

Joey
([EMAIL PROTECTED])

-- 
  / Martin Schulze  *  [EMAIL PROTECTED]  *  26129 Oldenburg /
 / http://home.pages.de/~joey/
/  Unable to locate coffee, operator halted.  -- Stefan Farsch  /


pgpMBMsrZgiMg.pgp
Description: PGP signature