Re: Time to rewrite dpkg IN IDL! :)

1999-05-20 Thread Elie Rosenblum
And thus spake Daniel James Patterson, on Fri, May 21, 1999 at 09:30:31AM +1000:
> On Fri, May 21, 1999 at 08:26:00AM +1000, Hamish Moffatt wrote:
> > 
> > Besides, any advantage in a nice OO design is lost by implementing it in 
> > C++!
> > 
> 
> There is no need to do it in C++.  My whole point is that I think an OO
> methodology would work well in this case simply due to the maintainability
> factor.
> 
>  We could do it in .ADA!

One thing that people seem to be forgetting (not necessarily you, but
I figured this was a good time to pipe in) is that it is desirable for
dpkg to 1) have a small footprint and 2) have few depencies.

I see the second as more important, because fewer dependencies mean
fewer chances to screw something up that will break dpkg (as we've
seen with C++ libraries breaking apt, etc).

-- 
Elie Rosenblum That is not dead which can eternal lie,
http://www.cosanostra.net   And with strange aeons even death may die.
Admin / Mercenary / System Programmer - _The Necronomicon_



Re: unknown host localhost

1999-05-20 Thread Sergey V Kovalyov

On Thu, 20 May 1999, Lawrence Walton wrote:

> On Thu, May 20, 1999 at 07:00:04PM -0400, Sergey V Kovalyov wrote:
> > After today's potato update my computer no longer knows about localhost.
> > Is this a known bug in some package or do I just need to reconfigure
> > something ?
> > Anyone else has similar problem ?
> > 
> What kernel are you using? if it's a non-2.2 kernel that might be the problem.
> If it's a non-2.2 kernel you might want to upgrade to the 2.2.7 kernel package
> I am rather fond of this kernel.

I'm using 2.2.8 and untill later today I did not have the problem.
Ok, it seems I've found the problem.
It turned out in /etc/nsswitch.conf I had "hosts dns ldap".
When nscd was on, it did not look into the local files. But without nscd
everything worked fine. So I've just added "hosts files dns ldap" and
everything started working Ok.
I probably should file a wishlist bug against libnss-ldap to include
"files" in the example nsswitch.conf.

Sorry for much noise out of nothing.

Sergey.



Re: Time to rewrite dpkg IN IDL! :)

1999-05-20 Thread Daniel James Patterson
On Fri, May 21, 1999 at 08:26:00AM +1000, Hamish Moffatt wrote:
> 
> Besides, any advantage in a nice OO design is lost by implementing it in C++!
> 

There is no need to do it in C++.  My whole point is that I think an OO
methodology would work well in this case simply due to the maintainability
factor.

 We could do it in .ADA!

daniel



Re: evan leibovitch and the LPI certification tests

1999-05-20 Thread Craig Sanders
On Fri, May 21, 1999 at 04:44:08AM -0700, Craig Brozefsky wrote:
> "Tyger Sunshine-Hill" <[EMAIL PROTECTED]> writes:
> 
> > If we don't, what is the point of pouring so much work into making
> > such a useful and _flexible_ distribution?
>
> Well, everyone has their own answer to that, but I'm satisfied that
> me, and my employer and some of my freinds are able to use this
> marvelous system.

precisely!

the point of debian (in fact, the point of all free software) is not
world domination or market share. the point of it all is that it is
available for use, modification, and sharing by those who want it.

we're not here to get 100% market share, or 50% or even 20%. we're here
to make the best system we can and share it amongst ourselves and with
others, and also to encourage others to join in the effort.

craig

--
craig sanders



Re: Paying for trade show booths?

1999-05-20 Thread David Bristel
Well, if we paid, maybe we could get space in a somewhat more populated area of
the show, hence more publicity.  If we can get around 3000 SETS of CDs(maybe
potato if it's out by the next LinuxWorld), and make a display of the release,
then it would definately help.

Dave


On Thu, 20 May 1999, Joseph Carter wrote:

> Date: Thu, 20 May 1999 15:03:11 -0700
> From: Joseph Carter <[EMAIL PROTECTED]>
> To: David Bristel <[EMAIL PROTECTED]>
> Cc: Tyger Sunshine-Hill <[EMAIL PROTECTED]>,
> debian-devel@lists.debian.org
> Subject: Paying for trade show booths?
> 
> On Thu, May 20, 1999 at 02:53:21PM -0700, David Bristel wrote:
> > I'd like to think we could use it to pay or help pay for booths to the trade
> > shows.  LinuxWorld, for those who were there was evidence that a small booth
> > just isn't big enough for all the Debian folks who want to help out, and 
> > for all
> > the cool stuff that people brought down.  Also, Debian CD's are always 
> > needed to
> > give out, electric, insurance, the booth space itself.  Rather than go on a 
> > show
> > to show basis, large donations COULD pay for the booth, or for a larger 
> > booth
> > than a 10x10.
> 
> Okay, next question would be then:  Do we want to be paying for large
> booths at trade shows?  I agree, LinuxWorld was a _MADHOUSE_, but is it
> something we want to spend donation money on?  ie, do people think the
> trade shows are that terribly important to us?
> 
> (I was at LinuxWorld and I must say it was cool!  Worth going, and even
> worth the financial nightmare it created in my life that is just now
> getting resolved a couple months later..)
> 
> 
> 
> Ahh, the psychic sig generator strikes again!
> 
> --
> Joseph Carter <[EMAIL PROTECTED]>Debian GNU/Linux developer
> PGP: E8D68481E3A8BB77 8EE22996C9445FBEThe Source Comes First!
> -
> * Culus thinks we should go to trade shows and see how many people we
>   can kill by throwing debian cds at them
> 


pgpcBW0kCH0kM.pgp
Description: PGP signature


unknown host localhost

1999-05-20 Thread Sergey V Kovalyov
After today's potato update my computer no longer knows about localhost.
Is this a known bug in some package or do I just need to reconfigure
something ?
Anyone else has similar problem ?

Sergey.




Apologies (2)

1999-05-20 Thread Marek Habersack
Hi all,

   Well, I wan't to apologize to all who feel offended with my views and
ideas (whether they worth anything or nothing at all). I seems that I am
simply not capable of taking part in public discussions or I lack fluency in
English to express myself in a clear way. 
   Either way, I just wanted to share my views and not even for a moment
thought about flames and such. If any of you cares, please go back and read
my postings again - maybe it will be more clear once you read it again...
   Anyway, I'm sorry for any flames I have caused and hope I won't be
removed from the list of subscribers to debian-devel :

regards,
  marek


pgpZ52EWMOXa8.pgp
Description: PGP signature


Re: Netscape under unstable...

1999-05-20 Thread Branden Robinson
On Thu, May 20, 1999 at 02:17:09PM -0700, Tom Lear wrote:
> Is it just me or is netscape crashing more recently?  Every machine that I
> have following unstable is having problems with netscape crashing, but the
> machines following stable work fine.

There is apparently an egcs optimization bug that miscompiles a few object
files that are included in the X libraries.  I am aware of Red Hat's fix
for this and it is a ghastly kludge.  I'm trying to come up with something
slightly less vomit-inducing for the next release of the X libraries
(3.3.3.1-5).

Alternatively, if egcs 2.95 is out and packaged before I release -5
(probably next week), that may have the fix.

This bug did not crop up in slink/stable because GNU gcc was still the
standard compiler at that point (I think -- my memory can't hold anything
prior to about 2 previous Debian X releases :) ).

-- 
G. Branden Robinson  |
Debian GNU/Linux |   Mob rule isn't any prettier just because
[EMAIL PROTECTED]   |   you call your mob a government.
cartoon.ecn.purdue.edu/~branden/ |


pgp8kUzeT83bE.pgp
Description: PGP signature


Re: Time to rewrite dpkg

1999-05-20 Thread John Lapeyre
*Marek Habersack wrote:
> Yes, yes. But you won't be able to use perl with C++ libraries.
If you use the C interface to the C++ libraries, and reimplement OO
in perl, yes you can. And the C++ wrapping has improved to the point that
people are using it directly for some projects.

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



Re: Time to rewrite dpkg

1999-05-20 Thread John Lapeyre
*Marcus Brinkmann wrote:
> On Thu, May 20, 1999 at 01:03:46AM +0200, Marek Habersack wrote:
> 
> > 3. Most programmers would write code in C
> 
> Yeah, uh. But that's the point isn't it?
> 
> The current dpkg is written in C. How many programmers are working on it?

I've often wondered about that.  Occaisionally I see people getting
involved, or offering patches, and it seems that IWJ is not interested.  I
will not speculate on what may be going on, but I have always found the
development of dpkg to be rather curious.  Anyone know what is going on ?


> 
> The only contributions to our packaging systems today are done with C++
> (apt), and perl (install methods).
> 
-- 
John Lapeyre <[EMAIL PROTECTED]>,  [EMAIL PROTECTED]
Tucson,AZ http://www.physics.arizona.edu/~lapeyre



Re: Time to rewrite dpkg IN IDL! :)

1999-05-20 Thread Craig Sanders
On Thu, May 20, 1999 at 10:09:34PM +0200, Marek Habersack wrote:
> Now you've proven it. You're a fanatic. And you offend people. Thanks.

there's no excuse for personal attacks. if you have a point to make,
then make it but don't stoop to ad hominem attacks.

i think i'll just ignore the rest of the thread now...it probably isn't
worth reading if it's got down to this level.

craig

--
craig sanders



Re: time to rewrite dpkg

1999-05-20 Thread Marek Habersack
* Branden Robinson said:

> > several lines? If so, then please go back AND READ IT. Only then you have a
> > right to jump upon me like that. Before you joined the discussion, we were
> > DISCUSSING matters, now we're FIGHTING and flaming each other. Thank you.
> 
> What is there to discuss with you?  Your entire position can be boiled down
Probably nothing...

> to a paraphrase of Henry Ford:
> 
> "You can rewrite dpkg in any language you want, as long as it's C."
Oh no I never said it... You're the next person to accuse me of it. I
think I really have nothing to say then... I'm sorry, I wasted your time.

> I'm sorry it offends your aesthetic that Aaron plans to reimplement dpkg in
NO IT DOESN'T! Have I made myself clear THIS TIME? It doesn't as I myself
program in BOTH languages - I just try to forsee what MIGHT be better.
That's what discussion is for. And if Aarond didn't want to discuss his idea
why would he send this posting? Wasn't it better to write the code and then
show it?? I think I'm getting wrong all of it here, maybe I'm just stupid...

> C++.  But it is not your decision to make.
Gosh... 

> The best support you can provide for your arguments is to redesign and
> reimplement the Debian packaging system yourself (or with people you
> recruit to the task).  So get to work.
I'm sorry, why are you attacking me? I wasn't the one who said he wants to
redesign the package. I responded to a posting posted to a PUBLIC mailing
list, that's it. Not even once I said here that I want to redesign it. I
just had my doubts and wanted to share them with you all - if that's a
crime, then I'm sorry - I'm guilty. It seems that one can express his ideas
and doubts as long as they are the same as of the original poster...

sorry for wasting your time, just ignore postings with my name on them

regards,
  marek


pgpYeHFrG6pMM.pgp
Description: PGP signature


Re: evan leibovitch and the LPI certification tests

1999-05-20 Thread John Lapeyre
*Joseph Carter wrote:
> First question:  If some major cash was donated to Debian, what would we
> do with it?  Seriously, do we have a purpose for it, or would we just
> re-donate it to other projects?  Sure that might look good for a story on
> Slashdot, but I'm more interested in making headlines for Debian because
> we actually accomplished something cool rather than making them just to
> make the average Slashdot reader think that Debian is as good as Redhat.
A couple of salaried positions would be nice.  Full time PR
staff, ... 


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



Re: [PRE-ANNOUNCE] DPKGv2 Project

1999-05-20 Thread Hamish Moffatt
On Thu, May 20, 1999 at 08:47:22AM -0400, Ben Collins wrote:
> This was not supposed to go out until Wichert got back and some details
> were settled, but with all the talk about redoing dpkg, I felt it necessary
> so that there weren't any duplication projects started and things didn't get
> complicated.

> There is a project underway to build a new package manager. It is being
> called DPKGv2, not simply because it wants to replace dpkg. This is aimed
> at package management in general, and across distributions other than
> Debian's. Yes, we hope it will replace the current package manager, as dpkg
> will retire sooner or later.
> 
> Please do not ask for any details, please don't ask to help, please don't ask

I'm surprised by this attitude; you seem to be suggesting that others
should not attempt a replacement, as yours already has Wichert's blessing.


Hamish
-- 
Hamish Moffatt VK3SB (ex-VK3TYD). 
CCs of replies from mailing lists are welcome.



Re: evan leibovitch and the LPI certification tests

1999-05-20 Thread John Lapeyre
*Manoj Srivastava wrote:
> I can't speak for others, but *I* do it cause it pleases my
>  muse. Getting Debian out to the great unwashed masses rouses little
>  but mild curiosity in me, and certainly not eough to warrant the
>  amount of effort I put into my packages. 

In general, it seems that  making Debian useful to the masses and
making it useful to developers are not antithetical goals.  There is a lot
that can be done to make it better for both groups.   I am worried about a
minimum amount of interest in order to keep Debian (or something like it )
going.  But it doesn't look like interest will wane in the near future.

RH's rhetoric is that growth of Debian and Caldera helps RH. And I
think they believe this rhetoric to a certain extent.  If the time came when
a significant number of people were asking companies to support their Debian
boxes, RH would not hesitate to offer that support.  Everything I have read
makes me believe that VA and SGI and Compaq and whoever will have no problem
responding to a demand to install and support Debian.

If Debian developers want more commercial success, they can work for
it.  If enough (like Manoj) don't care, then we won't get commercial support
and recognition.   It's probably OK either way.  They can't drive us out of
business.


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



Re: time to rewrite dpkg

1999-05-20 Thread Branden Robinson
On Thu, May 20, 1999 at 10:07:09PM +0200, Marek Habersack wrote:
> I have just one question to you - have you read the ENTIRE thread??? Or just
> several lines? If so, then please go back AND READ IT. Only then you have a
> right to jump upon me like that. Before you joined the discussion, we were
> DISCUSSING matters, now we're FIGHTING and flaming each other. Thank you.

What is there to discuss with you?  Your entire position can be boiled down
to a paraphrase of Henry Ford:

"You can rewrite dpkg in any language you want, as long as it's C."

You've made your point clear.  You (and Marcus, to a large degree) have
become completely sidetracked by arguing tiresome C++ pros and cons.

But Marcus also grasps that He Who Writes the Code Makes the Rules.

I'm sorry it offends your aesthetic that Aaron plans to reimplement dpkg in
C++.  But it is not your decision to make.

The best support you can provide for your arguments is to redesign and
reimplement the Debian packaging system yourself (or with people you
recruit to the task).  So get to work.

If you reply to this message, do not be surprised if I don't to yours.

-- 
G. Branden Robinson  |A committee is a life form with six or
Debian GNU/Linux |more legs and no brain.
[EMAIL PROTECTED]   |-- Robert Heinlein
cartoon.ecn.purdue.edu/~branden/ |


pgpiWAPjveWiw.pgp
Description: PGP signature


Re: Time to rewrite dpkg IN IDL! :)

1999-05-20 Thread Craig Sanders
On Thu, May 20, 1999 at 08:45:09PM +0200, Marcus Brinkmann wrote:
> On Fri, May 21, 1999 at 12:27:32AM +1000, Craig Sanders wrote:
>
> > C++ may be OO, but it's not very good OOand it tends to compile
> > into code which is both bloated and slow.
> >
> > dpkg is already far too slow on old hardware...hell, it's too slow
> > on a P200 with 200MB of RAM, now that the status and available files
> > have over 3300 packages detailed in them.
>
> Yeah, it's slow, and it's written in C.
>
> And you want to cinvince me by your un-emotional argumentation that it
> will be even slower in C++?
>
> Strange. Last time I took a look at Stroustrups language it seemed
> that it would be carefully designed to not enforce too much overhead
> on language features, and no overhead on language features not
> used. Stroustrups book goes into detail, and always mentions which
> run time overhead you have to expect when you use a certain language
> feature. Most features are only one function call away.

in theory, theory and practice are the same. in practise, they're
different.

i've always favoured practical considerations over nice theories.  

In practice, C++ programs are larger and slower than they ought to be.

craig
 
--
craig sanders



Re: Time to rewrite dpkg IN IDL! :)

1999-05-20 Thread Hamish Moffatt
On Thu, May 20, 1999 at 01:02:00PM -0700, Chris Waters wrote:
> Hamish Moffatt <[EMAIL PROTECTED]> writes:
> > I don't see anything in the Debian packaging system which fits
> > OO very well at all. We have just one type of package; there are no
> > special sub-types, for example.
> 
> Then you're not looking very carefully.  "It's overkill" may turn out
> to be a valid objection, but "it couldn't benefit from OO" is, IMO,
> completely false.  Elisp packages spring to mind.  We *do* have
> different classes of package; we just force them all into the same
> mold.

Can you expand the Elisp example? 


Hamish
-- 
Hamish Moffatt VK3SB (ex-VK3TYD). 
CCs of replies from mailing lists are welcome.



Re: Time to rewrite dpkg IN IDL! :)

1999-05-20 Thread Hamish Moffatt
On Thu, May 20, 1999 at 09:27:10PM +1000, Daniel James Patterson wrote:
> On Thu, May 20, 1999 at 09:14:26PM +1000, Hamish Moffatt wrote:
> > How about "it's complete overkill"?
> 
> I don't think so.  Yes you can write maintainable code with plain C,
> but with the number of developers moving in and out of Debian, I think
> that a decent OO approach for core software could make it more maintainable
> for _everyone_.  I often feel that I'd like to help contribute code to
> some things, but, not being an overly confident programmer, I am daunted
> by code that takes a long time to understand.  I personally find OO design
> much easier to follow.  This is personal preference however.

I think a good object-oriented design can be easier to follow too.
In circumstances where there is naturally some use for inheritance
it is very useful indeed. I don't see any natural inheritance in
managing packages, though. I think that forcing a procedural program into
classes just for the sake of it would destroy the clarity you're looking for.

Besides, any advantage in a nice OO design is lost by implementing it in C++!


Hamish
-- 
Hamish Moffatt VK3SB (ex-VK3TYD). 
CCs of replies from mailing lists are welcome.



ITP: mig (hurd-i386)

1999-05-20 Thread Marcus Brinkmann

Hello,

I plan to package the native version of mig, the Mach Interface Generator.

It will be hurd-i386 only. Not that it can't be compiled and used for other
arhces, too, but it will be completely useless to them. We don't want
unnecessary bloat, do we?

There is a cross mig for i386 there, it is in a seperate package maintained
by Santiago. They can probably be merged.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org   finger brinkmd@ 
Marcus Brinkmann  GNUhttp://www.gnu.org master.debian.org
[EMAIL PROTECTED]for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/   PGP Key ID 36E7CD09



Paying for trade show booths?

1999-05-20 Thread Joseph Carter
On Thu, May 20, 1999 at 02:53:21PM -0700, David Bristel wrote:
> I'd like to think we could use it to pay or help pay for booths to the trade
> shows.  LinuxWorld, for those who were there was evidence that a small booth
> just isn't big enough for all the Debian folks who want to help out, and for 
> all
> the cool stuff that people brought down.  Also, Debian CD's are always needed 
> to
> give out, electric, insurance, the booth space itself.  Rather than go on a 
> show
> to show basis, large donations COULD pay for the booth, or for a larger booth
> than a 10x10.

Okay, next question would be then:  Do we want to be paying for large
booths at trade shows?  I agree, LinuxWorld was a _MADHOUSE_, but is it
something we want to spend donation money on?  ie, do people think the
trade shows are that terribly important to us?

(I was at LinuxWorld and I must say it was cool!  Worth going, and even
worth the financial nightmare it created in my life that is just now
getting resolved a couple months later..)



Ahh, the psychic sig generator strikes again!

--
Joseph Carter <[EMAIL PROTECTED]>Debian GNU/Linux developer
PGP: E8D68481E3A8BB77 8EE22996C9445FBEThe Source Comes First!
-
* Culus thinks we should go to trade shows and see how many people we
  can kill by throwing debian cds at them


pgpUPVrKtDdzt.pgp
Description: PGP signature


Re: Netscape under unstable...

1999-05-20 Thread Martin Bialasinski

>> "TL" == Tom Lear <[EMAIL PROTECTED]> writes:

TL> Is it just me or is netscape crashing more recently?  Every
TL> machine that I have following unstable is having problems with
TL> netscape crashing, but the machines following stable work fine.

No, you are not the only one. Same thing here. This has been discussed
before. Most likely some kind of glibc2,1 problem.  

Ciao,
Martin



Re: Bug#38057: general: libgtop0: Depends: libglib1.1.13 (>= 1.1.13-1) but it is not installable

1999-05-20 Thread Martin Bialasinski

>> "JM" == James Mastros <[EMAIL PROTECTED]> writes:

JM> libgtop0 should be removed from the archive; it is obselete and
JM> replaced by libgtop1.  gnome-utils 0.99.3-1 depends on it -- but
JM> gnome-utils 0.99.3-1 is also obselete, but I cannot find a
JM> replacement, even though I have the replacement installed!  Is it
JM> still stuck in Incoming?

It is not there. I will copy the version from the staging area to
Incoming.

Ciao,
Martin



Re: evan leibovitch and the LPI certification tests

1999-05-20 Thread David Bristel
Think about it though, if Debian were the OS of choice, those who are involved
now would be considered the regional gurus, and that means we get paid more by
companies who want the most experienced and knowledgeable people.  Then we WOULD
have the masses groveling.

Dave Bristel


On 20 May 1999, Chris Waters wrote:

> Date: 20 May 1999 13:32:06 -0700
> From: Chris Waters <[EMAIL PROTECTED]>
> To: debian-devel@lists.debian.org
> Subject: Re: evan leibovitch and the LPI certification tests
> Resent-Date: 20 May 1999 20:34:49 -
> Resent-From: debian-devel@lists.debian.org
> Resent-cc: recipient list not shown: ;
> 
> Manoj Srivastava <[EMAIL PROTECTED]> writes:
> 
> > I can't speak for others, but *I* do it cause it pleases my
> >  muse. Getting Debian out to the great unwashed masses rouses little
> >  but mild curiosity in me, and certainly not eough to warrant the
> >  amount of effort I put into my packages. 
> 
> Hear hear!  I also like the idea of sharing my work with other
> *developers* so that *we* all have a better system.  I'm not
> interested in cramming my work down anyone's throat, however.  Anyone
> who *wants* to use it should feel free, but aside from that
> 
> > Market share and World domination are not goals I strive to
> >  achieve.
> 
> Market share, no.  But world domination?  C'mon, admit it would be fun
> to have the downtrodden of the world grovelling at your feet.  Dogbert
> has the right attitude.  Oh wait, you mean world domination for Debian?
> Never mind.  I don't care about the rest of you bums, I want those
> downtrodden grovelling at *my* feet!  :-)
> 
> -- 
> Chris Waters   [EMAIL PROTECTED] | I have a truly elegant proof of the
>   or[EMAIL PROTECTED] | above, but it is too long to fit into
> http://www.dsp.net/xtifr | this .signature file.
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 



Re: evan leibovitch and the LPI certification tests

1999-05-20 Thread David Bristel
I'd like to think we could use it to pay or help pay for booths to the trade
shows.  LinuxWorld, for those who were there was evidence that a small booth
just isn't big enough for all the Debian folks who want to help out, and for all
the cool stuff that people brought down.  Also, Debian CD's are always needed to
give out, electric, insurance, the booth space itself.  Rather than go on a show
to show basis, large donations COULD pay for the booth, or for a larger booth
than a 10x10.

David Bristel


On Thu, 20 May 1999, Joseph Carter wrote:

> Date: Thu, 20 May 1999 13:04:44 -0700
> From: Joseph Carter <[EMAIL PROTECTED]>
> To: Tyger Sunshine-Hill <[EMAIL PROTECTED]>
> Cc: debian-devel@lists.debian.org
> Subject: Re: evan leibovitch and the LPI certification tests
> Resent-Date: 20 May 1999 20:04:57 -
> Resent-From: debian-devel@lists.debian.org
> Resent-cc: recipient list not shown: ;
> 
> On Thu, May 20, 1999 at 07:09:28AM -0700, Tyger Sunshine-Hill wrote:
> > >RH isn't "competition" to debian except in the most positive sense of
> > >friendly rivalry.  We have different aims, different goals.  Their
> > >goal is to produce and market a linux distribution which keeps their
> > >company financially viable.  Our goal is to produce a distribution
> > >which does what we want with entirely free software.  Sometimes these
> > >goals co-incide or complement each other. sometimes they don't.  They
> > >certainly don't conflict or harm each other.
> > 
> > Well, maybe, but the fact is that Debian could use some sponsorships or 
> > major donations, and as long as RH keeps the spotlight, guess who they go 
> > to? Eventually, we have to get Debian out of its shell and get "the average 
> > linux user" (If there is such a thing) to use Debian more. If we don't, 
> > what 
> > is the point of pouring so much work into making such a useful and 
> > _flexible_ distribution?
> 
> First question:  If some major cash was donated to Debian, what would we
> do with it?  Seriously, do we have a purpose for it, or would we just
> re-donate it to other projects?  Sure that might look good for a story on
> Slashdot, but I'm more interested in making headlines for Debian because
> we actually accomplished something cool rather than making them just to
> make the average Slashdot reader think that Debian is as good as Redhat.
> 
> Sure PR is important, but I think we should be working harder to target
> our PR to the people it will do the most good.
> 
> --
> Joseph Carter <[EMAIL PROTECTED]>Debian GNU/Linux developer
> PGP: E8D68481E3A8BB77 8EE22996C9445FBEThe Source Comes First!
> -
>  abuse me.  I'm so lame I sent a bug report to
> debian-devel-changes
> 


pgp8dQl26VTSC.pgp
Description: PGP signature


Re: Bug#38057: general: libgtop0: Depends: libglib1.1.13 (>= 1.1.13-1) but it is not installable

1999-05-20 Thread Martin Bialasinski

>> "SC" == Sean Chuplis <[EMAIL PROTECTED]> writes:

SC> [EMAIL PROTECTED]:~# apt-get install libgtop0

libgtop0 is no longer. libgtop1 is the successor, so libgtop0 should
be removed from the distribution.

Note that there is only the binary left in the distribution. The
source, libgtop, only builds libgtop1.

I will reassign this bug to ftp.debian.org

Ciao,
Martin



Re: VA Research and linux.com

1999-05-20 Thread Joseph Carter
On Wed, May 19, 1999 at 01:46:57AM -0400, Phillip R. Jaenke wrote:
> If VAR's willing to toss a drive or even a system my way, or even a
> couple, at absolutely *no* charge, I will build them debian images they
> can use as masters for building Debian machines. Hell, I'll pay shipping
> back to them. It'd be my third time doing it (I've built a batch of 30
> debian machines, highly specialized, and a master image for 40
> non-specialized workstations.) and it really isn't that hard to duplicate
> drives.

Yeah, you and just about everybody else here right?  =p  =>

--
Joseph Carter <[EMAIL PROTECTED]>Debian GNU/Linux developer
PGP: E8D68481E3A8BB77 8EE22996C9445FBEThe Source Comes First!
-
 Oxymorons?  I saw one yesterday - the pamphlet on "Taco Bell
Nutritional Information"


pgpzIwrQGqxyI.pgp
Description: PGP signature


Processed: general bugs

1999-05-20 Thread Debian Bug Tracking System
Processing commands for [EMAIL PROTECTED]:

> reassign 38055 wmss
Bug#38055: general: Wmss depends on the unavailable package libwraster1.
Bug reassigned from package `general' to `wmss'.

> reassign 38057 libgtop0
Bug#38057: general:   libgtop0: Depends: libglib1.1.13 (>= 1.1.13-1) but it is 
not   installable  
Bug reassigned from package `general' to `libgtop0'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Ian Jackson
(administrator, Debian bugs database)



Re: request to kill nag messages

1999-05-20 Thread Dale Scheetz
On Thu, 20 May 1999, Joel Klecker wrote:

> At 18:10 +0100 1999-05-20, Adrian Bridgett wrote:
> >On Thu, May 20, 1999 at 06:47:28AM -0400, Dirk Eddelbuettel wrote:
> >>
> >>   Brian> Nag also sends emails regarding old bugs on your packages.  I 
> >> never
> >>   Brian> subscribed to that.  :p
> >>
> >> All I'm saying: Everybody is free to procmail away whatever they don't 
> >> like.
> >
> >This sounds like a good idea - send the Nag reports to the email address
> >@debian.org (which hopefully everyone has).  Then if some kind soul could
> >tell us what lines to add where to filter it everyone will be happy.
> 
> Don't presume to speak for everyone.
> 
> I would not be happy with that.
> 
> I will only say that "just filter it out" or "just press the delete 
> key" are spammers' answers.
> 
> I am well aware of my bugs, and I DO NOT need reminders of them.
> 
> One last thing, the next nag message I get will be treated as spam.

One way to deal with this is to just mark all your bugs as wish list. The
nags don't react to wish list bugs ;-)

Luck,

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

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

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



Bug#38057: general: libgtop0: Depends: libglib1.1.13 (>= 1.1.13-1) but it is not installable

1999-05-20 Thread James Mastros
On Thu, May 20, 1999 at 04:47:13PM -0400, Sean Chuplis wrote:
> Sorry, but the following packages have unmet dependencies:
>   libgtop0: Depends: libglib1.1.13 (>= 1.1.13-1) but it is not
> installable
libgtop0 should be removed from the archive; it is obselete and replaced by
libgtop1.  gnome-utils 0.99.3-1 depends on it -- but gnome-utils 0.99.3-1 is
also obselete, but I cannot find a replacement, even though I have the
replacement installed!  Is it still stuck in Incoming?

-=- James Mastros
-- 
First they came for the fourth amendment, but I said nothing because I
wasn't a drug dealer. Then they came for the sixth amendment, but I kept
quiet because I wasn't guilty. Finally they came for the first amendment,
and by then it was too late to say anything at all." 
-=- Nancy Lebowitz
cat /dev/urandom|james --insane=yes > http://www.rtweb.net/theorb/
ICQ: 1293899   AIM: theorbtwo  YPager: theorbtwo



Netscape under unstable...

1999-05-20 Thread Tom Lear
Is it just me or is netscape crashing more recently?  Every machine that I
have following unstable is having problems with netscape crashing, but the
machines following stable work fine.
- Tom

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  communicator-ba 4.5-7  Communicator base support for version 4.5
ii  libc6   2.1.1-5GNU C Library: Shared libraries and timezone
ii  libg++272   2.7.2.8-0.1The GNU C++ libraries (libc6 version).
ii  xlib6g  3.3.3.1-3  shared libraries required by X clients
ii  xpm4g   3.4k-1 X Pixmap run-time libraries




Re: Time to rewrite dpkg IN IDL! :)

1999-05-20 Thread Norbert Nemec
On Thu, May 20, 1999 at 02:50:38AM -0700, Chris Waters wrote:
> I think an interesting approach would be to use CORBA.  Make dpkg into
> a networkable server for polymorphic package objects!  G'wan, I dare
> ya!  :-)

Wowch! Nothing against CORBA, I love it, but if I think about the overhead.
I recently compiled the 2.2 Kernel: 6 minutes, I compiled MICO: 2 hours!!!
Ok, I know, handling the complexity of today computing needs powerful tools,
and CORBA is jsut the way to go, but i do not think, the world is ripe for
that in the *very basic* tool on any system. If you have to run a server
like that just to install Debian, you can well double the minimum amount of
needed memory.

So, having a way to access dpkg via CORBA would be a great thing, but still
it has to work without as well. Should be possible to have a simple C++
library but have IDLs for it as well in some way, so the objects can be
shared.

Ciao,
Nobbi
 
-- __
-- JESUS CHRIST IS LORD!
--  To Him, even that machine here has to obey...
--
-- _Norbert "Nobbi" Nemec
-- Hindenburgstr. 44  ...  D-91054 Erlangen  ...  Germany
-- eMail: <[EMAIL PROTECTED]>Tel: +49-(0)-911-204180



Re: lost packages

1999-05-20 Thread Turbo Fredriksson
[sorry martin, I forgot to address this to the list, only to you]

> "Martin" == Martin Bialasinski <[EMAIL PROTECTED]> writes:

>>> "MM" == Michael Meskes <[EMAIL PROTECTED]> writes:

MM> xadmin
Martin> Was discontinued because of serious bugs IIRC.

It did not conform to the Debian guidelines about changing configfiles
not in the package possession (xAdmin where changing /etc/{passwd|group|
*shadow} etc, which it shouldn't, since those files are owned by the base-
passwd package).

There _ARE_ newer versions available at 
'http://junk.nocrew.org/~turbo/debian.html'.

I more or less stopped developing it because of 'lost interest', so no 
guarantees :)
-- 
munitions FBI Ft. Bragg explosion bomb spy SDI Peking $400 million in
gold bullion jihad Qaddafi NORAD NSA AK-47 quiche


pgpJxCQNTytbH.pgp
Description: PGP signature


Bug#38057: general: libgtop0: Depends: libglib1.1.13 (>= 1.1.13-1) but it is not installable

1999-05-20 Thread Sean Chuplis
Package: general
Version: N/A

[EMAIL PROTECTED]:~# apt-get install libgtop0
Reading Package Lists... Done
Building Dependency Tree... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.

Since you only requested a single operation it is extremely likely that
the package is simply not installable and a bug report against
that package should be filed.
The following information may help to resolve the situation:

Sorry, but the following packages have unmet dependencies:
  libgtop0: Depends: libglib1.1.13 (>= 1.1.13-1) but it is not
installable
E: Sorry, broken packages

-- System Information
Debian Release: potato
Kernel Version: Linux krimson 2.2.7 #1 Wed May 19 02:16:06 EDT 1999 i586
unknown



Bug#38055: general: Wmss depends on the unavailable package libwraster1.

1999-05-20 Thread Sean Chuplis
Package: general
Version: N/A

[EMAIL PROTECTED]:~# apt-get install wmss
Reading Package Lists... Done
Building Dependency Tree... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.

Since you only requested a single operation it is extremely likely that
the package is simply not installable and a bug report against
that package should be filed.
The following information may help to resolve the situation:

Sorry, but the following packages have unmet dependencies:
  wmss: Depends: libwraster1 (>= 0.20.3) but it is not installable
E: Sorry, broken packages


-- System Information
Debian Release: potato
Kernel Version: Linux krimson 2.2.7 #1 Wed May 19 02:16:06 EDT 1999 i586
unknown



Re: evan leibovitch and the LPI certification tests

1999-05-20 Thread Chris Waters
Manoj Srivastava <[EMAIL PROTECTED]> writes:

> I can't speak for others, but *I* do it cause it pleases my
>  muse. Getting Debian out to the great unwashed masses rouses little
>  but mild curiosity in me, and certainly not eough to warrant the
>  amount of effort I put into my packages. 

Hear hear!  I also like the idea of sharing my work with other
*developers* so that *we* all have a better system.  I'm not
interested in cramming my work down anyone's throat, however.  Anyone
who *wants* to use it should feel free, but aside from that

> Market share and World domination are not goals I strive to
>  achieve.

Market share, no.  But world domination?  C'mon, admit it would be fun
to have the downtrodden of the world grovelling at your feet.  Dogbert
has the right attitude.  Oh wait, you mean world domination for Debian?
Never mind.  I don't care about the rest of you bums, I want those
downtrodden grovelling at *my* feet!  :-)

-- 
Chris Waters   [EMAIL PROTECTED] | I have a truly elegant proof of the
  or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.



Re: an idea - upload queue on va

1999-05-20 Thread Philip Hands
Joey Hess <[EMAIL PROTECTED]> writes:

> > When the upload queue software is packaged I'll evaluate installing it on
> > a couple machines.
> 
> Did someone volenteer? I forget..

Ah, I think that was me.

I forgot too.   Oops.  :-)

I should be able to sort it out on Saturday.

Cheers, Phil.



Re: [ITP/mostly packaged] hftpd

1999-05-20 Thread Chris Waters
Adrian Bridgett <[EMAIL PROTECTED]> writes:

> On Tue, May 18, 1999 at 05:09:27PM -0400, Michael Stone wrote:
> [snip]
> > > We really should have a policy for things like this. How about adding
> > > another Provides: to kernel images (built by the excellent make-kpkg):

> > Because too many people don't use debian kernel images.

> How about only making dependant packages "suggest" the appropriate kernel
> version?  That gets around this problem.

Or make it conflict with inappropriate versions?  (Actually, this
would work better if kernel-image-2.0.xx provided the virtual package
kernel-image-2.0, etc., but whatever.)

> Personally I'm fairly inclined to making it a recommends after all - anyone
> who doesn't use make-kpkg deserves what they get.

I agree, let 'em roll their own or use equivs if they don't want to
use the packaging system.  The argument that people can compile
libraries by hand doesn't hold water when it comes to library
dependencies, why should it hold for kernel dependencies?  It's not
like make-kpkg is difficult to use, or limiting in any way.
-- 
Chris Waters   [EMAIL PROTECTED] | I have a truly elegant proof of the
  or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.



Apologize

1999-05-20 Thread Marcus Brinkmann

Hello List,

I am sorry that I bored you with my silly contribution to the wrong thread.
I should have taken this to private much earlier, or better not started it
at all.

This is what you get when you are having a permanent net connection and
can respond (too fast). I have to learn that (I am in university, not at
home where I have dial up).

I don't apologize for what or how said it (sorry marek for not apologizing).

Marcus

-- 
"The purpose of Free Software is Free Software.
The End and the Means are the same."  -- Craig Sanders

Marcus Brinkmann <[EMAIL PROTECTED]>



Re: Time to rewrite dpkg

1999-05-20 Thread Marcus Brinkmann
On Thu, May 20, 1999 at 09:55:59PM +0200, Marek Habersack wrote:
> I'm sorry, but you seem to be arrogant here. You cut the DISCUSSION with
> statements like this instead of saying anything reasonable.

I said that I don't agree with you, and that I think your arguments against
C++ are invalid. I even said why I think so, and you just have to believe me
because you can't control what I think. You don't need to agree with me.

> So you think
> that design and project don't matter right?

No, I don't think so.

> That what developers and people
> who are to use dpkg thing doesn't matter, right?

Yes and No.

Yes, because we don't speak about changing dpkg.

No, because I think that some developers and uses have actually some useful
contributions to do. I didn't saw that from you.

> Well, I think you have
> worked for Micro$oft then.

You are putting an immediate end to the discussion. Thank you for that, I
was already trying to find a way out.

Marcus

-- 
"The purpose of Free Software is Free Software.
The End and the Means are the same."  -- Craig Sanders

Marcus Brinkmann <[EMAIL PROTECTED]>



Re: Time to rewrite dpkg IN IDL! :)

1999-05-20 Thread Marek Habersack
* Marcus Brinkmann said:

> > dpkg is already far too slow on old hardware...hell, it's too slow on
> > a P200 with 200MB of RAM, now that the status and available files have
> > over 3300 packages detailed in them.
> 
> Yeah, it's slow, and it's written in C.
Linux is slow. It's written in C. Yeah...

> And you want to cinvince me by your un-emotional argumentation that it will
> be even slower in C++?
[snip]
> ignoring things like maintenability and development of code looks
> simple-minded to me. The difference in speed will be unnoticable if the same
> algorithms are used.
Now you've proven it. You're a fanatic. And you offend people. Thanks.

marek


pgpHDpoQLf95Z.pgp
Description: PGP signature


ITP: namazu, namazu-el, tknamazu

1999-05-20 Thread Takuro KITAME
Hi, I'm packageing software "Namazu" and some client of Namazu
(namzu-el, tknamazu).

Namazu is the Full Text Search Engine.

About more, Please see 
   http://openlab.ring.gr.jp/namazu/index.html.en>
  This page is written in English.

Liecens:
 namazu: GPL2
 namazu-el : Public Domain
 tknamazu  : GPL2

Package: namazu
Priority: optional
Section: text
Version: 1.3.0.7-1
Depends: libc6 (>= 2.1), perl, nkf, kakasi
Suggests: www-browser, apache
Description: Full text search engine
 Namazu is full text search engine which usable via cgi.
 With Simply and Easy setup.
 Written with C and Perl.
 Namazu is using text utilities nkf and kakasi(or chasen, not available in 
Debian).

Package: namazu-el
Priority: optional
Section: text
Version: 0.0.19990510-1
Depends: emacsen, namazu
Description: Namazu client for Emacsen
 Namazu client for Emacsen.
 Namazu is Full Text Search Engine also available as Debian Paclage.
 About Namazu, Please see http://openlab.ring.gr.jp/namazu/

Package: tknamazu
Priority: optional
Section: text
Version: 1.11-1
Depends: namazu, wish, lynx
Description: Namazu client for tcl/tk
 Namazu client for tcl/tk
 Namazu is Full Text Search Engine also available as Debian Paclage.
 About Namazu, Please see http://openlab.ring.gr.jp/namazu/


Regards.

-- 
Takuro KITAME
  [EMAIL PROTECTED]
  [EMAIL PROTECTED] / [EMAIL PROTECTED]
  [EMAIL PROTECTED]



Re: time to rewrite dpkg

1999-05-20 Thread Marek Habersack
* Marcus Brinkmann said:

> > > Of course, you are entitled to your opinion. But the decisions are made by
> > > people who to do the work.
> > Not in this case. This is not their graduate project, nor an experiment.
> > It's a package which the entire Debian distribution relies on
> 
> You're wrong, reread what Aaron said. The CURRENT dpkg is what the entire
> distribution relies on. The CURRENT dpkg is written in C. You should be
> happy.
> 
> If you believe it would be better to rewrite dpkg in C, go for it. More
> power to you!
I have just one question to you - have you read the ENTIRE thread??? Or just
several lines? If so, then please go back AND READ IT. Only then you have a
right to jump upon me like that. Before you joined the discussion, we were
DISCUSSING matters, now we're FIGHTING and flaming each other. Thank you.

> > > The size of the language or the size of the binaries?
> > binaries, of course. Who cares about the language?
> 
> Interesting. So you prefer bloated program code instead of bloated binaries?
> The time a human needs to understand and maintain a program is less
> valuaable to you than a few kilobytes of source code? People read program
> code, but they almost never read binaries directly.
Yeah, yeah. Go back to one of your previous postings and read what you said:
"language doesn't guarantee anything. You have to code it." These are your
words and right now you are contradicting yourself. IF you design the code
well and implement it well, then it doesn't matter what language you use.
You seem to me a little bit fanatic, because what you suggest in the
statement above is that C cannot be used to write clear programs. That's a
bag of moonshine. C, C++, Python, Lisp, Scheme, Smalltalk - you name it, all
can be used to write awfully complicated code which nobody understands. The
design is what matters when you talk about readibility of the code. Look at
the linux sources, they are in C and theay readable and clear. Point taken?

> > > The language was carefully designed to avoid bloat of the binaries. C++ 
> > > does
> > Dream. C++ does bloat programs.
> 
> Some compiler bloat. The language does not.
Yes, but you use a compiler to produce a binary, not the language...

> And bloat is put a bit too simple. I don't care about a few kilobytes if it
> has direct and noticeable positive effect in the source code.
You don't care, good. I do care.

> > You would be surprised what problems people have with all the try/catch
> > blocks. 
> 
> You would be surprised what problems people have with all this pointer
> arithmetic. 
> You would be surprised what problems people have with all these regular
> expressions.
> You would be surprised what problems people have with all these parentheses.
> You would be surprised what problems people have with all these gotos.
> You would be surprised what problems people have with all these mnemonics.
> Did I get my point across?
yes, now I know you understand it well. But I don't know why are you trying
to pick up a flamewar? What are you so angry about? Why can't you discuss
instead of flaming?

> > You are talking about things like STL or other template-based libraries?
> > Then they will increase the binary size, and they will do it significantly.
> 
> How scary. What exactly is the problem with a bigger binary?
Hmm... what exactly? If we have 10 programs written in C that have to fit 
on one diskette and each of them adds extra 30KB, plus several dozens of
kilobytes for the libraries, then what has to fit on one diskette is at the
very least 300KB, and that's the problem I see.

> > > Your knowledge of the C++ language is a few years behind of current
> > > standards and implementation.
> > C++ isn't in state of flux anymore, true, but egcs (and it's the only
> > compiler around on the GNU platform which can be used to do serious C++
> > programming) is.
> 
> See, I am the maintainer of libgtkmm. This is a huge wrapper library around
> Gtk, which uses a lot of templates, classes, derivation, whatever. The
> maintainer (currently about three people are actively working on the code)
> were able to maintain compatibility even with g++ 2.7.2.3 (which is
> horribly broken in every respect) until recently. I don't see them rewriting
> their code everytime with another egcs release.
I never said every time. Once again, please, read the entire thread.

marek


pgp07ybzJmR4r.pgp
Description: PGP signature


Re: Time to rewrite dpkg IN IDL! :)

1999-05-20 Thread Chris Waters
Hamish Moffatt <[EMAIL PROTECTED]> writes:

> On Thu, May 20, 1999 at 08:25:17PM +1000, Daniel James Patterson wrote:
> > On Thu, May 20, 1999 at 02:50:38AM -0700, Chris Waters wrote:

> > > I think an interesting approach would be to use CORBA.  Make dpkg into
> > > a networkable server for polymorphic package objects!  G'wan, I dare
> > > ya!  :-)

> > I don't see why not.

> How about "it's complete overkill"?

Sure, and without complete overkill, how will we take full advantage
of the second-system effect?  :-)

> I don't see anything in the Debian packaging system which fits
> OO very well at all. We have just one type of package; there are no
> special sub-types, for example.

Then you're not looking very carefully.  "It's overkill" may turn out
to be a valid objection, but "it couldn't benefit from OO" is, IMO,
completely false.  Elisp packages spring to mind.  We *do* have
different classes of package; we just force them all into the same
mold.
-- 
Chris Waters   [EMAIL PROTECTED] | I have a truly elegant proof of the
  or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.



Re: evan leibovitch and the LPI certification tests

1999-05-20 Thread Joseph Carter
On Thu, May 20, 1999 at 07:09:28AM -0700, Tyger Sunshine-Hill wrote:
> >RH isn't "competition" to debian except in the most positive sense of
> >friendly rivalry.  We have different aims, different goals.  Their
> >goal is to produce and market a linux distribution which keeps their
> >company financially viable.  Our goal is to produce a distribution
> >which does what we want with entirely free software.  Sometimes these
> >goals co-incide or complement each other. sometimes they don't.  They
> >certainly don't conflict or harm each other.
> 
> Well, maybe, but the fact is that Debian could use some sponsorships or 
> major donations, and as long as RH keeps the spotlight, guess who they go 
> to? Eventually, we have to get Debian out of its shell and get "the average 
> linux user" (If there is such a thing) to use Debian more. If we don't, what 
> is the point of pouring so much work into making such a useful and 
> _flexible_ distribution?

First question:  If some major cash was donated to Debian, what would we
do with it?  Seriously, do we have a purpose for it, or would we just
re-donate it to other projects?  Sure that might look good for a story on
Slashdot, but I'm more interested in making headlines for Debian because
we actually accomplished something cool rather than making them just to
make the average Slashdot reader think that Debian is as good as Redhat.

Sure PR is important, but I think we should be working harder to target
our PR to the people it will do the most good.

--
Joseph Carter <[EMAIL PROTECTED]>Debian GNU/Linux developer
PGP: E8D68481E3A8BB77 8EE22996C9445FBEThe Source Comes First!
-
 abuse me.  I'm so lame I sent a bug report to
debian-devel-changes


pgpNYSlWBIkfS.pgp
Description: PGP signature


Package selection and alternatives

1999-05-20 Thread Edward Betts
At the moment, the alternatives system, the packaging system, the virtual
package names, the sensible-* scripts, the default X server, the kernel image
and the default window manager settings are all seperate entities. I think
they could all be more tightly intergrated.

At the moment, the default choice for the alternatives system is pre-deceided,
the sensible scripts are similar, except they look at enviroment instead,
hile the default kernel, X server and windows manager are all decieded from
questions in the postinst script.

Function
-
Debian has a lot of programs that do the same thing. These functions could be
descriped with a functions tag, in the package file. For each package there
could be more than one function. This tag would be slightly similar to the
virtual packages idea, but more advanced.

My basic example would be GNU Emacs. The functions tag could look like this:

Functions: editor, emacs, info-browser, mua, news-reader

I am sure it does more, but I can not think of any. Here is a list of possible
functions:

editor  - Any editor. examples: gnu emacs, vim, ed, nvi, jed, jove
  emacs - A version of emacs. How strict are we here? do these qualify?:
  jove - Jonathan's Own Version of Emacs qualify?
  zile - Zile is a lossy emacs
examples: gnu emacs, gnu emacs, xemacs, xemacs, jove ??, zile ??

  vi- A version of the bsd editor vi.
examples: nvi, vim, elvis, gnu emacs (in viper mode)

pager   - Any pager.  examples: less, more, vim -R, nview
  view  - The vi style pager. examples: nvi, vim -R

www-browser   examples: lynx, netscape
  netscapeexamples: communicator, navigator
mta   examples: exim, sendmail, smail
mua - Mail User Agent examples: mutt, elm, mailx
news-reader   examples: trn, slrn, tin, nn
news-server   examples: inn, cnews
irc-clientexamples: ircii, bitchx, epic
icq-clientexamples: zicq, micq, licq
aol-chat-client   examples: tix
ftp-clientexamples: lftp, ftp, ncftp
file-manager  examples: mc, kfm, explorer
c-complierexamples: gcc, bcc, gcc272
awk   examples: mawk, gnu awk
info-browser  examples: info, gnu emacs, pinfo
man-browser   examples: man-db, emacs, pinfo, info
graphics-viewer   examples: eeyes, imagemagik, xv
display-manager   examples: xdm, login.app, gdm, wdm
window-managerexamples: twm, fvwm, enlightenment, kwm, icewm
xserver   examples: xggi, xserver-*
kernelexamples: linux, hurd, bsd
(that one was a bit of a joke)
  linux-kernel-image
  linux-kernel-source
  linux-kernel-headers
  linux-kernel-doc
shell examples: bash, tcsh, ash, zsh
  sh-shellexamples: bash, ash, zsh
  csh-shell   examples: csh, tcsh
term-emulator examples: xterm, rxvt

I am sure there are more `functions', for examples there are loads more servers
(irc, nfs, ftp, web, etc).
Some can only really have one installed at a time, like the servers, but
others could have multiple installed. So you could have loads of editors and
web browsers. The main suggestion of this rant, is for them to have priorites
that can be adjusted by the user, and the system administrator. So as a user I
could run a dselect or apt like program with a list of packages and instead of 
selecting which to install, and which to hold, select priorites for the
functions listed above. I might select emacs as my main editor, gnu emacs 20
as my main emacs, and vim as my main vi. But I could still have the others
installed. I think this would be useful on a per machine and per user basis,
so that as a power user I could select a heavy weight editor, and other users
could select an easier to use one. It would be a handy tool for changing
window managers. It could use a similar symlink system to the alternatives
system, have cc as a symlink the the current C compiler and vi a link to the
current vi clone. The selected linux-kernel-image could be made the default in
lilo.

There are some more questions though, what of the interface? I tend to use
lynx on the console and netscape in X11, there should be some way of handling
this.

Interface 
--
Differnet people use Debian in different ways. I like to think of myself as a
bit of a console man, I tend not to use X11, but others, in the near future
at least, will swear by gnome or kde, refusing to touch anything with a
different interface. So why not give them an idea of the interface when
selecting packages? Here are some first run ideas for interfaces with
discriptions and example packages, in alphabetical order:

athena  - The original X11 toolkit, ugly and hard to code. Note: Some X programs
  do not use

Re: Time to rewrite dpkg

1999-05-20 Thread Marek Habersack
* Marcus Brinkmann said:
> On Thu, May 20, 1999 at 08:50:26PM +0200, Marek Habersack wrote:
> > > And note that development will just start. By the time this project 
> > > enters a
> > > critical stage, egcs will be improved again.
> > No, the development shouldn't start yet. A project should be presented to
> > the iterested people and a discussion should take place. Only THEN the
> > actual development should start. By that time many things can change, yes.
> > But if you start to write your code and base it on some feature which will
> > change in the egcs, then what? Simple - you will have to rewrite all your
> > code.
> 
> It's hardly to respond anything reasonable to that. This is such a gross
> exaggeration, and such a demanding and arrogant attitude, that I can simply
> stop just as well.
I'm sorry, but you seem to be arrogant here. You cut the DISCUSSION with
statements like this instead of saying anything reasonable. So you think
that design and project don't matter right? That what developers and people
who are to use dpkg thing doesn't matter, right? Well, I think you have
worked for Micro$oft then.

marek


pgphafRDfTGfa.pgp
Description: PGP signature


Re: Time to rewrite dpkg

1999-05-20 Thread Marek Habersack
* Marcus Brinkmann said:

> > Again, that's not an argument. People come and people go, and more of them
> > know C than C++. Besides, ech..., how can you draw an argument like this???
> 
> I can because I see what's happening to dpkg and it worries me.
> 
> We all are blinded by dpkg. It works, yes. How long? The current sources
> don't even build properly out of the box. Problems are cropping up without
> people knowing how to fix them (see the bug list). Even very simple patches
> and changes need months to get into yet another non-maintainer release.
I aggree. I have looked into dpkg code and it scared me, yes...

> Your argument is that there would be a lot of more hypothetical programmers
> for a C version. This is irrelevant as long as the real number of C
> programmers willing to do this is 0 == NULL and the number of C++
> programmers is at least 2, if not more.
You can count me in both groups - I have NO personal preference as to the
language used, none at all. The tool doesn't matter that much, the effect
does - and the more commonly acceptable, the better in that case.

> > Is that a reason to write dpkg in Heskell, because the current maintainer
> > fancies that?
> 
> You're exaggerating. What if someone would propose doing it in ZX 80
> assembler and running it on an emulator? Yeah. Bad idea.
> 
> But there seem to be enough C++ deevelopers around here, and more and more
> will follow (if you haven't noticed, on universities they teach Scheme, Java
> , Perl and C++, depends on which faculty you are looking, AI, linguistics or
> math/computer science).
Don't talk about universities. I've seen too many university graduates that
know nothing about "real-world programming"... 

> > And what about
> > compatibility? Extensibility? Interoperability? They don't matter at all,
> > right?
> 
> In my book, yes. But compatibility which what? Extensible to where?
Compatibility with everything used to program - meaning, easy interfacing
with other programming languages. Extensible to other environments, or
simply put - creating frontends and utilities to easily manage the packages
- vide gnomeapt for apt.

> Your arguments are not really good ones, you can write good and bad code in
> any language. But even if they were, they are hypothetical anyway. My proof:
> The current dpkg is written in C. Is it compatible? No. I needed to fix a
> lot of stuff to make it work on the Hurd, and it was a pain to find out how
> to fix things. Is it exensible? Not easily, because the code is difficult to
> follow. Is it interoperable? With what?
Once again: I DON'T CARE WHAT LANGUAGE IS USED HERE. I just see that blind
faith in any language can lead to a product which can be extended only in
that language. And why to do that when you can

a) DESIGN good procjec
b) CODE it in C
c) EXTEND it with virtually every other programming language

Can't you see that C is simply a BASIS on wich you can build everything you
imagine. Someone said C is "primitive" - true, but that's why it's so
powerful. There are better designed languages out there, which have better
theory behind them, true, but no language is so common as C, and as such
(!!) it should be chose to create tools which are to be extended, either now
or in the future. Look, how many years dpkg has been virtually in the center
of the Debian dist??? And that's why you have to THINK ABOUT THE FUTURE and
not discuss about what language is better for THEORETICAL reasons. We deal
with practice, not with theory here.

> I don't want to make dpkg bad here. But you tell me how wonderful C code can
> be, and how bad C++ code alwas can be, but I see dpkg, which is in C, and I
> see apt, which is in C++, and I don't understand how you can be so sure
> about that.
I'm starting to lose my nerve... I NEVER said that C is better or C++ is
better IN GENERAL. I just think that C is better for THIS task and so far
nobody convinced me that it cannot be done in C. It's all a matter of
design, when we speak about the program/library itself, and not of the
language chosen. But from the point of view of the final product, the
language choice appears to be important since it will affect what tools can
be used to FURTHER extend dpkg.

> Using C does not grant you immediate success. It does not give you
> compatibility for free. It does not give you extensibilty and operability.
I never said it.

> > > (apt), and perl (install methods).
> > Yes, yes. But you won't be able to use perl with C++ libraries.
> 
> Big deal. The current perl code does usually not use C libraries. They call
Big deal you say?  ^^^you said it. If the library is
written well in C, then code in perl, tcl, scheme, elisp, java, whatever
will use it because it will be EASIER this well. It all comes down to GOOD
DESIGN.

marek


pgp93xNXekGoa.pgp
Description: PGP signature


Re: better /etc/init.d/network

1999-05-20 Thread Massimo Dal Zotto
> 
> As we're discussing things here... i think it's important that we add the
> possbility to attach IPv6 addresses to an interface. Since you can have
> multiple IPv6 addresses on an interface i was thinking of something like
> this:
> 
> IPADDR = 192.168.2.1
> IP6ADDR = 3ffe:604:5:4::1/80
> IP6ADDR = 5ffe:12:2::1/80
> 
> Taking the current IPv6 aggregatable addressing scheme in mind it might be
> better to seperate the prefixes from the addresses, something like:
> 
> PREFIX6 = 3ffe:604:5:4/80
> PREFIX6 = 5ffe:12:2/80
> HOST6 = 1
> 
> If there's noone objecting to the addition of IPv6 stuff to the interface
> we could work out a proper way of specifying it on the debian-ipv6 list.
> 
> Comments?
> 
> Michel Onstein |   CistroN Group|  Linux-, Internet-
> [EMAIL PROTECTED] ||  Telecom specialists
> 

I don't know very much about IPv6. If anyone could give me some synthetic
information about the commands and the syntax needed to configure an IPv6
interface and add routing entries I will be glad to add the feature.

In the meantime you can try the next version of the package:

  http://www.cs.unitn.it/~dz/debian/net_1.1-1_all.deb

I have added the NETGROUP and OPTIONS fields to the config file and the
new hooks before_net_up() and after_net_down(). I haven't added support
for scripts like .postup. for two reasons, first you
can do the same things with net_up and the other functions and second I
don't like the idea of package postinst script messing with my network
configuration files. Those things should be done by hand.
Also the suggestion of an user option seems bad to me. I don't want my
users start and stop network interfaces. And it would also require a
setuid script, which is of course a very bad idea.

-- 
Massimo Dal Zotto

+--+
|  Massimo Dal Zotto   email: [EMAIL PROTECTED]   |
|  Via Marconi, 141phone: ++39-0461534251  |
|  38057 Pergine Valsugana (TN)  www: http://www.cs.unitn.it/~dz/  |
|  Italy pgp: finger [EMAIL PROTECTED]  |
+--+



Re: better /etc/init.d/network

1999-05-20 Thread Javier Fdz-Sanguino Pen~a

Well, I think your program goes in the right direction. However I
feel it should be more user-friendly regarding two things:
a) presenting the user a nice interface (not just read in console)
b) going through user input and checking errors.


I don't have time to help you with a) but I can surely help with a).
My proposal (and attached diff) is you use 'dialog' as an interface when
available. That way all config apps have the same "feel", and also, when in
X the more nice gdialog is used (if available).
Feel free to use my patch as you will. I have also changed the code
enough so I could make these changes.

Regards

Javi
--- net Sun May 16 20:47:45 1999
+++ net.dialog  Tue May 18 03:40:11 1999
@@ -20,6 +20,21 @@
 # along with this program; if not, write to the Free Software
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA.
 
+# This sets up the DIALOG variable in order to show information 
+# and receive input in a more user-friendly way, or at least show-off.
+# Only used when configuring the devices.
+# Jfs - mar may 18 03:39:51 CEST 1999
+GDIALOG="/usr/bin/gdialog"
+DIALOG="/usr/bin/dialog"
+if [ -x $GDIALOG ]; then
+   DIALOG=$GDIALOG
+fi
+if [ ! -x $DIALOG ]; then
+   DIALOG=""
+fi
+
+
+
 function usage() {
 local p=${0##*/}
 echo "Usage:  $p [start|stop|restart|status [interfaces...]]"
@@ -187,17 +202,28 @@
 }
 
 function ask_var() {
+# More error checking should be done in order to get useful
+# values (maybe when this script becomes a C program?)
 local prompt="$1" && shift
 local varname="$1" && shift
 local default="${!varname}"
 local default="${default:-$3}"
 
-echo -ne "$prompt [$default]: "; read val
-case "$val" in
+if [ -z $DIALOG ]; then
+   echo -ne "$prompt [$default]: "; read val
+else
+# If DIALOG is available it will show it in a more
+# user-friendly way
+   local tmp=`tempfile`
+   $DIALOG --inputbox "$prompt" 10 30 2>$tmp
+   val=`cat $tmp`
+   rm $tmp
+fi
+   case "$val" in
-|NONE) val="" ;;
"") val="$default" ;;
-esac
-eval "$varname"="$val"
+   esac
+  eval "$varname"="$val"
 }
 
 function config_interface() {
@@ -272,29 +298,33 @@
 
 CONFIG="${CONFIG:-$INTERFACE}"
 CONFIG="/etc/network/${CONFIG##*/}"
+STRING=""
+STRING="\nINTERFACE=$INTERFACE\n"
+STRING="${STRING}IPADDR=$IPADDR\n"
+if [ "$NETWORK" ]; then
+   STRING="${STRING}NETWORK=$NETWORK\n"
+   STRING="${STRING}NETMASK=$NETMASK\n"
+   STRING="${STRING}BROADCAST=$BROADCAST\n"
+elif [ "$POINTOPOINT" ]; then
+   STRING="${STRING}POINTOPOINT=$POINTOPOINT\n"
+fi
+if [ "$GATEWAY" ]; then
+   STRING="${STRING}GATEWAY=$GATEWAY\n"
+fi
+if [ "$ARGS" ]; then
+   STRING="${STRING}ARGS=\"$ARGS\"\n"
+fi
+if [ "$NOAUTO" ]; then
+  STRING="${STRING}NOAUTO=true\n"
+fi
+if [ -z $DIALOG ]; then
 {
-   echo
-   echo "INTERFACE=$INTERFACE"
-   echo "IPADDR=$IPADDR"
-   if [ "$NETWORK" ]; then
-   echo "NETWORK=$NETWORK"
-   echo "NETMASK=$NETMASK"
-   echo "BROADCAST=$BROADCAST"
-   elif [ "$POINTOPOINT" ]; then
-   echo "POINTOPOINT=$POINTOPOINT"
-   fi
-   if [ "$GATEWAY" ]; then
-   echo "GATEWAY=$GATEWAY"
-   fi
-   if [ "$ARGS" ]; then
-   echo "ARGS=\"$ARGS\""
-   fi
-   if [ "$NOAUTO" ]; then
-   echo "NOAUTO=true"
-   fi
-   echo
-}
-echo -n "Write file $CONFIG (y/N)? "; read x
+   echo -e $STRING
+   echo -n "Write file $CONFIG (y/N)? "; read x
+   }
+else
+   $DIALOG --yesno "$STRING\nSave file $CONFIG?"  20 40 && x="y"
+fi
 if [ ! "$x" -o "$x" != "y" ]; then
echo "Configuration not saved"
return


Re: Time to rewrite dpkg

1999-05-20 Thread Marcus Brinkmann
On Thu, May 20, 1999 at 08:50:26PM +0200, Marek Habersack wrote:
> > And note that development will just start. By the time this project enters a
> > critical stage, egcs will be improved again.
> No, the development shouldn't start yet. A project should be presented to
> the iterested people and a discussion should take place. Only THEN the
> actual development should start. By that time many things can change, yes.
> But if you start to write your code and base it on some feature which will
> change in the egcs, then what? Simple - you will have to rewrite all your
> code.

It's hardly to respond anything reasonable to that. This is such a gross
exaggeration, and such a demanding and arrogant attitude, that I can simply
stop just as well.

Sorry, but you seem to be trapped in your argumentation.
Marcus

-- 
"The purpose of Free Software is Free Software.
The End and the Means are the same."  -- Craig Sanders

Marcus Brinkmann <[EMAIL PROTECTED]>



Re: Time to rewrite dpkg

1999-05-20 Thread Marcus Brinkmann
On Thu, May 20, 1999 at 08:47:00PM +0200, Marek Habersack wrote:
> 
> > The current dpkg is written in C. How many programmers are working on it?
> Again, that's not an argument. People come and people go, and more of them
> know C than C++. Besides, ech..., how can you draw an argument like this???

I can because I see what's happening to dpkg and it worries me.

We all are blinded by dpkg. It works, yes. How long? The current sources
don't even build properly out of the box. Problems are cropping up without
people knowing how to fix them (see the bug list). Even very simple patches
and changes need months to get into yet another non-maintainer release.

Your argument is that there would be a lot of more hypothetical programmers
for a C version. This is irrelevant as long as the real number of C
programmers willing to do this is 0 == NULL and the number of C++
programmers is at least 2, if not more.

> Is that a reason to write dpkg in Heskell, because the current maintainer
> fancies that?

You're exaggerating. What if someone would propose doing it in ZX 80
assembler and running it on an emulator? Yeah. Bad idea.

But there seem to be enough C++ deevelopers around here, and more and more
will follow (if you haven't noticed, on universities they teach Scheme, Java
, Perl and C++, depends on which faculty you are looking, AI, linguistics or
math/computer science).

> And what if he gets tired maintainig it?

I am absolutely sure that it would take me less effort to learn Huskell from
scratch and work on a very clean and well written Huskell version of dpkg
than to work on the current dpkg in C. Yes, I have taken a deep look into
the dpkg source. I even worked on some things.

> And what about
> compatibility? Extensibility? Interoperability? They don't matter at all,
> right?

In my book, yes. But compatibility which what? Extensible to where?
Your arguments are not really good ones, you can write good and bad code in
any language. But even if they were, they are hypothetical anyway. My proof:
The current dpkg is written in C. Is it compatible? No. I needed to fix a
lot of stuff to make it work on the Hurd, and it was a pain to find out how
to fix things. Is it exensible? Not easily, because the code is difficult to
follow. Is it interoperable? With what?

I don't want to make dpkg bad here. But you tell me how wonderful C code can
be, and how bad C++ code alwas can be, but I see dpkg, which is in C, and I
see apt, which is in C++, and I don't understand how you can be so sure
about that.

Using C does not grant you immediate success. It does not give you
compatibility for free. It does not give you extensibilty and operability.

Neither does C++.

You have to code it.
 
> > The only contributions to our packaging systems today are done with C++
> > (apt), and perl (install methods).
> Yes, yes. But you won't be able to use perl with C++ libraries.

Big deal. The current perl code does usually not use C libraries. They call
the executable. Great, eh?

Marcus

-- 
"The purpose of Free Software is Free Software.
The End and the Means are the same."  -- Craig Sanders

Marcus Brinkmann <[EMAIL PROTECTED]>



Re: time to rewrite dpkg

1999-05-20 Thread Marcus Brinkmann
On Thu, May 20, 1999 at 08:39:32PM +0200, Marek Habersack wrote:
> > Of course, you are entitled to your opinion. But the decisions are made by
> > people who to do the work.
> Not in this case. This is not their graduate project, nor an experiment.
> It's a package which the entire Debian distribution relies on

You're wrong, reread what Aaron said. The CURRENT dpkg is what the entire
distribution relies on. The CURRENT dpkg is written in C. You should be
happy.

If you believe it would be better to rewrite dpkg in C, go for it. More
power to you!

> > The size of the language or the size of the binaries?
> binaries, of course. Who cares about the language?

Interesting. So you prefer bloated program code instead of bloated binaries?
The time a human needs to understand and maintain a program is less
valuaable to you than a few kilobytes of source code? People read program
code, but they almost never read binaries directly.
 
> > The language was carefully designed to avoid bloat of the binaries. C++ does
> Dream. C++ does bloat programs.

Some compiler bloat. The language does not.

And bloat is put a bit too simple. I don't care about a few kilobytes if it
has direct and noticeable positive effect in the source code.
 
> > and cleaner. About 50 percent of code is error handling. Use of exception
> > can reduce the amount of actual program code tremendously, which does
> > decrease the size of the program code (hence the binary). AND it is easier
> > to understand.
> You would be surprised what problems people have with all the try/catch
> blocks. 

You would be surprised what problems people have with all this pointer
arithmetic.

You would be surprised what problems people have with all these regular
expressions.

You would be surprised what problems people have with all these parentheses.

You would be surprised what problems people have with all these gotos.

You would be surprised what problems people have with all these mnemonics.

Did I get my point across?
 
> > Use of the standard library is another point. The standard library makes the
> > program code easier, and really does not increase the overall code, because
> > if you don't use it, you have to replace it with your own code, which is a
> > source of errors, too.
> You are talking about things like STL or other template-based libraries?
> Then they will increase the binary size, and they will do it significantly.

How scary. What exactly is the problem with a bigger binary?

> > >  The other is, C++ is in a constant state of flux.  
> > 
> > This is plain wrong.
> > 
> > Your knowledge of the C++ language is a few years behind of current
> > standards and implementation.
> C++ isn't in state of flux anymore, true, but egcs (and it's the only
> compiler around on the GNU platform which can be used to do serious C++
> programming) is.

See, I am the maintainer of libgtkmm. This is a huge wrapper library around
Gtk, which uses a lot of templates, classes, derivation, whatever. The
maintainer (currently about three people are actively working on the code)
were able to maintain compatibility even with g++ 2.7.2.3 (which is
horribly broken in every respect) until recently. I don't see them rewriting
their code everytime with another egcs release.

Marcus

-- 
"The purpose of Free Software is Free Software.
The End and the Means are the same."  -- Craig Sanders

Marcus Brinkmann <[EMAIL PROTECTED]>



Re: Time to rewrite dpkg IN IDL! :)

1999-05-20 Thread Marcus Brinkmann
On Fri, May 21, 1999 at 12:27:32AM +1000, Craig Sanders wrote:
> 
> C++ may be OO, but it's not very good OOand it tends to compile into
> code which is both bloated and slow.
> 
> dpkg is already far too slow on old hardware...hell, it's too slow on
> a P200 with 200MB of RAM, now that the status and available files have
> over 3300 packages detailed in them.

Yeah, it's slow, and it's written in C.

And you want to cinvince me by your un-emotional argumentation that it will
be even slower in C++?

Strange. Last time I took a look at Stroustrups language it seemed that it
would be carefully designed to not enforce too much overhead on language
features, and no overhead on language features not used. Stroustrups book
goes into detail, and always mentions which run time overhead you have to
expect when you use a certain language feature. Most features are only one
function call away.

Exceptions are the single exception. Use of them will reduce the amount of
code you have to write, and improves error handling drastically. Some
functions that have a lot of error conditions to check that are fourty lines
of C code with deep nesting are reduced to four or five lines of flat C++
code.

The speed of dpkg has little to do with the language (as long as you use a
compiled and not interpreted language). The number of packages is the cause
of the speed problem, and the involved algorithms (parsing the ASCII file
and putting it into a data structure). I am sure there is really room of
improvement here.

Picking one compiled language in favour of another for speed consideration
but ignoring things like maintenability and development of code looks
simple-minded to me. The difference in speed will be unnoticable if the same
algorithms are used.

Marcus

-- 
"The purpose of Free Software is Free Software.
The End and the Means are the same."  -- Craig Sanders

Marcus Brinkmann <[EMAIL PROTECTED]>



Re: exim mailer/dhis.org/debian mailing list question

1999-05-20 Thread Remi Lefebvre
On Thu, May 20, 1999 at 04:12:57AM -0500, [EMAIL PROTECTED] wrote:
> Howdy all.  I'm running potato with exim mailer and i am using the
> dhis.org dynamic dns service (there happens to be a nice dhis.org client
> in unstable, though it would be easy enough to compile it or get
> binaries...); it is set up so that mail sent to me while i'm offline is
I compiled my package on a slink box. You can get it at:
http://master.debian.org/~remi

regards,
remi

-- 
Remi Lefebvre - <[EMAIL PROTECTED]>



Re: Mail delivery failed: returning message to sender

1999-05-20 Thread Claudio S. Suarez Sanchez



   This is my fault. I'm sorry. No space left on my disk.


*
>This message was created automatically by mail delivery software.
>
>A message that you sent could not be delivered to all of its
>recipients. The following address(es) failed:
>
>  [EMAIL PROTECTED]:
>  generated |/home/css/bin/miprocmail
>  
>The following text was generated during the delivery attempt:
>  
>-- |/home/css/bin/miprocmail --
>  
>procmail: No space left to finish writing "backup"
>procmail: No space left to finish writing "Mail/devel"
> 
>-- This is a copy of the message, including all the headers. --

***

On Tue, May 18, 1999 at 05:02:13PM -0400, Brian Almeida wrote:
> On Wed, May 19, 1999 at 01:20:03AM +0200, Mail Delivery System wrote:
> > This message was created automatically by mail delivery software.
> Can we please block this guy?

   I can unsubscribe myself to debian-devel... But, do you think
   it is necesary ?

Regards,
  
  Claudio.



Re: evan leibovitch and the LPI certification tests

1999-05-20 Thread Manoj Srivastava
Hi,
>>"Tyger" == Tyger Sunshine-Hill <[EMAIL PROTECTED]> writes:


 Tyger> Well, maybe, but the fact is that Debian could use some
 Tyger> sponsorships or major donations,

We could? What shall we use them for? (Not that we shall turn
 away any donations, mind you, but we may *need* less than one
 thinks). 

 Tyger> and as long as RH keeps the spotlight, guess who they go to?

From the tone of your question, I'd say the expected answer is
 RH. More power to them. They are _not_ the enemy.

 Tyger> Eventually, we have to get Debian out of its shell and get
 Tyger> "the average linux user" (If there is such a thing) to use
 Tyger> Debian more.

Why on earth do we have to do that? 

 Tyger> If we don't, what is the point of pouring so much work into
 Tyger> making such a useful and _flexible_ distribution?

I can't speak for others, but *I* do it cause it pleases my
 muse. Getting Debian out to the great unwashed masses rouses little
 but mild curiosity in me, and certainly not eough to warrant the
 amount of effort I put into my packages. 

Market share and World domination are not goals I strive to
 achieve. And fragmenting the free software community to achieve them
 is definitly not the way I want to go.

I *like* Red Hat.

manoj
-- 
 UFOs are for real: the Air Force doesn't exist.
Manoj Srivastava   <[EMAIL PROTECTED]>  
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E



Re: Time to rewrite dpkg

1999-05-20 Thread Marek Habersack
* Marcus Brinkmann said:
> On Thu, May 20, 1999 at 12:47:59AM +0200, Marek Habersack wrote:
> > But the problem is that templates, nor exceptions or rtti (which are all
> > elements of MODERN C++ programming) don't work well enough on the GNU
> > platform...
> 
> It would be silly to try to use all features of such a complex language as
Templates, exceptions, polymorphism, encapsulation, multiple inheritance,
method and operator overloading - they all should be used in ANY modern C++
program. And at the very least, templates and exceptions still don't work
well enough in egcc.
 
> And note that development will just start. By the time this project enters a
> critical stage, egcs will be improved again.
No, the development shouldn't start yet. A project should be presented to
the iterested people and a discussion should take place. Only THEN the
actual development should start. By that time many things can change, yes.
But if you start to write your code and base it on some feature which will
change in the egcs, then what? Simple - you will have to rewrite all your
code.

marek


pgpQPPTsW3lkG.pgp
Description: PGP signature


Re: request to kill nag messages

1999-05-20 Thread Joel Klecker
At 18:10 +0100 1999-05-20, Adrian Bridgett wrote:
On Thu, May 20, 1999 at 06:47:28AM -0400, Dirk Eddelbuettel wrote:
  Brian> Nag also sends emails regarding old bugs on your packages.  I never
  Brian> subscribed to that.  :p
All I'm saying: Everybody is free to procmail away whatever they don't like.
This sounds like a good idea - send the Nag reports to the email address
@debian.org (which hopefully everyone has).  Then if some kind soul could
tell us what lines to add where to filter it everyone will be happy.
Don't presume to speak for everyone.
I would not be happy with that.
I will only say that "just filter it out" or "just press the delete 
key" are spammers' answers.

I am well aware of my bugs, and I DO NOT need reminders of them.
One last thing, the next nag message I get will be treated as spam.
--
Joel Klecker (aka Espy)Debian GNU/Linux Developer
mailto:[EMAIL PROTECTED]> mailto:[EMAIL PROTECTED]>
http://web.espy.org/>   http://www.debian.org/>


Re: Time to rewrite dpkg

1999-05-20 Thread Marek Habersack
* Marcus Brinkmann said:
> On Thu, May 20, 1999 at 01:03:46AM +0200, Marek Habersack wrote:
> 
> > 3. Most programmers would write code in C
> 
> Yeah, uh. But that's the point isn't it?
No, that's the reality.

> The current dpkg is written in C. How many programmers are working on it?
Again, that's not an argument. People come and people go, and more of them
know C than C++. Besides, ech..., how can you draw an argument like this???
Is that a reason to write dpkg in Heskell, because the current maintainer
fancies that? And what if he gets tired maintainig it? And what about
compatibility? Extensibility? Interoperability? They don't matter at all,
right?

> The only contributions to our packaging systems today are done with C++
> (apt), and perl (install methods).
Yes, yes. But you won't be able to use perl with C++ libraries.

marek


pgphVH7alp65y.pgp
Description: PGP signature


Re: Time to rewrite dpkg

1999-05-20 Thread Marcus Brinkmann
On Thu, May 20, 1999 at 12:47:59AM +0200, Marek Habersack wrote:
> But the problem is that templates, nor exceptions or rtti (which are all
> elements of MODERN C++ programming) don't work well enough on the GNU
> platform...

It would be silly to try to use all features of such a complex language as
C++ in a single program. The features exist to support your style of OO
programming, whatever this is. Only very complicated projects would want to
make use of such features in a way that current egcs can't handle.

And note that development will just start. By the time this project enters a
critical stage, egcs will be improved again.

Thanks,
Marcus

-- 
"The purpose of Free Software is Free Software.
The End and the Means are the same."  -- Craig Sanders

Marcus Brinkmann <[EMAIL PROTECTED]>



Re: Xfree 3.3.3.1 for slink anywhere?

1999-05-20 Thread Brian Servis
*- On 19 May, Adrian Bridgett wrote about "Xfree 3.3.3.1 for slink anywhere?"
> I've spent quite a while trying to find out but the only reference I could
> see doesn't have any packages there anymore (www.debian.org/~vincent IIRC).
> 
> NB: I know that generally you can just grab the Xserver you want.
> 


deb http://ftp.netgod.net/ x/

-- 
Brian 
-
Mechanical Engineering  [EMAIL PROTECTED]
Purdue University   http://www.ecn.purdue.edu/~servis
-



Re: Time to rewrite dpkg

1999-05-20 Thread Marcus Brinkmann
On Thu, May 20, 1999 at 01:03:46AM +0200, Marek Habersack wrote:

> 3. Most programmers would write code in C

Yeah, uh. But that's the point isn't it?

The current dpkg is written in C. How many programmers are working on it?

The only contributions to our packaging systems today are done with C++
(apt), and perl (install methods).

Marcus

-- 
"The purpose of Free Software is Free Software.
The End and the Means are the same."  -- Craig Sanders

Marcus Brinkmann <[EMAIL PROTECTED]>



Re: time to rewrite dpkg

1999-05-20 Thread Marek Habersack
* Marcus Brinkmann said:

> [...]
> 
> but it should have not. Please ignore my last mail on this topic. I just
> noticed that the general discussions was vastly ahead of your contribution.
Too late :))) I just responded :)

marek


pgpHQENkp6Wkz.pgp
Description: PGP signature


Re: time to rewrite dpkg

1999-05-20 Thread Marek Habersack
* Marcus Brinkmann said:

> This mail is ignoring Aaron's request for peace over this topic, but I am
I just can't resist writing it: there was NO war on this subject, so why do
you and Aaron want to make peace?

> > become the new standard, then the language you decide to use is very
> > important.
> 
> Think of egcs. We really should be happy that someone is actually deciding
egcs is a compiler which is not finished yet, it is (at least in respect
with C++) incompatible with gcc...

> to work on our package managment. Even if Aarons dpkg will not be the one
> used in future Debian releases, it will have affect on the current dpkg.
Of course, and nobody denies it.

> > > extremely friendly towards C++ implementations, and much more powerful 
> > > than
> > > common interop mechanisms with conventional languages such as RPC.
> > 
> > IMHO.  What the best thing to do is write your libdpkg in C.  Remember
> > C is still the standard language for Unix.
> 
> dpkg is not Unix. Do I have to say more? Dpkg is a package manager, and any
> language can be chosen. If Aaron had said he would write it in Scheme, I
> would have applauded it. If you tell me you want to write one, too, but in
> Pascal, more power to you.
Wrong. You're getting it all wrong. dpkg is a vital component of the Debian
distribution and, as such, it should be written with future in mind! And
future can bring a dozen of programmers who can extend dpkg in some way and
using a dozen differend languages. Then CAN interface with a C library
without any problems, then CANNOT interface a C++ library. Point. So, if you
want dpkg to be interoperable, extensible and following the rule "everyone
uses what language s/he likes", keep small size - you have to do it in C
(all disscusions about which language is better put aside, ok?).

> Of course, I am exagerrating. There are pros and contras for any language,
> but it is silly to rule out anything beside C for historical reasons.
You get it wrong again. It is not for HISTORICAL reasons, it's for the
current status quo and the FACTS that speak in C's favor.

> >  And it will also allow a
> > larger number of languages to possibily use those library calls.
> 
> Who will write all these programs? Will you? The current libdpkg is written
> in C, how many programs use it? If you say, that YOU are going to write
> something in a language you need support for, you would have a point.
Now, now! Those arguments are pretty inadequate, I'd say. Tell me, how many
programs use libcap? Is that a reason why libcap should be dumped? And, I'm
sure, there will be someone who will want to write the programs IF the
library is well-designed, well-written and INTEROPERABLE. And the
hypothaetical person will be free to chose the preferred language for his
work - but it will not be possible when the library is in C++.

> > It's your
> > project and you can do what you like, but I believe that libdpkg
> > should definately be written in C.
> 
> Of course, you are entitled to your opinion. But the decisions are made by
> people who to do the work.
Not in this case. This is not their graduate project, nor an experiment.
It's a package which the entire Debian distribution relies on - and that
makes it a COMMON EFFORT no matter who writes the program. The decisions how
to design and write the program should come from the developer community - a
common sense is what we need.

> > wrappers around libdpkg for that.
> >  C++ has problems, its size is one
> > of them.
> 
> The size of the language or the size of the binaries?
binaries, of course. Who cares about the language?

> The language was carefully designed to avoid bloat of the binaries. C++ does
Dream. C++ does bloat programs.

> not enforce any language feature on the programmer. The biggest size concern
> are exceptions. But exceptions will make error handling oh so much simpler
Not only. The IO library is really HUGE and you have to use it to be 100% C++.

> and cleaner. About 50 percent of code is error handling. Use of exception
> can reduce the amount of actual program code tremendously, which does
> decrease the size of the program code (hence the binary). AND it is easier
> to understand.
You would be surprised what problems people have with all the try/catch
blocks. 

> Use of the standard library is another point. The standard library makes the
> program code easier, and really does not increase the overall code, because
> if you don't use it, you have to replace it with your own code, which is a
> source of errors, too.
You are talking about things like STL or other template-based libraries?
Then they will increase the binary size, and they will do it significantly.

> >  The other is, C++ is in a constant state of flux.  
> 
> This is plain wrong.
> 
> Your knowledge of the C++ language is a few years behind of current
> standards and implementation.
C++ isn't in state of flux anymore, true, but egcs (and it's the only
compiler around on the GNU platform which can be use

DVD writers

1999-05-20 Thread MRI
Dear all:

Do any of yo have an idea where I can find a DVD-writer that is
compatible (software and hardware wise) with SUN workstations (Unix /
Solaris operating system)?

Thanks, Theo



Re: time to rewrite dpkg

1999-05-20 Thread Marcus Brinkmann
On Thu, May 20, 1999 at 08:02:09PM +0200, Marcus Brinkmann wrote:
> 
> This mail is ignoring Aaron's request for peace over this topic,

[...]

but it should have not. Please ignore my last mail on this topic. I just
noticed that the general discussions was vastly ahead of your contribution.

Thanks,
Marcus

-- 
"The purpose of Free Software is Free Software.
The End and the Means are the same."  -- Craig Sanders

Marcus Brinkmann <[EMAIL PROTECTED]>



Re: time to rewrite dpkg

1999-05-20 Thread Marcus Brinkmann

Hi,

This mail is ignoring Aaron's request for peace over this topic, but I am
not the person who can keep silent if there are obvious mistakes to point
out.

On Thu, May 20, 1999 at 12:39:39AM -0400, Dan Nguyen wrote:
> 
> Well your subject says it all "Time to rewrite dpkg."  I'm assuming
> that you want to completely rewrite dpkg as a replacement for the
> current dpkg.  A sort of dpkg2 persay.  If your dpkg does eventually
> become the new standard, then the language you decide to use is very
> important.

Think of egcs. We really should be happy that someone is actually deciding
to work on our package managment. Even if Aarons dpkg will not be the one
used in future Debian releases, it will have affect on the current dpkg.

Everyone should be upset about the current state of dpkg. The reason we are
not is because w are frightened, too.
 
> > The interoperability subject isn't really a big issue; the base
> > libraries could still be done in C for all I care, and I may just do so. But
> > C++ is compatible with C, and as such anything that can be wrapped into C
> > can be wrapped into C++, or vice versa. In addition, we have CORBA, which is
> > extremely friendly towards C++ implementations, and much more powerful than
> > common interop mechanisms with conventional languages such as RPC.
> 
> IMHO.  What the best thing to do is write your libdpkg in C.  Remember
> C is still the standard language for Unix.

dpkg is not Unix. Do I have to say more? Dpkg is a package manager, and any
language can be chosen. If Aaron had said he would write it in Scheme, I
would have applauded it. If you tell me you want to write one, too, but in
Pascal, more power to you.

Of course, I am exagerrating. There are pros and contras for any language,
but it is silly to rule out anything beside C for historical reasons.

>  And it will also allow a
> larger number of languages to possibily use those library calls.

Who will write all these programs? Will you? The current libdpkg is written
in C, how many programs use it? If you say, that YOU are going to write
something in a language you need support for, you would have a point.

> It's your
> project and you can do what you like, but I believe that libdpkg
> should definately be written in C.

Of course, you are entitled to your opinion. But the decisions are made by
people who to do the work.

> If you want to use C++ for he actual dpkg, then you can make C++
> wrappers around libdpkg for that.
>  C++ has problems, its size is one
> of them.

The size of the language or the size of the binaries?

The language was carefully designed to avoid bloat of the binaries. C++ does
not enforce any language feature on the programmer. The biggest size concern
are exceptions. But exceptions will make error handling oh so much simpler
and cleaner. About 50 percent of code is error handling. Use of exception
can reduce the amount of actual program code tremendously, which does
decrease the size of the program code (hence the binary). AND it is easier
to understand.

Did you take a look at the error handling code of dpkg?

Use of the standard library is another point. The standard library makes the
program code easier, and really does not increase the overall code, because
if you don't use it, you have to replace it with your own code, which is a
source of errors, too.

>  The other is, C++ is in a constant state of flux.  

This is plain wrong.

Your knowledge of the C++ language is a few years behind of current
standards and implementation.

Thanks,
Marcus

-- 
"The purpose of Free Software is Free Software.
The End and the Means are the same."  -- Craig Sanders

Marcus Brinkmann <[EMAIL PROTECTED]>



Xfree 3.3.3.1 for slink anywhere?

1999-05-20 Thread Adrian Bridgett
I've spent quite a while trying to find out but the only reference I could
see doesn't have any packages there anymore (www.debian.org/~vincent IIRC).

NB: I know that generally you can just grab the Xserver you want.

Cheers

Adrian

email: [EMAIL PROTECTED], http://www.poboxes.com/adrian.bridgett
Windows NT - Unix in beta-testing.   PGP key available on public key servers
Avoid tiresome goat sacrifices  -=-  use Debian Linux http://www.debian.org



Re: request to kill nag messages

1999-05-20 Thread Adrian Bridgett
On Thu, May 20, 1999 at 06:47:28AM -0400, Dirk Eddelbuettel wrote:
> 
>   Brian> Nag also sends emails regarding old bugs on your packages.  I never
>   Brian> subscribed to that.  :p
> 
> All I'm saying: Everybody is free to procmail away whatever they don't like.

This sounds like a good idea - send the Nag reports to the email address
@debian.org (which hopefully everyone has).  Then if some kind soul could
tell us what lines to add where to filter it everyone will be happy.

Cheers

Adrian

email: [EMAIL PROTECTED], http://www.poboxes.com/adrian.bridgett
Windows NT - Unix in beta-testing.   PGP key available on public key servers
Avoid tiresome goat sacrifices  -=-  use Debian Linux http://www.debian.org



Re: mass-installing Debian

1999-05-20 Thread Adrian Bridgett
On Wed, May 19, 1999 at 01:06:48PM -0400, tony mancill wrote:
[snip]
> On a related note, couldn't we have an environment variable set at
> installation time, e.g. "NON_INTERACTIVE_DPKG=TRUE", and have the
> maintainer scripts check this to see if they should ask questions or not? 
> If this variable were set to TRUE, I'd like to see packages which require
> configuration send mail to root with a message like: 

Somone a while ago suggested allowing the user to automatically answer all
of the "overwrite existing file? [N/y]" that dpkg asks when the config file
changes in the packge.  Just getting rid of these messages would get rid of
quite a few.

Personally I _always_ keep the current one. Then every now and again I go
through /etc and merge in any changes.

Adrian

email: [EMAIL PROTECTED], http://www.poboxes.com/adrian.bridgett
Windows NT - Unix in beta-testing.   PGP key available on public key servers
Avoid tiresome goat sacrifices  -=-  use Debian Linux http://www.debian.org



Re: [ITP/mostly packaged] hftpd

1999-05-20 Thread Adrian Bridgett
On Tue, May 18, 1999 at 05:09:27PM -0400, Michael Stone wrote:
[snip]
> > We really should have a policy for things like this. How about adding
> > another Provides: to kernel images (built by the excellent make-kpkg):
> 
> Because too many people don't use debian kernel images.

How about only making dependant packages "suggest" the appropriate kernel
version?  That gets around this problem.

make-kpkg really rocks.  Everyone should use it - and those deviants using
other distributions can always use "alien" ;-)

Personally I'm fairly inclined to making it a recommends after all - anyone
who doesn't use make-kpkg deserves what they get.

Adrian

email: [EMAIL PROTECTED], http://www.poboxes.com/adrian.bridgett
Windows NT - Unix in beta-testing.   PGP key available on public key servers
Avoid tiresome goat sacrifices  -=-  use Debian Linux http://www.debian.org



Re: better /etc/init.d/network

1999-05-20 Thread Marco d'Itri
On May 19, Michel Onstein <[EMAIL PROTECTED]> wrote:
 
 >As we're discussing things here... i think it's important that we add the
 >possbility to attach IPv6 addresses to an interface. Since you can have
Agreed. We should try doing it right the first time.

-- 
ciao,
Marco



Re: request to kill nag messages

1999-05-20 Thread Christian Kurz
Christian Meder <[EMAIL PROTECTED]> wrote:
> On Thu, May 20, 1999 at 11:48:25AM +0200, Christian Kurz wrote:
> > Christian Meder <[EMAIL PROTECTED]> wrote:
> > > Example: I've got an open old bug report that flying
> > > (a X11 pool game) doesn't support 16/24 bit displays. The upstream
> > 
> > This would speak for making the mechanismen configurable. Would this be
> > a solution?

> Making which mechanism configurable ? The bug system ? The nag messages ?
> Could you expand what you are aiming at ?

I meant the nag-messages about which we are talking here. Would be a
solution to make it configurable if you want to get those or not? 

Cheers
   Christian
-- 

* Christian Kurz  Debian Developer *
* Use Debian - a free Operating System for your PC *




Re: Release Plans (1999-05-10)

1999-05-20 Thread Richard Braakman
Oleg Krivosheev wrote:
> is there REALLY plans to release something around June 6?

No, and there never were.  Maybe they mean snapshots of unstable?


Richard Braakman



Re: Time to rewrite dpkg

1999-05-20 Thread Antti-Juhani Kaijanaho
On Fri, May 21, 1999 at 12:25:58AM +1000, Anthony Towns wrote:
> But yes, you can write an "id()" function which behaves differently depending
> on what is passed to it.

You misunderstand.  id is the identity function, defined for all types
and returns what it is given.  In C++ terms, then:

template 
T id (T t)
{
  return t;
}

and in Haskell

id x = x

with the optional type signature

id :: a -> a

OO people speak of polymorphism.  FP people call that polymorphism
"ad-hoc polymorphism", while the parametric polymorphism commonly
seen in functional languages is usually regarded as superior in most
application areas.

In parametric polymorphism, functions always behave the same way
independent of what data type it is passed.  Functions operate on as
many types is possible: id, for example, does nothing to its argument
so it can be applied to any type.

In ad-hoc polymorphism, you never know what a function does unless you
know the exact type of the argument.  In parametric polymorphism, you
always know what a function does, regardless of what it is applied to.

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

  Good Times are back again!
  http://www.iki.fi/gaia/zangelding/



Re: Time to rewrite dpkg

1999-05-20 Thread Antti-Juhani Kaijanaho
On Thu, May 20, 1999 at 03:07:03PM +0200, Sven LUTHER wrote:
> I also heard that templates bloat the code

Depends on how you use them.  Templates work by duplicating code.

> what size are your executable compared to equivalent C stuff,

Equivalent C code?  For every template in C++ the equivalent code
parametrised with macro expanion?  About the same.

> what speed do you loose by using C++ templates.

Runtime speed?  None.  Templates are optimised for speed.  In fact, one
of the design goals of C++ is that all features must be implementable
affordably (from a systems programming point of view).

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

  Good Times are back again!
  http://www.iki.fi/gaia/zangelding/



Re: mass-installing Debian

1999-05-20 Thread Jens Ritter
Dean Carpenter <[EMAIL PROTECTED]> writes:

> I've been thinking a bit about the need for mass-installations.  Having
> done a few of them, it gets to be a tad tedious ...
> 
> Currently, the preinst and postinst scripts ask the user questions, and
> make changes according to the responses.  Instead of that, we need a
> general service script that processes a package-specific file containing
> questions and answer-variables.  The results of this get appended to
> an installation response file that each package can source to retrieve
> the answers it needs.  Hrmm, got that ?

This solves only one problem: Questions asked during the installation.

It does not solve the problems you encounter when setting up e.g. a
beowulf type system. 

What do you do with an NFS mounted /usr partition? 
How do you traverse setup information to all nodes? 
How do you handle different setups for different nodes?

a clueless,

Jens


P.S.: Please vote against Spam! At
 http://www.politik-digital.de/spam/
(Sorry Europeans only)
---
[EMAIL PROTECTED]   [EMAIL PROTECTED]
Key ID: 2048/E451C639 Jens Ritter
Key fingerprint: 5F 3D 43 1E 24 1E CC 48  1E 05 93 3A A7 10 73 37 



Re: evan leibovitch and the LPI certification tests

1999-05-20 Thread Craig Brozefsky
"Tyger Sunshine-Hill" <[EMAIL PROTECTED]> writes:

> Well, maybe, but the fact is that Debian could use some sponsorships or 
> major donations, and as long as RH keeps the spotlight, guess who they go 
> to? Eventually, we have to get Debian out of its shell and get "the average 
> linux user" (If there is such a thing) to use Debian more. If we don't, what 
> is the point of pouring so much work into making such a useful and 
> _flexible_ distribution?

Well, everyone has their own answer to that, but I'm satisfied that
me, and my employer and some of my freinds are able to use this
marvelous system.

-- 
Craig Brozefsky<[EMAIL PROTECTED]>
Less matter, more form!  - Bruno Schulz
ignazz, I am truly korrupted by yore sinful tzourceware. -jb
The Osmonds! You are all Osmonds!! Throwing up on a freeway at dawn!!!



Re: time to rewrite dpkg

1999-05-20 Thread Marek Habersack
* Brandon Mitchell said:
> Hi Aaron,
> 
> I would be interested in seeing your design.  It may clear up some
> concerns as to why you are picking your language (which seems to have
I would like to see it as well. So far, not even a single argument has been
presented to justify the selection of C++ - and namely, what advantages it
gives here.

> guess I'm just a big fan of getting the design right since the resulting
> code of a bad design is much more difficult to fix than bad code with a
> good design.
Holy words! The design in such an important project is the primary objective
- the more thought over, the better will be the code.

marek


pgpgEZ2HkN2BQ.pgp
Description: PGP signature


vmware

1999-05-20 Thread Steve Lamb
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Reply-to...  reply-to...


==BEGIN FORWARDED MESSAGE==
From: "Steve Lamb" <[EMAIL PROTECTED]>
To: "Pollywog" <[EMAIL PROTECTED]>
Date: Thu, 20 May 1999 09:10:48 -0700
Reply-To: "Steve Lamb" <[EMAIL PROTECTED]>

On Thu, 20 May 1999 16:06:35 - (UTC), Pollywog wrote:

>$99 will be the price?   I was concerned it might cost much more than that.

$300 for commercial use, $99 for private, home use.  I've seriously
considered forking over the $99 so I can convert my machine machine to a
dual-boot system with Windows running inside Linux.  I wouldn't want to run
games on a VM so I would dual-boot for that, but for most of the applications
that I do need in Windows a VM machine would be perfect.

>If it works, I would be willing to part with $100 for it.

I'm suitably impressed with what they have done.

- -- 
 Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
 ICQ: 5107343  | main connection to the switchboard of souls.
- ---+-



===END FORWARDED MESSAGE===

- -- 
 Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
 ICQ: 5107343  | main connection to the switchboard of souls.
- ---+-

-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.0 (C) 1997 Pretty Good Privacy, Inc

iQA/AwUBN0Q1LXpf7K2LbpnFEQI68wCffWlSrnpdlj/svHuWPKetjrywUDcAoJsh
mQQKeGO0ZuSwiyu/BiGb5dW2
=ntup
-END PGP SIGNATURE-




Re: Time to rewrite dpkg

1999-05-20 Thread Marek Habersack
* Aaron Van Couwenberghe said:

> > The answer is - you can't... All the languages you mentioned have clean C
> > interacing methods, but no C++ ones. The reason is that C++ is not
> > interoperable.
> 
> No, no, no! one word for everyone. CORBA!
I'm sorry to say that, but dream on...

marek


pgpEM6prF0cPa.pgp
Description: PGP signature


Re: Time to rewrite dpkg

1999-05-20 Thread Marek Habersack
* Hamish Moffatt said:

> > mention templates. And I remember how did the C++ interface, in binary
> 
> This was certainly true in g++ 2.7.x, but egcs seems much better.
Much better, yes, but it's still not finished.

> (Exceptions and templates anyway; I don't know what rtti is.)
RTTI stands for RunTime Type Identification

marek


pgpduorjGLesk.pgp
Description: PGP signature


Re: Time to rewrite dpkg

1999-05-20 Thread Marek Habersack
* Sven LUTHER said:

> > > Is that true, I have heard this agrument often, but is it true, and is it 
> > > still
> > > so today ? Is there effort made to fix this ? how far are they ?
> > 
> > I haven't used RTTI, but in my experience templates work without problems
> 
> I also heard that templates bloat the code, not just that they don't
> work, what about it, what size are your executable compared to
> equivalent C stuff, what speed do you loose by using C++ templates.
I don't know about the overhead on GNU, but from what I remember Borland
added about 30KB to every C++ executable whether it used exceptions or not
(it was mostly the startup and stack unwinding code). As to the speed, it
shouldn't affect it - as long as you don't use the try/catch blocks in your
code.

marek


pgpvC4oHpSIea.pgp
Description: PGP signature


Re: Time to rewrite dpkg

1999-05-20 Thread Marek Habersack
* Antti-Juhani Kaijanaho said:

> > Is that true, I have heard this agrument often, but is it true, and is it 
> > still
> > so today ? Is there effort made to fix this ? how far are they ?
> 
> I haven't used RTTI, but in my experience templates work without problems
> and exceptions work most of the time (the problems I have may well be
Yes, most of the time..., but you can't rely on them working all the time.

> my bugs, not egcs').  Namespaces need work: for example, there is no
> clear separation between global namespace and the std namespace.
The namespace concept, as documented in the standards, is not implemented
even in half on the GNU platform, IMO.

> EGCS has contributed much to the progress.  A year ago I didn't feel
> like C++ was ready for my use on the GNU platform.
That's true, but it will take some more time before it is fully working.

marek


pgpjjD7Pdpr2p.pgp
Description: PGP signature


Re: Time to rewrite dpkg

1999-05-20 Thread Marek Habersack
* Sven LUTHER said:
> On Thu, May 20, 1999 at 12:44:02AM +0200, Marek Habersack wrote:
> > 
> > 1. you create a C library with all the dpkg functionality inside
> > 2. you compile and link it as a shared library
> > 3. you write several simple drivers to interface the user to that library 
> > 4. the .so is loaded only ONCE - that's what shared libraries are for
> > 
> 
> But you still have to parse the database, because you load the library only
> once don't mean that you will keep the database as is between two invocation 
> of
> the front-end that uses the library. Sure it can be done, but it is not
That's true. But it can be overcome by either using a database access daemon
(wasteful) that all programs communicate with in order to access the
database - it has the advantage that all the consistency checks are
performed on one level - by the daemon and it's the daemon who serializes
the database access. Second, the database itself could be optimized by using
a different format (perhaps, as RPM does, a DB database?) to speed up
searching it.

regards,
  marek


pgpa0696Ld8bo.pgp
Description: PGP signature


Re: Time to rewrite dpkg

1999-05-20 Thread Marek Habersack
* Sven LUTHER said:

> > > Agreed.  Too bad C++ does not support parametric polymorphism too well.
> > > Templates come close, so the hope is not lost.
> > But the problem is that templates, nor exceptions or rtti (which are all
> > elements of MODERN C++ programming) don't work well enough on the GNU
> > platform...
> 
> Is that true, I have heard this agrument often, but is it true, and is it 
> still
> so today ? Is there effort made to fix this ? how far are they ?
Yes, it is true. Moreover, AFAIK the g++ 2.7.2.x and egcs differ
substantialy in that matter - and that's another problem.

> I just want to be sure this is true before people start using this as argument
> without even checking if things still are like that.
For what it's worth, egcs is still in active development - thus you
shouldn't rely upon it too strongly (yes, potato uses egcs as a standard
compiler, but it still has problems) and g++ 2.7.2.x doesn't support the
advanced features of C++ very well...

marek


pgpLDWHFytWal.pgp
Description: PGP signature


Re: Time to rewrite dpkg

1999-05-20 Thread Marek Habersack
* Sven LUTHER said:

> > > Polymorphism is such an obvious pillar of structured programming that I
> > > can't understand how anybody could live without it.
> > Is it? AFAICS none of the traditional languages like Pascal or C has
> > polimorphism at its base...
> 
> What you call polymorphism is just function name overloading, isn't it ? or
Yes, function and operator overloading.

> does C++ implement true polymorphism this days, like what ML does ?
No, to my knowledge it doesn;t :))

regards,
  marek


pgpguwIYUQLjs.pgp
Description: PGP signature


Re: Hints about future improvements

1999-05-20 Thread Sven Rudolph
Adam Di Carlo <[EMAIL PROTECTED]> writes:

> Mitch Blevins <[EMAIL PROTECTED]> writes:
> 
> > I think the ideal solution would be to have a caching proxy based on
> > rsync to communicate with the upstream mirror, and http (or a new
> > apt method) to communicate with apt.
> 
> I was actually thinking the other day about why couldn't apt support
> rsync:// URLs?  That would be the way to implement it.
> 
> OTOH, I wonder how much benefit binary diffs could really give.  Since
> every .deb is mostly gzip compressed data, wouldn't you often need to
> retrieve the whole thing again anyway?

The binary diff/patch tools have to be aware of the Debian package
format. Means on-the-fly decompression/compression. Makes a CPU hog,
but for low bandwith it is useful.

In order to avoid md5sum changes created by different gzip options the
md5sums should be computed for the uncompressed data.

Sven
-- 
Sven Rudolph <[EMAIL PROTECTED]>http://www.sax.de/~sr1/



Intent to package netspades

1999-05-20 Thread Dan Nguyen
Hi all,

NetSpades is a client/server based system designed to be played over a
network of some kind.  It allows 4 people to play Spades, and chat as
well from anywhere in the world.  It includes a console client using
slang.  As well as a gtk based client for X.  And if you've got a
friend which doesn't use Linux then there is Windows base client as
well.  NetSpades is released under the GPL.  More info about NetSpades
can be found at

http://www-ece.rice.edu/~brentmh/spades/

I've got the packages pretty much done.  And will be uploading it in a
few days.


-- 
   Dan Nguyen  | It is with true love as it is with ghosts;
[EMAIL PROTECTED]   | everyone talks of it, but few have seen it.
 [EMAIL PROTECTED]|   -La Rochefocauld, Maxims
25 2F 99 19 6C C9 19 D6  1B 9F F1 E0 E9 10 4C 16



Re: request to kill nag messages

1999-05-20 Thread Christian Meder
On Thu, May 20, 1999 at 11:48:25AM +0200, Christian Kurz wrote:
> Christian Meder <[EMAIL PROTECTED]> wrote:
> > Example: I've got an open old bug report that flying
> > (a X11 pool game) doesn't support 16/24 bit displays. The upstream
> 
> This would speak for making the mechanismen configurable. Would this be
> a solution?

Making which mechanism configurable ? The bug system ? The nag messages ?
Could you expand what you are aiming at ?

Greetings,



Christian
-- 
Christian Meder, email: [EMAIL PROTECTED]
 
What's the railroad to me ?
I never go to see
Where it ends.
It fills a few hollows,
And makes banks for the swallows, 
It sets the sand a-blowing,
And the blackberries a-growing.
  (Henry David Thoreau)
 



Re: Real releases G2 player alpha

1999-05-20 Thread Edward Betts
On Wed, 19 May, 1999, Joey Hess wrote:
> Larry 'Daffy' Daffner wrote:
> The debian installer is uploaded, and uses the rpm. The only advantage over
> using alien is you get:
> 
> a) a clean upgrade path from the older package, and an easy upgrade to
>the next version when it comes out.
> b) registered with mime
> c) menu support
> d) eventual bug fixes if the bugs are things I can work around.

Has any attempt been made to conntact Real and ask whether they want a .deb
package on their download page? It could be done properly then (apart from
being non-free).

-- 
I consume, therefore I am


pgpo2w9N9kcJu.pgp
Description: PGP signature


Re: Time to rewrite dpkg IN IDL! :)

1999-05-20 Thread Craig Sanders
On Thu, May 20, 1999 at 09:27:10PM +1000, Daniel James Patterson wrote:
> Besides, as I said, at this stage, do the analysis, not the coding.  It can
> always be scrapped if it looks like it would be pointless, but I'd like to
> see some non-emotive reasons not to even _consider_ it.

here's a non-emotive reason:

dpkg has to be able to run on 386 and 486 boxes and m68k machines and
other old, slow hardware. any program which can't run on older hardware
is not going to replace the current dpkg...it just won't happen (at
least until debian stops officially supporting 386 and 486 hardware,
which wont be for a long time).

C++ may be OO, but it's not very good OOand it tends to compile into
code which is both bloated and slow.

dpkg is already far too slow on old hardware...hell, it's too slow on
a P200 with 200MB of RAM, now that the status and available files have
over 3300 packages detailed in them.

craig

--
craig sanders



Re: Time to rewrite dpkg

1999-05-20 Thread Anthony Towns
On Thu, May 20, 1999 at 03:34:27PM +0200, Sven LUTHER wrote:
> Something like 
> Objective Caml version 2.02
> # let id x = x ;;
> val id : 'a -> 'a = 
> ---
> Not sure, but i think we are not talking with the same definition of
> the same word ?

C++ isn't a pure object-oriented language -- not everything is an
object by any means. Nor are all classes subclasses of a single "Object"
superclass, which is what you're making use of above.

But yes, you can write an "id()" function which behaves differently depending
on what is passed to it. Either:

class foo { virtual int id() { return 1; } };
class bar : foo { virtual int id() { return 2; } };

foo f;
bar b;

cout << f.id();// 1
cout << b.id();// 2

// So yours would be:
int id2(foo x) { return x.id(); }

or:

int id(int i) { return 1; };
int id(double d) { return 2; };

cout << id(1);  // 1
cout << id(1.0);// 2

Cheers,
aj, who isn't sure this is particularly relevant to debian-devel anymore.

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

   ``There's nothing worse than people with a clue.
 They're always disagreeing with you.'' 
 -- Andrew Over



Re: Time to rewrite dpkg

1999-05-20 Thread Steve Dunham
Enrique Zanardi <[EMAIL PROTECTED]> writes:

> On Wed, May 19, 1999 at 05:24:08AM -0700, Aaron Van Couwenberghe wrote:
> [...]
> > Notably, I'm going to be writing it in C++. This will add
> > about 270k to the boot disks' root image, but as the floppy
> > install methods are for the most part phasing out under the shadow
> > of easier methods, I'm not going to lose any sleep over
> > this. libstdc++ can be minimized for static linkage anyway.

> dpkg is not on the boot disks' root image (thanks god). It's on the base
> system, with dselect, apt and, of course, libstdc++. You won't have to add 
> it. (Let's call that luck). :-)

> OTOH, your opinion that adding 200k to the boot disks' root image, thus
> breaking the "rescue" floppy, doesn't matter because the floppy install
> methods are phasing out is just plainly wrong.  Currently we have three
> ways of booting the installation system: bootable CDs (requires a modern
> BIOS), floppy disk and bootp (requires a netword card with the proper
> ROM, and a bootp+tftp server on the same network). Our bootable CDs use a
> floppy image for booting, the same "resc1440.bin" floppy image that's
> used on a floppy based installation.  That means two of our three methods
> (and I dare to say the third one is used on <5% of Debian installations)
> use the same "rescue" floppy disk. I won't say that's "pashing out". ;-)

Why would this add 200k to the root disk?  We don't have dpkg
on the root disk, it's in the base image.


Steve
[EMAIL PROTECTED]



Re: evan leibovitch and the LPI certification tests

1999-05-20 Thread Tyger Sunshine-Hill

RH isn't "competition" to debian except in the most positive sense of
friendly rivalry.  We have different aims, different goals.  Their
goal is to produce and market a linux distribution which keeps their
company financially viable.  Our goal is to produce a distribution
which does what we want with entirely free software.  Sometimes these
goals co-incide or complement each other. sometimes they don't.  They
certainly don't conflict or harm each other.
Well, maybe, but the fact is that Debian could use some sponsorships or 
major donations, and as long as RH keeps the spotlight, guess who they go 
to? Eventually, we have to get Debian out of its shell and get "the average 
linux user" (If there is such a thing) to use Debian more. If we don't, what 
is the point of pouring so much work into making such a useful and 
_flexible_ distribution?

___
Get Free Email and Do More On The Web. Visit http://www.msn.com


Re: [PRE-ANNOUNCE] DPKGv2 Project

1999-05-20 Thread Aaron Van Couwenberghe
On Thu, May 20, 1999 at 08:47:22AM -0400, Ben Collins wrote:
[snip]
> Do not worry, everyone will have a chance to view the code in an anonymous
> CVS server (which is already setup). There will be ample documentation
> and views on the current spec will be heard. Please consider this a semi
> formal "Intent To Program" :)
> 
> We do have a detailed specification which needs to be finalized. This is
> the milestone we have been waiting for prior to making a formal announcement.

So, now everyoe sees why I vainly attempted (without success and without
real skill ;P) to curb this discussion; I am preceded by one more competent
than I ;)
So, eh, good luck ben! and when you get that CVS server up I'll
definately be helping out.

Aaron



Re: Time to rewrite dpkg

1999-05-20 Thread Sven LUTHER
On Thu, May 20, 1999 at 01:14:31AM -0700, Aaron Van Couwenberghe wrote:
> On Thu, May 20, 1999 at 12:45:45PM +0200, Sven LUTHER wrote:
> > On Thu, May 20, 1999 at 12:44:02AM +0200, Marek Habersack wrote:
> > > * Aaron Van Couwenberghe said:
> > > 
> > > 
> > > > Polymorphism is such an obvious pillar of structured programming that I
> > > > can't understand how anybody could live without it.
> > > Is it? AFAICS none of the traditional languages like Pascal or C has
> > > polimorphism at its base...
> > 
> > What you call polymorphism is just function name overloading, isn't it ? or
> > does C++ implement true polymorphism this days, like what ML does ?
> 
> C++ has offered true polymorphism for some time, complete component
> interchangeability.

Something like 

---
bash-2.02$ ocaml
Objective Caml version 2.02

# let id x = x ;;
val id : 'a -> 'a = 
# id 0 ;;
- : int = 0
# id 1.2 ;;
- : float = 1.2
# id "hello" ;;
- : string = "hello"
# id id ;;
- : '_a -> '_a = 
---

Not sure, but i think we are not talking with the same definition of
the same word ?

Friendly,

Sven LUTHER



Re: Time to rewrite dpkg IN IDL! :)

1999-05-20 Thread Aaron Van Couwenberghe
On Thu, May 20, 1999 at 08:54:45PM +1000, Daniel James Patterson wrote:
> On Thu, May 20, 1999 at 08:44:39PM +1000, Anthony Towns wrote:
> > Speaking of baser instincts, Rationale Rose isn't free software, is it?
> > 
> > Are there any nice (or even not-nice) OO design tools that are?
> > 
> 
> No unfortunatley it isnt.  There is a solaris version, which is a bad port
> of the win32 version, and the win32 version doesn't run under wine.

Argo-UML. It's a UML design tool, designed to export Java; however, its
nature makes it useful for any (distributed or otherwise) OO design project.

I don't have a URL with me.

-Aaron



Re: gdm/xdm/login.app weirdnesses

1999-05-20 Thread Marcelo E. Magallon
On Thu, May 20, 1999 at 01:31:51PM +0200, Martin Bialasinski wrote:
> 
> >> "s" == solomon  <[EMAIL PROTECTED]> writes:
> 
> s> Manager) showed up in unstable so i grabbed it.  Next time i
> s> rebooted, it gave me the gnome login screen and my mouse works, but
> s> for some odd reason it disables my keyboard.
> 
> I already filed a bugreport about this. The maintainer thinks this may 
> be due to xdm and gdm both trying to serve :0.

I'm pretty sure it's because gdm is fighting with getty over vt2.  xdm does
that.  wdm does that.  Login.app doesn't (because it's spawned by init). 
Before the slink release, there was plenty of discussion regarding this. 
Most of the people involved in the discussion agree the start up process
needs to be modified in order to properly address this problem.  Most of the
people agree the modification is not trivial.


Marcelo



  1   2   >