Re: (Beware helix packages) Re: [CrackMonkey] The right to bare legs

[Ryan Murray]

On Tue, Aug 29, 2000 at 10:08:43PM -0500, Branden Robinson wrote:
> Don't do this.  If you're hellbent on forking Debian packages just for the
> sake of doing so, or spraying them with Helix musk, then name the packages
> appropriately.
> 
> helix-gnomecc
> helix-gnome-core
> helix-gdm

In the case of Storm, we aren't intending to fork packages, just add a few
things to make it work better in our distro, that Debian doesn't have/want,
so it makes no sense to put it back into Debian.

> > The scheme I am using now works perfectly for all the distributions we
> > support so far, except one: Debian unstable. It is a pity that the one
> > distribution that doesn't work as well is the same one I prefer to
> > use.
> 
> This is what happens when you fail to familiarize yourself with the Debian
> Packaging and Policy Manuals, and/or fail to run your ideas by Debian
> developers first.
> 
> > If there is a better solution, I am completely open to changing the
> > way things work on my end. I want to be able to preserve the upgrade
> > path for Helix GNOME packages, though. Using NMU versioning breaks
> > that, as it produces flip-flopping between the Debian versions of the
> > packages and mine.
> 
> I'm pretty sure that if you switch to using helix-* names for your
> packages, you won't take this problem.  You could even create a task
> packages, say "task-helix-gnome", and make things even easier on your
> users.  Unless you think usage of Helix .debs has already peaked, it's
> better to make this change sooner rather than later.
> 
> Progeny is going to have to deal with these issues as well, and we're bound
> and determined to do it the right way.  Corel hasn't managed it.  Stormix
> hasn't managed it.  Would you Helix like to be the first good example, or
> do you want to leave that to Progeny?

stable Debian releases only have security changes and critical bugfixes going
into them once released.  I feel that the security/bugfix is more important
than any of the "extras" offered in the Stormix packages, so your suggestion
means that the security upgrades won't be available to the users ASAP, and
must rather wait for Stormix to build a new version with the fixes.  I think
this removes a very powerful benefit to using Debian, and wouldn't want to
see users robbed of it.  Your definition of "right" seems to break this.
If you have a suggestion that solves this problem, and doesn't require the
current -#.storm# or something of that nature, I'd love to hear it.

-- 
Ryan Murray, ([EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED])
Programmer, Stormix Technologies Inc., Debian Developer
The opinions expressed here are my own.


pgpFQ5AepLHLa.pgp
Description: PGP signature

Re: (Beware helix packages) Re: [CrackMonkey] The right to bare legs

[Anand Kumria]

On Tue, Aug 29, 2000 at 10:02:04PM -0500, Branden Robinson wrote:
> > No, there is no difference between our apps and the upstream in most
> > cases. We do brand gnome-core and gdm, but those are the only packages
> > I can think of offhand. Those are only graphics changes, substituting
> > some of our images in place of the defaults.
> 
> Okay, fine.  Name the Helixified packages under the following scheme:
> 
> Package: helix-gnome-core
> Conflicts: gnome-core
> Provides: gnome-core
> 
> Package: helix-gdm
> Conflicts: gdm
> Provides: gdm
> 
> (The Provides: gdm isn't necessary if nothing depends on it, and off the
> top of my head I can't think of anything that would depend on a display
> manager.)
> 
> You can then version helix-gnome-core and helix-gdm however you see fit.
> I'm not in any position to guarantee this, but I think Debian can agree to
> cede this part of our packaging namespace to you.  You may then, on these
> packages, violate our version numbering conventions to your heart's
> content.

That is one mechanism of creating a private namespace, isn't another 
Setting the origin to something other than Debian?

I'm not familiar with the gritty details of creating Package(.gz) files.

Anand

Re: (Beware helix packages) Re: [CrackMonkey] The right to bare legs

[Branden Robinson]

On Tue, Aug 29, 2000 at 10:12:56PM -0700, Ryan Murray wrote:
> stable Debian releases only have security changes and critical bugfixes going
> into them once released.  I feel that the security/bugfix is more important
> than any of the "extras" offered in the Stormix packages, so your suggestion
> means that the security upgrades won't be available to the users ASAP, and
> must rather wait for Stormix to build a new version with the fixes.  I think
> this removes a very powerful benefit to using Debian, and wouldn't want to
> see users robbed of it.  Your definition of "right" seems to break this.
> If you have a suggestion that solves this problem, and doesn't require the
> current -#.storm# or something of that nature, I'd love to hear it.

I don't think 3rd party vendors can have it both ways.  If they want to
lock their users into, for example, the "Official Helix(tm) Debian
Packages", then they have to accept the responsibility for getting out
security releases in a timely manner.

If you want to take advantage of timely security updates by Debian, then
you need to play nice with us and not try to break our versioning system.

-- 
G. Branden Robinson |You should try building some of the
Debian GNU/Linux|stuff in main that is modern...turning
[EMAIL PROTECTED]  |on -Wall is like turning on the pain.
http://www.debian.org/~branden/ |-- James Troup


pgpXQtHKUh7or.pgp
Description: PGP signature

Re: (Beware helix packages) Re: [CrackMonkey] The right to bare legs

[Branden Robinson]

On Wed, Aug 30, 2000 at 04:48:19PM +1100, Anand Kumria wrote:
> That is one mechanism of creating a private namespace, isn't another 
> Setting the origin to something other than Debian?

Please see elsewhere in this thread for my other remarks on this subject.

An Origin field is a great idea.

Once we have it.

-- 
G. Branden Robinson |
Debian GNU/Linux| // // //  / /
[EMAIL PROTECTED]  | EI 'AANIIGOO 'AHOOT'E
http://www.debian.org/~branden/ |


pgpBTskltJTjA.pgp
Description: PGP signature

Re: (Beware helix packages) Re: [CrackMonkey] The right to bare legs

[Ryan Murray]

On Wed, Aug 30, 2000 at 01:28:18AM -0500, Branden Robinson wrote:
> On Tue, Aug 29, 2000 at 10:12:56PM -0700, Ryan Murray wrote:
> > stable Debian releases only have security changes and critical bugfixes 
> > going
> > into them once released.  I feel that the security/bugfix is more important
> > than any of the "extras" offered in the Stormix packages, so your suggestion
> > means that the security upgrades won't be available to the users ASAP, and
> > must rather wait for Stormix to build a new version with the fixes.  I think
> > this removes a very powerful benefit to using Debian, and wouldn't want to
> > see users robbed of it.  Your definition of "right" seems to break this.
> > If you have a suggestion that solves this problem, and doesn't require the
> > current -#.storm# or something of that nature, I'd love to hear it.
> 
> I don't think 3rd party vendors can have it both ways.  If they want to
> lock their users into, for example, the "Official Helix(tm) Debian
> Packages", then they have to accept the responsibility for getting out
> security releases in a timely manner.
> 
> If you want to take advantage of timely security updates by Debian, then
> you need to play nice with us and not try to break our versioning system.

Which is what a -#.storm# does exactly.  I don't want to "lock" users into
anything.  Being able to upgrade to woody is something I think is a good
thing.

I agree, however, that just a -storm does not play nicely with the versioning
system, and in those cases, it would be up to Storm to provide any security
updates.  From a quick look through the archive, the only package that seems
to do this is gdm, of which I maintain both Storm's and Debian's, which is
why I chose that for the case...

I hardly see how this is "not doing it right," as you said.

-- 
Ryan Murray, ([EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED])
Programmer, Stormix Technologies Inc., Debian Developer
The opinions expressed here are my own.


pgpHKOZEydEyo.pgp
Description: PGP signature

Re: Found the problem: was Re: Help

[Ulf Jaenicke-Roessler]

Dale Scheetz wrote:

> /usr/local/bin/pine not found
> 
> If I explicitly call /usr/bin/pine it works just fine.
> 
> I just checked on another user login, and no problems. This must be a bash
> command caching artifact. I guess logging out will fix it...

 hash -r would do it too.


  Ulf

Re: (Beware helix packages) Re: [CrackMonkey] The right to bare legs

[Jason Gunthorpe]

On Wed, 30 Aug 2000, Branden Robinson wrote:

> > That is one mechanism of creating a private namespace, isn't another 
> > Setting the origin to something other than Debian?
> 
> Please see elsewhere in this thread for my other remarks on this subject.
> 
> An Origin field is a great idea.

We have one, sorry I am so late making it be really useful - very busy you
know.. 

Assuming I can manage to get in the proper frame of mind this problem
should become much less troubling for most APT users.

The versioning scheme I will suggest is fairly direct:
  1) If the package is derived from a debian package it should encode that
 fact by using -1.storm.1, or -1.1, -0.storm.1, etc or whatever seems
 appropriate.
  2) If the package is not derived from a debian package it should use a 
 plain version, -1.storm, -1 or something
  3) Libraries - All possible effort should be made to make Debian the
 primary source of libraries. Period full stop. This is so important
 because of what we are seeing with helix and their special library 
 packages now. Thus, I suggest the following:
   a) If a add-on vendor needs a newer upstream library then they
  can follow standard NMU procedures, using a -0.1.helix type tag.
   b) If their is some critical bug in the Debian library then they
  should still follow NMU type procedures and work with the
  Debian library packager and upstream to make sure the next rev
  is properly fixed.
   c) I recommend the vendor provide a seperate section of their
  FTP site specifically for libraries, and tagged with a proper
  Release file. The libraries they collect there should be the
  libraries they use and have modified. It would be best if most
  of these files were exactly identical to what Debian ships.
  Rational: 
 i) I expect people like helix will include woody
libraries that work on a potato system. These can use the
'usual' 1.2-0.1.woody.1 tagging scheme and probably will not
be included by Debian.
ii) I want the user to be able to say 'I want only helix gnome 
but pick the newest library from the union of
debian+helix'. This is easiest if the libraries are
seperated.
   iii) Libraries are truely a shared resource, we need to take
special steps to ensure apps in Debian linked to them work
and apps in Helix linked to them work - best way to that
is to only have 1 library package that everyone uses and
tests against.

Encoding the vendor tag in the version string will allow the user to know
which version has been installed. It is also important to make sure that
each vendor is creating universially unique package/version/arch triplets.
APT can handle most cases where this is not true but it is *very*
confusing to the end user and is best advoided.

Inter-origin version comparisions is probably fairly pointless - what is
newer? libgnome 1.2-1.storm.1 or libgnome 1.2-1.helix.1 ? 

Selecting which origin is prefered (debian, helix, storm) is done in APT,
via a user configurable system on a per-package and 'default' sort of
basis. Vendors should not try to use weird versioning like epochs and
-storm and so on to enforce an upgrade path.

I hope there will ultimately be a nice simple command that says 
'Prefer to install packages from helix' which can be placed in
installation instructions and in installation scripts.

Night,
Jason

Postgres removing old database

[Tomas Berndtsson]

Recently, I upgraded from Postgres 6.5.3 (stable Debian) to Postgres
7.0 (unstable). During the installation, it didn't ask me anything,
besides overwriting the config files. Instead it gladly removed all my
databases which were in /var/lib/postgres/data/base/.

Luckily, I had made a dump myself, prior to the upgrade, so there was
no problem getting them back, but it would've been a good idea to have
it dump and restore the databases itself. I can remember an older
upgrade of postgres (6.0 -> 6.5 perhaps?) doing just this, so I wonder
why this didn't.


Tomas

Re: Non-US Incoming

[Michael Sobolev]

On Mon, Aug 21, 2000 at 06:38:38PM +1000, Hamish Moffatt wrote:
> On Sun, Aug 20, 2000 at 07:51:14PM +0400, Michael Sobolev wrote:
> > On Wed, Aug 16, 2000 at 08:54:53AM -0700, Wichert Akkerman wrote:
> > > Previously Michael Sobolev wrote:
> > > > Is it possible to access this for non-developers?
> > > 
> > > No.
> > Hmm..  And what's the reason of that?
> 
> Any reason why you need it?
Yes.  As time to time, I may find a newer version of a given package in
incoming.debian.org, it would be very convenient to have the same possibility
for non-us archive.

--
Misha

Re: Galeon and Debian?

[Peter Pregler]

On Tue, Aug 29, 2000 at 07:24:09PM -0500, Roland Bauerschmidt wrote:
> On Wed, Aug 30, 2000 at 10:41:16AM +1100, Andrew J Cosgriff wrote:
> > You need to set MOZILLA_FIVE_HOME to $HOME/.mozilla
> 
> Thanks! That was it! Now it runs fine.

This was not enough  for me. You also have to start mozilla at least
once to set up $HOME/.mozilla correctly.

-Peter

-- 
Email: [EMAIL PROTECTED]
WWW:   http://www.risc.uni-linz.ac.at/people/ppregler
ICQ:   61011460

Re: Galeon and Debian?

[Per Lundberg]

> "RB" == Roland Bauerschmidt <[EMAIL PROTECTED]> writes:

RB> ** CRITICAL **: file
RB> ../../../../../embedding/browser/gtk/src/gtkmozembed.cpp: line
RB> 298 (void gtk_moz_embed_init(GtkMozEmbed *)): assertion
RB> `retval == TRUE' failed.

FWIW, this is exactly the same error that I got.

Re: potato + updates

[Michael Meskes]

On Tue, Aug 29, 2000 at 06:44:48PM -0800, Ethan Benson wrote:
> > The README on security.debian.org already gives you that line..

Hmm, strange. It seems I missed reading this. 

Thanks.

Michael

-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!

Re: /bin/ksh as a default POSIX shell

[Anton Ivanov]

> Sean 'Shaleh' Perry <[EMAIL PROTECTED]> wrote:
> 
> > On 29-Aug-2000 Miros/law `Jubal' Baran wrote:
> >> 
> >> Isn't /bin/ash POSIX compliant?
> >> 
> 
> > I run ash as my /bin/sh.  As for its compliance, I am not certain and no one
> > will claim it being fullly compliant.
> 
> AFAIK ash is as complaint as bash (in fact at the moment it handles
> functions right while bash doesn't).  If you can come up with any
> violations I'd love to hear from you.

It parses command line -en different from bash. Different getopts ;-)

I envision lots of shell scripts taking a long holiday...


-- 
Anton R. Ivanov ARI2-RIPE
mailto:[EMAIL PROTECTED]
Today's deliverables will have to be delayed because:

NOTICE: alloc: /dev/null: filesystem full




pgpEcHI0a6gml.pgp
Description: PGP signature

Re: Bug#70269: automatic build fails for potato

[Richard Braakman]

On Tue, Aug 29, 2000 at 08:22:16AM +1100, Hamish Moffatt wrote:
> On Mon, Aug 28, 2000 at 06:21:55PM +0300, Antti-Juhani Kaijanaho wrote:
> > I doubt you know what the logic was.
> 
> No, I don't, because I can't see any logic in excluding debhelper.

I don't know how the decision ended up being made, but the argument
I presented at the time is that a dependency on debhelper is far more
likely to be versioned than the others are.  A package that makes use
of a new feature of debhelper is going to have to declare its own
build-depends anyway.

Richard Braakman

Re: /bin/ksh as a default POSIX shell

[Anton Ivanov]

> > Sean 'Shaleh' Perry <[EMAIL PROTECTED]> wrote:
> > 
> > > On 29-Aug-2000 Miros/law `Jubal' Baran wrote:
> > >> 
> > >> Isn't /bin/ash POSIX compliant?
> > >> 
> > 
> > > I run ash as my /bin/sh.  As for its compliance, I am not certain and no 
> > > one
> > > will claim it being fullly compliant.
> > 
> > AFAIK ash is as complaint as bash (in fact at the moment it handles
> > functions right while bash doesn't).  If you can come up with any
> > violations I'd love to hear from you.
> 
> It parses command line -en different from bash. Different getopts ;-)

Sorry meant echo -en there.

> 
> I envision lots of shell scripts taking a long holiday...
> 

The forecast still stands.

[snip]

-- 
Anton R. Ivanov ARI2-RIPE
mailto:[EMAIL PROTECTED]
Today's deliverables will have to be delayed because:

Having to manually track the satellite.




pgp38eEPWznL5.pgp
Description: PGP signature

Re: Free Pine?

[Christian Surchi]

On Tue, Aug 29, 2000 at 05:56:28PM +0300, Juhapekka Tolvanen wrote:

> http://home.sol.no/~egilk/mana.html

I was curious to see it, but I can't download. Ftp server does not allow
anonymous connection...

-- 
Christian Surchi  | [EMAIL PROTECTED] | www.debian.org
[EMAIL PROTECTED] | [EMAIL PROTECTED] | www.firenze.linux.it
--
Never trust an operating system you don't have sources for.

Re: /bin/ksh as a default POSIX shell

[Herbert Xu]

On Wed, Aug 30, 2000 at 10:10:04AM +0100, Anton Ivanov wrote:
> 
> It parses command line -en different from bash. Different getopts ;-)

How does it differ? AFAIK, ash's getopts is POSIX compliant.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: /bin/ksh as a default POSIX shell

[Anton Ivanov]

> On Wed, Aug 30, 2000 at 10:10:04AM +0100, Anton Ivanov wrote:
> > 
> > It parses command line -en different from bash. Different getopts ;-)
> 
> How does it differ? AFAIK, ash's getopts is POSIX compliant.

Sorry, wrote my first message with too high blood level in the caffeine 
subsystem. I meant echo -ne.

Yes, you are correct about getopts, but most linux shell scripts rely 
on gnu 
getopts. Which parses -ne as an equivalent of -n -e.

Example from apache start scripts: echo -ne

[EMAIL PROTECTED]:~$ echo -ne "Reloading $NAME configuration.\n"
Reloading  configuration.
[EMAIL PROTECTED]:~$ ash
[EMAIL PROTECTED]:\w$ echo -ne "Reloading $NAME configuration.\n"
-ne Reloading  configuration.\n
[EMAIL PROTECTED]:\w$

b0rken... 

Non-critical here. 

Can be worse somewhere else. There was a point when the kernel could not be 
built using ash because of that (check linux-kernel last year).

[snip]

-- 
Anton R. Ivanov ARI2-RIPE
mailto:[EMAIL PROTECTED]
Today's deliverables will have to be delayed because:

the printer thinks its a router.




pgpFD1B5BaTu6.pgp
Description: PGP signature

Re: Postgres removing old database

[Oliver Elphick]

Tomas Berndtsson wrote:
  >Recently, I upgraded from Postgres 6.5.3 (stable Debian) to Postgres
  >7.0 (unstable). During the installation, it didn't ask me anything,
  >besides overwriting the config files. Instead it gladly removed all my
  >databases which were in /var/lib/postgres/data/base/.
  
The only known case when the database gets removed is in a purge, and then
only if you say yes when asked.

  >Luckily, I had made a dump myself, prior to the upgrade, so there was
  >no problem getting them back, but it would've been a good idea to have
  >it dump and restore the databases itself. I can remember an older
  >upgrade of postgres (6.0 -> 6.5 perhaps?) doing just this, so I wonder
  >why this didn't.

It should have done; I can't think why it didn't.  If you can repeat
the operation and capture the whole session with script, I might be
able to see what happened.

-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight  http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47  6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
 
 "For what shall it profit a man, if he shall gain the 
  whole world, and lose his own soul?"  Mark 8:36 

Re: /bin/ksh as a default POSIX shell

[Herbert Xu]

On Wed, Aug 30, 2000 at 11:57:17AM +0100, Anton Ivanov wrote:
> 
>   Sorry, wrote my first message with too high blood level in the caffeine 
> subsystem. I meant echo -ne.

Neither SuS nor POSIX specifies -e so ash is free to do whatever it chooses.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: /bin/ksh as a default POSIX shell

[Anton Ivanov]

> On Wed, Aug 30, 2000 at 11:57:17AM +0100, Anton Ivanov wrote:
> > 
> > Sorry, wrote my first message with too high blood level in the caffeine 
> > subsystem. I meant echo -ne.
> 
> Neither SuS nor POSIX specifies -e so ash is free to do whatever it chooses.

If you noted I have not used the word POSIX anywhere. I just said that 
there 
are tons things that will break.

You cannot use it as a default shell without auditing all scripts. 

Also ash does with -e what all other sh clones do. It just parses opts 
differenly so -ne is not equivalent to -n -e.

[snip]

IMHO: 
1. Ash: You cannot use ash as /bin/sh on linux without breaking at 
least some 
things (actually a lot).
2. Ksh: Personally, I have had enough dealing with idiotic  60K programs
written in ksh just because "it is the standard shell supplied on (insert 
commercial *x here)" and you are not supposed to contaminate it with freeware. 
This is not the case for debian. Also, perl is in the base on debian. 
So I 
do not see any particular urge in ksh-ifying things that do not need 
ksh-ifying. It
is said in the declaration of human rights that no-one should be subjected to 
cruel
and unusual punishment. 
Having a clone just because there are people that will not write their
installation in anything else (I Blame M...) is enough. But making it the 
default
shell. No thank you. It will be the same story as bash. One year later most 
scripts
will be rigged with ksh-specifics the way they are now with bash-specifics 
(the echo -ne instead of -n -e for example) ;-)

This of course is just IMHO ;-)

-- 
Anton R. Ivanov ARI2-RIPE
mailto:[EMAIL PROTECTED]
Today's deliverables will have to be delayed because:

Dyslexics retyping hosts file on servers




pgpOsy9XNQsy4.pgp
Description: PGP signature

Re: /bin/ksh as a default POSIX shell

[Herbert Xu]

On Wed, Aug 30, 2000 at 12:31:15PM +0100, Anton Ivanov wrote:
> > 
> > Neither SuS nor POSIX specifies -e so ash is free to do whatever it chooses.
> 
>   If you noted I have not used the word POSIX anywhere. I just said that 
> there 
> are tons things that will break.

And this is Debian where we have a policy that says #!/bin/sh scripts
need to be POSIX compliant.

>   You cannot use it as a default shell without auditing all scripts. 

I use it on all my systems and currently nothing breaks.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Security of Debian SuX0r?

[Juhapekka Tolvanen]

I don't subscribe to these lists, but I am smart enough to use archives
of these mailing-lists in www. And you can Cc: to me, if you want.

 * * *

Have you guys and girls seen this? What do you think about it?

http://www.securityportal.com/closet/

Debian 2.2

Kurt Seifried

"August 30, 2000 - I wanted to write a really positive article about
Debian 2.2, which was just released a few weeks ago.  Unfortunately, I
can't. While Debian itself is a reasonably well-done Linux distribution,
it has some major security issues.

Before you flame me, please read the entire article. I realize there are
a lot of nice things about Debian, but I've also found a lot of
problems. The odd thing is that Debian seems to have gotten the niggly
little details right, but there are major issues they haven't
addressed."

-- 
Juhapekka "naula" Tolvanen * * * U of Jyväskylä * * [EMAIL PROTECTED]
http://www.cc.jyu.fi/~juhtolv/index.html * "STRAIGHT BUT NOT NARROW!"
-
"so impressed with all you do. tried so hard to be like you. flew too
high and burnt the wing. lost my faith in everything" nine inch nails

Re: /bin/ksh as a default POSIX shell

[Anton Ivanov]

> On Wed, Aug 30, 2000 at 12:31:15PM +0100, Anton Ivanov wrote:
> > > 
> > > Neither SuS nor POSIX specifies -e so ash is free to do whatever it 
> > > chooses.
> > 
> > If you noted I have not used the word POSIX anywhere. I just said that 
> > there 
> > are tons things that will break.
> 
> And this is Debian where we have a policy that says #!/bin/sh scripts
> need to be POSIX compliant.

OK. 
If you are right at least apache scripts are not. I suggest you 
file a bug against it.

> 
> > You cannot use it as a default shell without auditing all scripts. 
> 
> I use it on all my systems and currently nothing breaks.

[snip]

Cheers ;-)

-- 
Anton R. Ivanov ARI2-RIPE
mailto:[EMAIL PROTECTED]
Today's deliverables will have to be delayed because:

Neutrino overload on the nameserver




pgpJa5elL1kJQ.pgp
Description: PGP signature

Re: Bug reports by maintainer

[Josip Rodin]

On Tue, Aug 29, 2000 at 07:58:14PM -0300, Nicolás Lichtmaier wrote:
> > I believe the goal is to remove the static pages completely. Only a
> > few more scripts need to be written.
> 
>  And how would that be a good goal? People can mirror static pages, caches
> can cache them...

We don't have a good, fast system that is able to regenerate the static
pages in a timely manner.

-- 
Digital Electronic Being Intended for Assassination and Nullification

Re: XEmacs/GTK 21.1.11

[Juhapekka Tolvanen]

Aaron Lehmann <[EMAIL PROTECTED]>,
that on Tue, 29 Aug 2000, +02:34:41 EEST (UTC +0300)
pressed these keys:

> On Mon, Aug 28, 2000 at 07:34:11PM -0400, James LewisMoss wrote:
> > > On Tue, 29 Aug 2000 00:31:11 +0300, Juhapekka Tolvanen <[EMAIL 
> > > PROTECTED]> said:
> > 
> >  Juhapekka> Who will package this?:
> >  Juhapekka> http://www.cs.indiana.edu/elisp/gui-xemacs/
> > 
> >  Juhapekka> This looks really uebercool.
> > 
> > I was planning on it actually.  If no one else feels the need.
> > (Noticed it on Freshmeat today actually.)
> > 
> 
> I think the author is planning on merging it into the official XEmacs.
> So once this happens we would be able to create xemacs-x, xemacs-gtk,
> etc packages from the same source.

I fear, that it will take so much time, that we must have separately
packaged XEmacs/Gtk meanwhile. And I fear, that latest upstream sources
of XEmacs will ship with too old version of XEmacs/Gtk. Just check out,
how old version of Gnus and Auctex ships with latest XEmacs, if you
don't believe me.

-- 
Juhapekka "naula" Tolvanen * * * U of Jyväskylä * * [EMAIL PROTECTED]
http://www.cc.jyu.fi/~juhtolv/index.html * "STRAIGHT BUT NOT NARROW!" 
-
"so impressed with all you do. tried so hard to be like you. flew too
high and burnt the wing. lost my faith in everything" nine inch nails

Re: (Beware helix packages) Re: [CrackMonkey] The right to bare legs

[Raphael Hertzog]

Le Sat, Aug 26, 2000 at 03:07:03PM -0500, Joseph Carter écrivait:
> Perhaps the existing Gnome maintainers interested could help by working on
> the packages in CVS?  This takes some load off of Peter who is currently
> trying to do the whole Debianization process as well as upstream work
> himself and helps to guarantee that the packages are getting the attention
> of people who (hopefully) have experience dealing with the Debian
> packages and those people could upload the Helix packages to Debian since
> frankly by comparison the Debian packages are usually outdated and buggy.
> 
> Perhaps that is too much of a simple and logical solution.

That's more or less what I asked at the very beginning. Peter said that he
would look at it (ie the possibility of having the debian directory in the
Gnome CVS so that Peter and the actual Debian Gnome maintainer can both
work on the same package). It would be great for everybody, it would ease
the testing of the "development" Gnome since Debian packages would be easy
to build.

But we had no real response so far (I don't know what Peter did try to
setup this). But I'd still love to see this happen.

Cheers,
-- 
Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/
Naviguez sans se fatiguer à chercher : http://www.deenoo.com
Formation Linux et logiciel libre : http://www.logidee.com

Re: Bug reports by maintainer

[Julian Gilbey]

On Wed, Aug 30, 2000 at 02:02:40PM +0200, Josip Rodin wrote:
> On Tue, Aug 29, 2000 at 07:58:14PM -0300, Nicolás Lichtmaier wrote:
> > > I believe the goal is to remove the static pages completely. Only a
> > > few more scripts need to be written.
> > 
> >  And how would that be a good goal? People can mirror static pages, caches
> > can cache them...
> 
> We don't have a good, fast system that is able to regenerate the static
> pages in a timely manner.

What about these new scripts?  How about something like every n hours,
using a Perl script which essentially does:

for every file in /debian/debbugs/db/*.report
  /debian/debbugs/archive/*.status
- if it's new or been changed in the last n hours, run the CGI script
  to regenerate the bug page, and note the package it's in

Finally, regenerate all of the affected packages' pages

To avoid having to figure out which packages have been affected, one
could always make the debbugs scripts note in a log file any package
which has been affected, and then use that file every n hours.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer,  see http://www.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Re: .bashrc (ls --color=auto setting)

[Wichert Akkerman]

Previously Marcus Brinkmann wrote:
> What you mean is actually done by dircolors, which checks the terminal type
> in a rather dump way, using a database, and not verifying termcaps:

Why do you need to run dircolors anyway? I don't and I still get
coloured output..

Wichert.

-- 
   
 / Generally uninteresting signature - ignore at your convenience  \
| [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: .bashrc (ls --color=auto setting)

[Paul Slootman]

On Wed 30 Aug 2000, Wichert Akkerman wrote:
> Previously Marcus Brinkmann wrote:
> > What you mean is actually done by dircolors, which checks the terminal type
> > in a rather dump way, using a database, and not verifying termcaps:
> 
> Why do you need to run dircolors anyway? I don't and I still get
> coloured output..

Then you must have some other arrangement to get the colors;
it's not enabled by default. Try a fresh install (I have).
Maybe a direct setting of LS_COLORS in your .bash_profile or 
whatever?

Paul Slootman
-- 
home:   [EMAIL PROTECTED] http://www.wurtel.demon.nl/
work:   [EMAIL PROTECTED]   http://www.murphy.nl/
debian: [EMAIL PROTECTED]  http://www.debian.org/
isdn4linux: [EMAIL PROTECTED]   http://www.isdn4linux.de/

Re: Bug#70269: automatic build fails for potato

[Julian Gilbey]

On Wed, Aug 30, 2000 at 03:45:06PM +1100, Anand Kumria wrote:
> Not having the helper packages included in the autobuild system appears to
> benefit, at most, around ~470 packages. 

It is not a benefit; it is simply irrelevant to them.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer,  see http://www.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Re: Security of Debian SuX0r?

[Robert van der Meulen]

Hi,

I don't like crossposting to mailinglists, so i post this to debian-devel,
as well as a Cc to the original author.

Quoting Juhapekka Tolvanen ([EMAIL PROTECTED]):
> Have you guys and girls seen this? What do you think about it?
> 
> http://www.securityportal.com/closet/
> 
> Before you flame me, please read the entire article. I realize there are a
> lot of nice things about Debian, but I've also found a lot of problems.
> The odd thing is that Debian seems to have gotten the niggly little
> details right, but there are major issues they haven't addressed."
The main thing i thought (after reading the article) was that you're mostly
right, as far as i know.
The package-signing thing has been bothering me as well.

But.

Your example of rpm's package-signature checking gives an example of a
better idea, but i don't want to think about what happens when the vendor
key is compromised.
If somebody has the key the rpm's are signed with, he/she can create a very
real false sense of security ('the signature's right, so the package is 100%
certain correct and secure, as well'), by applying the signature to
altered/compromised packages.

The lilo-security thing seems a little farfetched to me as well. I didn't
see a comparison with other distributions, and as far as i know, there are
no other distributions that enforce a lilo-password.

Did you check the packages of wich you mentioned there was a security hole
in them (proftpd, apache) ?
A lot of debian packages (and these as well, afaik), are patched to fix
those holes.
Apart from that, Debian offers (fast) updates to vulnerable packages, in the
form of a security.debian.org apt-rule, where fixed/patched versions are
available.

>From your article:
>This portion could be rather long, so I'll cut the list short. Debian has
>shipped more than a few daemons that have severe security problems, many 
>of which were fixed well before Debian 2.2 was released. I find this 
>unacceptable, especially in the light that Debian has not released any
>updates for these packages!

I wonder if you actually checked all these 'more than a few daemons'. By my
knowledge there are no publicly known vulnerabilities in Debian.

Some comments on your summary:

>Debian's goal of a bug free-release hasn't been met. But to be fair, it's
>not like any software vendor will ever release bug-free software. 
>Debian has done a particularly bad job in my opinion, shipping out-of-date 
>software and especially publicly available network daemons that have root
>hacks in them. 

There is no such thing as a bug-free release.
Debian has done a pretty good job in keeping their releases (including the
latest one) secure.
There is no software shipped in the last Debian distribution with the
publicly known root hacks you're talking about.

>If you do go with Debian, you'll have a lot of manual updating ahead of you 
>to bring it up-to-date and secure it.  Unfortunately, the argument "
>apt-get, apt-upgrade" won't work, since many of these updates are not 
>available as dpkg's yet. 
Adding security.debian.org in your apt-rules list works just fine. A lot of
Debian maintainers fix security bugs in their packages, often before they
become publicly known.
An out-of-the-box Debian system will only have the security bugs that have
become publicly known after its release date, and these can be fixed with
the above-mentioned security updates.

>Debian has also ignored a lot of work other vendors have put into making their 
>distributions more secure. If you don't learn from the mistakes and 
>improvements of others, there is little hope. This is especially frustrat
>ing in light of Debian's effort to secure various parts of the distribution,
>using Exim by default instead of Sendmail. 
>Having seen things like that during the install, I had a lot of hope for
>Debian, but my hopes were dashed to pieces upon closer inspection.
Debian is a distribution that _adds_ to the work other vendors do, making
their distributions more secure.
If you actually would would have taken a closer look (wich you obviously
haven't done), you would've seen there's a lot more work being done on the
security of Debian than you're mentioning.
Your article shows some knowledge of security in linux systems, but also a
very badly-informed, no-research, superficial look on Debian security
issues.

Greets,
Robert

-- 
|  [EMAIL PROTECTED] - Cistron Internet Services - www.cistron.nl|  
|  php3/c/perl/html/c++/sed/awk/linux/sql/cgi/security |
| My statements are mine, and not necessarily cistron's.   |
Life is a sexually transmitted disease with 100% mortality.

CGI bug scripts

[Julian Gilbey]

Anthony,

Is it my imagination, or is bugreport.cgi *really* slow?  I think that
we should really investigate the possibility of using mod_perl.  It's
using CGI.pm, which is *big* and takes time to load.  I've written
scripts which I use under mod_perl and the time difference is
astonishing.  It would probably really help if we want to regenerate
static pages as well, and also reduce the load on master when people
do things like:

wget -X Bugs/db/si,Bugs/db/ix -r -l 1 -nv -nH \
  'http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED]'

to download all of their bug reports.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer,  see http://www.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Re: Installed ld.so.preload-manager 0.3.2-2 (source i386)

[Ron Rademaker]

On Mon, 28 Aug 2000, Ben Collins wrote:

> > Changes: 
> >  ld.so.preload-manager (0.3.2-2) unstable; urgency=low
> >  .
> >* Closes:#70398
> 
> I've noticed sort of a trend here lately. Changelog entries are getting
> more and more ambiguous. Can this stop please? 

You won't see anything like this in my packages any more, my sponsor
already said to me that I should add a brief describtion of the bug when I
close it.

Ron

Descriptions and specifics
> in changelogs are never a bad thing. This sort of entry is of little use
> and might as well be removed completely.
> 
> Note, this is just one example I am picking on. It's not the worst.
> 
> Ben
> 
> -- 
>  ---===-=-==-=---==-=--
> /  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
> `  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
>  `---=--===-=-=-=-===-==---=--=---'
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

Re: /bin/ksh as a default POSIX shell

[Ulf Jaenicke-Roessler]

Anton Ivanov wrote:

>   If you are right at least apache scripts are not. I suggest you 
> file a bug against it.

 If you know how to call apache scripts to demonstrate the error then
 please file the bug yourself.

 Check before, if you run an up-to-date apache.
 
 apache starts up correctly for me on every system boot, and I do have
 /bin/sh pointing to /bin/ash as well.

 I don't see any problems with this setup, apart from occasional
 'bashisms', which have to be reported and fixed (see Policy).

> > >   You cannot use it as a default shell without auditing all scripts. 

 This is not correct. The scripts are fairly reliable in not using
 bashisms, cause these had been fixed some time ago.


  Ulf

P.S.: Please can you go without the PGP stuff for the mailing list? It
  seems to double the size of your messages. Thanks.

Strange messages...

[Dale Scheetz]

Since my last upgrade to potato I've been getting a lot of messages like
the following:

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

There doesn't seem to be any real information here. Can anyone tell me
what is triggering these messages?

Thanks,

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

_-_-_-_-_-_- See www.linuxpress.com for more details  _-_-_-_-_-_-_-

Re: Strange messages...

[Robert van der Meulen]

Quoting Dale Scheetz ([EMAIL PROTECTED]):
> Since my last upgrade to potato I've been getting a lot of messages like
> the following:

> There doesn't seem to be any real information here. Can anyone tell me
> what is triggering these messages?

They're postgres debug messages. 
Somehow, the newest postgres packages are emitting debug messages all the
time. I've seen them too, but haven't gotten around to checking where they
come from yet.

Greets,
Robert

-- 
|  [EMAIL PROTECTED] - Cistron Internet Services - www.cistron.nl|  
|  php3/c/perl/html/c++/sed/awk/linux/sql/cgi/security |
| My statements are mine, and not necessarily cistron's.   |
Dance is the vertical expression of a horizontal intention.

Re: Strange messages...

[Jules Bean]

On Wed, Aug 30, 2000 at 04:17:42AM -0400, Dale Scheetz wrote:
> Since my last upgrade to potato I've been getting a lot of messages like
> the following:
> 
> DEBUG:  --Relation pg_rules--
> DEBUG:  Pages 0: Changed 0, Reapped 0, Empty 0, New 0; Tup 0: Vac 0,
> Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 0, MaxLen
> 0; Re-using: Free/Avail. Space 0/0; EndEmpty/Avail. Pages 0/0. Elapsed 0/0

[snip]

> There doesn't seem to be any real information here. Can anyone tell me
> what is triggering these messages?

Well, they're from Postgres, I can tell you that much.

Probably you have one of the debug trace options on in your postgres
config files (in /etc/postgresql).

HTH

Jules

debian 2.2 review at http://www.securityportal.com/closet/

[Paul Slootman]

I've just read your article on debian 2.2.
While you make many valid points, I'm confused about a couple of
them.

Moving on. Once the basic install is done, you will discover
that several services are enabled in inetd that shouldn't
be. Discard, daytime, time, shell, login, and exec (r
services) are all enabled by default

echo, daytime, time were specifically disabled on my installation.

crypt passwords are trivial to brute-force when
compared to MD5ed ones.

I think the operative phrase is "when compared to MD5ed ones".
Besides, you need access to the crypted password to be able to
brute-force it. /etc/shadow isn't readable for mortals.

As an example, the ftp site ftp.win.tue.nl was
cracked into some time ago, and several packages
were replaced with Trojaned versions.  TCP_WRAPPERS
was compromised, among other things. Over 50 people
downloaded these packages before someone noticed
they were not properly signed with PGP, and raised
the alarm. 

Doesn't this in fact indicate that signed packages aren't that useful,
as people don't check them anyway?

You'd think that now that 2.2 is out the door,
Debian could focus a lot of activity on fixing it.

Actually, the intention is to get 2.3 out of the door now.  Unlike
some vendors, debian tries to release _after_ problems are resolved,
not "release first, patch later".  The freeze period, during which the
system is tested and all serious bugs (as far as they are detected)
are fixed, was a couple of months long. During this time no new
packages are allowed in, which explains for example why apache is
1.3.9.  Anyway, had you taken the time to do some investigation, you
would have seen the following in the debian changelog for apache:

  * [RC, security] Backported security fix for Cross Site Scripting issue
(CERT Advisory CA-2000-02) from apache 1.3.11 patch.

This was done  Sun, 16 Apr 2000. I haven't checked others, I expect that
you will find that there too fixes have been backported. Please update
your review to reflect any such findings.

It would have been much more useful to have done your review during
the freeze period, when these reports can make a difference. The
freeze period is a time where debian encourages people like yourself
to test the system and submit bug reports where necessary. I hope that
when debian 2.3 is frozen you will take the time to do another
thorough review _before_ it is released.

Regards,
Paul Slootman <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: (Beware helix packages) Re: [CrackMonkey] The right to bare legs

[Peter Teichman]

On Tue, Aug 29, 2000 at 10:02:04PM -0500, Branden Robinson wrote:
> > No, there is no difference between our apps and the upstream in most
> > cases. We do brand gnome-core and gdm, but those are the only packages
> > I can think of offhand. Those are only graphics changes, substituting
> > some of our images in place of the defaults.
> 
> Okay, fine.  Name the Helixified packages under the following scheme:
> 
> Package: helix-gnome-core
> Conflicts: gnome-core
> Provides: gnome-core
> 
> Package: helix-gdm
> Conflicts: gdm
> Provides: gdm
> 
> (The Provides: gdm isn't necessary if nothing depends on it, and off the
> top of my head I can't think of anything that would depend on a display
> manager.)

The task-helix-core package I provide depends on gdm. That's the only
one I can think of offhand, though, and I would want to depend on
helix-gdm there.

This solution looks like the best one. I'll start rebuilding our
packages immediately.

> > We are only collecting existing apps in an easily installed and
> > updated set. We have never claimed to do anything else.
> 
> Then why not just ship the Debian versions?  Or, if you making
> non-Helixified changes and bugfixes, why not submit them back to Debian?

The reason why we aren't shipping the Debian versions is that the
current binary packages are guaranteed to work on both potato and
woody, so I have to provide all the dependencies in our packages.

This is very broken. Fixing this is going to be part of the grand
rebuild for helix-* packages.

Peter

Re: Strange messages...

[Ashley Clark]

* Dale Scheetz in "Strange messages..." dated 2000/08/30 04:17 wrote:

> Since my last upgrade to potato I've been getting a lot of messages
> like the following:
> 
> DEBUG:  --Relation pg_rules--
> DEBUG:  Pages 0: Changed 0, Reapped 0, Empty 0, New 0; Tup 0: Vac 0,
> Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 0, MaxLen
> 0; Re-using: Free/Avail. Space 0/0; EndEmpty/Avail. Pages 0/0. Elapsed 0/0
> sec.

[snip]

> There doesn't seem to be any real information here. Can anyone tell
> me what is triggering these messages?

They are courtesy of PostgreSQL, the behaviour of the config file has
changed between two of the versions. You can add PGDEBUG=0 to your
/etc/postgresql/postmaster.init file and they will disappear.

-- 
hackers ally


pgpnMLidb4d2b.pgp
Description: PGP signature

Re: (Beware helix packages) Re: [CrackMonkey] The right to bare legs

[Peter Teichman]

On Wed, Aug 30, 2000 at 01:20:48AM -0600, Jason Gunthorpe wrote:
> 
> On Wed, 30 Aug 2000, Branden Robinson wrote:
> 
> > > That is one mechanism of creating a private namespace, isn't another 
> > > Setting the origin to something other than Debian?
> > 
> > Please see elsewhere in this thread for my other remarks on this subject.
> > 
> > An Origin field is a great idea.
> 
> We have one, sorry I am so late making it be really useful - very busy you
> know.. 
> 
> Assuming I can manage to get in the proper frame of mind this problem
> should become much less troubling for most APT users.
> 
> The versioning scheme I will suggest is fairly direct:

[ versioning scheme removed ]

This looks good to me. I will start obeying these standards in the
Helix GNOME packages.

Peter

Re: .bashrc (ls --color=auto setting)

[Nils Rennebarth]

On Wed, Aug 30, 2000 at 02:31:26PM +0200, Paul Slootman wrote:
> > Why do you need to run dircolors anyway? I don't and I still get
> > coloured output..
> Then you must have some other arrangement to get the colors;
> it's not enabled by default. Try a fresh install (I have).
> Maybe a direct setting of LS_COLORS in your .bash_profile or 
> whatever?
Setting LS_COLORS only affects the colors that certain files get, based on
their suffix or file type (directory, block device, etc).
Unsetting LS_COLORS gives you the default coloring.

Coloring or not only depends on the options you give to ls. There are
however aliases suggested by .bashrc (initally commented out) and
environment variable settings that do:

LS_OPTIONS=--color=auto
alias ls='ls $LS_OPTIONS'

--color=auto tells ls to use color iff output is a tty. ls never looks at
the terminal type.

Basically: yes, ls could be improved. It uses hardcoded escape sequences.

Nils

-- 
Quotes from the net, featuring John Lapeyre[L] and Christopher F. Miller [M]:
M> I'm not sure what the right words are to describe Upside.  Last month they
M> mentioned the sendmail **web server** as an example of the failure of the
M> open source process
L> Well, sendmail does a lousy job of serving webpages.


pgpgOOFVvWm7m.pgp
Description: PGP signature

Re: /bin/ksh as a default POSIX shell

[Anton Ivanov]

> Anton Ivanov wrote:
> 
> > If you are right at least apache scripts are not. I suggest you 
> > file a bug against it.
> 
>  If you know how to call apache scripts to demonstrate the error then
>  please file the bug yourself.
> 
>  Check before, if you run an up-to-date apache.

I do

>  
>  apache starts up correctly for me on every system boot, and I do have
>  /bin/sh pointing to /bin/ash as well.

My fault. It actually uses #!/bin/bash which it should not anyway

> 
>  I don't see any problems with this setup, apart from occasional
>  'bashisms', which have to be reported and fixed (see Policy).

It is a bashism. 100% one. See above.

> 
> > > > You cannot use it as a default shell without auditing all 
> > > > scripts. 
> 
>  This is not correct. The scripts are fairly reliable in not using
>  bashisms, cause these had been fixed some time ago.

OK. 

> 
> 
>   Ulf
> 
> P.S.: Please can you go without the PGP stuff for the mailing list? It
>   seems to double the size of your messages. Thanks.

Bad habits. 

> 
> 

-- 
Anton R. Ivanov ARI2-RIPE
mailto:[EMAIL PROTECTED]
Today's deliverables will have to be delayed because:

We are currently trying a new concept of using a live mouse.  Unfortuantely, 
one has yet to survive being hooked up to the computer.please bear with us.

APT problem

[Michael Meskes]

I just tried to upgrade my Corel installation via the net and have some
strange behaviour when using apt:

feivel:~# dpkg -l libc6¸
Desired=Unknown/Install/Remove/Purge
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ NameVersionDescription
+++-===-==-
ii  libc6   2.1.3-10   GNU C Library: Shared libraries and Timezone
feivel:~# dpkg --print-avail libc6
Package: libc6
[...]
Version: 2.1.3-10
[...]
feivel:~# apt-get upgrade
[...]
Get:1 ftp://ftp.corel.com corellinux-1.2/corel_updates libc6 2.1.3-10 [1904kB]
[...]

Could anyone please explain this to me? Did Corel do anything to their files
that makes apt think it has to upgrade although its up-to-date? Or is this
a bug in apt?

Michael
-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!

Re: /bin/ksh as a default POSIX shell

[Ulf Jaenicke-Roessler]

Anton Ivanov wrote:

> >  apache starts up correctly for me on every system boot, and I do have
> >  /bin/sh pointing to /bin/ash as well.
> 
> My fault. It actually uses #!/bin/bash which it should not anyway

 Well, #!/bin/bash scripts are allowed to use bashisms :)

  Ulf

Re: (Beware helix packages) Re: [CrackMonkey] The right to bare legs

[Christian Marillat]

 "PT" == Peter Teichman <[EMAIL PROTECTED]> writes:

[...]

PT> This solution looks like the best one. I'll start rebuilding our
PT> packages immediately.

Don't forget to put this field in debian/control:

Send-To: [EMAIL PROTECTED]

Christian

Re: Free Pine?

[Chris Allegretta]

On Wed, Aug 30, 2000 at 12:03:44PM +0200, Christian Surchi wrote:
> On Tue, Aug 29, 2000 at 05:56:28PM +0300, Juhapekka Tolvanen wrote:
> 
> > http://home.sol.no/~egilk/mana.html
> 
> I was curious to see it, but I can't download. Ftp server does not allow
> anonymous connection...

I found a copy at ftp://ftp.kvaleberg.com/pub/mana-4.0beta.tar.gz, I
guess it's a mirror.  A whole lot of warnings when trying to compile it,
but it looks interesting.

Chris A
-- 
Chris Allegrettahttp://www.asty.org

"I can't be calm, no no no no no no.  I'm the MASTER of the MECHANICAL
*STUFF*!  And I have to HELP YOU!" - Artemis Gordon, Wild Wild West

dpkg-scanpackages arguments, output Packages files, and apt

[Eray Ozkural]

I was running dpkg-scanpackages to construct a custom apt source.
This was the first time I really ran it, so I encountered the
peculiar style that I had to conform to.

This was what I had to write to make a Packages file in a flat dir:
[EMAIL PROTECTED]:~/public_html/debian$ dpkg-scanpackages . override ./  
>Packages


This is a line from the output Packages file:
Filename: ././ddclient_2.3.1-1_all.deb


And this is the line required to indicate it as an apt source
deb http://borg/~exa/debian/ ./


IMHO, this is all wrong. In the first one, the clumsy ./ is redundant,
working directory can, and _should_, be assumed for the third argument.
In the second, the output is redundant, it should simply be 
ddclient_2.3.1-1_all.deb
and in the third one, the ./ is redundant, it should be regarded as default.

And I was amazed at the fact that you need to provide both Packages and
Packages.gz for some strange reason. I think apt-get should check if
there is a Packages.gz, and if it isn't present fallback to Packages 

For which of these should I file bugs? Please don't tell me that
these are the way they should be, they are obviously counter-intuitive
and must be fixed. It shouldn't be difficult for the authors of apt, anyway.


Thanks,

-- 
 -+++-+++-++-++-++--+---++- ---  --  -  - 
 +  Eray "exa" Ozkural   .  .   .  . . .
 +  CS, Bilkent University, Ankara ^  .  o   .  .
 |  mail: [EMAIL PROTECTED].  ^  .   .

Re: Free Pine?

[Martin Jenssen]

* Chris Allegretta

| I found a copy at ftp://ftp.kvaleberg.com/pub/mana-4.0beta.tar.gz, I
| guess it's a mirror.  A whole lot of warnings when trying to compile it,
| but it looks interesting.

Actually, I think it's the official site.  The official homepage for
Mana is:

http://www.kvaleberg.com/mana.html


Martin



pgprFd0jdWcnY.pgp
Description: PGP signature

apt source for sather and ddclient

[Eray Ozkural]

You may use the following apt source for my ddclient deb and
the sather debs that I've fixed for woody.

deb http://139.179.21.143/~exa/debian/ ./


Please see ITPs on wnpp and on this list for information on these
packages.

Thanks,

__
 -+++-+++-++-++-++--+---++- ---  --  -  - 
 +  Eray "exa" Ozkural   .  .   .  . . .
 +  CS, Bilkent University, Ankara ^  .  o   .  .
 |  mail: [EMAIL PROTECTED].  ^  .   .

Re: CGI bug scripts

[Julian Gilbey]

On Wed, Aug 30, 2000 at 01:53:46PM +0100, Julian Gilbey wrote:
> Anthony,
> 
> Is it my imagination, or is bugreport.cgi *really* slow?  I think that
> we should really investigate the possibility of using mod_perl.  It's
> using CGI.pm, which is *big* and takes time to load.  I've written
> scripts which I use under mod_perl and the time difference is
> astonishing.  It would probably really help if we want to regenerate
> [...]

I just looked at the load on master (=bugs.debian.org).  It's
averaging around 8 or 9, and running top, I saw times when there were
about 10 copies of {bug,pkg}report.cgi running simultaneously.  I
think that if the BTS is moving to dynamically generated pages only,
mod_perl is going to be a necessity.

I don't have much time right now, but I'd be happy to help when I do
(in October, most likely).

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer,  see http://www.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Crazy idea: removing version numbers from debian

[Thomas Guettler]

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

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

A Debian package is either unstable, (testing) or stable.
And everybody should use the package that fits his needs.

Debian is evolving constantly, not in single steps.

I don't know anything about the internals of
"apt-get upgrade", maybe I should. 

But I am interested
what you think about this crazy idea to remove
version numbers (like debian2.2) from debian?


-- 
Thomas Guettler
Office:  www.interface-business.de
Private:  http://yi.org/guettli
(Replace _NoSpam_ with @)

ANNOUNCE: First official release of "apt-show-source"

[Dennis Schoen]

ANNOUNCE: First official release of "apt-show-source"

What is it?

 It's a perl script that parses the dpkg status file and that APT
 list files that end with Sources, without any options it prints out all
 installed packages and versions were a different version is available
 through your sources-list. The generated output looks like:

 Inst. Package= Version | Source Package  = Version
 --
 mtools   = 3.9.6-3.1   | mtools  = 3.9.7+2821
 sharutils= 1:4.2.1-1   | sharutils   = 1:4.2.1-2
 netbase  = 3.18-4  | netbase = 4.03
 ...


For what do I need it?

 It's very handy when in your sources-list the "deb" entries point
 to stable and only the "deb-src" entries point to unstable. Until now i never
 found a good way to check if a newer version of package XXX is available
 through my source-entries.
 Now I can run:

 [EMAIL PROTECTED]:~ $ apt-show-source --package=console-tools

 Inst. Package= Version | Source Package  = Version
 --
 console-tools= 1:0.2.3-10.3| console-tools   = 1:0.2.3-14


Where can i get it?

 Currently it's available at http://www.debian.org/~dennis/apt-show-source/
 or via apt-get with this sources-list entries:

 # apt-show-source
 deb http://www.debian.org/~dennis apt-show-source/
 deb-src http://www.debian.org/~dennis apt-show-source/


Notice that I will only upload it to the Distribution if there's
some feedback that it is used by someone.
I don't see any sense of uploading when i'm the only user.

Comments are very welcome.

Dennis
-- 
| Dennis Schoen   | "Contrary to popular belief,
| [EMAIL PROTECTED]   |  UNIX is a user-friendly Operating
| http://www.gt.owl.de/~dschoen/  |  System. It's just choosy about
| +49-5207-923701 |  who its friends are."


pgpa33DdG65UB.pgp
Description: PGP signature

ITP: bbppp -- A blackbox ppp tool

[Timshel Knoll]

Package: wnpp
Version: N/A; reported 2000-08-31
Severity: normal

Source: bbppp
Section: x11
Priority: optional
Maintainer: Timshel Knoll <[EMAIL PROTECTED]>
Build-Depends: debhelper (>= 1.2.9), xlib6g-dev, libstdc++-dev, g++
Standards-Version: 3.1.1

Package: bbppp
Architecture: any
Depends: ${shlibs:Depends}
Description: PPP tool for the blackbox window manager
 bbppp is a blackbox tool to control your PPP link. It can
 start up /shut down your ppp connection (by running
 pon/poff), and displays a modem-lights style PPP load.


-- System Information
Debian Release: woody
Architecture: i386
Kernel: Linux pippin 2.2.16 #1 Sun Aug 27 18:05:30 EST 2000 i586

-- 
   Timshel Knoll <[EMAIL PROTECTED]>  for Debian email: <[EMAIL PROTECTED]>
Second year Computer Science, RMIT   |   CS108 Tutor (Semester 2, 2000)
Debian GNU/Linux developer, see http://www.debian.org/~timshel/
   For GnuPG public key: finger [EMAIL PROTECTED] or [EMAIL PROTECTED]


pgpDG5DYK07QR.pgp
Description: PGP signature

ITP: bbdate -- A blackbox date tool

[Timshel Knoll]

Package: wnpp
Version: N/A; reported 2000-08-31
Severity: normal

Source: bbdate
Section: x11
Priority: optional
Maintainer: Timshel Knoll <[EMAIL PROTECTED]>
Build-Depends: debhelper (>= 1.2.9), xlib6g-dev, libstdc++-dev, g++
Standards-Version: 3.1.1

Package: bbdate
Architecture: any
Depends: ${shlibs:Depends}
Description: Date tool for the blackbox window manager
 bbdate is a simple blackbox tool for displaying the date
 in your blackbox slit.


-- System Information
Debian Release: woody
Architecture: i386
Kernel: Linux pippin 2.2.16 #1 Sun Aug 27 18:05:30 EST 2000 i586

-- 
   Timshel Knoll <[EMAIL PROTECTED]>  for Debian email: <[EMAIL PROTECTED]>
Second year Computer Science, RMIT   |   CS108 Tutor (Semester 2, 2000)
Debian GNU/Linux developer, see http://www.debian.org/~timshel/
   For GnuPG public key: finger [EMAIL PROTECTED] or [EMAIL PROTECTED]


pgptReMQ4R7ZI.pgp
Description: PGP signature

ITP: bbsload -- A blackbox system load tool

[Timshel Knoll]

Package: wnpp
Version: N/A; reported 2000-08-31
Severity: normal

Source: bbdate
Section: x11
Priority: optional
Maintainer: Timshel Knoll <[EMAIL PROTECTED]>
Build-Depends: debhelper (>= 1.2.9), xlib6g-dev, libstdc++-dev, g++
Standards-Version: 3.1.1

Package: bbdate
Architecture: any
Depends: ${shlibs:Depends}
Description: System load tool for the blackbox window manager
 bbsload is a blackbox tool to display your system load. It
 can show simple system bar graphs, including load averages
 for 1, 5 and 15 minute periods, memory usage, swap usage,
 total system usage, as well as CPU loads for user, nice
 and system processes and idle time.


-- System Information
Debian Release: woody
Architecture: i386
Kernel: Linux pippin 2.2.16 #1 Sun Aug 27 18:05:30 EST 2000 i586

-- 
   Timshel Knoll <[EMAIL PROTECTED]>  for Debian email: <[EMAIL PROTECTED]>
Second year Computer Science, RMIT   |   CS108 Tutor (Semester 2, 2000)
Debian GNU/Linux developer, see http://www.debian.org/~timshel/
   For GnuPG public key: finger [EMAIL PROTECTED] or [EMAIL PROTECTED]


pgpaWpfRtQyXK.pgp
Description: PGP signature

ITP: bbtime -- A blackbox time tool

[Timshel Knoll]

Package: wnpp
Version: N/A; reported 2000-08-31
Severity: normal

Source: bbdate
Section: unknown
Priority: optional
Maintainer: Timshel Knoll <[EMAIL PROTECTED]>
Build-Depends: debhelper (>= 1.2.9), xlib6g-dev, libstdc++-dev, g++
Standards-Version: 3.1.1

Package: bbdate
Architecture: any
Depends: ${shlibs:Depends}
Description: Time tool for the blackbox window manager
 bbppp is a blackbox tool to control your PPP link. It can
 start up /shut down your ppp connection (by running
 pon/poff), and displays a modem-lights style PPP load.


-- System Information
Debian Release: woody
Architecture: i386
Kernel: Linux pippin 2.2.16 #1 Sun Aug 27 18:05:30 EST 2000 i586

-- 
   Timshel Knoll <[EMAIL PROTECTED]>  for Debian email: <[EMAIL PROTECTED]>
Second year Computer Science, RMIT   |   CS108 Tutor (Semester 2, 2000)
Debian GNU/Linux developer, see http://www.debian.org/~timshel/
   For GnuPG public key: finger [EMAIL PROTECTED] or [EMAIL PROTECTED]


pgpF4FdgqatBC.pgp
Description: PGP signature

Re: MANA - Free Pine? yet another dead mailer/newsreader?

[Sven Guckes]

* Jimmy O'Regan <[EMAIL PROTECTED]> [000829 22:40]:
> ) But are there any features that
> ) mutt and slrn do not offer yet?
> How about "it's pine" ;)

No further questions.  ;-)

> Problem is though, the discussion about the IMAPD license
> started with rms mentioning that the FSF had tried to
> resurrect pine 3.91, and were threatened with a lawsuit by UW,
> who interpret the X type license pine 3.91 was under as being
> the same as the current pine license (he wanted someone to
> check if they assumed the same with X type license on IMAPD).

Sheesh.  "Death of Pine predicted.  [EMAIL PROTECTED]"

Just to end the crosspoting between
individuals and mailing lists:
  Followup-To: comp.mail.misc ?

Sven

Re: Crazy idea: removing version numbers from debian

[Bernd Eckenfels]

On Wed, Aug 30, 2000 at 05:05:58PM +0200, Thomas Guettler wrote:
> But I am interested
> what you think about this crazy idea to remove
> version numbers (like debian2.2) from debian?

How do u call slink? "Old Stable"? :)

No i think it is not a bad idea to have a version number. The only question
is if the Version number should cover the whole distribution (including
contrib, non-free, non-US,...) or only the base section (like with FreeBSD).

But since we do not have yet another distribution schema, I think our
current practice ov giving version and release numbers is the best. This is
especially for CD Manucatureres and Security Admin important. It is also
important if you want to talk about events in the past.

Greetings
Bernd

Re: APT problem

[Bernd Eckenfels]

On Wed, Aug 30, 2000 at 03:49:27PM -0700, Michael Meskes wrote:
> Could anyone please explain this to me? Did Corel do anything to their files
> that makes apt think it has to upgrade although its up-to-date? Or is this
> a bug in apt?

I see this quite often, so it is a bug in the curret apt lib. aptitude is
even more vulnerable to this... at least the cache does work so u d/l it
only once.

Greetings
Bernd

Re: (Beware helix packages) Re: [CrackMonkey] The right to bare legs

[Peter Teichman]

On Wed, Aug 30, 2000 at 03:50:08PM +0200, Christian Marillat wrote:
>  "PT" == Peter Teichman <[EMAIL PROTECTED]> writes:
> 
> [...]
> 
> PT> This solution looks like the best one. I'll start rebuilding our
> PT> packages immediately.
> 
> Don't forget to put this field in debian/control:
> 
> Send-To: [EMAIL PROTECTED]

Oh, thanks for reminding me.

I just got this added to our build system.. I still have to rebuild
everything to take advantage of it though.

Peter

Re: CGI bug scripts

[James A. Treacy]

On Wed, Aug 30, 2000 at 03:43:29PM +0100, Julian Gilbey wrote:
> On Wed, Aug 30, 2000 at 01:53:46PM +0100, Julian Gilbey wrote:
> > Anthony,
> > 
> > Is it my imagination, or is bugreport.cgi *really* slow?  I think that
> > we should really investigate the possibility of using mod_perl.  It's
> > using CGI.pm, which is *big* and takes time to load.  I've written
> > scripts which I use under mod_perl and the time difference is
> > astonishing.  It would probably really help if we want to regenerate
> > [...]
> 
> I just looked at the load on master (=bugs.debian.org).  It's
> averaging around 8 or 9, and running top, I saw times when there were
> about 10 copies of {bug,pkg}report.cgi running simultaneously.  I
> think that if the BTS is moving to dynamically generated pages only,
> mod_perl is going to be a necessity.
> 
> I don't have much time right now, but I'd be happy to help when I do
> (in October, most likely).
> 
>Julian
> 
It's easy to set up. I'll do it after the scripts have stabilized.

-- 
James (Jay) Treacy
[EMAIL PROTECTED]

Re: Bug#70269: automatic build fails for potato

[Steve Greenland]

On 29-Aug-00, 16:05 (CDT), Buddha Buck <[EMAIL PROTECTED]> wrote: 
> Would it make sense to make policy something like "All official Debian 
> auto-build machines will have installed this set of build packages: gcc, 
> ..., and debhelper.  Debian packages are not required to specify build 
> dependencies on these packages."

That's pretty much the definition (or at least the *use*) of
Build-Essential: packages that may be assumed to be present, so that
they need not be listed in Build-Depends.

Repeating myself: listing a tool as build-essential does not mean that
packages are required to use it, just that packages my assume that the
tool is present.

Steve

-- 
Steve Greenland <[EMAIL PROTECTED]>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)

Re: Bug#70269: automatic build fails for potato

[Steve Greenland]

On 30-Aug-00, 04:21 (CDT), Richard Braakman <[EMAIL PROTECTED]> wrote: 
> 
> I don't know how the decision ended up being made, but the argument
> I presented at the time is that a dependency on debhelper is far more
> likely to be versioned than the others are.  A package that makes use
> of a new feature of debhelper is going to have to declare its own
> build-depends anyway.

It is not unreasonable to assume that the latest-and-greatest version of
all the build-essential packages will be installed. If one is concerned
about back-building (e.g. a woody package on a slink machine), then you
need to worry about compiler and libc versions as well, so you might as
well build everything.

Steve

-- 
Steve Greenland <[EMAIL PROTECTED]>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)

Re: Strange messages...

[Dale Scheetz]

On Wed, 30 Aug 2000, Jules Bean wrote:

> Well, they're from Postgres, I can tell you that much.

OK...
> 
> Probably you have one of the debug trace options on in your postgres
> config files (in /etc/postgresql).

"I have"? ;-)

I looked in /etc/postgresql and found several files, none of which set any
debug options.

 pg_hba.conf 
  Mostly comments except for a two line declaration that
  local host is trusted.

 pg_ident.conf
  Completely comments

 postgresql.env
  Incorporates postmaster.init into script and then assigns
  and exports several paths, two of which do not exist on my
  machine.

 postmaster.init
  Asside from a small block of code that determines POSTGRES_HOME
  and a line setting PGDATESTYLE to ISO, this file is all
  comments as well.

So it looks like this is somehow "hard coded" in the binary?

I guess I could just remove the package ... I installed it for educational
purposes, and then never got to class ;-)

Thanks,

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

_-_-_-_-_-_- See www.linuxpress.com for more details  _-_-_-_-_-_-_-

Re: ANNOUNCE: First official release of "apt-show-source"

[Jim Lynch]

Hi,

If you were to augment apt-show-source in the following ways, I can see
it becoming a household word :)

I think for people inside debian who "never gets out", this package can
be useful, because then they can see what upstream source pkg to get if
they decide to poke outside. 

However, I don't see much use for others, so I make these suggestions:

I occasionally get a list of everything on metalab, so I can see what
new stuff is out there, or review things I have used in the past to 
see if they've grown or were otherwise upgraded. 

What would also be useful to me, is if I could take the name of an
upstream source package such as might be found on metalab and get the
name of any package that uses pieces of it. For example, if I feed
x3c.tar.gz, I expect to get a list of the X package names. You might
have to parse the copyright file which gets installed in the doc dir,
in a dir named after the package.

If you end up parsing the copyright file, then it might also be nice
if people can get "where the upstream source is" from a debian package
name.

Sometimes, I think that because many debian developers can choose to
name packages differently from the name of the upstream source tarball,
that effectively isolates debian from the outside, and makes it harder
to find out where to get things from outside. Lately, I get rumblings
that some developers are not using unmodified source for the "orig.tar.gz"
part of the upload, an action that completely breaks outside connections.
It means I cannot effortlessly find out where upstream sources are or
even what their names are. (sorry, I don't have examples off the top
of my head, if there is interest, I will pursue this.)

The augmentations I have outlined above would at least let me know
where I can get things upstream. Also, if I want to find out if a
particular source tree available upstream has already been packaged
for debian, I can find that out also. This would help me. It can
also help someone new to debian but experienced with linux outside
of debian.

-Jim

---
Jim Lynch   Finger for pgp key
as Laney College CIS admin:  [EMAIL PROTECTED]   http://www.laney.edu/~jim/
as Debian developer: [EMAIL PROTECTED]  http://www.debian.org/~jwl/

Re: (Beware helix packages) Re: [CrackMonkey] The right to bare legs

[Wichert Akkerman]

Previously Christian Marillat wrote:
> Don't forget to put this field in debian/control:
> Send-To: [EMAIL PROTECTED]

Where did that come from That won't do anything at all and will make
dpkg-gencontrol complain loudly at you.

Wichert.

-- 
   
 / Generally uninteresting signature - ignore at your convenience  \
| [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: Crazy idea: removing version numbers from debian

[Vincent L. Mulhollon]

> A Debian package is either unstable, (testing) or stable.
> And everybody should use the package that fits his needs.
> 
> Debian is evolving constantly, not in single steps.
> 
> But I am interested
> what you think about this crazy idea to remove
> version numbers (like debian2.2) from debian?
> 

I had a similar thought this weekend.

Perhaps any package can live in unstable, but any package that has a
release critical bug older than 1 week is zapped from stable and placed back
in unstable.  Upon next package upload, it will be reinstated into stable.

New packages would not be allowed into stable until x days had passed in
unstable status without a Release Critical Bug.

Or perhaps any package can live in unstable, and every package has a copy of
itself in unstable, but on the last day of the month it is kicked out of
stable if it has an open RCB.  If you are picky about RCBs, only apt-get
stable on the first of the month.  If you need a buggy package anyway, get
it out of unstable.

Or perhaps any package lives in unstable, and instead of kicking packages
out of stable if it has a RCB, the BTS would interact such that the author
or "someone trusted" can specify the newest "old" version that does not have
the bug.

There are events like libc upgrades where pretty much everything needs to be
recompiled.  This issue must be dealt with.

In theory this would complicate support because there would be so many
"versions" of debian, yet developers survive with "daily" versions...

Finally the idea I like the best is no numbers, only named updates.

And we'd have a goal for the name.  Like the goal for "whiskey" release
would be every package that needs it supports debconf, or the goal for
"vodka" is every package supports kernel 2.4 and IPv6, or the goal for
"scotch" is every package supports perl 5.6 or whatever.

Rfp: galeon

[Daniele Cruciani]

Hi,

I've read on this list about ITP of galeon (web browser), but
i don't remenber who announce ITP and I can't find that package on
experimental.



thank you.

-- 
Daniele Cruciani <[EMAIL PROTECTED]>
Universita` di Pisa - Informatica -
http://www.cli.di.unipi.it/~cruciani/

Re: Strange messages...

[Dale Scheetz]

On Wed, 30 Aug 2000, Ashley Clark wrote:

> They are courtesy of PostgreSQL, the behaviour of the config file has
> changed between two of the versions. You can add PGDEBUG=0 to your
> /etc/postgresql/postmaster.init file and they will disappear.
> 
Cool!

Thanks,

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

_-_-_-_-_-_- See www.linuxpress.com for more details  _-_-_-_-_-_-_-

Re: (Beware helix packages) Re: [CrackMonkey] The right to bare legs

[Peter Teichman]

On Wed, Aug 30, 2000 at 01:20:48AM -0600, Jason Gunthorpe wrote:
>   3) Libraries - All possible effort should be made to make Debian the
>  primary source of libraries. Period full stop. This is so important
>  because of what we are seeing with helix and their special library 
>  packages now. Thus, I suggest the following:

I agree with this completely.

>a) If a add-on vendor needs a newer upstream library then they
>   can follow standard NMU procedures, using a -0.1.helix type tag.
>b) If their is some critical bug in the Debian library then they
>   should still follow NMU type procedures and work with the
>   Debian library packager and upstream to make sure the next rev
>   is properly fixed.
>c) I recommend the vendor provide a seperate section of their
>   FTP site specifically for libraries, and tagged with a proper
>   Release file. The libraries they collect there should be the
>   libraries they use and have modified. It would be best if most
>   of these files were exactly identical to what Debian ships.
>   Rational: 
>  i) I expect people like helix will include woody
> libraries that work on a potato system. These can use the
> 'usual' 1.2-0.1.woody.1 tagging scheme and probably will not
> be included by Debian.

Our potato packages are going to move on to their own directory, so we
won't be trying to make packages work on both woody and potato. That
will resolve my having to put most library packages in with our woody
stuff.

As far as I can tell, the Helix GNOME support for woody is only going
to be about five packages.

> ii) I want the user to be able to say 'I want only helix gnome 
> but pick the newest library from the union of
> debian+helix'. This is easiest if the libraries are
> seperated.
>iii) Libraries are truely a shared resource, we need to take
> special steps to ensure apps in Debian linked to them work
> and apps in Helix linked to them work - best way to that
> is to only have 1 library package that everyone uses and
> tests against.

I have one question. What is the preferred way for me to handle our
gtk package? This is a library package that we actually apply some
patches to for a slightly nicer user interface.

Peter

Re: Bug#70269: automatic build fails for potato

[Antti-Juhani Kaijanaho]

On 2830T112651-0500, Steve Greenland wrote:
> On 29-Aug-00, 16:05 (CDT), Buddha Buck <[EMAIL PROTECTED]> wrote: 
> > Would it make sense to make policy something like "All official Debian 
> > auto-build machines will have installed this set of build packages: gcc, 
> > ..., and debhelper.  Debian packages are not required to specify build 
> > dependencies on these packages."
> 
> That's pretty much the definition (or at least the *use*) of
> Build-Essential: packages that may be assumed to be present, so that
> they need not be listed in Build-Depends.

It's not the definition.  One of the explicit design goals for the current
setup was that policy should not need to mention specific packages.

The definition is the following:

 It is not be necessary to explicitly specify build-time relationships
 on a minimal set of packages that are always needed to compile, link
 and put in a Debian package a standard "Hello World!"  program written
 in C or C++.  The required packages are called _build-essential_, and
 an informational list can be found in
 `/usr/share/doc/build-essential/list' (which is contained in the
 `build-essential' package).

(Debian Policy v. 3.2.1.0, section 2.4.2.)

-- 
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%

   Hypertekstivisionääri Ted Nelson luennoi Jyväskylässä 29.-31.8.
   Lisätietoja saa minulta.

Re: RFP: galeon

[Roland Bauerschmidt]

On Tue, Aug 29, 2000 at 08:30:39PM -0500, Roland Bauerschmidt wrote:
> Package: wnpp
> Severity: wishlist

Sorry, /me is a fool. I should have looked in the bug database before
reporting this. :-/ Nevertheless I've made a galeon package which should
work ok. You can find them under http://www.debian.org/~rb/galeon/ .
Unfortunately I don't think I have enough time to maintain it at the
moment. So I would be pleased if somebody else would volunteer to
maintain it. As I said before I'd be happy to sponsor uploads for it.

Regards, Roland

-- 
Roland Bauerschmidt <[EMAIL PROTECTED]>

Re: XEmacs/GTK 21.1.11

[Joachim Trinkwitz]

Juhapekka Tolvanen <[EMAIL PROTECTED]> writes:

> I fear, that it will take so much time, that we must have separately
> packaged XEmacs/Gtk meanwhile. And I fear, that latest upstream sources
> of XEmacs will ship with too old version of XEmacs/Gtk. Just check out,
> how old version of Gnus and Auctex ships with latest XEmacs, if you
> don't believe me.

The strategy of the emacs{19|20} Debian packages, which have much more
separate lisp packages, though born of need, results in much fresher
modules and quicker update cycles, which would be nice to have for
XEmacs too (never mind my english, I hope you understand what I mean).

Maybe all those Debian packages like psgml, auctex, gnus etc. should
be made for XEmacs too.

Greetings,
joachim

Re: Bug#70269: automatic build fails for potato

[Steve Greenland]

On 30-Aug-00, 12:51 (CDT), Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> wrote: 
> On 2830T112651-0500, Steve Greenland wrote:
> > That's pretty much the definition (or at least the *use*) of
> > Build-Essential: packages that may be assumed to be present, so that
> > they need not be listed in Build-Depends.
> 
> It's not the definition.  

Which is why I hedged with "pretty much" and "*use*". :-)

> One of the explicit design goals for the current
> setup was that policy should not need to mention specific packages.

Which is just a stupid pain in the ass. I had to track through three
different references and finally install the "build-depends" package to
find out what I could leave out of by "Build-Depends" stanza. It would
*much* easier for developers, if less ideologically pure, to just list
the damn packages on the Developers Corner part of the website.

And yes, I followed the discussion and reasons. I didn't disagree at the
time, but when the time came to use it, it was severely annoying.

Steve
-- 
Steve Greenland <[EMAIL PROTECTED]>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)

Re: Security of Debian SuX0r?

[Colin Watson]

Robert van der Meulen <[EMAIL PROTECTED]> wrote:
>I don't like crossposting to mailinglists, so i post this to debian-devel,
>as well as a Cc to the original author.

Maybe you should have *really* Cc'd the original author :) (Read the
article again; he isn't Juhapekka, that's for sure ...)

-- 
Colin Watson [EMAIL PROTECTED]

Re: Security of Debian SuX0r?

[Bob Bernstein]

Juhapekka Tolvanen <[EMAIL PROTECTED]> wrote:

> Have you guys and girls seen this? What do you think about it?
> 
> http://www.securityportal.com/closet/

I demur from the generally benign flavor of the reactions I've seen so far. I
think this was a hatchet job by a guy who appears completely disingenuous when
he claims he would have liked to have written a glowing review of Debian.
Here's my reply to him, which was a kneejerk reaction and could have been
longer and more thorough: 

Date: Wed, 30 Aug 2000 12:51:12 -0400 (EDT)
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
From: Bob Bernstein <[EMAIL PROTECTED]>
Subject: point by point rebuttal

I will back up my claim that the review was biased herewith:

A casual read suggests that other distros do things much better. Wrong. Kurt
seems to think that any distro that doesn't follow *his* notion of a secure
system is flawed, i.e. contains 'bugs'. 

Thus his first "Debian" criticism is something *every* distro does:

The first thing I noticed was
that while formatting the disk,
Debian defaults to an enormous /
partition and a swap partition.

I know of no Linux distro that does otherwise. And he is wise enough to
acknowledge that here. But that is the last we see of this wisdom. (NetBSD and
FreeBSD offer default disklabels that are better. OpenBSD does not bother to
offer any default at all; you're on your own.) So, next:

The next default that really
ticks me off is the password
encryption scheme - the default
is to use crypt. You can also use
MD5, but there is a warning about
compatibility.

So there's a warning? At least MD5 *can* be implemented at install-time. Why
doesn't he mention that Caldera for one doesn't even offer MD5 as an _option_
at install-time? Next:

Moving on. Once the basic install
is done, you will discover that
several services are enabled in
inetd that shouldn't be. Discard,
daytime, time, shell, login, and
exec (r services) are all enabled
by default, few of which (none,
in my opinion) are needed on
modern systems.

As you once pointed out in a linuxplanet article, this is a fault of ALL Linux
distros, in fact of ALL distros I know of other than OpenBSD! Next:

dpkg - My main beef with dpkg is
the lack of package signing
support. 

The guy is simply a raving rpm zealot here. To trade off the superb utility of
the Debian package system for PGP sigs is stupid. And no, MD5 sigs are not
that much more of a risk here because due to the excellence of the Debian
package collection one is rarely IF EVER called on to use a non-official
package. This is very much in contrast to the chaos that reigns in the rpm
world. Next:

Home directories for users in
Debian are by default world
readable and executable (to
change into a directory, you need
executable permission). This is a
very bad idea. It is made even
worse by the fact that the
default umask is 022. 

These are world-wide Unix standard values. And they are install DEFAULTS. If
you are going to administer a system with public access and/or large numbers
of users then you have to make some decisions and let your users know what the
reality is. It foolish to assume on any Unix system that the files in your
home dir cannot be read by others logged on to the system. And it is simple to
create a confidential subdir or - if you're not using Apache's 'public_html'
default - to change the permissions on your home dirs (as he notes). He is
creating a tempest in a tea pot here. Next:

LILO is also configured very
poorly. Despite the fact that
Debian 2.2 specifies "sulogin"
for single user mode, prompting a
user for the root password is
easily bypassed, by entering the
following argument at the LILO
command line:
Linux init=/bin/sh

I don't know how other distros do this. Kurt's discussion of these matters in
his LASG is the best I know of. And, I believe this has come up on the
debian-devel list. So I will give him a point here _tentatively_, until I hear
the other side. But, as usual, and as noted, the fix is simple. How does COL
do it? (I would add that anyone in the world can create a boot floppy or CD
that will obtain the same results! I am a big supporter of boot security, as
my security piece indicates, but at a certain point you have say that given
physical access to the machine, all bets are off.)

The rest of the article seems to be limited to a critique of the package
versions that are distributed with this release. I don't know how to answer
that. At a certain point one must freeze a release in order to make it
actually a release! The implication here is that it is possible on God's good
earth to make a release wherein none of its member packages contain any
security flaws at all! How silly. As for the fact that Debian hasn't applied
known, available fixes to certain packages in the release, he may be right
there. That's the second and last point I will _tentatively_ give him. Now he
says:

Debian's goal of a bug
free-release hasn't been met.

I haven't seen one "bug" mentioned in this articl

Re: Rfp: galeon

[Roland Bauerschmidt]

On Wed, Aug 30, 2000 at 06:59:25PM +0200, Daniele Cruciani wrote:
>   I've read on this list about ITP of galeon (web browser), but
> i don't remenber who announce ITP and I can't find that package on
> experimental.

I have made a package which can be found uder
http://www.debian.org/~rb/galeon/, but unfortunately I think that I
don't have the time to maintain it at the moment. I would be glad if
somebody would do this.

Roland

-- 
Roland Bauerschmidt <[EMAIL PROTECTED]>

Bug#70603: Can we please list build-essential packages in Developer's Corner?

[Antti-Juhani Kaijanaho]

Package: www.debian.org
Severity: wishlist

On 2830T130630-0500, Steve Greenland wrote:
> find out what I could leave out of by "Build-Depends" stanza. It would
> *much* easier for developers, if less ideologically pure, to just list
> the damn packages on the Developers Corner part of the website.

Well, since Developer's Corner is not Policy, we can make that happen.

Webmasters, can we get some arrangement such that the informational
list of build-essential packages (see the package build-essential) is
available in the Developer's Corner, preferably automatically updated
from the package?

-- 
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%

   Hypertekstivisionääri Ted Nelson luennoi Jyväskylässä 29.-31.8.
   Lisätietoja saa minulta.

Re: (Beware helix packages) Re: [CrackMonkey] The right to bare legs

[John Goerzen]

Christian Marillat <[EMAIL PROTECTED]> writes:


> Don't forget to put this field in debian/control:
> 
> Send-To: [EMAIL PROTECTED]

Whoa!  What packages understand this, and where is it documented?

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

-- 
John Goerzen <[EMAIL PROTECTED]>   www.complete.org
Sr. Software Developer, Progeny Linux Systems, Inc.www.progenylinux.com
#include  <[EMAIL PROTECTED]>

Re: Bug#70269: automatic build fails for potato

[Arthur Korn]

Hello.

Anand Kumria schrieb:
> Not having the helper packages included in the autobuild system appears to
> benefit, at most, around ~470 packages.

May I ask how they benefit?

It's only a (little) burden on the packages that use debhelper,
but I can't see any benefits for packages not using it. Nobody
will force debhelper on anyone.

As soon as you want to build something you will most probably
end up installing debhelper anyway, thus it's only wasted space
on the mirrors if all these hundreds of packages that use
debhelper have to declare this in their Build-Depends:.

On the other hand it probably makes counting them easier ... ;)

ciao, 2ri
-- 
0 and 1. Now what could be so hard about that?

Re: Crazy idea: removing version numbers from debian

[Eray Ozkural]

Thomas Guettler wrote:
> But I am interested
> what you think about this crazy idea to remove
> version numbers (like debian2.2) from debian?

It's really crazy. Removing version numbers mean that the
dependency graph must be synchronized globally which is
impossible AFAIK. In addition to this, it renders the
package pools idea essentially useless, which is the sane thing
that is needed.  :)

A better idea would be to perhaps indicate symbolically the
usability level of the package in the binary format. That
might give users some convenience, I dunno.

I have a lot of crazier ideas about distribution, release
management and package classification so keep these mental
inventions coming. :) This is exactly the place to discuss these.

Thanks,

-- 
 -+++-+++-++-++-++--+---++- ---  --  -  - 
 +  Eray "exa" Ozkural   .  .   .  . . .
 +  CS, Bilkent University, Ankara ^  .  o   .  .
 |  mail: [EMAIL PROTECTED].  ^  .   .

Re: (Beware helix packages) Re: [CrackMonkey] The right to bare legs

[Christian Marillat]

 "JG" == John Goerzen <[EMAIL PROTECTED]> writes:

>> Don't forget to put this field in debian/control:
>> 
>> Send-To: [EMAIL PROTECTED]

JG> Whoa!  What packages understand this, and where is it documented?

Sorry this is a error.

The right place for this is in:

/usr/share/bug/$package/control

For more documentation /usr/share/doc/bug/README.developers

Christian

Re: Installed console-apt 0.7.7.2potato1 (source i386)

[Christian Surchi]

On Wed, Aug 30, 2000 at 02:52:16PM -0400, Randolph Chung wrote:
> Installed:
> console-apt_0.7.7.2potato1_i386.deb
>   to dists/proposed-updates/console-apt_0.7.7.2potato1_i386.deb

What does it mean? console-apt is not in potato and is it put again in
stable?

bye
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 <--
"You are *so* lovely."  
"Yes."  "Yes!  And you take a compliment, too!  I like that in a goddess."

Re: Rfp: galeon

[Eray Ozkural]

orion:exa$ galeon
/usr/bin/galeon-bin: error in loading shared libraries: libgtkembedmoz.so: 
cannot open
shared object file: No such file or directory

What's happening? Where's this library? How could I install the package
if this is a dependency?

Thanks,

-- 
 -+++-+++-++-++-++--+---++- ---  --  -  - 
 +  Eray "exa" Ozkural   .  .   .  . . .
 +  CS, Bilkent University, Ankara ^  .  o   .  .
 |  mail: [EMAIL PROTECTED].  ^  .   .

Re: /bin/ksh as a default POSIX shell

[Manoj Srivastava]

>>"Herbert" == Herbert Xu <[EMAIL PROTECTED]> writes:

 Herbert> And this is Debian where we have a policy that says #!/bin/sh scripts
 Herbert> need to be POSIX compliant.

What policy says is:

 The standard shell interpreter ``/bin/sh'' can be a symbolic link to
 any POSIX compatible shell, if `echo -n' does not generate a newline.
 [1] Thus, shell scripts specifying ``/bin/sh'' as interpreter should
 only use POSIX features.  If a script requires non-POSIX features from
 the shell interpreter, the appropriate shell must be specified in the
 first line of the script (e.g., ``#!/bin/bash'') and the package must
 depend on the package providing the shell (unless the shell package is
 marked `Essential', e.g., in the case of `bash').

[1]  Debian policy specifies POSIX behavior for /bin/sh, but echo -n has
 widespread use in the Linux community (including especially debian
 policy, the linux kernel source, many debian scripts, etc.). This echo
 -n mechanism is valid but not required under POSIX, hence this
 explicit addition. Also, rumour has it that this shall be mandated
 under the LSB anyway. 


manoj
-- 
 Ma Bell is a mean mother!
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Crazy idea: removing version numbers from debian

[Eric Schwartz]

[EMAIL PROTECTED] (Vincent L. Mulhollon) writes:
> Perhaps any package can live in unstable, but any package that has a
> release critical bug older than 1 week is zapped from stable and placed back
> in unstable.  Upon next package upload, it will be reinstated into stable.

Ack!  Can you imagine what would happen under that system with a package
whose bugs are not handled that quickly?  The version in stable would be
$foo, next week it's $foo.1, a week later it's $foo again because of a RC 
bug filed in week 1, another week passes and the bug is fixed, so it's
$foo.1 again.  Not to mention we'd have to start supporting downgrades as 
well as upgrades (although I'm a new developer, I'm fairly sure we don't
do that).

> New packages would not be allowed into stable until x days had passed in
> unstable status without a Release Critical Bug.

Then someone files one when the maintainer's on vacation, nobody has time 
to do a NMU, and it pops back into unstable.  Ick.

> Or perhaps any package can live in unstable, and every package has a copy of
> itself in unstable, but on the last day of the month it is kicked out of
> stable if it has an open RCB.  If you are picky about RCBs, only apt-get
> stable on the first of the month.

What if a RC bug is filed the day before the deadline?  Last day of the
month hits, users apt-get dist-upgrade and then are faced with having to
downgrade their software.

>  If you need a buggy package anyway, get it out of unstable.

Better yet, don't put packages into stable until we release.  "Stable"
has a fairly well-defined meaning; I don't see much benefit from changing 
it.

> In theory this would complicate support because there would be so many
> "versions" of debian, yet developers survive with "daily" versions...

But because those "daily" versions are numbered, we know that the version 
we're getting is the latest (or not, as we choose).  How do you tell
somebody "I know that was fixed in the version I uploaded last week;
don't download today's though, as it's known buggy" without using version 
numbers?  You could use dates, but that can get hideously complicated
very quickly.

> Finally the idea I like the best is no numbers, only named updates.

See above.  Numbers make a lot of things easier.

> And we'd have a goal for the name.  Like the goal for "whiskey" release
> would be every package that needs it supports debconf, or the goal for
> "vodka" is every package supports kernel 2.4 and IPv6, or the goal for
> "scotch" is every package supports perl 5.6 or whatever.

A great idea.  But can't we do that now?

-=Eric
-- 
Any philosophy that can be put in a nutshell belongs there.
-- Sydney J. Harris

Re: /bin/ksh as a default POSIX shell

[Sean 'Shaleh' Perry]

> 
>   You cannot use it as a default shell without auditing all scripts. 
> 

I have used ash for over a year now as my /bin/sh.

Re: .bashrc (ls --color=auto setting)

[Wichert Akkerman]

Previously Paul Slootman wrote:
> Then you must have some other arrangement to get the colors;
> it's not enabled by default. Try a fresh install (I have).
> Maybe a direct setting of LS_COLORS in your .bash_profile or 
> whatever?

Nope:

[tornado;~/cistron]-15> env|grep LS
zsh: done   env | 
zsh: exit 1 grep LS

I have ls aliased to 'ls --color=auto', which works great.

Wichert.

-- 
  _
 /   Nothing is fool-proof to a sufficiently talented fool \
| [EMAIL PROTECTED]   http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |


pgpTmT8Xs6KHW.pgp
Description: PGP signature

Re: /bin/ksh as a default POSIX shell

[Anton Ivanov]

> > 
> >   You cannot use it as a default shell without auditing all scripts. 
> > 
> 
> I have used ash for over a year now as my /bin/sh.
> 

OK, OK, OK, I surrender. 

I have to admit my experience was rather old 
and the quantity of bashisms have sharply decreased. So you can run 
another POSIX compliant shell happily for sh nowdays.


-- 
Anton R. Ivanov ARI2-RIPE
mailto:[EMAIL PROTECTED]
Today's deliverables will have to be delayed because:

Interference between the keyboard and the chair.

Suggestion about security

[Cherubini Enrico]

Hi,
my suggestion about choosing between a simple to install or increased
security: you can work for easy installing and giving the people the freedom
to choice at the end of the installation process if secure the system. There
will be a procedure at the end of the installation that will take any action
every maintainer will think is better for increasing security of the
package.
IMHO: it's better a secure distrib instead of a easy one, there are many
other distributions claiming to be easy to install, I like to think that
debian is the serious one that take things seriously and security have to be
take in this way.
Just my suggestion, you can put it in the trash (or in /dev/null if you
prefer ;) )

-- 


Bye
++ Maybe you are searching for freedom
| Enrico |Maybe you can't find it anywhere
++  I found it in linux...

But the dangers are greater each year, and now Microsoft has explicitly 
 targeted our community. We can't take the future of freedom for granted. Don't
 take it for granted! If you want to keep your freedom, you must be prepared to 
   defend it. (C) Richard Stallman http://www.gnu.org/gnu/thegnuproject.html

Re: APT problem

[Jason Gunthorpe]

On Wed, 30 Aug 2000, Bernd Eckenfels wrote:

> > Could anyone please explain this to me? Did Corel do anything to their files
> > that makes apt think it has to upgrade although its up-to-date? Or is this
> > a bug in apt?
> 
> I see this quite often, so it is a bug in the curret apt lib. aptitude is
> even more vulnerable to this... at least the cache does work so u d/l it
> only once.

*blink* could I hear more details on this?

I'd like to see the dpkg --status for the offending package and the
dpkg-deb -I output for the deb.

Thanks,
Jason

Re: Bugs over two years old

[Adrian Bunk]

On Sun, 27 Aug 2000, Anthony Towns wrote:

> For your amusement: (it's actually been a year or two since I last posted
> this now too... The comments are probably pretty outdated)
> 
> Bugs Over Two Years Old
>...
>Package: emacs19
>Maintainer: [EMAIL PROTECTED] (Mark W. Eichin)
>4107 emacs leaves stale lockfiles and publishes pathnames
>4388 emacs mail-mode fails RFC822 section 3.4.7
>4890 emacs has bad path for jka-compr in site-start
>4997 mh-e will fail inc askes for POP passwd.
>7074 feature request (Was: Carsten Leonhardt: Re: ~/Maildir/ user
>interface)
>8468 missing call to fix_glyph on border (Evil hacking with glyphs,
>faces, d-tables)
>8723 emacs and xemacs manpage problem
>9032 Double C++-mode menu in Emacs.
>9740 following up under GNUS
>9741 Emacs save and auto-save not reliable
>9761 emacs: html-mode -> tag font bugged
>10123 emacs: doesn't properly respect INFOPATH.
>11079 gnus.el has wrong value of gnus-info-nodes
>12171 Bug in Emacs's C indenting !
>12677 No docs in /usr/doc
>14762 diary window date not updated
>15955 /usr/man/man1/etags.1.gz should be an alternative too
>16715 emacs has no recent custom library
>17441 crypt++ for emacs
>17469 Emacs not 8 bit-clean by default
>17509 gnus doesn't work!
>17696 emacs: Emacs adds a From: header line when sending mail. After
>that, a definition of from_field in /etc/smail/config is not honoured
>19114 Italian Ispell and Emacs
>20253 emacs icon is too big
>20525 emacs: can open concurent sessions on ONE file
>21309 emacs19: does not provide `editor' alternative
>21310 emacs19: menu icon too large
>22076 usr/info/emacs is missing
>22838 emacs19: emacs.1.gz not a symlink
>23149 Error building emacs19_19.34-19 from source
>23414 Error building emacs19_19.34-20 from source
>24005 emacs19 install fails
>24059 emacs19: Error installing alternatives for
>/usr/man/man1/emacs.1.gz
>24214 emacs19: mmencode is missing
>24499 emacs19: Repeatable segmentation fault
>24594 emacs19: info uplink in emacs-1.gz is wrong
>25417 emacs19: changing font takes long
>...

Isn't it time to remove emacs19 from unstable? The emacs20 package is more
than 2 1/2 years old and RMS said that emacs19 is no longer supported
upstream.

> Cheers,
> aj

cu,
Adrian

-- 
A "No" uttered from deepest conviction is better and greater than a
"Yes" merely uttered to please, or what is worse, to avoid trouble.
-- Mahatma Ghandi

Re: APT problem

[Jason Gunthorpe]

On Wed, 30 Aug 2000, Michael Meskes wrote:

> | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
> |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: 
> uppercase=bad)
> ||/ NameVersionDescription
> +++-===-==-
> ii  libc6   2.1.3-10   GNU C Library: Shared libraries and 
> Timezone
> feivel:~# dpkg --print-avail libc6

> Package: libc6
> [...]
> Version: 2.1.3-10
> [...]
> feivel:~# apt-get upgrade
> [...]
> Get:1 ftp://ftp.corel.com corellinux-1.2/corel_updates libc6 2.1.3-10 [1904kB]
> [...]

> Could anyone please explain this to me? Did Corel do anything to their files
> that makes apt think it has to upgrade although its up-to-date? Or is this
> a bug in apt?

This is a feature going awry in APT.. someone at Corel must have done
something weird to their package files. Basically APT looks at the
control records in the packages for tell tale signs of recompiles. Ie if
you have one package that depends on libc6 and one that depends on libc5
it can know. In this case it differentiates the remote package and the
local package and then always installs the remote package.

What needs to be done is diff the record from the corel package file
against what is in their .deb and see if there is a difference in any
fields.

Depending on what it is I will say two things
   1) Forget it, corel has to update their package file
   2) Oops, APT needs to ignore that difference.

Jason

Re: Bug#70269: automatic build fails for potato

[Wichert Akkerman]

Previously Steve Greenland wrote:
> It is not unreasonable to assume that the latest-and-greatest version of
> all the build-essential packages will be installed.

I wonder what world you are living in. It is in reality a completely
unreasonable assumption.

Wichert.

-- 
  _
 /   Nothing is fool-proof to a sufficiently talented fool \
| [EMAIL PROTECTED]   http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |


pgpdMShK1m3M1.pgp
Description: PGP signature

Re: Bug#70269: automatic build fails for potato

[Wichert Akkerman]

Previously Richard Braakman wrote:
> I don't know how the decision ended up being made, but the argument
> I presented at the time is that a dependency on debhelper is far more
> likely to be versioned than the others are.  A package that makes use
> of a new feature of debhelper is going to have to declare its own
> build-depends anyway.

Very much agreed, excellent point

Wichert (who has grown very tired of debhelper changes making building
security fixes a painful job at times)

-- 
  _
 /   Nothing is fool-proof to a sufficiently talented fool \
| [EMAIL PROTECTED]   http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |


pgpmFMDQBKIRO.pgp
Description: PGP signature

Re: Crazy idea: removing version numbers from debian

[Wichert Akkerman]

Previously Thomas Guettler wrote:
> Debian is evolving constantly, not in single steps.

True.

> But I am interested
> what you think about this crazy idea to remove
> version numbers (like debian2.2) from debian?

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

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

Wichert.

-- 
  _
 /   Nothing is fool-proof to a sufficiently talented fool \
| [EMAIL PROTECTED]   http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |


pgp5OPPLqc8ZM.pgp
Description: PGP signature

Re: APT problem

[Wichert Akkerman]

Previously Michael Meskes wrote:
> Could anyone please explain this to me? Did Corel do anything to their files
> that makes apt think it has to upgrade although its up-to-date? Or is this
> a bug in apt?

It means the libc6 package you have installed has a different md5sum then
the package it finds on ftp.corel.com, and assumes that the version on
ftp.corel.com is a newer recompile. Strange logic, but that is how
libapt-pkg thinks.

Wichert.

-- 
  _
 /   Nothing is fool-proof to a sufficiently talented fool \
| [EMAIL PROTECTED]   http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |


pgpuPKa3GfcZ8.pgp
Description: PGP signature

Re: Bugs over two years old

[Mark W. Eichin]

>> Isn't it time to remove emacs19 from unstable? The emacs20 package is more
>> than 2 1/2 years old and RMS said that emacs19 is no longer supported
>> upstream.

In fact, it is in the WNPP with an intent-to-orphan... but people seem
to care enough to keep doing NMU's...