Re: Source-depends?

[Antti-Juhani Kaijanaho]

On Sat, May 22, 1999 at 05:05:10PM -0400, Chris Lawrence wrote:
> Some of these can be detected automatically (#5 could be discovered with a
> grep on debian/rules, for example), but some can't.

So, what's the problem?  We don't autodetect all of binary dependencies
either.  Maintainers generally know what they need to build their packages;
it should be trivial for them to list the dependencies explicitly!

Besides, if source dependencies were completely autodetectable, we wouldn't
need them.

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

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

Re: An 'ae' testimony

[Steve Lamb]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, 23 May 1999 09:47:33 +1000, Craig Sanders wrote:
>2, so far. maybe more. nowhere near as many as those who want vi in some
>form on the boot disks (which is why we have ae's vi emulation mode
>now...and we'd have elvis-tiny too if we hadn't had to switch to slang).

Oh come off it, Craig.  From where I've been reading damn near everyone
has been saying that if ee fits the bill use it.  I think the 2 you mentioned
were those who were completely apposed and one of them is you.  Geez.


- -- 
 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/AwUBN0dHb3pf7K2LbpnFEQIOaACdGEgswYAD6mMwrMQPjdijIyFOulsAniMe
M0KQgMSV8oGLSTgIvojMko5z
=bgdh
-END PGP SIGNATURE-

Re: An 'ae' testimony

[Craig Sanders]

On Sat, May 22, 1999 at 07:54:57PM -0400, Michael Stone wrote:
> On Sun, May 23, 1999 at 09:47:33AM +1000, Craig Sanders wrote:
> > that extra 30k (if it is actually available on the rescue disk) would be
> > better used either as part of the space needed by elvis-tiny (**) or by
>
> I still don't understand the sentiment that people can only understand
> vi.

it's not that vi is the only editor which is understood. it's more that
when you're in a hurry trying to fix some system that has gone down you
don't have time to mess around learning some stupid editor which doesn't
do any of the things you need it to do.

being restricted to a primitive editor after you have become
proficient with vi is akin to re-learning how to talk after having a
stroke...you've lost some really fundamental ability which you take
for granted. when you know vi you don't need to remember the commands,
you just think about what changes you want to make and (metaphorically
speaking) your fingers do the rest. having to use a primitive editor
reduces you to hunt-and-peck typing and having to think about each
individual keystroke.


> Are other editors really so difficult?

yes.  difficult and clumsy and lacking basic functionality.

craig

--
craig sanders

Re: An 'ae' testimony

[Steve Lamb]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, 23 May 1999 10:10:56 +1000, Craig Sanders wrote:

>it's not that vi is the only editor which is understood. it's more that
>when you're in a hurry trying to fix some system that has gone down you
>don't have time to mess around learning some stupid editor which doesn't
>do any of the things you need it to do.

So then, because I use joe almost exclusively and don't have time to
learn vi we should put joe on there as well?  


- -- 
 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/AwUBN0dJZHpf7K2LbpnFEQIRZACg7gR8vhX6oXGze9sZquXRXAvFz+0AmQEb
T+7AgQftcvZrk+CPGJtCfiXt
=CIk9
-END PGP SIGNATURE-

Re: An 'ae' testimony

[moron]

May I put in a word on behalf of anyone like me who comes from a dos/windows
environment and loves the whole concept of linux and debian in particular
but feels absolutely lost in it?  I've spent hours a day for the last few
weeks trying to edit configuration files and cut down the size of log files
(Am I supposed to do that?) and wishing I had something as intuitive as dos
edit, where arrow-up goes up one and arrow-left goes left one and (not
intuitive, but easily learnt) the shift key marks it and the delete key
removes it.  I use ae because it seems to me (as someone coming from dos) a
little less unpredictable than vi, and with the trouble I've had so far I
don't feel like experimenting with emacs or joe or jed or whatever else.

David

Re: An 'ae' testimony

[Josip Rodin]

On Sun, May 23, 1999 at 10:10:56AM +1000, Craig Sanders wrote:
> it's more that
> when you're in a hurry trying to fix some system that has gone down you
> don't have time to mess around learning some stupid editor which doesn't
> do any of the things you need it to do.
> 
> being restricted to a primitive editor after you have become
> proficient with vi is akin to re-learning how to talk after having a
> stroke...you've lost some really fundamental ability which you take
> for granted. when you know vi you don't need to remember the commands,
> you just think about what changes you want to make and (metaphorically
> speaking) your fingers do the rest. having to use a primitive editor
> reduces you to hunt-and-peck typing and having to think about each
> individual keystroke.

Well, what can the bootdisk makers say about that, but - who cares?!
I use joe all the time, but I do not complain that the boot disk doesn't
contain it, and that I am "restricted to a primitive editor" and I have
to "think about each individual keystroke" etc etc...

You have to have a broader view (is that the expression?) in this case,
since it is not only yours boot disk, but everyone elses.

If you want all of the stuff you commonly use on the boot disk, modify
it yourself. Simple :)

-- 
enJoy -*/\*- http://jagor.srce.hr/~jrodin/

Re: Source-depends?

[Josip Rodin]

On Sun, May 23, 1999 at 03:07:19AM +0300, Antti-Juhani Kaijanaho wrote:
> > Some of these can be detected automatically (#5 could be discovered with a
> > grep on debian/rules, for example), but some can't.
> 
> So, what's the problem?  We don't autodetect all of binary dependencies
> either.  Maintainers generally know what they need to build their packages;
> it should be trivial for them to list the dependencies explicitly!
> 
> Besides, if source dependencies were completely autodetectable, we wouldn't
> need them.

Agreed. We don't need any magic, just a common location for that useful
piece of information.

-- 
enJoy -*/\*- http://jagor.srce.hr/~jrodin/

Re: An 'ae' testimony

[Mark Blunier]

Craig Sanders wrote:
> being restricted to a primitive editor after you have become
> proficient with vi is akin to re-learning how to talk after having a
> stroke...you've lost some really fundamental ability which you take
> for granted.

This sounds like a great arguement to use any editor other than vi for
anything.  In order to protect new users from the evils of vi, lets 
replace vi with a script that echos:
"The use of vi can cause learning disabilties, as though you had a stroke"

If you can't figure out how to use ae (in a not vi emulation mode), are
you sure you want to install Linux on your own?  As far as a recovery disk
goes, you are much better off with a real recovery disk.  The boot disk
is severely crippled when compared to other recovery disks that are
readily available.

Mark Blunier

Re: An 'ae' testimony

[Craig Sanders]

On Sun, May 23, 1999 at 02:40:12AM +0200, Josip Rodin wrote:

> Well, what can the bootdisk makers say about that, but - who cares?!
> I use joe all the time, but I do not complain that the boot disk
> doesn't contain it, and that I am "restricted to a primitive editor"
> and I have to "think about each individual keystroke" etc etc...

you are making the mistake of assuming that the boot disk is solely for
installation of new debian systems.

it's not.

it's called the "rescue" disk for a reason.


you are also making the mistake of assuming that joe is in any way a
standard tool. it is not. the only two text editors which can lay claim
to being a standard part of any unix are ed and vi.  


> You have to have a broader view (is that the expression?) in this
> case, since it is not only yours boot disk, but everyone elses.

i think it is you who needs the broader view. the world is not composed
entirely of newbies seeking escape from dos/windows. in fact, it's fair
to say that complete newbies aren't our target market, we make a high
quality distribution perfectly suited to experienced unix users. even
so, we support them by including a simple editor (ae) on the rescue
disk...why should we do less for our target market?

debian has been criticised in the past for failing to include vi on the
rescue floppy. we copped a lot of flack for not having one as it is a
tool which any experienced unix user can reasonably expect to find on a
rescue floppy.which is why we ended up with ae's vi emulation. it
may not be real vi, but it's infinitely better than nothing.


> If you want all of the stuff you commonly use on the boot disk, modify
> it yourself. Simple :)

i don't want all the stuff i commonly use. i just want the bare minimum,
and that includes a decent editor.

craig

--
craig sanders

X on a Dell Inspiron Laptop

[Douglas Bates]

A friend recently bought a high-end Dell laptop computer.  The model
is the Inspiron 8000, if I recall correctly.  It has a hard drive that
is about 9.5 Gb (yes, nearly 10 Gb on a laptop) and fips20.exe seemed
to have some trouble creating a second partition.  We wanted to save
the Windows 98 partition so we used fips to create a second partition
then installed Debian 2.1.  The partition table doesn't appear to have
the correct geometry specs and the total amount of disk space
available now is about 7.5 Gb instead of 9.5.  Has anyone encountered
problems like this on large hard drives before?  Any suggestions for
repairing the partition table? Is it likely that a 2.2.x kernel will
be able to probe the apparent geometry of the drive more successfully?

Another problem we encountered is in the configuration of the X
server.  The version of SuperProbe and the xservers in Debian 2.1 were
not able to recognize the chip.  We installed the 3.3.3.1 X11 packages
compiled for Debian 2.1 from the www.netgod.net site.  That version of
SuperProbe recognized the chip and describes it as

 First video: Super-VGA
 Chipset: ATI 264LT Pro (Port Probed)
 Memory: 8192 Kbytes
 RAMDAC: ATI Mach64 integrated 15/16/24/32-bit DAC w/clock
 (with 6-bit wide lookup tables (or in 6-bit mode))
 (programmable for 6/8-bit wide lookup tables)
 Attached graphics coprocessor:
   Chipset: ATI Mach64
   Memory: 8192 Kbytes

but neither the xserver-svga nor the xserver-mach64 packages seem to
want to drive it.  Does anyone know if there are more recent drivers
at xfree86.org or at SuSE that will drive this video system?

Re: An 'ae' testimony

[Craig Sanders]

On Sat, May 22, 1999 at 03:16:18PM -0500, John Goerzen wrote:
> Well put, Dale.  I think you have done the correct thing here.  If the
> vi emulation is not sufficiently complete to work as expected of vi,
> and esp. if it's really bad, remove it.

i disagree. while ae's vi emulation is far from perfect, it should not
be removed until there is a replacement which can fit on the rescue
disk.

craig

--
craig sanders

Re: An 'ae' testimony

[Steve Lamb]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, 23 May 1999 11:13:29 +1000, Craig Sanders wrote:

>it's called the "rescue" disk for a reason.

Then it should have all the rescue tools on there, not bare minimum. 
Wait, that would make it too bit for an install disk, wouldn't it.  Either,
or, Craig, not both.

>you are also making the mistake of assuming that joe is in any way a
>standard tool. it is not. the only two text editors which can lay claim
>to being a standard part of any unix are ed and vi.  

vi is no longer a "Standard" tool either except for historical purposes. 
In case you missed it, over the past decade a lot of people who are quite
experienced with Unix have never touched vi.  Historical reasons alone are
not enough to put a vi or vi emulation on an install disk.

>debian has been criticised in the past for failing to include vi on the
>rescue floppy.

Debian is critizied for a lot of things, so what?

>i don't want all the stuff i commonly use. i just want the bare minimum,
>and that includes a decent editor.

If you want the bare minimum, then you need to ask for a lot more than
just an editor.

- -- 
 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/AwUBN0dYDXpf7K2LbpnFEQKgCwCff0+iklRIF87y7Gv3IC9H7T3Z9+EAoLhY
6iirsG9G3asJPLnADAdOG4rO
=nmWt
-END PGP SIGNATURE-

Re: request to kill nag messages

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:
> I'm not the only one to be annoyed at the nag messages that are sent out.
> Can the script please be disabled. 

Absolutely.  I've asked before for the nag widget to be turned off, and I
strongly support turning it off now.

Yes, I have a couple of packages with very old bugs open (can you say "bind"?),
but getting nagged about them not only adds no value, it actively reduces my
interest in addressing the listed bugs.

Turn the damn thing off.

Bdale

Re: GTK problems - not compiling

[Greg Stark]

So it's not a bug and we're satisfied with the following situation?

 Some programs from other linux systems or even hamm systems will randomly seg
 fault. 

 If any libraries from other linux distributions or even hamm systems are
 present on a potato machine when programs are compiled the resulting binaries
 may randomly crash.

 There's no supported way to compile programs on a potato system that will run
 on a hamm system or any other glibc2.0 distribution. This may impact our
 responsiveness handling security issues in hamm.

Really I think the glibc maintainers made a fundamental error in
overestimating the sophistication of linux's shared library versioning scheme.
A little work should have gone into ld.so before trying this experiment.

In linux two libraries with the same soname are required to be fully
compatible. period. Otherwise it isn't possible to exchange binaries or
libraries between two machines. One-direction compatibility is simply not
adequate to justify keeping the same soname.

greg

Re: Intent to package: GREED

[Greg Stark]

Leon Breedt <[EMAIL PROTECTED]> writes:
> 
> Regarding curl, I'll be packaging an SSL enabled version only, as it seems
> that policy doesnt cover a source package building for both US & non-US.

There are a couple packages which do this, mutt-i etc. I think they all make
some minor alteration like touching a file and then rebuid and upload to nonus
including a complete duplicate of the source package.

I struggled for a while to build nonus versions of fetchmail and zephyr build
against kerberos, but couldn't do it to my liking. Too many tools assumed they
could run over debian/control and pick out package names themselves and too
many assumed that every package listed in debian/control should be built.

Really someone should come up with a single library of debian/* parsing
routines, preferably compiled into a library which could be linked into perll
a bash builtin module, dpkg-deb, and whatever else. Then everyone would use
the same parsing routines to access these files. If a new feature is needed
then it could be added to one place.

Well, that's just a thought, there are disadvantages to that approach too.

But I found it very frustrating at the time. Incidentally Just because the
binary can't be exported doesn't mean the source can't be exported. fetchmail
and zephyr, for example, include only hooks for authentication. Absolutely no
hooks directly to encryption. (I think.) So there's no reason the source
shouldn't be exportable. The resulting binary would have "hooks" in the form
of dynamic linking to the encryption routines though...

greg
  

Re: An 'ae' testimony

[Josip Rodin]

On Sun, May 23, 1999 at 11:13:29AM +1000, Craig Sanders wrote:
> > Well, what can the bootdisk makers say about that, but - who cares?!
> > I use joe all the time, but I do not complain that the boot disk
> > doesn't contain it, and that I am "restricted to a primitive editor"
> > and I have to "think about each individual keystroke" etc etc...
> 
> you are making the mistake of assuming that the boot disk is solely for
> installation of new debian systems.
> 
> it's not.
> 
> it's called the "rescue" disk for a reason.

How did you come to that conclusion (that I don't know that it is a
rescue disk)?

> you are also making the mistake of assuming that joe is in any way a
> standard tool. it is not. the only two text editors which can lay claim
> to being a standard part of any unix are ed and vi.  

On a rescue disk you don't need standard tools. You need any kind of
tools that do their job. If there would be standard tools on it, then
we would have to include X and at least two emacs variants on it ;)

> > You have to have a broader view (is that the expression?) in this
> > case, since it is not only yours boot disk, but everyone elses.
> 
> i think it is you who needs the broader view. the world is not composed
> entirely of newbies seeking escape from dos/windows. in fact, it's fair
> to say that complete newbies aren't our target market, we make a high
> quality distribution perfectly suited to experienced unix users. even
> so, we support them by including a simple editor (ae) on the rescue
> disk...why should we do less for our target market?

No, I don't think that including ae was done becuse of the
user-friendliness - ae, as any usual unix text editor, is something that
complete newbies don't like. If we cared about newbies, we would get a
MS-DOS edit clone or even start up the X just after booting (I don't exactly
know how, but you get the point).

> debian has been criticised in the past for failing to include vi on the
> rescue floppy. we copped a lot of flack for not having one as it is a
> tool which any experienced unix user can reasonably expect to find on a
> rescue floppy.

However, the situation is a bit more complicated than what it may seem
to an innocent bystander - we have the boot disk, and the rescue disk
in the same image, i.e. on the same 1.44MB  - and that is a really practical
reason why we needed to put a very very small (yet functional) editor on it.
Debian should not be criticized because of that decision, it was completely
logical in these circumstances.

Also, I don't think that most of the people using Debian are experienced
Unix users. The majority of the users aren't dumb, but they also don't
know ksh scripting. For these people, ae is a perfectly valid editor, not
too different from  vi, joe, pico, ee, or anything similar (by look).

> > If you want all of the stuff you commonly use on the boot disk, modify
> > it yourself. Simple :)
> 
> i don't want all the stuff i commonly use. i just want the bare minimum,
> and that includes a decent editor.

Ae is an editor decent enough for the bare minimum cathegory... but you're
free to disagree.

-- 
enJoy -*/\*- http://jagor.srce.hr/~jrodin/

Re: Source-depends?

[James Mastros]

On Sat, May 22, 1999 at 04:38:21AM +0930, Ron wrote:
> > Well, it sounds like you repeated what about a dozen people have already
> > said. The concern is an automated way to generate the depends. 
Umm, any purticular reason to that compile-depends must be autogenerated --
why can't they be done manualy by the packager?  (I realize that this is less
then ideal -- but having this in optionaly, manualy seems better then not
having it at all.)

> > The
> > autobuilders already use a semi-working type of this, but it isn't perfect
> > and makes assumptions that can't always be assumed.
Mind describing the method the autobuilders use (and where I can find
approprate source)?

> > I have already made a patch for dpkg-* programs to use source deps in a
> > control field, that's not the problem though.
Any reason not to put it in your next upload?

> As this has probably been thrashed about innumerable times before, yet we
> all agree that having source dependancies would be valuable, could someone
> summarise (or provide a pointer to) the problems that have been identified.
> 
> I see two situations up front:
>  - a need to describe the tools needed to build a package
> (eg. gcc, bison, flex, etc..)
>  - and a need to describe the other source packages or librarys required
> to build a working binary.
Why do these need to be treated differently?

> as well as a way to auto-detect these dependancies, what else is required?
I've read through all of the archives that seemed appropriate, and found the
following problems that had been brought up:
1. Automatic generation of the field(s)
2. Required/Recomened/Sugueted defs (for ex, what to do with tex tools and
   such that are required for only minor peices of the packages.)
3. Requiring bin-packages vs. requiring build trees from other package's
   source

In general, on prior discussions, there was no conclusion on 1 and 2, but on
3 it was suguested that requiring build trees from another package was
considered buggy.

A soultion to number 1 that was tossed around included using libtricks to
get a list of files accessed, and is therefor (IIRC) obselete.  (And in any
case is prohibitively slow.)

-=- 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

Re: An 'ae' testimony

[Steve Lamb]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, 23 May 1999 03:58:32 +0200, Josip Rodin wrote:

>know ksh scripting. For these people, ae is a perfectly valid editor, not
>too different from  vi, joe, pico, ee, or anything similar (by look).

Request for package: mcrypt

[Joel Klecker]

It'd be nice if someone in the free world could package this.
mcrypt is a replacement for the old unix crypt(1). It uses the block 
algorithms DES, TripleDES, Blowfish, 3-WAY, SAFER-SK64, SAFER-SK128, 
TWOFISH, TEA, RC2, RC6, IDEA and GOST in CBC, OFB, CFB and ECB modes. 
It is compatible with the old unix crypt(1) and the solaris des(1).



--
Joel Klecker (aka Espy)Debian GNU/Linux Developer
mailto:[EMAIL PROTECTED]> mailto:[EMAIL PROTECTED]>
http://web.espy.org/>   http://www.debian.org/>

Re: xfstt 0.9.99 uploaded - some news with it

[Greg Stark]

[EMAIL PROTECTED] (Marco d'Itri) writes:

> On Apr 28, "Stephen J. Carpenter" <[EMAIL PROTECTED]> wrote:
> 
>  >The MAIN process runs as root. This is because if it recieves a kill signal
>  >it needs to clean up its pid file. Can't do that if it was not root (not
>  >without the permissions on /var/run changeing)
> This is NOT an excuse for running as root. Make it create the pidfile in
> /var/run/xfstt like other similar programs do.

Couldn't we just set the sticky bit on /var/run ?

I guess this doesn't solve the problem for non-debian systems, hm.

Re: An 'ae' testimony

[Adam Di Carlo]

> "Craig" == Craig Sanders <[EMAIL PROTECTED]> writes:

Craig> On Sat, May 22, 1999 at 03:16:18PM -0500, John Goerzen wrote:
>> Well put, Dale.  I think you have done the correct thing here.  If
>> the vi emulation is not sufficiently complete to work as expected
>> of vi, and esp. if it's really bad, remove it.

Craig> i disagree. while ae's vi emulation is far from perfect, it
Craig> should not be removed until there is a replacement which can
Craig> fit on the rescue disk.

Well, I think you're in the minority.  Most agree (including myself)
that the vi emulation mode in ae does more harm then good.

When we have a vi-alike which is small enough to squeeze on an
oversqueezed floppy, then we'll consider it.  Right now it's moot,
because we don't.

Aside from that, I think the best we can hope for is an "expanded
rescue" situation, i.e., an optional two- or three- floppy rescue
image, or (Corel is working on this) a rescue system bootable from a
CD or other media.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Source-depends?

[Ben Collins]

On Sat, May 22, 1999 at 12:43:50AM -0400, James Mastros wrote:
> On Sat, May 22, 1999 at 04:38:21AM +0930, Ron wrote:
> > > Well, it sounds like you repeated what about a dozen people have already
> > > said. The concern is an automated way to generate the depends.
> Umm, any purticular reason to that compile-depends must be autogenerated --
> why can't they be done manualy by the packager?  (I realize that this is less
> then ideal -- but having this in optionaly, manualy seems better then not
> having it at all.)

The reason to not setup this up now and leave it as a "side affect" is
so it get's done right. There is no point in doing this half assed, and
have everyone get used to doing it that way, and it never getting done
the way it needs to be.

> > > The
> > > autobuilders already use a semi-working type of this, but it isn't perfect
> > > and makes assumptions that can't always be assumed.
> Mind describing the method the autobuilders use (and where I can find
> approprate source)?
>
> > > I have already made a patch for dpkg-* programs to use source deps in a
> > > control field, that's not the problem though.
> Any reason not to put it in your next upload?

Because dpkg is not mine ;)

--
--- -  -   ---  -  - - ---   
Ben Collins <[EMAIL PROTECTED]>Debian GNU/Linux
OpenLDAP Dev - [EMAIL PROTECTED] The Choice of the GNU Generation
-- -- - - - ---   --- --  -  - ---  -  --

Re: An 'ae' testimony

[Dale Scheetz]

On 22 May 1999, Adam Di Carlo wrote:

> 
>  a) keep ae, but remove the vi emulation mode -- I haven't seen anyone
>  claim that ae sans emulation mode is good enough.  The list seems to
>  agree, the ae maintainer agrees, and it's easy to implement, so I
>  suggest this is the course of action we take.
> 
>  b) replace ae with something else, the only real contender AFAICT
>  being 'ee'
> 
> Dale, do you agree with (a)?   Should we just go with that?

Done,

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 _-_-_-_-_-_-_-

Re: An 'ae' testimony

[Michael Stone]

On Sat, May 22, 1999 at 07:09:09PM -0700, Steve Lamb wrote:
> After all of this I took a look at both ae and ee.  Both lack something
> that I think needs to be addressed.  AE's movement keys don't appear to have
> any rhyme or reason to them.  They're not grouped together and not in any
> direction.  
> AE's isn't either, but at least they're mnemonic.  ^Up, ^Down, ^Left, ^Right.

Or you could just use the arrows...which works fine in either editor...

Mike Stone



pgprNAgO715MF.pgp
Description: PGP signature

Re: xfstt 0.9.99 uploaded - some news with it

[Michael Stone]

On Sat, May 22, 1999 at 10:24:17PM -0400, Greg Stark wrote:
> [EMAIL PROTECTED] (Marco d'Itri) writes:
> > This is NOT an excuse for running as root. Make it create the pidfile in
> > /var/run/xfstt like other similar programs do.
> 
> Couldn't we just set the sticky bit on /var/run ?

No, that creates different problems.

Mike Stone

Re: netscape crashes on potato

[Greg Stark]

So the people who don't see crashes, which version of Netscape are you using?
Do you use java successfully in Netscape? Do you have plugger installed? Do
you have any other plugins installed? Which versions of libc are you using?

# dpkg -l \*netscape\* | grep ^hi
hi  netscape-base-4 5  Popular World-Wide-Web browser software (bas
hi  netscape-base-4 4.5-1  Popular World-Wide-Web browser software (bas
hi  netscape-java-4 4.5-1  Popular World-Wide-Web browser software (jav

Unfortunately all the later versions have an erroneous dependency on glicb2.1
(I'm pretty certain Netscape hasn't released any glibc 2.1 dependent binaries!) 

Actually, would it be possible to bug the netscape maintainer into releasing
libc5 packages? That might solve a lot of problems since the libc5 version
isn't actually beta... 



Remco Blaakmeer <[EMAIL PROTECTED]> writes:

> On Fri, 30 Apr 1999, Dan Nguyen wrote:
> 
...
> > > Is this just me??or is this a glibc2.1 issue?

No, I have these problems with glibc2.0.

I would *love* to find out why some people don't have problems and fix this.

> > My netscape just loves to go insane.  I try to visit a page, and it
> > begins to take up 100% cpu time, and doesn't stop.  Generally after a
> > minute of waiting to see that it's gone I end up killing it.  I've had
> > this problem with 4.5 and 4.51

I've seen this problem too. 100% cpu and 100% memory too. I've never seen a
128Mb desktop thrash its swap so badly before. Linux really doesn't behave any
better in this case than I remember 1.2.13 doing, sigh.

> I've had this, too, with both navigator 4.0x and navigator 4.5x. Try
> disabling java support and see if that helps. It helped me a lot.
> 
> Somehow, either the java vm in glibc2 netscape is very buggy or there are
> a whole lot of buggy java applets out there, or both.

I have java disabled already because any java reliably causes Netscape to seg
fault immediately. As soon as I hit a page with an applet in it boom, gone.

If I had to guess I would guess the memory thrashing was some loop running off
the end of a buffer and going through all of its heap, possibly related to
javascript stuff. Hm, what kind of gc does javascript use? If it's something
like the Boehm conservative gc... Well this is all conjecture.

greg

Re: An 'ae' testimony

[Mark Blunier]

On 22 May 1999, Adam Di Carlo wrote:

> Aside from that, I think the best we can hope for is an "expanded
> rescue" situation, i.e., an optional two- or three- floppy rescue
> image, or (Corel is working on this) a rescue system bootable from a
> CD or other media.

I've already done it.  My 'rescue' CD is an image of a working Debian
system (including X, ftp server, emacs, vi, and anything else I want
to put on a 600 meg system), that boots from either a floppy or the CD.
The scripts that I've used to create it are at:
http://www.ocslink.com/~blunier

Mark Blunier

why equivs won't (yet) work for metapackages

[Adam Di Carlo]

In message <[EMAIL PROTECTED]> you wrote:
>I will use equivs to get the skeleton, then change the needed things
>(I think I add an option to specify a README.Debian file on the
>command line or in the control file). equivs builds the package, but
>it leaves the tree. This is the one thing I will change and then
>rebuild. You can import that tree into CVS and use it like any other
>package. 
>
>Or you can put the equivs control file under cvs control (and the
>README.Debian after I added this function).

I would prefer this, since I don't like putting derived files in 
CVS.

>Tell me about other options/feature you need, and I will implement
>them as far as it is possible.

I absolutely, positively, need to be able to (a) have a local
override of README.debian.in (should probably be README.Debian.in,
BTW), and (b) a local changelog, and (c) a local copyright file.
Finally, why does equivs want to run dpkg-buildpackage at all?
That's a big mess and shouldn't be done, or, if done, should
be done properly (no source or signing is done currently, so
it's not uploadable).

The lack of the changelog and copyright control is a crucial, 
crucial problem.

I suggest you rip up equivs again, and change the following:

. create a dir - rather than , default to 1.0 for rev

. allow files in the same dir as the control file to exist, and
to override the template files or be extra files which goes into
the debian subdir (this solves the changelog, copyright, etc issues).

. when you run dh_gencontrol, I suggest you run 'dh_gencontrol -u-isp'
(I don't understand why this isn't the default)

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Intent to package KerberosV

[Greg Stark]

Bear Giles <[EMAIL PROTECTED]> writes:

> My plan, back when I was exploring the idea of a US-only package 
> and/or derived distribution, was to use shared libraries and create 
> a special null Kerberos package which would return error codes, something
> very close to the Kerberos 'bones' package (which is not export restricted).
> The resulting package should be exportable and Kerberos functionality
> would be enabled whenever someone installed the Kerberos packages.

This wouldn't hold water unfortunately. US Crypto export law includes
prohibitting software with hooks "specifically" for crypto. So generic hooks
for arbitrary filters are ok, hooks just for authentication (such as the
fetchmail source) are ok, but binary packages are certain to include calls to
crypto routines, which is verbotten. 

> The second is that both Kerberos and SSLeay use "libcrypto"  Maintainers
> could change the library name expected, but it's a pain.

Uhoh, is this a problem for our existing kerberos 4 packages (that everyone
seems to have forgotten about, hmph.)? I haven't gotten any bug reports about
conflicts with libcrypto and it's definitely included.

> > So far, I haven't considered adding the Kerberos compile options, because
> > of doubt about this and also because no-one has ever asked for it.

I tried to build nonus versions of zephyr and fetchmail with kerberos support
a while back and found our tools just couldn't handle a source package that
could produce different binary packages depending on the whim of the user. 
(This would have been especially neat since libzephyr contains all the
kerberos calls, I could have produced a single libzephyr-i that switched the
behaviour of all the zephyr clients.) 

Alas, my current solution is to just make it really easy for other people to
build their own kerberized packages. To build a kerberized set of zephyr
packages you just do "debian/rules WITHOUT_KRB4= binary" and for fetchmail I
think you can just rebuild with kerbero4kth-dev installed and it dtrt.

This satisfied my immediate needs, I can get my mail and read mit zephyrs, but
doesn't really help the kerberos cause. I do want to get the kerberos pam
module packaged but don't know anything about it myself.

greg

Re: Install-time byte-compiling: Why bother?

[Greg Stark]

<[EMAIL PROTECTED]> writes:

> Obviously I've misunderstood the behaviour of Emacs here - I'd assumed 
> that the internal form was the same regardless of whether one got
> there via byte-compiling or not.  Apparently this isn't the case!

it certainly isn't. I have to question your results too, the times I had to
work with Gnus or W3 with only a single file non-byte-compiled (to debug it)
I've found they were *unusably* slow.

Also you should try them on a machine that's a little memory starved. You'll
find any substantial package will take huge amounts of memory if you run it
without byte-compiling it. 

That said, I would agree with leaving any small to moderate sized packages
non-byte-compiled. I think that's our current policy? Most packages don't
really gain much from byte-compiling. Just large packages like Calc, W3, Gnus
etc. (In fact I suspect the main determining factor is whether the package
makes heavy use of the cl package...)

greg

Re: netscape crashes on potato

[UnderGrid Founder]

Greg Stark decided to waste my bandwidth saying:
> 
> So the people who don't see crashes, which version of Netscape are you using?
> Do you use java successfully in Netscape? Do you have plugger installed? Do
> you have any other plugins installed? Which versions of libc are you using?
> 
> # dpkg -l \*netscape\* | grep ^hi
> hi  netscape-base-4 5  Popular World-Wide-Web browser software 
> (bas
> hi  netscape-base-4 4.5-1  Popular World-Wide-Web browser software 
> (bas
> hi  netscape-java-4 4.5-1  Popular World-Wide-Web browser software 
> (jav
> 
[EMAIL PROTECTED]:~$ dpkg -l \*netscape\* |grep ^ii
ii  netscape-base-4 14 Popular World-Wide-Web browser software (bas
ii  netscape-base-4 4.51-1 4.51 base support for netscape
ii  netscape-base-4 4.6-1  4.6 base support for netscape
ii  netscape-java-4 4.51-1 Netscape Java support for version 4.51
ii  netscape-java-4 4.6-1  Netscape Java support for version 4.6

Both versions have work'd fine for me... I just install'd 4.6 and have
been runnin 4.51 for sometime since it came out... Both have been ran through
Fortify (1.4.1 with 4.51 and 1.4.2 with 4.6) to enable 128bit encryption...
This is on my main potato-i386 system which was updated in the last 24 hours
and runnin the 2.2.7 kernel... No special installs... if dselect/apt couldn't
install it then it ain't runnin...

Respectfully,
Jeremy T. Bouse

-- 
,-,
| Jeremy T. Bouse  -  UnderGrid Network Services, LLC  -   www.UnderGrid.net  |
| PGP ID/Fingerprint: 1024/E83D9AE5/4ACC03F098D78198 19D0593E50E597E9 |
| Public PGP key available via 'finger [EMAIL PROTECTED]'|
| [EMAIL PROTECTED]  -  NIC Whois: JB5713  -  [EMAIL PROTECTED] |
|  promotion, n.: New title, new salary, new office, same old crap.   |
`-'


pgpvdV3PhL24b.pgp
Description: PGP signature

Re: request to kill nag messages

[Manoj Srivastava]

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

 John> I mean, fix bugs.  Then they can be closed.  I am aware that
 John> not all bugs have easy solutions, but just because the solution
 John> isn't easy doesn't mean that it is any less important to fix
 John> it.

And unwanted, and unnecesary, periodic zero content nags help
 this process how? Do they help me getting my tough bugs resolved?
 What purpose are they serving, then? Why should they not be treated
 as any other spam?

manoj
-- 
 A visit to a strange place will bring fresh work.
Manoj Srivastava   <[EMAIL PROTECTED]>  
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

intent to package: vdkbuilder

[Ionutz Borcoman]

Hi,
(B
(BI'm the maintainer of vdk debian package (vdk is a C++ wrapper over gtk)
(Band a member of the vdk/vdkbuilder development team. We have released
(Bthe vdkbuilder, a nice clone of C++ Builder. Some of the features:
(B
(B- GPL licence
(B- GUI designer
(B- Project manager
(B- Text Editor with syntax highlighting
(B- Widget Inspector
(B- the generated code can be compiled with vdk.
(B
(BThis is an alpha release, but you still can do a lot with it. We are
(Bvery interested in user's impressions to decide what new features are
(Bneeded and how to improve the existent ones.
(B
(BIf everything goes well, the deb package will be ready in a couple of
(Bdays (less than 2 weeks). Maybe I'll finish the package even today. I'll
(Bdo my best, but I have a rather busy schedule these days :-/
(B
(BWe have mailing lists for vdk and vdkbuilder.
(BWe also have an irc server for developers of vdk/vdkbuilder.
(B
(BUsefull links:
(B
(Bhttp://www.guest.net/homepages/mmotta/VDKHome/index.htm
(Bhttp://www.guest.net/homepages/mmotta/vdkbuilder/index.htm
(B
(BIonutz
(B-- 
(BMental backup in progress - Do Not Disturb!
(B--
(Bhttp://borco-ei.eng.hokudai.ac.jp/~borco/

Re: RFD: Debian advertising in LJ, elsewhere

[Peter Moulder]

So long as the intent is to allow people to make better decisions
about what distribution to use, instead of simply to switch as many
people as possible to using Debian.

We do not want to switch people if they're better off using some other
distribution, and nor do we wish to waste effort switching someone who 
is equally well off whether they use Debian or some other distribution.

The most beneficial way is to write an article (which you don't even have
to pay LJ for!) that tries to direct each reader to the distribution 
that's best for them.

By being one-sided, advertisements have a higher tendency to direct 
people _away_ from what's best for them; and are also less credible.

However, an ad may be beneficial in redressing imbalance in image
portrayal if such an imbalance exists.

pjm.

Re: request to kill nag messages

[Hamish Moffatt]

On Sun, May 23, 1999 at 01:00:19AM -0500, Manoj Srivastava wrote:
> >>"John" == John Goerzen <[EMAIL PROTECTED]> writes:
> 
>  John> I mean, fix bugs.  Then they can be closed.  I am aware that
>  John> not all bugs have easy solutions, but just because the solution
>  John> isn't easy doesn't mean that it is any less important to fix
>  John> it.
> 
> And unwanted, and unnecesary, periodic zero content nags help
>  this process how? Do they help me getting my tough bugs resolved?
>  What purpose are they serving, then? Why should they not be treated
>  as any other spam?

What does that treatment involve exactly?


Personally I can't see what the fuss is; I'd just delete it if
I didn't like it.


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

Re: An 'ae' testimony

[Manoj Srivastava]

Hi,
>>"Craig" == Craig Sanders <[EMAIL PROTECTED]> writes:

 Craig> i disagree. while ae's vi emulation is far from perfect, it
 Craig> should not be removed until there is a replacement which can
 Craig> fit on the rescue disk.

That is an opinion. Well, in my opinion we do not need a vi
  clone on the rescue disk. So there.

manoj

-- 
 A thing is not necessarily true because a man dies for it. Oscar
 Wilde, "The Portrait of Mr. W.H."
Manoj Srivastava   <[EMAIL PROTECTED]>  
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

Re: An 'ae' testimony

[Manoj Srivastava]

Hi,
>>"Craig" == Craig Sanders <[EMAIL PROTECTED]> writes:


 Craig> it's not that vi is the only editor which is understood. it's more that
 Craig> when you're in a hurry trying to fix some system that has gone down you
 Craig> don't have time to mess around learning some stupid editor which doesn't
 Craig> do any of the things you need it to do.

What doesn't ae to? As an editor for a damaged system, it
 seems to work well.

 Craig> being restricted to a primitive editor after you have become
 Craig> proficient with vi is akin to re-learning how to talk after having a
 Craig> stroke..

Ahem. vi non-primitive heh-heh-heh.



 Craig>  .you've lost some really fundamental ability which you take
 Craig> for granted. when you know vi you don't need to remember the commands,
 Craig> you just think about what changes you want to make and (metaphorically
 Craig> speaking) your fingers do the rest. having to use a primitive editor
 Craig> reduces you to hunt-and-peck typing and having to think about each
 Craig> individual keystroke.

Are vi users less capable, or more inflexible, than users of
 better editors? I think you are doing vi users a dissservice,
 labeling them so incapable and unadapting. 

Anyway, every one knows that vi is primitive ;-)

manoj

-- 
 One of the worst of my many faults is that I'm too critical of
 myself.
Manoj Srivastava   <[EMAIL PROTECTED]>  
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

Re: An 'ae' testimony

[Manoj Srivastava]

Hi,
>>"Craig" == Craig Sanders <[EMAIL PROTECTED]> writes:

 Craig> you are also making the mistake of assuming that joe is in any
 Craig> way a standard tool. it is not. the only two text editors
 Craig> which can lay claim to being a standard part of any unix are
 Craig> ed and vi.

Historical inertia is rarely a good argument. We are making a
 better system than unices used to be. Easier to use (which unices
 never were). 

 >> You have to have a broader view (is that the expression?) in this
 >> case, since it is not only yours boot disk, but everyone elses.

 Craig> i think it is you who needs the broader view. the world is not
 Craig> composed entirely of newbies seeking escape from
 Craig> dos/windows. in fact, it's fair to say that complete newbies
 Craig> aren't our target market, we make a high quality distribution
 Craig> perfectly suited to experienced unix users. even so, we
 Craig> support them by including a simple editor (ae) on the rescue
 Craig> disk...why should we do less for our target market?

Our target market, for the most part, is smart, adaptive, and
  perfectly capable of living with ae  when they have to. Inflexible
  users of a primitive visual editor are not my concern.


 Craig> debian has been criticised in the past for failing to include
 Craig> vi on the rescue floppy. we copped a lot of flack for not
 Craig> having one as it is a tool which any experienced unix user can
 Craig> reasonably expect to find on a rescue floppy.which is why
 Craig> we ended up with ae's vi emulation. it may not be real vi, but
 Craig> it's infinitely better than nothing.

Actually, in the opinion of a lot of people, it is not better
  than nothing, it is worse. I tend to concur.

 >> If you want all of the stuff you commonly use on the boot disk, modify
 >> it yourself. Simple :)

 Craig> i don't want all the stuff i commonly use. i just want the bare minimum,
 Craig> and that includes a decent editor.

That rules vi out, then.

manoj
-- 
 "It's the best thing since professional golfers on 'ludes." Rick
 Obidiah
Manoj Srivastava   <[EMAIL PROTECTED]>  
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

Re: An 'ae' testimony

[Joseph Carter]

On Sun, May 23, 1999 at 09:47:33AM +1000, Craig Sanders wrote:
> > > Isn't PICO non-free? (similar to pine). Slap me if I am wrong here.
> > 
> > Yes, but it is the standard newbie editor.
> 
> it's not debian's standard newbie editor and can't be because it's
> non-free.
> 
> end of story. pico is out of the picture.
> 
> if you like pico then write a free clone.

Please aquire a clue.  I even said two messages up in this thread that
pico was totally unsuitable for the base disks.  It's 360k last I looked,
and it's non-free.

Debian has not had an officially recommended newbie editor.  However I've
been hearing more and more people suggesting ee for this because it's
much more functional than pico and almost 1/8th the size!


> > I think a growing segment of people agree that ee should replace ae
> 
> 2, so far. maybe more. nowhere near as many as those who want vi in some
> form on the boot disks (which is why we have ae's vi emulation mode
> now...and we'd have elvis-tiny too if we hadn't had to switch to slang).

Yes, MAYBE more.  I've counted at least 4, plus more on irc.  Given that
there have been at most 8 people involved in this thread, I think we seem
to be approaching the point at which you can no longer ignore those of us
who think ee is a good choice.

Well, you may choose to ignore us, but I hope others will not as
willfully ignorant of what's been said.  And before you answer that, I
will point out that your comments above about me and pico ARE willfully
ignorant.


> > for the base disks.  I'm guessing slcurses would be used for that, and
> > I think there is some slight bit of porting involved for that.  I'd be
> > interested to know how much there is if anything, I'd be interested
> > in building mp3blaster and joe against slang. curses sometimes has
> > annoying bugs.
> 
> ae does the job of a simple no-frills editor in ~20K. ee does it in
> ~50k (*)
> 
> ae wins.
> 
> that extra 30k (if it is actually available on the rescue disk) would be
> better used either as part of the space needed by elvis-tiny (**) or by
> a second copy of ae hacked to remove the non-modalness which dale said
> were what is causing the problems with the vi emulation.
> 
> if the second copy didn't have to carry the baggage of supporting a
> non-modal mode :-) , it may be possible to get the vi emulation to a
> decent state. it *almost* works now, which is what is so annoying about
> it.

Do the math.  I did.  On the base disks there are ae, a little sh script
for making ae act like vi, and a pair of ~4k rc files.  Adding those up
ee is only 17k bigger than ae is.  Granted, you lose the vi mode this
way, but the vi mode doesn't work anyway.  Of course, that's raw
filesizes..  That doesn't really matter much because we have to talk
inodes here, not raw sizes.

du says:
49  /usr/bin/ee
25  /bin/ae
1   /bin/ae.vi.sh
4   /etc/ae/ae2vi.rc
4   /etc/ae.rc

Seems that du thinks the difference is 15k.

If you can find a vi that will fit in the difference .  ;>


> (*) ee requires ncurses now...but i'm assuming it can be ported to
> slang's slcurses.h if somebody is motivated enough to do it.

At least someone else has said this is not difficult.  It didn't just
build when I tried it, so there's probably at least a couple of things I
would need to do.  Of course, it includes a new_curse.[hc] which I told
it not to use when I tried to build it.  Looks straight forward enough,
but I'll need to spend a good 20 minutes tinkering with it.

If it settles this thread faster, I'll do so.  Otherwise I won't put any
rush on it, I was planning to make other mods as well.  I started all
this last night when I tried ee and realized it might be a nice general
purpose editor with some changes---and if I could get rid of the curses
dependency.

Of course this evening I discovered zed.  It doesn't use curses or slang,
it uses its own hardcoded stuff.  Of course it's 170k or so, not suitable
for a boot disk.  BUT OTOH it's almost identical to qedit!!  I have
missed qedit so much that provided I can get it to behave sanely inside
screen, joe is going byebye.


> (**) elvis-tiny needs ncurses now. again, i'm assuming it can be ported
> to slang using slcurses.h. i made a start on this yesterday and cleared
> up a few dozen trivial problems (elvis' own curses.h redefines many
> slcurses.h macros) but ran into a problem with elvis' qfaddch macro
> which requires more knowledge about curses than i currently have.

agh.  I don't see why you're so insistant that there be a vi on the boot
disk.  My complaint with ae is that it's broken.  If it weren't broken,
I'd say leave it be.  OTOH ee is not broken and it's a whole 15k bigger. 
If it can be built with slcurses, PLEASE replace ae with it.

I've confirmed that FreeBSD doesn't ship with a vi on their disk, they
use ee.  Why ee and not ae?  ee works.  why not elvis-tiny?  Too big.

--
Joseph Carter <[EMAIL PROTECTED]>Debian GNU/Linux developer
PGP: E8D68481E3A8BB

Re: A joe testimony (was: An 'ae' testimony)

[Joey Hess]

Steve Lamb wrote:
> Are you sure about that?  I moved them into a completely different
> directory and joe didn't complain that they weren't there.  It looks like it
> uses the standard termcap/terminfo files.

Hm, very interesting.. Strace shows it never touches them. Oh, I see. if
falls back to them if the normal terminfo doesn't turn up your terminal type.

> >This, FYI, is why I sopped using joe. Not only is it buggy if used from a
> >buggy terminal emulator like windoze telnet, it had occasional bugs running
> >in an xterm (not screen display, but failure to reset the terminal properly
> >on exit).
> 
> This, IIRC, is a bug with xterm, not joe, as other editors do it as well.

I've only seen joe trigger this, but perhaps I'm using the wrong (well,
right ;-) editors.

-- 
see shy jo

Re: An 'ae' testimony

[Joey Hess]

Adam Di Carlo wrote:
> Aside from that, I think the best we can hope for is an "expanded
> rescue" situation, i.e., an optional two- or three- floppy rescue
> image, or (Corel is working on this) a rescue system bootable from a
> CD or other media.

I really thing Tom's Root Boot or something similar is the way to go. Tom's
crams an amazing amount of stuff into one floppy, using tricks like
rewriting common unix utilities in awk so they take up less space.

-- 
see shy jo

Re: request to kill nag messages

[Joseph Carter]

On Sat, May 22, 1999 at 03:24:57PM -0500, John Goerzen wrote:
> Joseph Carter <[EMAIL PROTECTED]> writes:
> 
> > Someone wishing to have a reminder of bug status may choose to subscribe
> > to a report.
> > 
> > Closing bugs just because you can't fix them is wrong.
> 
> I *NEVER* said that one ought to do that, and AFAIK, nobody else did
> either.

Someone suggested the bugs shold be closed.

--
Joseph Carter <[EMAIL PROTECTED]>Debian GNU/Linux developer
PGP: E8D68481E3A8BB77 8EE22996C9445FBEThe Source Comes First!
-
I can just see it now: nomination-terrorism ;-)
-- Manoj

haha!  i nominate manoj.
-- seeS


pgpiN6jUCUBjv.pgp
Description: PGP signature

Re: An 'ae' testimony

[Joseph Carter]

On Sat, May 22, 1999 at 09:07:21PM +0200, Josip Rodin wrote:
> > joe is not discontinued upstream.  Joe Allen just hasn't worked on it in
> > 3+ years as he worked on other things.  Recent posts from him on 
> > comp.editors
> > suggests that he is going to start working on joe again.
> 
> That's great news!
> 
> > I've never seen a problem with its termcap/ncurses interface.  Could you
> > explain?
> 
[.. joe problems ..]
> 
> Still, it's the best editor around =%o)

It also has a habit (curses related) that sometimes it changes your stty
settings and doesn't change them back, leaving you with a mess rquireing
stty sane to fix.  This is a bug against the package, but nobody has any
idea what causes it.

It may have gone away with ncurses 4.  If so, I think I need to have a
look at a couple other programs that had the problem.  =>

--
Joseph Carter <[EMAIL PROTECTED]>Debian GNU/Linux developer
PGP: E8D68481E3A8BB77 8EE22996C9445FBEThe Source Comes First!
-
* m2 stares at the monitor... it looks like a hamburger...
 m2 - that's a bad sign


pgpg46OdEvHV2.pgp
Description: PGP signature

Re: An 'ae' testimony

[Joseph Carter]

On Sat, May 22, 1999 at 12:17:14PM -0700, Joey Hess wrote:
> The reason it has this problem is because it uses its own special terminal
> data files (/etc/joe/terminfo) instead of the standard ones.
> 
> This, FYI, is why I sopped using joe. Not only is it buggy if used from a
> buggy terminal emulator like windoze telnet, it had occasional bugs running
> in an xterm (not screen display, but failure to reset the terminal properly
> on exit).

In screen and console too.

--
Joseph Carter <[EMAIL PROTECTED]>Debian GNU/Linux developer
PGP: E8D68481E3A8BB77 8EE22996C9445FBEThe Source Comes First!
-
* Tv lives in X.
* Knghtbrd lives in console
* wichert lives in the netherlands
* Espy is dead


pgpQ28Tw5YPzJ.pgp
Description: PGP signature

Re: mail clients

[Steve Lamb]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, 23 May 1999 03:44:17 -0500, John Foster wrote:

>I don't want to break up this lively discourse but has anyone here tried
>the IshMail  Mail client? I am about to try it but want to know if there
>are homemade .debs around or if I will have to make them myself.

No, but then, it just went free.  ;)

- -- 
 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/AwUBN0fBG3pf7K2LbpnFEQIZTACeOWbnkszLaghXjdeOvLrofRRdgaEAniwH
bNiSFVJOPO/vW7yN2RcEcqXU
=BfcL
-END PGP SIGNATURE-

Re: Time to rewrite dpkg

[Joey Hess]

Goswin Brederlow wrote:
> I think its a bad idea to say "You want to access to dpkg, programm in 
> XXX". All interaction should be via a call to dpkg itself. Also
> modules should be programs by itself and not linked.
> 
> dpkg would then call "dpkg-download-ftp" to download a package via
> ftp, or it could call "dpkg-download-apt" to use apt and so on.
> 
> That way all modules can be written in any language. They only must
> share a common interface via commandline options, which all programs
> can provide easily.

Library interfaces can be much richer and let you do a lot of things that
are a royal pain with a command line interface. They also have less overhead.

C libraries are quite usable from other languages.

-- 
see shy jo

Re: RFD: Debian advertising in LJ, elsewhere

[Chris Lawrence]

On May 23, Peter Moulder wrote:
> We do not want to switch people if they're better off using some other
> distribution, and nor do we wish to waste effort switching someone who 
> is equally well off whether they use Debian or some other distribution.

I think the LJ ad would be mainly directed at:

1. People who are new to Linux.  My guess is people new to Linux in
   1999 would buy LJ before selecting a distribution (unless they've
   already picked up a copy of Red Hat, in which case it's too late
   for now).

2. People who want to "step up" to a more sophisticated system.  Not
   even Red Hat + contrib matches the selection of Debian, and
   Debian's quality is uniformly high (there's no "contrib dropoff").

3. Everyone.  Debian needs positive publicity in the "mainstream"
   Linux world.  If nothing else, it says "Debian is here, just like
   we've always been."  It would remind people that there is a
   principled alternative to commercial Linux distributions.  It would
   help shake off the "hackers only" image that we've acquired because
   nobody *individually* has a vested interest in promoting
   Debian... read Dan Quinlan's article in this month's LJ, which left
   me with the impression that he thought Debian was no longer a "big
   boy" distribution (lumped in with, among others, Yggdrasil and SLS;
   this may be a misreading of his *intent* but certainly not of what
   some newbie could perceive).

I don't think switching is productive for most people, although I bet
Debian's upgrade path is smoother than Red Hat's, once you get through
the first install.

> However, an ad may be beneficial in redressing imbalance in image
> portrayal if such an imbalance exists.

See 3.  Count the number of ads for Debian in LJ.  You may see a
mention or two buried in the Infomagic ad.  Compare that to ads for
Red Hat, Caldera, Pacific HiTech (TurboLinux), SuSE and Walnut Creek
(Slackware).  Anyone could be left with the mistaken impression that
those are the only distributions out there...  Beyond the ads, LJ is
more balanced (mainly because a lot of Debian people write stuff for
LJ... Martin "Joey" Schulze has an article in this month's LJ, for
example), but the ads are where a lot of people decide what to use.

Personal experience note: I probably wouldn't have put Debian on my
i386 unless I'd already installed and used it on my m68k box (and that
only because Debian--still--has the best multiarch support of any
distribution).

In any event, I wouldn't expect a penny from SPI for this
project... just a few (or, better yet, a bunch of) Debian CD vendors
pooling some resources to (a) give an in-kind contribution of free (to
SPI and everyone else) PR to Debian and (b) give ourselves some
publicity we simply couldn't afford to buy on our own.


Chris
-- 
=
|Chris Lawrence |Get your Debian 2.1 CD-ROMs|
|   <[EMAIL PROTECTED]>| http://www.lordsutch.com/ |
|   |   |
|Amiga A4000 604e/233Mhz|This address has been spam-proofed.|
| with Linux/APUS 2.2.3 | All spam goes to your postmaster. |
=

Re: An 'ae' testimony

[Joseph Carter]

On Sat, May 22, 1999 at 05:46:29PM -0400, Adam Di Carlo wrote:
> joseph> It didn't work right console, that was my issue.  It may work
> joseph> better now, but the thing is still messy and the editor
> joseph> doesn't allow you to do basic editor functions. 
> 
> How can you sit there, with your bare face hanging out, and say in one
> breath that you haven't tried it for a while, and in the other breath,
> claim it's broken?

because the version is 962-23 and I last tried 962-21.1, aaand...

ae (962-23) unstable; urgency=low

  * Set up "fake" vi mode to work with update-alternatives instead of script.
  *   * Use a wrapper script, ae.vi.sh, to use the correct rc file.
  *   * Set update-alternatives to call the script for calls to vi.
  *   * Set priority for update-alternatives to -20 for immediate replacement.
  * This should fix the problem for the HURD caused by the original script.

 -- Dale Scheetz <[EMAIL PROTECTED]>  Sat, 17 Apr 1999 12:22:17 -0400

ae (962-22) frozen unstable; urgency=high

  * recompiled under slang1 to match non-maintainer upload
  * added patch so LD = $(CC): fixes 31545
  * added glibc 2.1 patch for strdup: fixes 22530 and 22637
  * removed extra reference to ^? in ae2vi.rc: fixes 23572

 -- Dale Scheetz <[EMAIL PROTECTED]>  Wed,  6 Jan 1999 17:39:12 -0500


Nothing there indicates a fix for the problems I've had with it.  In
fact, the only thing that could come close is the ^? reference which is
in the vi mode, not the normal mode.

--
Joseph Carter <[EMAIL PROTECTED]>Debian GNU/Linux developer
PGP: E8D68481E3A8BB77 8EE22996C9445FBEThe Source Comes First!
-
 anyone around?
 no, we're all irregular polygons


pgpEWx0lykmxm.pgp
Description: PGP signature

Re: An 'ae' testimony

[Joseph Carter]

On Sat, May 22, 1999 at 07:54:57PM -0400, Michael Stone wrote:
> > that extra 30k (if it is actually available on the rescue disk) would be
> > better used either as part of the space needed by elvis-tiny (**) or by
> 
> I still don't understand the sentiment that people can only understand
> vi. Are other editors really so difficult?

No, but vi users are.  ;>

--
Joseph Carter <[EMAIL PROTECTED]>Debian GNU/Linux developer
PGP: E8D68481E3A8BB77 8EE22996C9445FBEThe Source Comes First!
-
 RMS for President???
 ...or ESR, he wants a new job ;)


pgplKFGJEagq3.pgp
Description: PGP signature

Re: An 'ae' testimony

[Joseph Carter]

On Sun, May 23, 1999 at 10:10:56AM +1000, Craig Sanders wrote:
> > Are other editors really so difficult?
> 
> yes.  difficult and clumsy and lacking basic functionality.

All that missing functionality in ee (and ae in normal mode) is present
in ae in vi mode?  Yeah.  You argued that vi mode SHOULD be preserved
even if it was broken.

--
Joseph Carter <[EMAIL PROTECTED]>Debian GNU/Linux developer
PGP: E8D68481E3A8BB77 8EE22996C9445FBEThe Source Comes First!
-
"my biggest problem with RH (and especially RH contrib packages) is that
they DON'T have anything like our policy.  That's one of the main reasons
why their packages are so crappy and broken.  Debian has the teamwork
side of building a distribution down to a fine art."


pgpEDxshmFxaw.pgp
Description: PGP signature

Re: An 'ae' testimony

[Craig Sanders]

On Sun, May 23, 1999 at 02:35:37AM -0500, Manoj Srivastava wrote:

> What doesn't ae to? As an editor for a damaged system, it seems to
> work well.

you can't yank lines. you can't cut and paste. you can't exec a program
and have the output inserted in the bufer. you don't have multiple undo
and redo. you can't pipe a block of text through a program. you can't
join lines reliably. to change anything you first have to delete the old
text and then type the new text. it's more reliable and less hassle to
just re-type an entire line than it is to edit it. you can't do regexp
search and replace. there is no way to visually distinguish between tabs
and spaces. these are just some of the basic things that are missing or
wrong in ae...there are many more, without even beginning to count the
more useful advanced functions.

ae is an adequate minimal no-frills, no-features text editor. it's
better than cat. it's even better than pico (which isn't hard). it's no
substitute for vi.


> > being restricted to a primitive editor after you have become
> > proficient with vi is akin to re-learning how to talk after having a
> > stroke..
>
> Ahem. vi non-primitive heh-heh-heh.

yes, vi IS non-primitive.  do not mock what you fail to understand.


> >  .you've lost some really fundamental ability which you take
> > for granted. when you know vi you don't need to remember the
> > commands, you just think about what changes you want to make and
> > (metaphorically speaking) your fingers do the rest. having to use a
> > primitive editor reduces you to hunt-and-peck typing and having to
> > think about each individual keystroke.
>
> Are vi users less capable, or more inflexible, than users of better
> editors? I think you are doing vi users a dissservice, labeling them
> so incapable and unadapting.

no, vi users are not less capable or more inflexible (and there are
no better editors -- emacs is not a text editor, it's a programmable
editing environment. if you like that kind of thing then more power to
you...but emacs is also no substitute for vi).

i thought i explained it well enough. vi is the sort of tool that when
you get good at it becomes like an extension of your thoughts - you
don't have to consciously think about HOW to do something, you just
think about WHAT you want to do and it happens.

this doesn't mean that vi users are less flexible or less capable.
it means that trying to use some other less capable editor is like
trying to edit with one hand tied behind your back and three fingers of
your remaining hand chopped off. you can do so much more with vi that
anything less is a major handicap.


i fail to see any further point in this thread. it's gone on way too
long already. the fact is that vi is a basic unix tool which should
be availablenot providing it on the rescue disk when we can do so
would be absurdly laughable if it weren't so outrageously blinkered and
pedestrian.


> Anyway, every one knows that vi is primitive ;-)

i expected better of you than pointless cheap shots like this. guess i
was mistaken.

craig

--
craig sanders

Re: An 'ae' testimony

[Enrique Zanardi]

On Sat, May 22, 1999 at 03:31:37AM -0700, Joseph Carter wrote:
> Okay, let me offer this a bit here...  Do the rescue floppies currently
> use libncurses at all?  I think they don't.

You're right, they don't.

> Seems that we have to move to 3 floppies for potato anyway because a 2.2
> kernel takes really that much.  This of course requires that ee use
> slang.

We need a modular kernel for potato, not the huge beast we call our
official kernel (heck, soon it won't fit on a single floppy!).
Moving to 3 floppies is the wrong answer, sorry.

--
Enrique Zanardi[EMAIL PROTECTED]

Re: An 'ae' testimony

[Josip Rodin]

On Sun, May 23, 1999 at 01:46:18AM -0700, Joseph Carter wrote:
> > This, FYI, is why I sopped using joe. Not only is it buggy if used from a
> > buggy terminal emulator like windoze telnet, it had occasional bugs running
> > in an xterm (not screen display, but failure to reset the terminal properly
> > on exit).
> 
> In screen and console too.

I cannot confirm this, since I have never experienced it - it has never
had any problems in neither xterm, screen nor console, wherever I used it.
Only when you run it remote from non-Linux software.

-- 
enJoy -*/\*- http://jagor.srce.hr/~jrodin/

Re: An 'ae' testimony

[Craig Sanders]

On Sun, May 23, 1999 at 02:40:48AM -0500, Manoj Srivastava wrote:
> > and that includes a decent editor.
> 
> That rules vi out, then.

for politeness' sake i will interpret your remarks in the most positive
light possible: you are mistaken.

craig

--
craig sanders

Re: An 'ae' testimony

[Craig Sanders]

On Sun, May 23, 1999 at 02:11:03AM -0700, Joseph Carter wrote:
> On Sun, May 23, 1999 at 10:10:56AM +1000, Craig Sanders wrote:
> > > Are other editors really so difficult?
> > 
> > yes.  difficult and clumsy and lacking basic functionality.
> 
> All that missing functionality in ee (and ae in normal mode) is present
> in ae in vi mode?  Yeah.  

no, most of that functionality is missing from ae's crappy vi mode. that
is why it would be good if there were room for elvis-tiny to fit on the
boot disks, and that is why i object to the idea of wasting space on the
rescue floppy on 'ee' when it is basically the same as 'ae'. if there is
any extra space on the boot floppy then it should not be squandered on
ee, it should be used for something useful - a decent vi, preferably.

> You argued that vi mode SHOULD be preserved even if it was broken.

yes, i have argued that ae's vi emulation is better than nothing.

craig

--
craig sanders

Re: An 'ae' testimony

[Steve Lamb]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, 23 May 1999 20:36:10 +1000, Craig Sanders wrote:

>you can't yank lines.

Joe can do that.

>you can't cut and paste.

Joe can do that.

>you can't exec a program and have the output inserted in the bufer. 

Joe can do that.

>you don't have multiple undo and redo. 

Joe can do that.

>you can't pipe a block of text through a program. 

Joe can do that.

>you can't join lines reliably. 

Joe can do that.

>to change anything you first have to delete the old text and then type the
>new text. 

Joe can replace instead of insert.

>you can't do regexp search and replace.  

Joe can.

>there is no way to visually distinguish between tabs and spaces. 

You know, I don't even need that in vim.  Something about the cursor
jumping back and forth kinda clues me in.

>these are just some of the basic things that are missing or wrong in
>ae...there are many more, without even beginning to count the more useful
>advanced functions.

Your point?  For a basic install/rescue editor *NONE* of that is *NEEDED*.

>ae is an adequate minimal no-frills, no-features text editor. it's
>better than cat. it's even better than pico (which isn't hard). it's no
>substitute for vi.

Then will you shut up about vi?  You just admited what we've been trying
to tell you all the long!

>yes, vi IS non-primitive.  do not mock what you fail to understand.

vi is primitve.  I say that even as I type this message in vim.

>i thought i explained it well enough. vi is the sort of tool that when
>you get good at it becomes like an extension of your thoughts - you
>don't have to consciously think about HOW to do something, you just
>think about WHAT you want to do and it happens.

What do you know.  Joe does everything you say VI does, I consider joe an
extension of myself, I don't think, I do.  Therefore, Joe should go onto the
boot disk!  Thanks, Craig, the next time I ever use it I'll be most
appreciative of your logic!

>it means that trying to use some other less capable editor is like
>trying to edit with one hand tied behind your back and three fingers of
>your remaining hand chopped off. you can do so much more with vi that
>anything less is a major handicap.

And how does this fit into the context of an install/rescue disk.  *IT*
*DOESN'T*.

>i fail to see any further point in this thread. it's gone on way too
>long already. the fact is that vi is a basic unix tool which should
>be availablenot providing it on the rescue disk when we can do so
>would be absurdly laughable if it weren't so outrageously blinkered and
>pedestrian.

Yup, so laughable, FreeBSD, which adheres to the historical aspect of unix
more than Debian ever will, doesn't put vi on its install/rescue disk.  They
go with ee.  H, food for thought.

>i expected better of you than pointless cheap shots like this. guess i
>was mistaken.

Well, craig, it seems to be the only thing that you respond to.  It
appears most of your arguements fall into that catagory.  What is best for
Craig Sanders, God of the Internet, Master of Debian and to hell with the
peons.  

Jeez, Craig, I consider joe in the same vein you consider vi and I'm
willing to use ee or ae if it gets the job done because they are better for
the distribution.  Noone except for idiot blowhards like you give a damn
about vi anymore.


- -- 
 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/AwUBN0fenXpf7K2LbpnFEQJ7XQCgzG00U619tWAaJVYH8QCaI2OMGmQAn04T
SG+cDMrJMLqVna6Zrj6Y1fKh
=py/A
-END PGP SIGNATURE-

Re: An 'ae' testimony

[Steve Lamb]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, 23 May 1999 20:48:50 +1000, Craig Sanders wrote:

>ee, it should be used for something useful - a decent vi, preferably.

Vi isn't useful to a newbie who doesn't know vi.  Hell, it isn't useful
to experienced unix people who have never had to touch vi.  Go away, Craig,
please, just go away.

- -- 
 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/AwUBN0fe/npf7K2LbpnFEQK1UgCdGTP0uJYV69L1ABQ2hd6xvuGcUbAAoIZb
sWKlSxCGUgNuYSr/S0NMUPaA
=aWLc
-END PGP SIGNATURE-

Re: X on a Dell Inspiron Laptop

[Andreas Plesner Jacobsen]

On Sat, May 22, 1999 at 08:14:32PM -0500, Douglas Bates wrote:

> A friend recently bought a high-end Dell laptop computer.  The model
> is the Inspiron 8000, if I recall correctly.

Check out http://www.eecs.umich.edu/~steveh/inspiron/ for notes on
the Inspiron 7000, I think much of the info there is usable.

-- 
Andreas

Re: Request for package: mcrypt

[J.H.M. Dassen]

On Sat, May 22, 1999 at 19:17:15 -0700, Joel Klecker wrote:
> mcrypt is a replacement for the old unix crypt(1). It uses the block 
> algorithms DES, TripleDES, Blowfish, 3-WAY, SAFER-SK64, SAFER-SK128, 
> TWOFISH, TEA, RC2, RC6, IDEA and GOST in CBC, OFB, CFB and ECB modes. 

I'd love to see it split in a free (no IDEA, RC6? and possibly others) and a
full version.

Last time I checked, the upstream version didn't produce shared libraries.
It should probably be modified to do so, and such changes should be
integrated upstream (to prevent .so version issues).

Ray
-- 
ART  A friend of mine in Tulsa, Okla., when I was about eleven years old. 
I'd be interested to hear from him. There are so many pseudos around taking 
his name in vain. 
- The Hipcrime Vocab by Chad C. Mulligan 

Re: xfstt 0.9.99 uploaded - some news with it

[Marco d'Itri]

On May 23, Greg Stark <[EMAIL PROTECTED]> wrote:
 >> /var/run/xfstt like other similar programs do.
 >Couldn't we just set the sticky bit on /var/run ?
We don't need another world writeable directory in /var.

-- 
ciao,
Marco

Re: An 'ae' testimony

[Guenther Thomsen]

In message <[EMAIL PROTECTED]>, Josip Rodin writes:
> On Sun, May 23, 1999 at 11:13:29AM +1000, Craig Sanders wrote:
[..]
> 
> > you are also making the mistake of assuming that joe is in any way a
> > standard tool. it is not. the only two text editors which can lay claim
> > to being a standard part of any unix are ed and vi.  
> 
> On a rescue disk you don't need standard tools. You need any kind of
> tools that do their job. If there would be standard tools on it, then
> we would have to include X and at least two emacs variants on it ;)
 Yes, but we need minimalistic tools, which behave in a standard (i.e. well
known) way. 

> 
> > > You have to have a broader view (is that the expression?) in this
> > > case, since it is not only yours boot disk, but everyone elses.
> > 
> > i think it is you who needs the broader view. the world is not composed
> > entirely of newbies seeking escape from dos/windows. in fact, it's fair
> > to say that complete newbies aren't our target market, we make a high
> > quality distribution perfectly suited to experienced unix users. even
> > so, we support them by including a simple editor (ae) on the rescue
> > disk...why should we do less for our target market?
> 
> No, I don't think that including ae was done becuse of the
> user-friendliness - ae, as any usual unix text editor, is something that
> complete newbies don't like. If we cared about newbies, we would get a
> MS-DOS edit clone or even start up the X just after booting (I don't exactly
> know how, but you get the point).
 I like to second that. Newbies are likely to be overtaxed by the very 
situation, where a _rescue_ disk is necessary. They're starting to whine
and yell and call for help from a friend or contractor anyway.

> 
> > debian has been criticised in the past for failing to include vi on the
> > rescue floppy. we copped a lot of flack for not having one as it is a
> > tool which any experienced unix user can reasonably expect to find on a
> > rescue floppy.
> 
> However, the situation is a bit more complicated than what it may seem
> to an innocent bystander - we have the boot disk, and the rescue disk
> in the same image, i.e. on the same 1.44MB  - and that is a really practical
> reason why we needed to put a very very small (yet functional) editor on it.
> Debian should not be criticized because of that decision, it was completely
> logical in these circumstances.
 Well, than should Debian be criticizied for the decision, to use just one
disk? I would prefer to swap disks (a _few_ times) instead of using a 
crippled editor. I can cope with ae (and measured by its size, it is an 
awesome tool), but more than once, I wished to have something closer to vi.
Vi might scare newbies to death, but at least, it's documented in most Unix
beginner's books.

Guenther

Re: CALL for PAM support

[Michael Alan Dorman]

Ben Collins <[EMAIL PROTECTED]> writes:
> There is a libapache-mod-pam, which enables apache auth using PAM
> modules, already packaged. It has some drawbacks due to permissions
> (apache runs as www-data so it cannot access /etc/shadow). This can't
> be avoided however.

Um, doesn't libpwdb take care of this?  I would swear (though I can't
confirm it right now, or I would) that I had apache running the
mod_pam module authenticating against shadow with no problems, *once I
installed libpwdb*.

Mike.

Re: X on a Dell Inspiron Laptop

[Michael Neuffer]

* Douglas Bates ([EMAIL PROTECTED]) [990523 03:30]:
> A friend recently bought a high-end Dell laptop computer.  The model
> is the Inspiron 8000, if I recall correctly. 

>From the graphics hardware it is an Inspiron 7000, there is no 8000

> Another problem we encountered is in the configuration of the X
> server.  The version of SuperProbe and the xservers in Debian 2.1 were
> not able to recognize the chip.  We installed the 3.3.3.1 X11 packages
> compiled for Debian 2.1 from the www.netgod.net site.  That version of
> SuperProbe recognized the chip and describes it as
> 
>  First video: Super-VGA
>  Chipset: ATI 264LT Pro (Port Probed)
>  Memory: 8192 Kbytes
>  RAMDAC: ATI Mach64 integrated 15/16/24/32-bit DAC w/clock
>  (with 6-bit wide lookup tables (or in 6-bit mode))
>  (programmable for 6/8-bit wide lookup tables)
>  Attached graphics coprocessor:
>Chipset: ATI Mach64
>Memory: 8192 Kbytes
> 
> but neither the xserver-svga nor the xserver-mach64 packages seem to
> want to drive it.  Does anyone know if there are more recent drivers
> at xfree86.org or at SuSE that will drive this video system?


Unfortunately does the XFree86 Xserver still not completely support
the LT variant of the Rage Pro chipset.

What you need to do is to take the latest Debian Mach64 Xserver from 
unstable and add a few things that you can find here:

http://www.eecs.umich.edu/~steveh/inspiron/

It is quite possible that you need to downgrade the BIOS of the laptop 
tothe A06 revision, since newer revisions do not set up the Rage LT Pro 
chip properly

I've been running my I7k under X since October last year. First with the
dongle solution later then with the help of the vesa-fb driver in the 
kernel.

If you still have problems with your friends laptop after reading the 
above web site, I can mail you my detailed setup.

Mike

Re: An 'ae' testimony

[Hamish Moffatt]

On Sun, May 23, 1999 at 01:46:18AM -0700, Joseph Carter wrote:
> On Sat, May 22, 1999 at 12:17:14PM -0700, Joey Hess wrote:
> > The reason it has this problem is because it uses its own special terminal
> > data files (/etc/joe/terminfo) instead of the standard ones.
> > 
> > This, FYI, is why I sopped using joe. Not only is it buggy if used from a
> > buggy terminal emulator like windoze telnet, it had occasional bugs running
> > in an xterm (not screen display, but failure to reset the terminal properly
> > on exit).
> 
> In screen and console too.

When I use rxvt, LOTS of programs have trouble restoring the screen on
exit. vi, for one. I'd guess all ncurses programs, but I'm not sure.



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


pgpYxogNdKLKE.pgp
Description: PGP signature

Re: An 'ae' testimony

[Hamish Moffatt]

On Sun, May 23, 1999 at 03:57:02AM -0700, Steve Lamb wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Sun, 23 May 1999 20:48:50 +1000, Craig Sanders wrote:
> 
> >ee, it should be used for something useful - a decent vi, preferably.
> 
> Vi isn't useful to a newbie who doesn't know vi.  Hell, it isn't useful
> to experienced unix people who have never had to touch vi.  Go away, Craig,
> please, just go away.

joe and ae are no more intrinsically friendly, they just have help
windows at the top of the screen. If we put one in a small vi, would
that shut you up?


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

Re: An 'ae' testimony

[Michael Stone]

On Sun, May 23, 1999 at 11:46:43PM +1000, Hamish Moffatt wrote:
> joe and ae are no more intrinsically friendly, they just have help
> windows at the top of the screen. If we put one in a small vi, would
> that shut you up?

I disagree: a modal editor is intrisically easier to get stuck in,
because most beginners don't understand the modality concept.

Mike Stone

Re: CALL for PAM support

[Ben Collins]

On Sun, May 23, 1999 at 09:33:36AM -0400, Michael Alan Dorman wrote:
> Ben Collins <[EMAIL PROTECTED]> writes:
> > There is a libapache-mod-pam, which enables apache auth using PAM
> > modules, already packaged. It has some drawbacks due to permissions
> > (apache runs as www-data so it cannot access /etc/shadow). This can't
> > be avoided however.
>
> Um, doesn't libpwdb take care of this?  I would swear (though I can't
> confirm it right now, or I would) that I had apache running the
> mod_pam module authenticating against shadow with no problems, *once I
> installed libpwdb*.

No. pam_pwdb modules uses an external program that is sgid shadow to
authenticate users without having the calling program be sgid shadow.
However it only authenticates the calling user (www-data in this case),
so it wont work for any normal users.

--
--- -  -   ---  -  - - ---   
Ben Collins <[EMAIL PROTECTED]>Debian GNU/Linux
OpenLDAP Dev - [EMAIL PROTECTED] The Choice of the GNU Generation
-- -- - - - ---   --- --  -  - ---  -  --

Re: An 'ae' testimony

[Josip Rodin]

On Sun, May 23, 1999 at 01:20:11PM +0200, Guenther Thomsen wrote:
> > > you are also making the mistake of assuming that joe is in any way a
> > > standard tool. it is not. the only two text editors which can lay claim
> > > to being a standard part of any unix are ed and vi.  
> > 
> > On a rescue disk you don't need standard tools. You need any kind of
> > tools that do their job. If there would be standard tools on it, then
> > we would have to include X and at least two emacs variants on it ;)
>  Yes, but we need minimalistic tools, which behave in a standard (i.e. well
> known) way. 

It's better to have an unknown set of keybindings, because if there was
a standard one (emacs, vi, wordstar, MS Word^H^H^H^H^H^H^H), we'd have
another flamewar

> > However, the situation is a bit more complicated than what it may seem
> > to an innocent bystander - we have the boot disk, and the rescue disk
> > in the same image, i.e. on the same 1.44MB  - and that is a really practical
> > reason why we needed to put a very very small (yet functional) editor on it.
> > Debian should not be criticized because of that decision, it was completely
> > logical in these circumstances.
>  Well, than should Debian be criticizied for the decision, to use just one
> disk? I would prefer to swap disks (a _few_ times) instead of using a 
> crippled editor. I can cope with ae (and measured by its size, it is an 
> awesome tool), but more than once, I wished to have something closer to vi.
> Vi might scare newbies to death, but at least, it's documented in most Unix
> beginner's books.

Complain to debian-boot@lists.debian.org, or file a bug against
boot-floppies.

-- 
enJoy -*/\*- http://jagor.srce.hr/~jrodin/

Re: An 'ae' testimony

[Hamish Moffatt]

On Sun, May 23, 1999 at 09:56:06AM -0400, Michael Stone wrote:
> On Sun, May 23, 1999 at 11:46:43PM +1000, Hamish Moffatt wrote:
> > joe and ae are no more intrinsically friendly, they just have help
> > windows at the top of the screen. If we put one in a small vi, would
> > that shut you up?
> 
> I disagree: a modal editor is intrisically easier to get stuck in,
> because most beginners don't understand the modality concept.

What if we make the help text mode-sensitive? eg

--EDIT MODE--
Enter text. Hit ESCAPE to return to command mode.


--COMMAND MODE--
i - insert at current cursor position   :wq - Save
a - insert after current cursor position:d  - Delete a line
arrow keys to move (assuming they work)



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

Re: stupid idea - metapackages

[Adrian Bridgett]

On Sat, May 22, 1999 at 05:18:24PM -0400, Adam Di Carlo wrote:
> > "Philip" == Philip Hands <[EMAIL PROTECTED]> writes:
> 
> Philip> How about creating a new section ``profiles'' for them, so
> Philip> that they are all grouped together in dselect ?
> 
> I think it's a little too early for new sections.  The boot-floppies
> team, in particular, wanted to see someone implement some metapackages
> before moving the profile/task system over to them.
> 
> [Also, I think we need to totally rip up our archive sections, adding
> stuff like 'database', 'i18n', 'lang/perl', 'lang/python',
> 'lang/elisp', etc, and also allow pkgs to be in more than one
> section.]

I really like this idea (I had the same idea a while ago so I'm biased ).
The sections need to be listed somewhere, but it would be pretty cool to
have netscape in 
web/browsers
web/editors
news/readers
mail/readers

I think we should still use a hierarchal FTP layout though - putting 1000's
of files in one directory is slow, if nothing.
(web/readers isn't common terminology incase you were wondering).

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: Paying CD vendors for freebies

[Adrian Bridgett]

On Sat, May 22, 1999 at 04:10:01PM -0700, Joseph Carter wrote:
[snip]
> Yes, but we tend to run out quickly, too quickly.  A bit of reference,
> CD's (usually a CD sells for about US$2, they cost US$.43 to make last
> time I checked---for a run of 1000), well their donations are pretty
> significant.  500 sets, 4 CDs a set, that adds up.
> 
> What I'm wondering is if we could make arrangements with them for
> something that would involve us paying for some of the CDs so we'd have
> more.  At LinuxWorld, we really did not have enough to go around and the
> ones we had were gone in 30 minutes.

How about having a donation box. Debian is a registered charity after all.
With a suggested donation of a couple of dollars?  I appreciate that this
might be against the freebie policy, but would serve three purposes:
  a) disuade people who just pick it up because it's a freebie
  b) recoup some of the costs
  c) have more CDs left for the needy [1](because of a)

[1] those still on bo or rex.

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

Request for package: Midgard

[Henri Bergius]

Greetings!

First, I guess it would be a good idea to introduce me
and the project I'm talking about. I am working as a
Webmaster for a finnish IT company. Our Web Team does all of
the development using Free Software tools, and also participates
actively in some projects in our field, most important of
these being the Midgard project. Midgard is a freely-available
web application server based on PHP3 
(http://www.midgard-project.org).

Now, as I use Debian boxes at work, I have been thinking
on making a Debianized version of Midgard so that it would
work better for users of this very nice distribution.

However, after studying the matter for a while, I understand
that while I could easily get Midgard packaged and make it
available, I still wouldn't propably have enough time to fulfill
the responsibilities of a Debian Developer properly.

Because of this I am asking you whether there would be interest
in some of you to work on creating an maintaining the Debian
packages for this application server suite.

The Midgard Project is evolving quite fast and new versions
are popping up every few weeks. It is licensed under LGPL with
example code in it distributed under the X Consortium license. 
This would make it suitable for the main branch. However, as 
it depends on MySQL (non-free, I guess) at this point it should
propably be placed in contrib. We are looking to add support
for other databases and this problem should disappear sometime
during June.

If you are interested in the project, please contact me and
I'll be happy to help you with getting the project started
and working.

Thanks in advance!

/Bergie
-- 
-- Henri Bergius -- +358 40 525 1334 -- [EMAIL PROTECTED] --
   http://www.iki.fi/Henri.Bergius

Re: Bug#37789: libssl09: version incompatibility

[Clint Adams]

> The programs have to be relinked with openssl.

Fair enough.

> So, there should be bugs filed against the packages which have to be
> relinked. 

While that is true, that still does not prevent someone from
upgrading either the packages which depend upon libssl09 or
libssl09 and not the dependent packages, thereby breaking
everything with no apparent explanation.

I'm back from vacation now

[Wichert Akkerman]

As the subject already says, I'm back from my vacation again. I had
a really good time, I'ld like to thank Konstantinos Margaritis
(aka as Feanor on irc) for acting as our tour guide through Athens.

I'm slowly working my way through about 4000 emails now. If you feel
something needs my quick attention or I missed something please send
it again with a reminder.

Wichert.

-- 
==
This combination of bytes forms a message written to you by Wichert Akkerman.
E-Mail: [EMAIL PROTECTED]
WWW: http://www.wi.leidenuniv.nl/~wichert/


pgpsk1HvoOacL.pgp
Description: PGP signature

Re: [PRE-ANNOUNCE] DPKGv2 Project

[Wichert Akkerman]

Previously Hamish Moffatt wrote:
> 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.

Personally I wouldn't mind other similar projects. I do think that
people should give this one a close look before going off to do
something themselves as well.

Also please don't consider is a DPL-blessing or so, it is just something
that has crossed my mind quickly once or twice, and I hope to do part of
this as my MSc project.

Wichert.

-- 
==
This combination of bytes forms a message written to you by Wichert Akkerman.
E-Mail: [EMAIL PROTECTED]
WWW: http://www.wi.leidenuniv.nl/~wichert/

Re: 3c5x9setup and isapnptools

[Wichert Akkerman]

Previously Ben Pfaff wrote:
> The corresponding program for configuring Western Digital and SMC
> Ethernet cards (wdsetup) is in netstd.  Perhaps this is the approved
> place for such tools?

Or maybe we should move them all to the hwtools package?

Wichert.

-- 
==
This combination of bytes forms a message written to you by Wichert Akkerman.
E-Mail: [EMAIL PROTECTED]
WWW: http://www.wi.leidenuniv.nl/~wichert/


pgp8Pwjxr50Or.pgp
Description: PGP signature

Re: capabilities

[Wichert Akkerman]

Previously Marco d'Itri wrote:
> What would you all think about a patch to start-stop-daemon to remove
> capabilities from spawned daemons?
> Whith this patch many daemons would not need uid=0 anymore.

You either run with uid=0 and remove capabilities, or run with another
uid and add capabilities. Make up your mind :).

The right solution is probabily either something like a capd, or a
capabilities-enhanced filesystem (I think there are patches for ext2fs,
and ext3fs already has it?).

Wichert.

-- 
==
This combination of bytes forms a message written to you by Wichert Akkerman.
E-Mail: [EMAIL PROTECTED]
WWW: http://www.wi.leidenuniv.nl/~wichert/


pgpi6youYF8LI.pgp
Description: PGP signature

Re: (LONG) Correct non-US solution

[Wichert Akkerman]

(I'm coming in late here, but I'll make some remarks anyway. If others
made them as well just ignore me).

A couple of remarks:
* we don't control how mirrors mirror our archives, and we don't want to
  create a situation where mirrors need special tools and/or scripts.
  (okay, we probably could create a `safe' symlink-tree or so, but
  that's ugly).

* the same discussion was held earlier as while. One of the points made
  was that you don't want to list the countries in the package, but the
  reasons why a package is restricted (ie RSA, LZW, mp3) and have a
  seperately maintained list to map those to countries.

Wichert.

-- 
==
This combination of bytes forms a message written to you by Wichert Akkerman.
E-Mail: [EMAIL PROTECTED]
WWW: http://www.wi.leidenuniv.nl/~wichert/


pgpVBKJ48fD6K.pgp
Description: PGP signature

Re: new arch required

[Wichert Akkerman]

Previously Martin Schulze wrote:
> vger

strike strike cross cross, cvs.on.openprojects.net (it moved)

Wichert.

-- 
==
This combination of bytes forms a message written to you by Wichert Akkerman.
E-Mail: [EMAIL PROTECTED]
WWW: http://www.wi.leidenuniv.nl/~wichert/


pgpnOc4UGXWcG.pgp
Description: PGP signature

Suggestion: new "debian" archive section

[Julian Gilbey]

At the moment, all of the Debian-specific development and packaging
tools are scattered around various sections of the archive, some in
base (understandably!), some in devel, some in utils, and probably
others in other sections.  But in some sense, they don't belong in any
of them (except for dpkg and a very few others in base): they are not
really "development libraries" needed for non-Debian developers to
compile software, they are not really general purpose utilities, and
so on.

I propose that the distribution should have a new "debian" section
which would be the place to put all of the Debian-specific packages,
at least in the source distribution.  It would also be the location
for the packages needed only by developers in the binary
distribution.  (Of course, "needed" here has a loose meaning.)  This
would include:
  dpkg*, apt (and any associated packages), debhelper, debstd,
  devscripts, dupload, debian-keyring (?), and others.

This would help (a) new developers looking to find out which packages
they will need, (b) non-developers looking for certain Debian-specific
packages, and also those *not* looking for them, and (c) anyone who
wants to help Debian improve its system will have a simple place to
start!

Thoughts, anyone?

   Julian

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

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
 Debian GNU/Linux Developer.  [EMAIL PROTECTED]
   -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-

Re: An 'ae' testimony

[Justin N. Penney]

Just thought that i would throw my two cents in since i still remember the
switch from DOS/Windows to Linux.

I had some problems with ae on my first install (1.3). I just installed off of
floppies and only new about ae. So i was using it for editing. After i learned
a little about bash i edited my bash profile and added some aliases. None of
them worked cuz ae actually inserted ^M when i hit return. So i got on irc (on
a windows box) and asked a friend what the errors that i was getting were. He
told me to edit the file again in vi and see if there wer any control
characters that were in the file. So i typed 'vi .bash_profile' and was lost.
I did see hte ^M's though so i knew i could fix it from there and bought UNIX
for Dummies to learn vi. I still liked ae though.

Next install (2.0) ae was completely different. None of the keystrokes were
the same and some of them just seemed to not work. I learned more about vi,
installed vim and went on with that.

Well i tried to install FreeBSD about 5 months ago. I did NOT go smoothly
especially the dialing my isp and ftping it, Just would not work right. So my
friend set up his box for ip-masq and i installed it that way. well ee was the
editor and my only thought was "Well this is easy." I wish it had been on the
debian boot disks at the time that i needed them.

I will agree with the vi zealots that vi is fast, easy and once you learn it
like second nature. But remembering what it was actually like to come from
where most new linux users come from i remember how hard vi was and how weird
ae was. 

-- 
  _   _   _   _   _   _   _   _   _   _   _   _  Justin N. Penney
 / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ 
( s | p | a | n | k | e | n | s | t | e | i | n )
 \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/@mindless.com 
 http://echo.sound.net/~clancey/
 http://egb.home.dhs.org/

Re: An 'ae' testimony

[Steve Lamb]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, 23 May 1999 23:46:43 +1000, Hamish Moffatt wrote:

>joe and ae are no more intrinsically friendly, they just have help
>windows at the top of the screen. If we put one in a small vi, would
>that shut you up?

Nope, because vi also is modal.  That, by default, makes it intristically
less friendly.  
- -- 
 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/AwUBN0gnxXpf7K2LbpnFEQJGQgCeOPEf+aH5eNkIPkUhfEfo2JoZsI0AoIu9
ZcLMeGb4zsBrwWjPBrpUtMb0
=IlHC
-END PGP SIGNATURE-

Re: netscape crashes on potato

[Per Lundberg]

Greg Stark <[EMAIL PROTECTED]> writes:

> So the people who don't see crashes, which version of Netscape are you using?

I've tried 4.08, 4.5 and 4.6 (all glibc, "standalone").


> Do you use java successfully in Netscape?

Yes.


> Do you have plugger installed?

No.


> Do you have any other plugins installed?

No.


> Which versions of libc are you using?

glibc 2.1.1 on both the computers I've tried this on.


> # dpkg -l \*netscape\* | grep ^hi
> hi  netscape-base-4 5  Popular World-Wide-Web browser software 
> (bas
> hi  netscape-base-4 4.5-1  Popular World-Wide-Web browser software 
> (bas
> hi  netscape-java-4 4.5-1  Popular World-Wide-Web browser software 
> (jav

Oh, BTW, I used the "netscape4" package for installation.

HTH.

-- 
 .,---.-..-.-.---.-.-.-.--+-.-.---.-.---..-.-,+--.-,.
;  Per Lundberg)  [EMAIL PROTECTED]  )
(  "Down, not across"  (  http://www.chaos-development.cx/   ;
 `^--.-+---+--.+-+-+---++-+-+--+-+-+-+-+-+-+--+-+.+.+++^'

Re: request to kill nag messages

[Manoj Srivastava]

Hi,
>>"Hamish" == Hamish Moffatt <[EMAIL PROTECTED]> writes:

 Hamish> What does that treatment involve exactly?

My lawyer says I should not answer this question.

 Hamish> Personally I can't see what the fuss is; I'd just delete it if
 Hamish> I didn't like it.

Ah, the classic refrain of spammers. Just hit the delete key
 if you do not like spam.

manoj
-- 
 "I'd love to go out with you, but it's my parakeet's bowling night."
Manoj Srivastava   <[EMAIL PROTECTED]>  
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

Re: (LONG) Correct non-US solution

[Jonathan Walther]

On Sun, 23 May 1999, Wichert Akkerman wrote:
> A couple of remarks:
> * we don't control how mirrors mirror our archives, and we don't want to
>   create a situation where mirrors need special tools and/or scripts.

According to previous posts, our top tier mirrors already run special
software to mirror us, and under the new scheme those are the only ones that
would need to run our custom stuff anyways.

>   was that you don't want to list the countries in the package, but the
>   reasons why a package is restricted (ie RSA, LZW, mp3) and have a
>   seperately maintained list to map those to countries.

Yes, that is undoubtedly a superior solution, but a lot more work.  It
relies on a few people to make up these lists and maintain them.  The new
way would distribute the load over all our developers, as it would
distribute load over our mirrors.

a) the file mapping is much more complex to implement
b) doesn't give a developer much control over his own package 
(ie, if your package suddenly became illegal somewhere for some reason that
wasn't already listed, the developer could quickly respond, instead of
yanking it from the distribution)

Jonathan

Re: Bug#37789: libssl09: version incompatibility

[Christoph Martin]

Clint Adams writes:
 > > So, there should be bugs filed against the packages which have to be
 > > relinked. 
 > 
 > While that is true, that still does not prevent someone from
 > upgrading either the packages which depend upon libssl09 or
 > libssl09 and not the dependent packages, thereby breaking
 > everything with no apparent explanation.

The new packages like telnet-ssl, apache-ssl and lynx-ssl all depend
on libssl09 (>= 0.9.2b)

The other packages should do this also.

Christoph

Re: An 'ae' testimony

[Manoj Srivastava]

Hi,
>>"Hamish" == Hamish Moffatt <[EMAIL PROTECTED]> writes:

 Hamish> What if we make the help text mode-sensitive? eg

Do that, and still have the editor small enough (isn't ae like
 25Kb or something?), and then we shall have something to talk
 about. In the meanwhile, vi is not an option as the sole editor at
 install/rescue times.

manoj
-- 
 I can't stand squealers; hit that guy. Albert Anastasia
Manoj Srivastava   <[EMAIL PROTECTED]>  
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

Re: An 'ae' testimony

[Manoj Srivastava]

Hi,
>>"Craig" == Craig Sanders <[EMAIL PROTECTED]> writes:

 
 Craig> ae is an adequate minimal no-frills, no-features text editor.

Bingo. That is what we absolutely need -- the rest of the
 features are what you just said -- frills.

 Craig> it's better than cat. it's even better than pico (which isn't
 Craig> hard). it's no substitute for vi.

Opinions. Anything, IMHO, is better than vi ;-)

 >> > being restricted to a primitive editor after you have become
 >> > proficient with vi is akin to re-learning how to talk after having a
 >> > stroke..
 >> 
 >> Ahem. vi non-primitive heh-heh-heh.

 Craig> yes, vi IS non-primitive.  do not mock what you fail to understand.

Oh, I understand vi. I have been using it for 12 years now. I
 just find it incredibly primitive. We do seem to be trading opinions
 in this thread, so I just added mine. Or is it that only some people
 can flaunt their opinions, and dissenters can't? 


 >> Are vi users less capable, or more inflexible, than users of better
 >> editors? I think you are doing vi users a dissservice, labeling them
 >> so incapable and unadapting.

 Craig> no, vi users are not less capable or more inflexible (and there are
 Craig> no better editors -- emacs is not a text editor, it's a programmable
 Craig> editing environment. if you like that kind of thing then more power to
 Craig> you...but emacs is also no substitute for vi).

 Craig> i thought i explained it well enough. vi is the sort of tool that when
 Craig> you get good at it becomes like an extension of your thoughts - you
 Craig> don't have to consciously think about HOW to do something, you just
 Craig> think about WHAT you want to do and it happens.

Yes. And in a full fledged system you should probably have
 access to this paragon of productivity. However, we are talking about
 impaired systems, where everyone has to settle for less. 

 Craig> this doesn't mean that vi users are less flexible or less
 Craig> capable.

I seem to only hear them complaining. I used occams razor to
 decide what the reason could be.

 Craig> it means that trying to use some other less capable editor is like
 Craig> trying to edit with one hand tied behind your back and three fingers of
 Craig> your remaining hand chopped off. you can do so much more with vi that
 Craig> anything less is a major handicap.

The same could be said of XEmacs. Unfortunately, this is an
 impaired system we are talking about. 


 Craig> i fail to see any further point in this thread. it's gone on way too
 Craig> long already. the fact is that vi is a basic unix tool which should
 Craig> be availablenot providing it on the rescue disk when we can do so
 Craig> would be absurdly laughable if it weren't so outrageously blinkered and
 Craig> pedestrian.

I see. 

 >> Anyway, every one knows that vi is primitive ;-)

 Craig> i expected better of you than pointless cheap shots like this. guess i
 Craig> was mistaken.

I see that your cool has not been the sole victim of this
 thread. Your sense of humour has died too. (You do know what a smiley
 means, don't you?)

manoj
 who has not had a good editor war in years
-- 
 To find a friend one must close one eye; to keep him -- two. Norman
 Douglas
Manoj Srivastava   <[EMAIL PROTECTED]>  
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

Re: Source-depends?

[Martin Bialasinski]

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

JM> A soultion to number 1 that was tossed around included using
JM> libtricks to get a list of files accessed, and is therefor (IIRC)
JM> obselete.  (And in any case is prohibitively slow.)

But it would greatly help. And you won't do it everytime you build the
package, but only once, or when upstream changes significantly so it
is easier to run the program again.

Usually you do some testbuilds until everything fits as intended, then 
you do the ful build with signing etc. So before the final step, you
would do run this program zu build the list of source dependencies,
edit the control file and do the final build.

Ciao,
Martin

Re: Source-depends?

[Ron]

> > I see two situations up front:
> >  - a need to describe the tools needed to build a package
> > (eg. gcc, bison, flex, etc..)
> >  - and a need to describe the other source packages or librarys required
> > to build a working binary.
> Why do these need to be treated differently?

They don't need to be if they are all available as .debs, but I
envisaged the possibility of:

> 3. Requiring bin-packages vs. requiring build trees from other package's
>source

thinking about that though, I tend to agree with:

> In general, on prior discussions, ... on 3 it was suguested that
> requiring build trees from another package was considered buggy.

There are exceptions to this of course.. some packages require kernel
source to build modules etc.  but in general I would think that this
sort of dependency should be resolved by having a foo-dev.deb package.

Re: An 'ae' testimony

[Riku Voipio]

On Sun, May 23, 1999 at 02:27:57AM +0200, moron wrote:

>  I've spent hours a day for the last few
> weeks trying to edit configuration files and cut down the size of log files
> (Am I supposed to do that?) and wishing I had something as intuitive as dos
> edit, where arrow-up goes up one and arrow-left goes left one and (not
> intuitive, but easily learnt) the shift key marks it and the delete key
> removes it.

You may want to try fte and fte-console. They work exectly as you
defined. 

-- 
Riku Voipio|[EMAIL PROTECTED] |
Poutamäentie 15 B 78   |+358 50 3313498  --+--
00360 Helsinki |   |
Facts do not cease to exist because they are ignored.  |

Re: Source-depends?

[Ron]

> > > Some of these can be detected automatically (#5 could be discovered with a
> > > grep on debian/rules, for example), but some can't.
> > 
> > So, what's the problem?  We don't autodetect all of binary dependencies
> > either.  Maintainers generally know what they need to build their packages;
> > it should be trivial for them to list the dependencies explicitly!
> > 
> > Besides, if source dependencies were completely autodetectable, we wouldn't
> > need them.
> 
> Agreed. We don't need any magic, just a common location for that useful
> piece of information.

This seems like a very rational place to start..  we need a control field
to describe source dependencies before we can have any magic (ordinary or
otherwise;) that will use them..

How then do we get this a step closer to reality..  should this become a
formal policy proposal for including a source-depends description to the
control files, or do we handball this to the team that will ultimately
undertake the rehash of the packaging system?

I think I'd like to see dpkg-ng handling *both* source and binary package
installs in the future, but perhaps someone has reasons that I am misguided
in this??

best,
Ron.

Re: An 'ae' testimony

[David Frey]

On Fri, May 21, 1999 at 11:34:24PM -0700, Chris Waters wrote:
>"Steve Lamb" <[EMAIL PROTECTED]> writes:
>> If ee does this (I dunno, but my friend swears by it), then so be it,
>> install it, move on.
>Again, ae is *half* the size of ee, and ee doesn't even offer the
>option of vi emulation.  If we can't fix some of the more noticable
>problems of ae, and *still* come in smaller than ee, there's something
>wrong with us.

I personally *hate* ae. I think it is essential to have some vi-clone
installed on the bootdisk or at least ed for the advanced users (so that
one can fix e.g. /etc/fstab without cut and paste and grep alone).
Of course, an ee (or if you must ae) for the newbies should be there too.

David
-- 
Those who do not understand Unix are condemned to reinvent it, poorly.
  -- Henry Spencer

Re: Request for package: Midgard

[Christian Hammers]

On Sun, 23.05.99 14:50 +, Henri Bergius wrote:
> This would make it suitable for the main branch. However, as 
> it depends on MySQL (non-free, I guess) at this point it should
> propably be placed in contrib. We are looking to add support
> for other databases and this problem should disappear sometime
> during June.
There is a free mysql client in main and the GPL'ed server will follow
at the Linux-Expo in June.

> /Bergie
read you,

   -christian- (Debian MySQL Maintainer)

-- 
Linux - the choice of the GNU generation.  Join the Debian Project 
 http://www.debian.org 
Christian Hammers * Oberer Heidweg 35 * D-52477 Alsdorf * Tel: 02404-25624
50 3C 52 26 3E 52 E7 20  D2 A1 F5 16 C4 C9 D4 D3  1024/925BCB55 1997/11/01

Re: netscape crashes on potato

[Bob Nielsen]

On Sat, May 22, 1999 at 11:13:56PM -0400, Greg Stark wrote:
> 
> So the people who don't see crashes, which version of Netscape are you using?
> Do you use java successfully in Netscape? Do you have plugger installed? Do
> you have any other plugins installed? Which versions of libc are you using?


I haven't had any problem with navigator versions 4.07 and 4.6, as well
as communicator 4.08. I did have a problem with 4.51 crashing, however. 
I have used java and plugger.  I think I had libc6 (2.0.x) with 4.07 and
have use both 2.0 and 2.1 with 4.08 and 4.6. 

Bob

-- 
Bob Nielsen Internet: [EMAIL PROTECTED]
Tucson, AZ  AMPRnet:  [EMAIL PROTECTED]
DM42nh  http://www.primenet.com/~nielsen

logos ( Cervantes like) : the end

[Thierry Laronde]

( I post this in the list in order that people who read the archives and
still follow the links to my web page can know I have taken it out)

/*
 For the few men who have sent me a kind comment : don't be surprised to
receive this  message apparently twice if you subscribed to
debian-devel : one is a blind copy, so that  you don't have the "public
shame" !:-)!to be, even in the header, associated with what I have done.
*/

AFAIK, my proposal for the logos based on Cervantes characters has been,
at best, ignored, at worst, rejected. The fact is that debians haven't
judged it at the level of the logos included in the final set.
I don't know if this is because they found my messages exasperating, my
thinking outrageous and my drawing ridiculous, or the whole
insignificant. I'm sorry for the waste of time and bandwidth, and thank
the almost two hundred people who honoured me by giving a look at the
job :-D.

So we are in the second case that I have touched in the previous message
: I give asylum to DQM and Pancho at Polynum's, where the two chimeras
will illustrate the two faces of a french limited reflection upon
liberty and business ( especially in computing) - it's only right,
because the initial idea came to me when I was thinking about this ( the
idea is still obvious for me). 

As a result, the web page will be taken out in the next days, and the
mentions DEBIAN and DEBIAN friendly removed from the pictures so that
nobody can think you endorse them.

Thanks for reading.
 
-
Thierry LARONDE
http://www.polynum.com
[EMAIL PROTECTED]
-
Ubi solitudinem faciunt, pacem appellant

Re: LinuxExpo report, Day 1

[Justin Maurer]

> First, I've got photos of the day at LinuxExpo.  They're all either
> 1280x960 or 1024x768 JPEGs; by the time you read this or shortly
> thereafter, they'll be up on my website at:
> 
>   http://www.debian.org/~jgoerzen/lexpo-photos/

oh my god, my ass is huge! ;)
haha, man, the way my clothes wrinkled up, i got screwed in pic #2

my photos are being developed as we speak

-- 
Justin Maurer[EMAIL PROTECTED]
IFT Systems, Inc.http://linux.hypnotic.org
6717 N.31st Street  Tel: +1 (703) 237-5511 
Arlington, Virginia, 22213 USA acf on LinuxNet

XEmacs 21.1 was released, when Debian package ?

[Takuro KITAME]

Hi,
I heard that XEmacs 21.1 was released, and http://www.xemacs.org/ is saying
"Current Version: 21.1, released May 14, 1999".

I need xemacs21 Debian package because xemacs20's mule seems to be broken.

When XEmacs21 Debian package will be release?

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

ITP: select-xface

[Takuro KITAME]

I'm working package select-xface.

Liecens: GPL

Package: select-xface
Section: mail
Depends: emacsen
Suggests: x-face-el, bitmap-mule
Description: Insert X-Face mail heaer with viewing and selecting a bitmap.
 Insert X-Face Mail/News heaer with viewing and selecting a bitmap.

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

Intent to package GNU Philosophy web pages

[Edward Betts]

 new debian package, version 2.0.
 size 570634 bytes: control archive= 2271 bytes.
 534 bytes,22 lines  control  
4932 bytes,56 lines  md5sums  
 191 bytes, 6 lines   *  postinst #!/bin/sh
 171 bytes, 6 lines   *  prerm#!/bin/sh
 Package: gnu-philosophy
 Version: 1.0
 Section: doc
 Priority: optional
 Architecture: i386
 Installed-Size: 1090
 Maintainer: Edward Betts <[EMAIL PROTECTED]>
 Description: The GNU Philosophy web pages.
  This is a mirror of the philosophy section of the GNU web site.
  .
 Table of Contents
  .
  * About Free Software
  * About the GNU project
  * Licensing Free Software
  * Laws
  * Terminology and Definitions
  * GIFs
  * Motivation
  * Speeches
  * Third Party Ideas
  * Translations of these documents

Will upload in a couple of days if no complaints.

-- 
I consume, therefore I am


pgpseJm7m0hKx.pgp
Description: PGP signature