Re: X and Window Mangers

[Joey Hess]

Branden Robinson wrote:
> /etc/X11/window-managers is created in xbase's postinst iff the file does
> not already exist.
> 
> Elimination of behavior like this is on my List.
>
> The long-term plan is:
> 
> 1) ship an empty /etc/X11/window-managers with xbase
> 2) mark it as a conffile
> 3) separate twm into its own package
> 4) write /usr/sbin/register-window-manager

Yay! I've had several wishlist bugs filed against debhelper asking for a
dh_installwindowmanagers type script, and I've held off on writing it
becuase I didn't like the current way /etc/X11/window-managers is handled.
Now I think I will write the script and when you create
register-window-manager, it will start using it.

-- 
see shy jo


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

Re: X and Window Mangers

[Joey Hess]

Ben Pfaff wrote:
> Could we instead have a default priority assigned to each window
> manager?  So postinst scripts would run it like this:
> 
>register-window-manager pathname priority

You know, this looks like a job for update-alternatives. Maybe we should
have a /usr/X11R6/bin/sensible-window-manager, or some such thing?

-- 
see shy jo


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

Re: X and Window Mangers

[Joey Hess]

Branden Robinson wrote:
> 1) ship an empty /etc/X11/window-managers with xbase
> 2) mark it as a conffile
> 3) separate twm into its own package
> 4) write /usr/sbin/register-window-manager

FWIW, 2 and 4 conflict. I think it's in policy now (or soon will be) that a
package cannot modify any conffile, even if the conffile in in the package.
So instead, I suggest:

1) make xbase create an empty /etc/X11/window-managers if it doesn't exist
2) separate twm
3) write /usr/sbin/register-window-manager

-- 
see shy jo


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

The latest XFree86 (3.3.2-4)

[Branden Robinson]

Hi, folks, your friendly neighborhood X maintainer here.

XFree86 3.3.2-4 just got installed into the archive today (I uploaded it
Sunday).

Unless you have bandwidth to spare, please don't download it without
good reason.  With impeccable timing, a CERT bulletin warning of
possible security problems with xlib and xterm was released just after
I finished -4, so -5 will be coming out very, very soon.  Anybody
interested in accelerating this process should see the X Strike Force
page .

-- 
G. Branden Robinson |
Purdue University   |  kernel panic -- causal failure
[EMAIL PROTECTED]  |  universe will now reboot
http://www.ecn.purdue.edu/~branden/ |


pgpYrIIkcUbsJ.pgp
Description: PGP signature

Re: X and Window Mangers

[Ben Pfaff]

   > Could we instead have a default priority assigned to each window
   > manager?  So postinst scripts would run it like this:
   > 
   >register-window-manager pathname priority

   You know, this looks like a job for update-alternatives. Maybe we should
   have a /usr/X11R6/bin/sensible-window-manager, or some such thing?

Actually I like that a lot better myself.  Could we do it that way
instead, Branden?


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

Re: RFC: dpkg and handling of the Unconfigured state

[Jason Gunthorpe]

On Tue, 28 Apr 1998, Yann Dirson wrote:

> Jason Gunthorpe writes:
>  > Well, I have not observed that dpkg is capable of placing guarentees on
>  > the dependency state during the *rm scripts. Alot of packages make use of
>  > their dependents during their removal which leads the the problem that you
>  > can no longer upgrade without configuring alot of stuff as it is unpacked.
> 
> Ah.  That may be another problem, which probably comes from the fact
> that dpkg is not able to do multiple install/configure cycles in one
> run.  Once that is fixed, I think the problem you mention will go
> away.  Right ?

No, I'm assuming that dpkg would be changed to consider dependencies for
the *rm scripts, the side effect is a fairly substantial change to how
dpkg will need to install things.

Bascially we loose alot of the delayed configuration stuff with an idea
like this.

Jason


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

Re: netstd tools in the base system (was Re: What to do with /bin/perl symlink?)

[Jason Gunthorpe]

On Tue, 28 Apr 1998, Igor Grobman wrote:

> What if the person does not want to use dselect?  Many people (not me) prefer 
> to download packages themselves, and dpkg -i them.  Now that ftp is removed, 
> they would either have to download netstd using something other than linux, 
> or 
> use dselect to download netstd.  Given some people's dislike of dselect, this 
> will be a major complaint.

Some people can't use dselect's ftp method, firewalls and so on.
 
Jason


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

Re: Boot Disks

[Lindsay Allen]

On Tue, 28 Apr 1998, Bob Hilliard wrote:

> Jason Gunthorpe <[EMAIL PROTECTED]> writes:
> > On Tue, 28 Apr 1998, Hamish Moffatt wrote:
> > 
> > > The sensitivity to good disks is, as I understand it, caused by poor
> > > BIOS floppy drivers and is independent of the Linux kernel, let alone
> > > which distribution you are running.
> > 
> > Actually, as I understood it, the problem was poor linux floppy
> > drivers. You'll note that when most errors occure is when reading the base
> > image or rescue disks, I have very rarely had the boot disk fail.
> 
[analysis snipped]

May I suggest that you forward your message upstream to either the kernel
people or those who do the drivers.  It is downright embarrasing to have
our favourite OS not be able to read a floppy reliably.

> 
> Bob
> -- 
>_
>   |_)  _  |_   Robert D. Hilliard<[EMAIL PROTECTED]>
>   |_) (_) |_)  Palm City, FL  USAPGP Key ID: A8E40EB9

Lindsay

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lindsay Allen   <[EMAIL PROTECTED]>  Perth, Western Australia
voice +61 8 9316 248632.0125S 115.8445Evk6lj  Debian Unix
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=



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

Re: X and Window Mangers

[Branden Robinson]

On Tue, Apr 28, 1998 at 08:54:18PM -0400, Ben Pfaff wrote:
>> Could we instead have a default priority assigned to each window
>> manager?  So postinst scripts would run it like this:
>> 
>>register-window-manager pathname priority
> 
>You know, this looks like a job for update-alternatives. Maybe we should
>have a /usr/X11R6/bin/sensible-window-manager, or some such thing?
> 
> Actually I like that a lot better myself.  Could we do it that way
> instead, Branden?

Uh, I've never played with alternatives before.  Would someone care to
flesh out this proposal?

Remember, twm will be a separate package in slink, and xbase will probably
recommend the virtual package "window-manager", which all window managers
will provide.

-- 
G. Branden Robinson | If you wish to strive for peace of soul,
Purdue University   | then believe; if you wish to be a
[EMAIL PROTECTED]  | devotee of truth, then inquire.
http://www.ecn.purdue.edu/~branden/ | -- Friedrich Nietzsche


pgpNepldxlSv6.pgp
Description: PGP signature

Re: X and Window Mangers

[Joey Hess]

Branden Robinson wrote:
> Uh, I've never played with alternatives before.  Would someone care to
> flesh out this proposal?

Sure.. make all window managers that would previously register themselves in
/etc/X11/window-managers instead register themselves as an alternative
providing /usr/X11R6/bin/window-manager. This means that we have to assign
different priorities to each window manager, which they use when
registering (notice this requires some cooperation between maintainers of
window managers to set the priorities). update-alternatives makes 
/usr/X11R6/bin/window-manager be a symlink to whichever window manager has 
the highest priority and is currently installed. 

If an admin prefers some other window manager be default, there is a 
update-alternatives command they can use to increase its priority so it 
becomes the default. It's even possible to preserve that priority change
accross upgrades. If we want to get fancy, there can be a frontend to this.

Then you make /etc/X11/window-managers contain only
"/usr/X11R6/bin/window-manager" (or you get rid of the file and hard-code
that in the Xsession file).

This parallels how /usr/bin/editor and /usr/bin/pager currently work. Check
them out. 

It also means that window managers need not depend on xbase at all.

-- 
see shy jo


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

Re: X and Window Mangers

[Ben Pfaff]

   > Actually I like that a lot better myself.  Could we do it that way
   > instead, Branden?

   Uh, I've never played with alternatives before.  Would someone care to
   flesh out this proposal?

Okay, here we go:

/usr/bin/sensible-window-manager (or whatever) is a symlink to one of
the installed window managers.  The symlink is managed by calling
update-alternatives.  update-alternatives has the following interface:

update-alternatives --install window-manager \
/usr/X11R6/bin/sensible-window-manager /usr/X11R6/bin/twm 10 

This sort of call is made from the window manager's postinst.  It
makes a link from /usr/X11R6/bin/sensible-window-manager to
/etc/alternatives/window-manager.  In turn,
/etc/alternatives/window-manager points to the currently installed
window manager with the highest priority, where 10 is the priority for
/usr/X11R6/bin/twm.

update-alternatives --remove window-manager /usr/X11R6/bin/twm

Called by the window manager's prerm, makes sure that the
/etc/alternative link doesn't point to that window manager, and
removes the link entirely if no window manager is installed any
longer.

Do you need more details?


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

Re: X and Window Mangers

[Jason Gunthorpe]

On Tue, 28 Apr 1998, Marcelo E. Magallon wrote:

> (predepend, isn't it?) Given the binaries provided by xbase --  BTW, some of

No, predepends would be used if the ore-inst needs the package, since the
post inst is what uses it there is no need.

Jason


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

Re: X and Window Mangers

[Branden Robinson]

So I go to all the trouble of drafting a proposal for
register-window-manager, and even start coding it, and you guys don't want
to use it?

*sigh*

All right, if we can weather the inevitable religious flame war about which
what the default priority for each window manager should be, I'll implement
this solution.

Less work for me, anyway.  All I have to do is have /etc/X11/Xsession do
this:

if [ -x $startup ] && grep -q ^allow-user-xsession /etc/X11/config; then
  exec $startup
else
  xterm -ls &
  if [ -x /usr/bin/X11/window-manager ]; then
exec /usr/bin/X11/window-manager ]
  elif [ -x /usr/bin/X11/window-manager ]; then
exec /usr/bin/X11/sensible-window-manager
  else
xmessage -nearmouse -button "Quit X Windows" "No window manager installed!"
  fi
fi

-- 
G. Branden Robinson |  A committee is a life form with six or
Purdue University   |  more legs and no brain.
[EMAIL PROTECTED]  |  -- Robert Heinlein
http://www.ecn.purdue.edu/~branden/ |


pgpbM6MejqVYb.pgp
Description: PGP signature

Re: X and Window Mangers

[Ben Pfaff]

   So I go to all the trouble of drafting a proposal for
   register-window-manager, and even start coding it, and you guys don't want
   to use it?

Don't overreact.  Marcelo just brought up what may be a valid point.
Does either proposal include support for varying default command-line
options for each window manager?


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

Re: Conflicts between developers and policy

[Raul Miller]

Manoj Srivastava <[EMAIL PROTECTED]> wrote:
>   Please point the clause to me that I should use the help of a
>  a dictionary to elucidate for my feeble intellect.

Policy: 1. a plan of action; way of management; "It is a poor policy to
promise more than you can do." "The tight-money policy was also reducing
the pressure on prices" (Time). 2. practical wisdom; prudence: "In
this ... he was actuated by policy rather than sentiment" (Edward A.
Freeman).

-- 
Raul


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

Re: Conflicts between developers and policy

[Philip Hands]

Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> Raul> Since when is "The flight of the Bumble Bee" the right thing to
> Raul> do?
>
>   Since I decided on it. What is to prevent me?

This epitomises the point you insist on missing here.

What prevents you, is YOU.  If it turns out that you are a painful git who 
just wants to throw a spanner in the works, then there would very soon be a 
consensus to expel you from the project, otherwise you will do the right 
thing, because it is the right thing, no coercion required (or available as it 
happens).

>   I want a simple statement that says: Policy is to be
>  followed, with certain riders.

  [Oxford English Dictionary]
  policy[1]: noun.
prudent conduct, sagacity;
course or general plan of action (to be) adopted by government, party, 
person etc.

In other words, the fact that we are calling this a ``Policy'' rather than a 
``Hovercraft'' implies that it would be prudent for the party in question 
(i.e. Debian developers) to use this document as a plan of action.

Therefore any statement to that effect within the policy, would be redundant.

Cheers, Phil.



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

Re: License advice

[Buddha Buck]

I am not a lawyer either, but...

Marcus Brinkmann said:
> The other comments state the difference in copyright law, if everything is
> forbidden that is not explicitely allowd or if everything that is not
> explicitely forbidden is allowed.

I don't really see how this applies here...

Yes, the standard American legal system follows the principle that if 
an action is not specifically forbidden by law (either statute or 
common law), it is legal.  In theory, this would mean that in the 
absense of a law to the contrary, I could modify and distribute any 
piece of software without penalty.

But there is a law to the contrary:  US Copyright Law grants several 
exclusive rights to the Author of a copyrightable work.  This 
specifically forbids others from modifying and distributing a work 
without the permission of the copyright holder.  So the claim that I 
can do it because what isn't forbidden is allowed fails, since it is 
forbidden.

> We have the Bern convention in europe which specifies the former. I don't
> know about the letter, and would assume the worst to be on the safe side.
> 
> In general, I prefer to have a license that does not leave any ambiguity or
> interpretation on my side.
> 
> Marcus
> 
> -- 
> "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ 
> Marcus Brinkmann   http://www.debian.orgmaster.debian.org
> [EMAIL PROTECTED]for public  PGP Key
> http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/   PGP Key ID 36E7CD09
> 
> 
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice


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

Re: netstd tools in the base system (was Re: What to do with /bin/perl symlink?)

[Rev. Joseph Carter]

On Tue, Apr 28, 1998 at 07:00:48PM -0600, Jason Gunthorpe wrote:
> > What if the person does not want to use dselect?  Many people (not me) 
> > prefer 
> > to download packages themselves, and dpkg -i them.  Now that ftp is 
> > removed, 
> > they would either have to download netstd using something other than linux, 
> > or 
> > use dselect to download netstd.  Given some people's dislike of dselect, 
> > this 
> > will be a major complaint.
> 
> Some people can't use dselect's ftp method, firewalls and so on.

Unless the firewall doesn't allow ANY ftp at all, the ftp method supports
passive mode.


pgpekApV0GiCB.pgp
Description: PGP signature

Re: X and Window Mangers

[Marcelo E. Magallon]

On Tue, Apr 28, 1998 at 10:53:22PM -0400, Ben Pfaff wrote:

> Okay, it's a good thing you brought that up then.  Does Branden's
> proposal include support for this?  Perhaps I need to go back and read
> it better, but I don't remember anything about command-line options.

Branden proposes the existance of a script that is called on
post{inst,rm} which manages additions to
/etc/X11/window-managers. It's exactly the same as the current
situation, but in line with policy (besides making the whole thing
more consistent, and easier for window manager maintainers). That is,
Xsession calls the first valid program listed on window-managers.

The other is alternatives (/usr/bin/X11/sensible-window-manager), and
(here I'm guessing) /etc/X11/Xsession calls /usr/bin/X11/s-w-m because
that's the "default" window manager. So far, so good. I cann't name a wm
that gets its configuration from the command line.

> Are there some options that can't be passed to some window managers in
> configuration files?

WindowMaker has -nocpp, -nodock and -nofiend (there are options that
are not available on the configuration files). My point is having
/usr/X11R6/bin/sensible-window-manager as a symlink to wmaker would make

$ sensible-window-manager -nodock

valid, but if the default window manager is fvwm2, then it's
not. Alternatives, as I understood them, have to be command line
compatible because a situation like the one I just described is not
desirable.


Marcelo

pgp1uOI4q5Z7D.pgp
Description: PGP signature

as much business as you can handle

[emailprofits5]

Hello,

If You're Marketing a Product, Service, or Opportunity on the Internet, 
or Through an Online Service, or Have a Web Site, You Will *Definitely* 
Be Interested In What We Have To Offer.  


We'll send out Your *Targeted* E-mail Advertisement.  Period.  
No qualifiers, no conditions, no nonsense.  We'll do it quickly, and 
we'll do it at a *great price*.  Give us a call, and we'll give you 
advice on how to write your material, and much more.

and... Our Services Are Guaranteed!

* Guaranteed Delivery And Minimum Response Rates!  Call For Details.
* Fresh, *Targeted* Names Compiled *Specifically* For Your Campaign
* Response Rates From 1% to 33% Have Been Achieved!
  (This also depends on your product and offer)
* Your EXCLUSIVE Ad!  Up To A Full Page. No Co-ops! 
* Experience, Experience, Experience.

   
   Call Us Today!  352.319.829924 Hrs!  EST  (mention code#: 425b)


DIRECT E-MAIL WORKS!!


* YOUR MAILING IS ALWAYS SENT ON ITS OWN,
NEVER WITH ANY OTHER ADS!


If you receive 1% response for mailing 100,000 Email addresses
you would receive 1,000 replies

How much MONEY would YOU make?


Prices With *Highly Targeted* Names by City, Hobbies, Job, 
Business Opportunity, MLM, “Women in Colorado Who Ski”, Etc.,.
Response Rates From 1% to 33% (or Higher)!

  10,000 names  $395.00 (Next 72 Hrs:  $195 Limited Time Only!)
  20,000 names  $595.00 
  30,000 names  $795.00 
  40,000 names  $995.00 
  50,000 names $1195.00 
 100,000 names $1995.00 (Promo: $795)


Start Generating As Many ORDERS and/or SIGNUPS as You Can Handle!
Call Us Right Now To Discuss Increasing Your Business And Cash Flow!


Call Now!  352.319.829924 Hrs!  EST  (promo code#: 425b)


We Also Take All Major Credit Cards, and Checks By Fax/Phone!
Thank You And Have A Profitable Day!


352.319.8299   24 Hrs

(promo code#: 425b)
(mention this code when you call 
to receive the promotion prices!)



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

Re: Licensing, was elvis package

[Shaya Potter]

At 14:17 28/04/98 -0400, Raul Miller wrote:
>Shaya Potter <[EMAIL PROTECTED]> wrote:
>> which is my point on, the fact that it's a little hypocritical (not very,
>> but a little), for the FSF to make emacs compilable out of the box for
>> Motif.  They would never do that for Qt, which would be "free" to compile
>> with, but Motif, which would cost each compiler $$$, they do it with.
>
>emacs needed to work with motif to run on proprietary operating systems

?

It's seems to run fine with normal athena widgets on linux.

Shaya


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

Lilo..

[matthew.r.pavlovich.1]

I am getting a quirky bug with lilo.  I have a 4gig Wide SCSI drive that
is set to scsi id 0.  I can partition the disk, write to the disk, read,
mount it as /, but I cannot boot from it (The boot flag is set on the
first primary partition). I have an adaptec 2940UW controller w/ 2.0.33.
Lilo runs correctly, and the light flashes on the drive, but at boot it
just hangs..not even a 'Li'.  I was wondering if anyone has seen a similar
problem with lilo and large drives, or lilo and adaptec 2940's.  Lilo
works correctly with another hard drive, that is a 2gig and on the narrow
bus.  

-Matt
[EMAIL PROTECTED]  


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

as much business as you can handle

[emailprofits5]

Hello,

If You're Marketing a Product, Service, or Opportunity on the Internet, 
or Through an Online Service, or Have a Web Site, You Will *Definitely* 
Be Interested In What We Have To Offer.  


We'll send out Your *Targeted* E-mail Advertisement.  Period.  
No qualifiers, no conditions, no nonsense.  We'll do it quickly, and 
we'll do it at a *great price*.  Give us a call, and we'll give you 
advice on how to write your material, and much more.

and... Our Services Are Guaranteed!

* Guaranteed Delivery And Minimum Response Rates!  Call For Details.
* Fresh, *Targeted* Names Compiled *Specifically* For Your Campaign
* Response Rates From 1% to 33% Have Been Achieved!
  (This also depends on your product and offer)
* Your EXCLUSIVE Ad!  Up To A Full Page. No Co-ops! 
* Experience, Experience, Experience.

   
   Call Us Today!  352.319.829924 Hrs!  EST  (mention code#: 425b)


DIRECT E-MAIL WORKS!!


* YOUR MAILING IS ALWAYS SENT ON ITS OWN,
NEVER WITH ANY OTHER ADS!


If you receive 1% response for mailing 100,000 Email addresses
you would receive 1,000 replies

How much MONEY would YOU make?


Prices With *Highly Targeted* Names by City, Hobbies, Job, 
Business Opportunity, MLM, “Women in Colorado Who Ski”, Etc.,.
Response Rates From 1% to 33% (or Higher)!

  10,000 names  $395.00 (Next 72 Hrs:  $195 Limited Time Only!)
  20,000 names  $595.00 
  30,000 names  $795.00 
  40,000 names  $995.00 
  50,000 names $1195.00 
 100,000 names $1995.00 (Promo: $795)


Start Generating As Many ORDERS and/or SIGNUPS as You Can Handle!
Call Us Right Now To Discuss Increasing Your Business And Cash Flow!


Call Now!  352.319.829924 Hrs!  EST  (promo code#: 425b)


We Also Take All Major Credit Cards, and Checks By Fax/Phone!
Thank You And Have A Profitable Day!


352.319.8299   24 Hrs

(promo code#: 425b)
(mention this code when you call 
to receive the promotion prices!)



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

Re: Only m68k and i386 in hamm?

[Guy Maor]

Martin Schulze <[EMAIL PROTECTED]> writes:

> Sounds good.

I know it sounds good.  I just want to be sure that's it's the right
thing to do. :)

So my understanding is that only i386 and m68k are to be official 2.0
releases.  alpha (and other) will wait for 2.1.


Guy


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

Re: Conflicts between developers and policy

[Manoj Srivastava]

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

Philip> [Oxford English Dictionary] policy[1]: noun. prudent conduct,
Philip> sagacity; course or general plan of action (to be) adopted by
Philip> government, party, person etc.

Raul Miller <[EMAIL PROTECTED]> also quoted things
 similar. So, we have officially accepted and ratified the Policy
 documents, I take it, and I just missed the party?

If the project has indeed ``adopted'' the Policy documents, I
 have nothing further to say. I just wish you guys had brought this up
 when people were fighting the Policy tooth and nail. 

If we have not adopted policy, then quoting the lexicon is a
 meaningless play on words; and even though they be named policy, they
 are evidently not.

Which is it? (can't have it both ways, folks).

manoj
-- 
 Wear me as a seal upon your heart, as a seal upon your arm; for love
 is strong as death, passion cruel as the grave; it blazes up like
 blazing fire, fiercer than any flame. [Song of Solomon 8:6 (NEB)]
Manoj Srivastava  <[EMAIL PROTECTED]> 
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


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

Re: Licensing, was elvis package

[Mark W. Eichin]

> emacs needed to work with motif to run on proprietary operating systems

Uhh, that's deep into fantasy land.  Emacs didn't use *any* widget set
until emacs19, and emacs18 worked all over the place (and the problems
it had on newer platforms had far more to do with memory allocation
than window system.)

The motif code in emacs is relatively new, and totally cosmetic.  I'll
try and find out from some FSF people if there was anything that
specifically made Motif fit in that extension class [which, as I
recall, was specifically written to let you link against *libc* on
a proprietary system!] or if it was just availability combined with
people actually writing GPLed code that used it...


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

Re: disappearance of dists/stable link from ftp archive

[Guy Maor]

http://www.debian.org/Lists-Archives/debian-devel-9804/msg01409.html

A reasonable amount of time has passed.  I'll check a few randomly
selected mirrors and restore the links if all is well.


Guy


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

Re: Bug#21691: perl-base is essential nothing should Depend: on it.

[Enrique Zanardi]

On Tue, Apr 28, 1998 at 04:41:08PM -0400, Michael Alan Dorman wrote:
> "Darren/Torin/Who Ever..." <[EMAIL PROTECTED]> writes:
> > Sorry, I mis-stated the question.  Why does libnet-perl depend on
> > data-dumper in base.  I thought we (as in debian-devel) had discussed
> > not asking the libnet-perl configuration questions during install.
> > Since Net::Config is the only place where Data::Dumper is used, it
> > probably shouldn't be depended on for base.
> 
> That's a good point.  I'm willing to get rid of the dependency for
> libnet-perl.

Great! That way I won't have to enter in dpkg territories. :-)

Thanks,
--
Enrique Zanardi[EMAIL PROTECTED]


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

Re: Bug#21691: perl-base is essential nothing should Depend: on it.

[Enrique Zanardi]

On Tue, Apr 28, 1998 at 01:14:46PM -0700, Darren/Torin/Who Ever... wrote:
> -BEGIN PGP SIGNED MESSAGE-
> 
> Enrique Zanardi, in an immanent manifestation of deity, wrote:
> >> P.S. Why is data-dumper in base?
> >'Cause libnet-perl depends on it.
> 
> Sorry, I mis-stated the question.  Why does libnet-perl depend on
> data-dumper in base.  I thought we (as in debian-devel) had discussed
> not asking the libnet-perl configuration questions during install.
> Since Net::Config is the only place where Data::Dumper is used, it
> probably shouldn't be depended on for base.
 
Some random thoughts about packages in base (talking here about
libnet-perl, but the same is valid to any other package in there):

libnet-perl in base is the same libnet-perl package we have in the FTP
archive, with the same dependencies. As we don't have (yet?) a way to
force the automatic upgrade of a package, if I modify libnet-perl
dependencies in the base system (by "editing" dpkg databases, using 
libdpkg), the user would have to know that and upgrade to the "right"
version, to be able to reconfig the package. I may edit the databases to
"downgrade" the package version too, but then the maintainer will have to
know that when a user reports a bug in libnet-perl_AAA-BbaseC, he is
talking about _the_same_ libnet-perl_AAA-B built by the maintainer, only
the information in the control file (Version: and Depends: for
libnet-perl) would have changed.

If I simply remove data-dumper from the base system, but libnet-perl
(the package) still depends on it, the user may have problems when doing
an upgrade, because the base system is in a "broken" state wrt
dependencies.  

OTOH, I remember someone said the latest libnet version in CPAN doesn't
need data-dumper at all. Can anyone confirm that?

Thanks,
--
Enrique Zanardi[EMAIL PROTECTED]


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

Re: How Debian Linux could be made more secure

[Mark W. Eichin]

yeah, lintian might be cool, but it didn't make it into unstable until
a week or two ago, so I haven't tried it...

I don't know how I missed the 19217 bug report, but a fixed xcontrib
is in Incoming as of a few hours ago; it didn't help the situation
that xload was added back "late" after it fell out of one of the
proc packages [which then switched maintainers, and *then* people
noticed it was missing, oops :-)]

So I think the only thing here was some last minute clumsiness, rather
than anything pervasive.  (I handed off the rest of X because I was
already too busy, after all...)  There is a kind of annoying tendency
for people to take a bug report or two as a symptom of great
conspiracies, it'd make me happier if we tried to avoid that...


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

Re: Only m68k and i386 in hamm?

[Hamish Moffatt]

On Tue, Apr 28, 1998 at 10:02:56AM -0400, Christopher C. Chimelis wrote:
> I agree with this and it's been very frustrating to try to get things
> ported over (fyi, for the x86 folks).  Also, often, new upstream sources

Is there an alpha machine with accounts available so that we i386
maintainers could try doing alpha compiles ourselves? Can you give,
or give reference to, some information about why alpha appears to be
more trouble than m68k?


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


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

Re: Lilo..

[Oliver Elphick]

"matthew.r.pavlovich.1" wrote:
  >I am getting a quirky bug with lilo.  I have a 4gig Wide SCSI drive that
  >is set to scsi id 0.  I can partition the disk, write to the disk, read,
  >mount it as /, but I cannot boot from it (The boot flag is set on the
  >first primary partition). I have an adaptec 2940UW controller w/ 2.0.33.
  >Lilo runs correctly, and the light flashes on the drive, but at boot it
  >just hangs..not even a 'Li'.  I was wondering if anyone has seen a similar
  >problem with lilo and large drives, or lilo and adaptec 2940's.  Lilo
  >works correctly with another hard drive, that is a 2gig and on the narrow
  >bus.  
  >

Is this relevant? (from lilo docs):

  ([Lilo produces] ) 
No part of LILO has been loaded. LILO either isn't installed 
or the partition on which its boot sector is located isn't active. 
-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight  http://www.lfix.co.uk/oliver

PGP key from public servers; key ID 32B8FAA1

 
Come to me, all you who labour and are heavily laden, and I will
give you rest. Take my yoke upon you, and learn from me; for I am
meek and lowly in heart, and you shall find rest for your souls.
For my yoke is easy and my burden is light.(Matthew 11: 28-30)



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

Re: How Debian Linux could be made more secure

[Andreas Jellinghaus]

i agree with you.

a) every package should use suidmanager if it needs a 1000 2000 or 4000 bit.
b) every package should document why it uses this special permission in 
/usr/doc//Security.Note (or README.Debian ?).
c) security should be more important than functionality or featurism.
remove the damned suid bit from all svgalib programs.
everyone can use sudo or something like that ...

>- The Debian Installer should check for every package, if
>  all suid binaries contained therein have an entry in
>  that list.  If a binary fails to have been registered,
>  the Installer should complain loudly to the package
>  maintainer.

not a good idea. remove all special permissions from all files, and use sudo.
guy could add a hook to his scripts on master, and reject all packages with
suid/sgid permissions. it's a very easy thing.

debian should do this, and not move the work to sysadmins.

>- /usr/sbin/checksecurity should compare the clearance
>  list to the installed system and loudly complain to the
>  system administrator if it finds any differences.

i agree. but /etc/suid.conf is fine, why an additional list ?

>- Additionally, the postinst script of that package itself
>  should perform the same check and complain loudly.

double and tripple checks ? why ?

[list of questions]
 - what will happen, if the program has not the sgid/suid bit ?

>As time proceeds, tools for (e.g.) testing for buffer
>overflows should be made available.  Their application by
>package maintainers should be required.

yes. but also every sgid/suid bit that is not necessary should be removed.
for example : all svgalib games. everyone should use sudo or sometghing like 
that so he can restrict the access to a few trusted users.

>As an additional level of "certification", packages may be
>tagged "insecure"

a package may not be insecure. either you install it in a secure way
(e.g. svgalib games _not_ suid root), and tell the sysadmin how he
can use it, and what risks he will have, or drop the package art all.

security is more important than functionality or featurism.

please start now :
 - document every sgid/suid bit
 - use suidmanager, so a sysadmin can turn something off
 - defaults settings should always reflect the secure setting,
even if this breaks functionality. README.Debian should then
tell how to enable some feature, and that this is insecure

christian, did you count how often this was proposed ?

i know, that some people do not like suidmanager, and so they don't use it.
they should be forces to use it, or write something better.

andreas


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

Re: Lilo..

[Enrique Zanardi]

"matthew.r.pavlovich.1" wrote:
>I am getting a quirky bug with lilo.  I have a 4gig Wide SCSI drive that
>is set to scsi id 0.  I can partition the disk, write to the disk, read,
>mount it as /, but I cannot boot from it (The boot flag is set on the
>first primary partition). I have an adaptec 2940UW controller w/ 2.0.33.
>Lilo runs correctly, and the light flashes on the drive, but at boot it
>just hangs..not even a 'Li'.  I was wondering if anyone has seen a similar
>problem with lilo and large drives, or lilo and adaptec 2940's.  Lilo
>works correctly with another hard drive, that is a 2gig and on the narrow
>bus.  
>

I had the same problem some time ago (Adaptec card, I don't remember the
model). I solved it by disabling the "Extended translation mode for big
disks" in the adaptec BIOS and adding the "linear" option to lilo.config.
I hope that helps.

--
Enrique Zanardi[EMAIL PROTECTED]


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

Re: How Debian Linux could be made more secure

[Richard Braakman]

Martin Schulze wrote:
> I thought lintian already detects setuid binaries and needs
> confirmation by the author that it needs to be setuser or
> not.

Not really.  It warns for suid and sgid binaries in the package; but often,
packages don't include such binaries directly.  They call suidregister
in the postinst, and use chown and chmod if suidregister is not available.

Lintian would have to parse that in order to get a full list, and it
doesn't do that (yet).

Richard Braakman


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

Re: X and Window Mangers

[Falk Hueffner]

Branden Robinson <[EMAIL PROTECTED]> writes:

> Remember, /etc/X11/window-managers is *only* used if the person using
> startx or logging in with XDM has no ~/.xsession file, which I image most
> experienced X users have.

Will there be a way for a user to change his wm without copying over
the whole .xssession? Maybe a .window-manager? I think that would be
useful, since there are many people who insist on a particular window
manager, but don't want to change anything else.

Falk Hueffner


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

Re: X and Window Mangers

[Enrique Zanardi]

On Wed, Apr 29, 1998 at 11:40:17AM +0200, Falk Hueffner wrote:
> Branden Robinson <[EMAIL PROTECTED]> writes:
> 
> > Remember, /etc/X11/window-managers is *only* used if the person using
> > startx or logging in with XDM has no ~/.xsession file, which I image most
> > experienced X users have.
> 
> Will there be a way for a user to change his wm without copying over
> the whole .xssession? Maybe a .window-manager? I think that would be
> useful, since there are many people who insist on a particular window
> manager, but don't want to change anything else.

There's no need to copy /etc/X11/Xsession. That file "exec"s the user's
$HOME/.xsession if there's one.

The user may have just the following two lines in his .xsession:
#!/bin/sh
exec 

(add a "xterm -sl 500 -sb -ls -fn 10x20 -j &" line before the exec if you
want an open xterm on startup).
--
Enrique Zanardi[EMAIL PROTECTED]


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

Re: How Debian Linux could be made more secure

[Thomas Roessler]

On Wed, Apr 29, 1998 at 11:29:20AM +0200, Andreas Jellinghaus wrote:

> a) every package should use suidmanager if it needs a 1000 2000 or 4000 bit.
> b) every package should document why it uses this special permission in 
>   /usr/doc//Security.Note (or README.Debian ?).

Make it an extra file.

> c) security should be more important than functionality or featurism.

YES.

> >- The Debian Installer should check for every package, if
> >  all suid binaries contained therein have an entry in
> >  that list.  If a binary fails to have been registered,
> >  the Installer should complain loudly to the package
> >  maintainer.

> not a good idea. remove all special permissions from all
> files, and use sudo. guy could add a hook to his scripts
> on master, and reject all packages with suid/sgid
> permissions. it's a very easy thing.

Not really.  Administrators may decide not to rely on the
security of sudo, but on a few well-defined programs which
can be run suid root (things like /bin/passwd).  There are
some places where perm & 07000 != 0 is needed or ok.

> >- /usr/sbin/checksecurity should compare the clearance
> >list to the installed system and loudly complain to the
> >system administrator if it finds any differences.

> i agree. but /etc/suid.conf is fine, why an additional list ?

The /etc/suid.conf has the local system administrator's
and the package maintainer's view of things.  The
clearance list contains a different view which is based on
the clearance procedure, and recent bug reports.  Think of
it as a way to distribute security knowledge to users.

> >- Additionally, the postinst script of that package itself
> >should perform the same check and complain loudly.

> double and tripple checks ? why ?

Think of an environment with lots of packets, where the
administrator decides to update some of them, including
the clearance list.  He will then get warnings about
security problems on his system which may come from
recentyl discovered breaches, or from configuration
errors.

> [list of questions]
>  - what will happen, if the program has not the sgid/suid bit ?

ACK.

> yes. but also every sgid/suid bit that is not necessary
> should be removed.

Certainly.

> i know, that some people do not like suidmanager, and so they don't use it.
> they should be forces to use it, or write something better.

ACK.

tlr
-- 
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
 2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1


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

Re: X and Window Mangers

[Enrique Zanardi]

On Tue, Apr 28, 1998 at 09:58:47PM -0500, Branden Robinson wrote:
> So I go to all the trouble of drafting a proposal for
> register-window-manager, and even start coding it, and you guys don't want
> to use it?
> 
> *sigh*

Let's use our existing tools if possible. You are doing a wonderful work
with the X packages, don't make it harder if you can avoid it. :-)

> All right, if we can weather the inevitable religious flame war about which
> what the default priority for each window manager should be, I'll implement
> this solution.
> 
> Less work for me, anyway.  All I have to do is have /etc/X11/Xsession do
> this:
> 
> if [ -x $startup ] && grep -q ^allow-user-xsession /etc/X11/config; then
>   exec $startup
> else
>   xterm -ls &
>   if [ -x /usr/bin/X11/window-manager ]; then
> exec /usr/bin/X11/window-manager ]
>   elif [ -x /usr/bin/X11/window-manager ]; then
> exec /usr/bin/X11/sensible-window-manager
>   else
> xmessage -nearmouse -button "Quit X Windows" "No window manager 
> installed!"
>   fi
> fi

Just a comment, xmessage is in xcontrib_*.deb, so the script should check
if it's there before calling it (or xmessage should be moved to xbase, or
xbase should depend on xcontrib, or ...).

Thanks,
--
Enrique Zanardi[EMAIL PROTECTED]


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

Re: Conflicts between developers and policy

[Philip Hands]

Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> Philip> [Oxford English Dictionary] policy[1]: noun. prudent conduct,
> Philip> sagacity; course or general plan of action (to be) adopted by
> Philip> government, party, person etc.
>
>   Raul Miller <[EMAIL PROTECTED]> also quoted things
>  similar. So, we have officially accepted and ratified the Policy
>  documents, I take it, and I just missed the party?
>
>   If the project has indeed ``adopted'' the Policy documents, I
>  have nothing further to say. I just wish you guys had brought this up
>  when people were fighting the Policy tooth and nail. 
>
>   If we have not adopted policy, then quoting the lexicon is a
>  meaningless play on words; and even though they be named policy, they
>  are evidently not.
> 
>   Which is it? (can't have it both ways, folks).

Are you suggesting that we should interpret the meaning of the policy
differently depending upon whether it has been adopted by the project ?

If that is the case, we can never adopt it, since the act of adoption 
would (according to you) change it's meaning, and therefore it would no longer 
be the document we decided to adopt.

I would say that it is self evident that a policy document should accurately
reflect one's intent, and that people should generally abide by it.

I would also say that there is no need to adopt it in any formal way, since
the constructive thing to do is to follow it where appropriate, and fix it
otherwise --- what other use would we have for a policy document ?

Regardless of any adoption of policy, I will still reserve the right to apply
my judgement to the way I construct packages, and I would hope you would too.
 
Are you suggesting that you would do something destructive if it were allowed 
by policy ?   Do we really have to close all loopholes, or can we rely on one 
another to be reasonable and constructive, without needing a watertight policy 
with which to cudgel one another ?

People that are going to be destructive:

  a) wouldn't join Debian in the first place,
  b) wouldn't care about policy even if it were ratified, and
  c) could just be expelled from the project if they don't mend their ways

so why start writing rules with a sub-text of ``you developers are a bunch of 
untrustworthy skumbags'', when we can rely on one another to be reasonable 
instead ?

If you treat people like children, they will tend to act like them.  Let's 
decide to be adult about this instead.

Cheers, Phil.



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

Re: X and Window Mangers

[Branden Robinson]

On Wed, Apr 29, 1998 at 10:53:36AM +0100, Enrique Zanardi wrote:
> (add a "xterm -sl 500 -sb -ls -fn 10x20 -j &" line before the exec if you

Wow, that's a mighty Byzantine xterm line.  But to each his own.  :)

-- 
G. Branden Robinson |If you make people think they're
Purdue University   |thinking, they'll love you;
[EMAIL PROTECTED]  |but if you really make them think,
http://www.ecn.purdue.edu/~branden/ |they'll hate you.


pgpQ9pVZIADen.pgp
Description: PGP signature

Re: X and Window Mangers

[Enrique Zanardi]

On Wed, Apr 29, 1998 at 05:30:26AM -0500, Branden Robinson wrote:
> On Wed, Apr 29, 1998 at 10:53:36AM +0100, Enrique Zanardi wrote:
> > (add a "xterm -sl 500 -sb -ls -fn 10x20 -j &" line before the exec if you
> 
> Wow, that's a mighty Byzantine xterm line.  But to each his own.  :)

Well, it's only the usual stuff, scrollbars, smooth scrolling, a big font
for my poor tired eyes... 8-)

--
Enrique Zanardi[EMAIL PROTECTED]


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

Re: Only m68k and i386 in hamm?

[Michael Alan Dorman]

Hamish Moffatt <[EMAIL PROTECTED]> writes:
> Is there an alpha machine with accounts available so that we i386
> maintainers could try doing alpha compiles ourselves?

No. The machines that most alpha developers have available are either
not well connected, in environments that require more security, or
simply aren't sufficiently powerful to make it reasonable.

In the past I proposed to Bruce that Debian could use some of its
funds to purchase a fast Alpha motherboard and memory to which I could
add plenty of disk space, network connectivity and administrative
services, but got no response.

> Can you give, or give reference to, some information about why alpha
> appears to be more trouble than m68k?

There's more divergence from the i386 environment wise---in all the
packages I've compiled in the last several days, there were at least a
handful of failures because of attempts to make oldlibs packages that
are totally inappropriate for the Alpha since we've been glibc from
the beginning.  Those packages *are* needed cor m68k, which has been
around since libc5 days.

Compiler support is less mature---we just now got a version of egcs
that can compile emacs20 reliably.  I, personally, have used gcc on
the m68k for nearly a decade, all the way back to 1.X days.

Also, the Alpha is a 64-bit platform, which means we also tend to turn
up issues with source code that makes 32-bit assumptions.  And even
Linux/Alpha has undergone one major transition during its availablity
(ECOFF to Elf), that means even emacs-20.2 (only release a few months
ago) needs to be hacked to work correctly, since it's still worrying
about ECOFF.

In addition, remember that glibc patches for many packages (especially
net based ones) originated in the Alpha port.  We've been using glibc
exclusively for a year, and had to put in a lot of hard work at the
very beginning to deal with a lot of glibc issues that other hamm
developers were free to not deal with.

Finally, realize that packages-wise, we probably rival RedHat's Alpha
port---something on the order of 800+ packages are available on the
Alpha.  However, that's *half* of the number available in Debian/i386.
Many of the ones that haven't been ported are the more obscure ones
that probably don't support Alpha at all.  But we try to make it work
anyway.

Mike.


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

Re: x 3.3.2-4

[Remco Blaakmeer]

On Fri, 24 Apr 1998, Branden Robinson wrote:

> On Fri, Apr 24, 1998 at 12:25:56PM +0200, Michael Meskes wrote:
> > What happened? Were the files simply removed? I was just downloading them to
> > test the new version.
> 
> Oops.  Sorry, yes, they were, hence my "WITHDRAWN" message on
> debian-devel-changes.
> 
> xbase-configure was stupidly broken.  More ominously, xterm segfaults after
> it reads XKeysymDB.  A gentleman on #debian moved in the 3.3.2-3 xterm and
> it worked, so one of the two patches that was applied to xterm broke
> things.  Later today I will be investigating.
> 
> Apart from those, the new package seemed to work all right, but I'm not
> letting anything with bugs that bad sit around with *my* name on it.  :)
> 
> The truly masochistic (with accounts on master) can get the stuff from
> /debian2/tmp/branden/ . The fixed xbase-configure script is in my home
> directory.  Any one interested in helping with the postmortem on xterm
> is invited to dig through there.
> 
> I will be making a few more changes and will rebuild and re-release -4
> probably by Monday.  Hopefully sooner.

Can you make that -5 so that those who did get the broken version will get
the right version? Releasing two different versions of a package with the
same release number is bad, IMHO, even if the first one was only available
for a very short time.

Remco


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

Re: x 3.3.2-4

[Branden Robinson]

On Wed, Apr 29, 1998 at 02:06:55PM +0200, Remco Blaakmeer wrote:
> Can you make that -5 so that those who did get the broken version will get
> the right version? Releasing two different versions of a package with the
> same release number is bad, IMHO, even if the first one was only available
> for a very short time.

Well, it's too late now, but -4 has been rendered undesirable anyway
because of the CERT advisory (for which I still don't have fixes -- well,
xterm should be okay thanks to Richard Braakman, but xlib6g still needs
patching).  Not to mention some small, annoying, idiotic bugs.

I urge those who'd like to see -5 come out quickly to visit
http://master.debian.org/~branden/xsf.html and see what you can do to help.

-- 
G. Branden Robinson |
Purdue University   |Music is the brandy of the damned.
[EMAIL PROTECTED]  |-- George Bernard Shaw
http://www.ecn.purdue.edu/~branden/ |


pgpmhb6cwlDJl.pgp
Description: PGP signature

Re: Constitution - formal proposal (v0.7)

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

 5. No detailed design work.
Then Technical Committee does not engage in design of new

Should be "The", I think.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNUcduSqK7IlOjMLFAQGkhAP+LvASURChex4byQh9nbEvV44sZUkfL8Pr
cb46lY3Qs/3fb2sPJfiJgjjWLuFwYaRLSuRnyYwt5YKI3EA44TAEpy0TZktf9Dha
ZPJ3Y1ZZ2j58zn+HmabnqhfgxcsWN5XdPzO1y5hVoVRWOo/zRRXhWadSQUKrRS5a
7zM0GQnYoG4=
=Ev27
-END PGP SIGNATURE-


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

problem for qpopper2.4 with shadow password

[julien ORTEGA]

I want to compile qpopper2.4 with the shadow passwords. 

The INSTALL file explain that i have to define a AUTH variable in the
Makefile but at the compile there is a error, in pop_pass.c ,with 
pw_encrypt
-- 
Julien Ortega -- EXTERN
e-mail: [EMAIL PROTECTED]


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

Languages for Description (Was: language for changelog)

[Yann Dirson]

While we're talking about language issues and people not speaking
english: if we want Debian to be one day a valid choice for a lambda
user in a random country, we *will* have to work out some mechanism
that allows translated Descriptions: fields.

[I guess this issue does not really belong to deb-policy, so warn your
CC: - I only added it in mine so that people who raised an interest in
such issues in the previous thread read it]

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


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

Re: first proposal for a new maintainer policy

[Dale Scheetz]

On 28 Apr 1998, Manoj Srivastava wrote:

>   I prefer the codification of rules that have to be followed
>  and putting them out in the open, rather than continuing to depend on
>  the judgement of a few good people in perpetuity. Some have called my
>  view fascist.
> 
> Codification of laws and rules is not fascism; on the
>  contrary, it has served the masses more often than now. (Tha Magna
>  Carta, and various and sundry constitutions around the world). It all
>  started with Hammurabi codifying the laws, and limiting the power of
>  the technical committee (I mean, the kings).
> 
The Documents you site are sets of rules that "limit" the power of
government over its people, and are certainly not fascist.

The Policy Statement is a set of rules for the behavior of developers, set
down by the "ruling body", sometimes referred to as "the government". When
those rules are viewed as more important than the people participating,
that view is a Fascist one.

Waiting is,

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

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

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


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

Re: How Debian Linux could be made more secure

[Andreas Jellinghaus]

>> not a good idea. remove all special permissions from all
>> files, and use sudo. guy could add a hook to his scripts
>> on master, and reject all packages with suid/sgid
>> permissions. it's a very easy thing.
>
>Not really.  Administrators may decide not to rely on the
>security of sudo, but on a few well-defined programs which
>can be run suid root (things like /bin/passwd).  There are
>some places where perm & 07000 != 0 is needed or ok.

lets say : no package may have files with perl & 0700 != 0,
becuase then an administrator setup a local security policy.

but a package (such as passwd) may use suidmanager, to vote
for a file to be suid root, or whatever.

btw: as long term solution dpkg should integrate suidmanager.
the reason is : if i want to modify the permissions of files not in
the suidregistry, the ahcnge might get (temporary ?) lost during the
upgrade to a new version.


>> i agree. but /etc/suid.conf is fine, why an additional list ?
>
>The /etc/suid.conf has the local system administrator's
>and the package maintainer's view of things.  The
>clearance list contains a different view which is based on
>the clearance procedure, and recent bug reports.  Think of
>it as a way to distribute security knowledge to users.

Packages without clearence should be removed from debian,
or installed in a secure way, with README.debia or Security.note
listing the details (maybe how to activate it).

an additional source for informat is always ok, but the primary information
should be in the packages, and they always must have a secure setup.

>Think of an environment with lots of packets, where the
>administrator decides to update some of them, including
>the clearance list.  He will then get warnings about
>security problems on his system which may come from
>recentyl discovered breaches, or from configuration
>errors.

there is one problem in debian : if you update your list of available
packages, you only see "ah, a new version is available". you don't see
whether it's a securiy fix, or fixing a typo, or a rather experimental
trial+failure version.

this information should be in a new package "security-advisor" ?
i agree that this will solve the problem, but its a quick hack rather than
a long term solution. but for now it's ok.

oh, and please don't forget the devices, and other files. not only
binaries are a security thread. if you have a local debian mirror,
do a dpkg-deb -c of all files. you will find lots of files :
 - not owned by root or
 - not group root or
 - not mode 755 (dirs) 644 (files) 755 (files in */s?bin)

many automatic services operate under their own user id (mail,news,lists,...)
and such packages should follow the golden rule, too : if it's not absolutely
necessary for a file/dir/link to have different owner/group/permission
than root/roto rwXrXrX, don't do it.

my last check found several strange things, so i wrote emails. don't know
what happend.

andreas


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

Re: Boot Disks

[Bob Hilliard]

Lindsay Allen <[EMAIL PROTECTED]> writes:
> May I suggest that you forward your message upstream to either the kernel
> people or those who do the drivers.  It is downright embarrasing to have
> our favourite OS not be able to read a floppy reliably.

 Actually, my points were that almost all of the failures I have
observed were in reading the rescue disk (which AFIK is read by the
BIOS drivers), and that the failures were truly random, and that new
disks performed no better than used ones.  The previous message, from
Jason Gunthorpe <[EMAIL PROTECTED]>, I believe, made the
suggestion that the Linux drivers were the source of the problem.

Bob
-- 
   _
  |_)  _  |_   Robert D. Hilliard<[EMAIL PROTECTED]>
  |_) (_) |_)  Palm City, FL  USAPGP Key ID: A8E40EB9


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

weird effect

[Hamish Moffatt]

Tonight I upgraded to current hamm; I was asked if I wanted to replace my
issue and issue.net files; I replied N to both. issue was preserved,
but issue.net is gone!

The preinst for base-files removes /etc/issue.net if it is a link (why?)
but it wasn't.


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


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

uncertain status -ideas and Questions

[Stephen Carpenter]

-BEGIN PGP SIGNED MESSAGE-

I have been using linux for a while now but as far as 
Debian is concerned I am a "Relative"  newbie...
I have finnally gotten to that stage of waning to help out and
decided to register and take over a package that someone didn't
want.
Comming from this position I would like to say first that 
debian has a great system put together (ittook me only hours
to figure out how to work wwith a pcakge and even 
upgrad to a new version of the upstream source and get a 
the package all ready to go - as a test it installed fine ad works
on my home system)
One place were i see lacking is in someof the documentation
not the technical side of how to package something...more
of how to get started.
I would like to see (and would definitly be willing to
work on or write) a more concise "gude" on how to get started...
not more than a page or two.,..more of a checklist than a
full blown guide.
Let me use my experiance here as an example...
i read over the packageing manual, glanced over the policy one,
read the DFSG (er whatevver those letters are...you know what I mean)
I found a package on the WNPP that I was interested in.
The actual process of everything tat needs to be done now is a
little hard to figure out...
I sent an e-mail to the currently listed maintainer (because I had
heard that this package was already taken but..not more than a rummor)
He said bsically that if I want itt its mine
So i sent my e-mail to [EMAIL PROTECTED] with everything that 
the guide says is needed...
I was unsuure of what to do from that point...so I started to work on
the package itself...pt my name in a maintainer in control
and upgraded the upstream source, and added to the
changelog (and a afew other thhings hardly worth menttioning..
pakcge specifics...BTW the package is xfstt )
Now I believe the package is all ready to go...
I was looking over the manual again...it mebntiones that to
find out the status on a package or to let you know of a new mantainer to
e-mail [EMAIL PROTECTED] ...so I did that also
hI have not recived any message back yet
(iee I am not yet registerdd as a maintainer with the ability
to upload yet...but there is an issue with theh ability yto verify I
am who i say I am...no scanner aailable so I will have to snailmail)
does it sound like I am doing this right?
it seems right buit with all of these things in differnt
areas of differt documents...maybe they should be cmpiled
into one sort of a "quick checklist" to make sure
someone who is new to the system (like myself) doesn't miss anything
also as I said...I iwould be happy to write somnmething like  that
up...once I have some idea what is correct
- -Steve


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

iQCVAwUBNUcFNXxvn0zebBV9AQEpAwQAqSvBHKzMXrgv24uoEXz1ka1av5//u15N
bZo0KZzIFFII/9WL4a4gMZ2yzRZMyauuMhtdSkWgxFRF4vJlMbjyO+j5m4mQc7Ls
jP8m71fgK+QopA77ZNsb+2ZxO/QAVySNS4qJpuStPxUauZDWDx92yb58h/XNhk3M
NfQgUNWVUvg=
=BliJ
-END PGP SIGNATURE-


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

Re: weird effect

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Thu, 30 Apr 1998, Hamish Moffatt wrote:

> Tonight I upgraded to current hamm; I was asked if I wanted to replace my
> issue and issue.net files; I replied N to both. issue was preserved,
> but issue.net is gone!
> 
> The preinst for base-files removes /etc/issue.net if it is a link (why?)

Because it is a conffile since base-files_1.3.5 (at least), and having a
conffile being a symlink is tricky. Default issue.net was a symlink
to issue in the first base-files (or maybe base?) releases.

> but it wasn't.

Mmm, really strange. Which was your previous base-files version?
Did you upgrade from rex or from bo?

I would like to reproduce the same error.

It is true that when issue.net is a symlink to issue, then it is simply
removed, because once it is removed, dpkg see it as an inexistant conffile
and do not ask. This dpkg behaviour is not the desired one in most cases
and I think it is already reported as a bug. Perhaps I should treat
issue.net in the same way I already treat /root/.bashrc?

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNUc9hyqK7IlOjMLFAQEGVQQAjWHMO5yYssPiDGPbhAYsdYGl6t2rrAQP
W/2VZsPgnNgfERWTnGEnhXktHJ7c95EwVddD0zBBagxZqaMpsxEnFoDL7w3asMBl
kwwIlUatvhHg3EDGAz3SEFTNSlVs9G6OzaiYVWTKEbMaei9mhnQ9kuf4L1XqyBn9
5OXhHFC1n0c=
=7kij
-END PGP SIGNATURE-


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

Re: Conflicts between developers and policy

[John Lines]

Someone (I don't have the list archive handy here so I can't remember who)
said on the firewalls list recently that security policy (but I think it
also is valid for debian policy) should be regarded as a cache of good,
well thought out decisions.

Policy represents the collective wisdom of a lot of smart people who have
thought out some of the downstream consequences of doing particular things
and found that some ways of doing things are better than others. Thus
developers should follow policy for their own sakes, because it is likely
to work out better for them in the long run.

If a developer comes across a case where the policy is incorrect (leads to
consequences which are a Bad Thing) then they should not just ignore the
policy but try to explain their particular case and get the overall policy
updated for that case - thus ending up with a better policy and saving
someone else from having to go through the same process.



John Lines



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

xmem ?

[David Welton]

Hi, first of all, thanks to everyone who replied regarding my boot
disk questions.  Given that this is not quite so immediate, and the
record breaking warm weather, this has been postponed in favor of bike
riding:->

I am, however, curious what happened to xmem, it seems to have slipped
through the cracks of xcontrib and xproc.  Will it be packaged
seperately?  Should it be part of one of those humongous X builds?

Thanks:-)
-- 
David Welton  http://www.efn.org/~davidw 

Debian GNU/Linux - www.debian.org


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

intent to take mawk and gawk

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

If nobody objects, I intent to take mawk and gawk.

[ There have been no maintainer uploads since March 1997, is one year
  enough? ].

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNUdt9yqK7IlOjMLFAQH0XgP/VDlUE4ye939QxpFJ401coph8+iw4fc5E
DHxXtzyCtdNCntOaEdqJ3NDlga3NJdU3Ip1P+eh/87De1UXBIFdIpsjjN9QDW8ov
anhLZtJZ/a1LfbOjLMhzz/TeZ7WsEO97NHVE5krBT/Qxag7Pw3QIrEMxUoxIAcT6
nUvlmLfuRJg=
=1DMX
-END PGP SIGNATURE-


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

Re: Conflicts between developers and policy

[Manoj Srivastava]

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

>>  Raul Miller <[EMAIL PROTECTED]> also quoted things
>> similar. So, we have officially accepted and ratified the Policy
>> documents, I take it, and I just missed the party?
>> 
>> If the project has indeed ``adopted'' the Policy documents, I have
>> nothing further to say. I just wish you guys had brought this up
>> when people were fighting the Policy tooth and nail.
>> 
>> If we have not adopted policy, then quoting the lexicon is a
>> meaningless play on words; and even though they be named policy,
>> they are evidently not.
>> 
>> Which is it? (can't have it both ways, folks).

Philip> Are you suggesting that we should interpret the meaning of the
Philip> policy differently depending upon whether it has been adopted
Philip> by the project ?

Well, policy means something which has been adopted by a
 body. Hace we actually done so? Am I saying we interpret the contents
 of the policy documents differently? no, but the significance of the
 policy documents definitely shall change.

Philip> If that is the case, we can never adopt it, since the act of
Philip> adoption would (according to you) change it's meaning, and
Philip> therefore it would no longer be the document we decided to
Philip> adopt.

That is not what I said. I said we cannot in all honesty call
 something policy unless it has been adopted by the project; so I am
 objecting to the NAME of the ``policy'' docuents. Unless you aver
 that indeed, the project has adopted policy.

Philip> I would also say that there is no need to adopt it in any
Philip> formal way, since the constructive thing to do is to follow it
Philip> where appropriate, and fix it otherwise --- what other use
Philip> would we have for a policy document ?

If we all actually agree to this, then that would be
 tantamount to adopting policy.

Philip> Regardless of any adoption of policy, I will still reserve the
Philip> right to apply my judgement to the way I construct packages,
Philip> and I would hope you would too.
 
Philip> Are you suggesting that you would do something destructive if
Philip> it were allowed by policy ?

No, Assuming I knew better. We are supposed to generally treat
 policy as correct, and as wisdom handed down by technically competent
 people. There are lots if people who would follow something blindly.

Philip> Do we really have to close all loopholes,

Yes.

Philip> or can we rely on one another to be reasonable and
Philip> constructive, without needing a watertight policy with which
Philip> to cudgel one another ?


Philip> so why start writing rules with a sub-text of ``you developers
Philip> are a bunch of untrustworthy skumbags'', when we can rely on
Philip> one another to be reasonable instead ?

Having an ANSI C standard does not mean us C programmers are,
 and I quote, "a bunch of untrustworthy skumbags:, unquote. This line
 of argument is puerile.

Philip> If you treat people like children, they will tend to act like
Philip> them.  Let's decide to be adult about this instead.

I am glad ISO does not listen to you.

manoj
-- 
 Time flies like an arrow, fruit flies like a banana.
Manoj Srivastava  <[EMAIL PROTECTED]> 
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


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

Re: Conflicts between developers and policy

[Manoj Srivastava]

Hi,
>>"Ian" == Ian Jackson <[EMAIL PROTECTED]> writes:

Ian> Manoj suggests on the one hand that there is too little control
Ian> over the Technical Committee, and then on the other hand that we
Ian> should elevate policy (which is currently decided on by fiat by
Ian> one person, in cases where they choose to do so)

I have generally found that policy is actually decided by
 discussion on the policy lists, and I do not agree with your
 characterization that the multi-maintianer issue had obviously not
 reached a consensus. There were objections, but (apart from you, who
 were silent) the objectors did seem to be coming around to having on
 maintainers address on the package.

Moreever, in absence of a technical committee to help resolve
 issues, fiat by a balanced policy manager was the best we could do.

I am, personally, appalled at the attacks on the Policy
 manager. For the most part, in my opinion, he has been doing a good
 job. 

Ian> to the status of law. This is clearly inconsistent,

No ot os not. Policy can be influenced by anyone joining the
 policy group, which is open to everyone. The technical committee is a
 cabal which the unwashed masses have little say in selecting.

Ian> and anyway, as Raul says, there is plenty of opportunity to
Ian> override the Technical Committee.

That is open to interpretation, is it not?

Ian> But the key point is this: the proposed constitution is now being
Ian> discussed on debian-devel and will soon be voted on.

Please note that the debian-devel list has always been cc-ed
 to until you removed it from the headers. Why is this discussion any
 less valid for the purposes of modifying the constitution? This is
 aimed not as a proposed amendment, but to raise an issue and test the
 waters. If anything, I think people should consider this aspect of
 the constitution. 

Ian> _That_ document is what will define the answer to what power is
Ian> ultimately held by whom, not any flameage here or anything
Ian> written into the policy manuals themselves.

Labelling a discussion not going in the direction you wish as
 flameage is sheer demagoguery. If people reading this consider this
 issue to have any merit, they shall vote accordingly on the
 constitution. 

manoj
-- 
 My boss just told the quote-of-the-day(TM) after talking to our
 friendly IBM salesguy who said: "You've got be careful about getting
 locked into open systems."  Heh!  Why don't I trust these people? :-)
 Ian Dickinson ([EMAIL PROTECTED])
Manoj Srivastava  <[EMAIL PROTECTED]> 
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


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

Re: first proposal for a new maintainer policy

[Manoj Srivastava]

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

Dale> The Policy Statement is a set of rules for the behavior of
Dale> developers, set down by the "ruling body", sometimes referred to
Dale> as "the government". When those rules are viewed as more
Dale> important than the people participating, that view is a Fascist
Dale> one.

Please elucidate hw the laws of the united states, canada, the
 united kindom, or indeed, any european union country (pardon
 for missing your country here) does not fit the same criterion.

If I wish to go out and help myself to the extra ``petty''
 cash lying around in banks, I shall soon find whether the laws of the
 land are considered more important than the people.

I guess the ANSI C standard is fascist too. Hmm.

manoj
 amused
 Is invoking hascism the same as invoking hitler in a discussion?
-- 
 "When I was a boy I was told that anybody could become president; I'm
 beginning to believe it." Clarence Darrow
Manoj Srivastava  <[EMAIL PROTECTED]> 
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


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

Intent to package: uedit

[James Troup]

Hi,

I intend to package uedit.  I've always bemoaned the lack of a decent
editor on Linux, but I've finally found one.  For all those of you
who, like me, have long detested the bloated pig that is X11, you will
rejoice to know that this editor is console based.

This editor bypasses the bloated, useless and inefficient ncurses
library and uses it's own highly optimized textmode library for
improved performance.  To do it's funky stuff the library does require
uedit to be setuid, but please, don't let these security fascists put
you off, this is functionality well worth the so-called security risk.

uedit disables consoles switching, but don't fear this is not a bug,
but rather a feature.  To get maximum speed uedit will disable the
wasteful multi-tasking behaviour of Linux and make it do the Right
thing, DOS-style single-tasking.  Obviously neither X nor networking
survive, yay!  Network users should stop wasting bandwidth and use a
local machine.

As to placement within the Debian archive, it will have to go to
non-free as due to the haranguing and harassment of inhabitants of
comp.os.linux.* the author is loathed to reveal his secrets in case
sicko Linux-leechers try to steal his ideas, so there is no source.
People using non-i386 architectures should get a grip, get a life and
buy some real hardware.

Alas all is not good and great, there are several known bugs which
cause the editor to randomly segfault, but rest assured the author is
working on these and hopes to have them stamped out soon.

I hope you'll be as glad as I am to know that this is only the first
of many console-based tools planned by the author.  I look forward to
packaging them all!

More information about this exciting program and future plans for
others like it is available at:

http://home.att.net/~SAMIGWE>

I'll take it as read that there are no objections.  How could there
be?

-- 
James


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

Re: intent to take mawk and gawk

[James Troup]

Santiago Vila <[EMAIL PROTECTED]> writes:

> If nobody objects, I intent to take mawk and gawk.

I object.  I've talked with Christopher and I'm taking the packages on
a temporary basis (but as the real maintainer).  Christopher still
wants to maintain mawk & gawk and is still around, he anticipates the
possibility of being able to work on them again RSN, but if that
doesn't work out, I will actively maintain them until he is ready.

I'll try and work on both packages tonight or tomorrow (YAWN süger)
and fix whatever outstanding issues prompted Santiago to try and
hijack the packages.

Any objections?

-- 
James


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

Re: Intent to package: uedit

[Ben Pfaff]

   I'll take it as read that there are no objections.  How could there
   be?

Gadzooks!  You know, it's almost May 1, but that's not the same thing
as April 1, not at all.  I hope that this is a joke, at any rate it's
not a very funny one.  This program is a monstrosity.


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

Re: intent to take mawk and gawk

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On 29 Apr 1998, James Troup wrote:

> Santiago Vila <[EMAIL PROTECTED]> writes:
> 
> > If nobody objects, I intent to take mawk and gawk.
> 
> I object.  
> I've talked with Christopher and I'm taking the packages on
> a temporary basis (but as the real maintainer).

I object to taking a package in secret without announcing it here first,
as I did.

Do we have the rules for taking an orphaned package?

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNUd9NiqK7IlOjMLFAQFPhwP+ObhuotrRmt4Dl//XwagsltPEHLNQNK4/
nfmnz2acvg9FbIj6XZyKgiNb7tDiVZYvNHbfaoeGeYREKwN454STLwfGGftQthiT
6QIcLGs7P/JpAuYkkP07kuBM/tk/tny3Ragq5mjrbjVQ+PhZluPUl8Khwr2G9zL1
NJ6qB8EXwE0=
=+WRv
-END PGP SIGNATURE-


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

installation report of hamm 26.4.

[Andreas Jellinghaus]

ok, i tried to install from cdrom.
cd1 containes : main
cd2 containes : contrib, non-US, non-free (and other stuff)

a) my cd contained only frozen. but dselect want's stable ...
b) some problem with perl : dselect->install did not work.
i helped myself with "dpkg -iGROEB /cdrom"
c) gpm has a strange -l setting. reading the manpage, i guess 
its for german charsets. if this is the case, i wonder
why such things are not handled with LC_ codes...
d) i had problems with the keyboard - i'm sure i selected  german
(de-latin1-nodeadkeys) but it didn't work right.
later i executed kbdconfig again, and this helped.
e) apache - is this interactive configuration realy necessary ?
what about providing a save default, and allow a sysadmin to
change this later with apacheconfig ? maybe some only wants to
access his /doc tree, dhtml etc.
f) xserver offered my to "configure now". this failed, because not everything
was installed, so it could not work.
g) cvs is in default ! no ! most people don't use it, and it contains a
server, that has to be configured. this is work, and for people who
don't know cvs its very confuseing.
h) xbase: some files were already there, but empty (Xserver). maybe this has
todo with f). many people had problems with bo, when /etc/init.d/xdm
did exist, but was empty, and they did not press "I" to replace it.
now the same thing again ?
i) pcmcia ? this machine doesn't need it, so no reason to install it.
j) mail server in the default set ? i think this is obsolete. 
most people begin with x11 and netscape, and everything else comes
later.
h) xserver installation. the user needs your help !
i didn't know, what xserver i need, so i installed only vga16,
so XF86Setup will tell me more. result : fatal.
the first time it failed because mach64 server was not installed.
this will confuse users !
i suggest to do an appropiate "echo xserver-|dpkg
--set-selection" call, save the default config, and ask the user
to run dpkg again and continue later.

ok, so i had to care about this myself, and started xf86setup later again,
doing the whole configuration again... this time i got :

missing close-brace
("if" then script line 1)
while compiling
"if {![getline]} { ..."
(file "/ ... /phase5.tcl" line 26)
invoked within "source /.../phase5.tcl"

XF86Config was written, but Xserver was not modified.

xdm-start-server was not listed in /etc/X11/config.
calling xbase-configure did not help. this script should assist the user in
such stuff, because the debian way to do these things is only known to some
hackers.

ok, at least xbase-configure changed the xdm/Xserver file, after i added
the "xdm-start-server" line.
btw: this seems to be redundant information to me. 

i) i made a mistike with the non-free directory on my cd.
what is the right way to create packages files ? 
several packages were without description. ihoped running dpkg-scanpackages
would be enough. but it isn't. i also installed it in the wrong directory
(non-free, not non-free/Packages). 

so i found out : dselect isn't very helpy, if you don't know the exact path.
and how can i get dselect to handle non-US ? ok, i used the local/ path for
that, because i had no local directory.

is something planed, how can dselect work with data on several files ?
in the end i copied both cdroms to the hard disk, because i found no 
other solution. dselect could also be a bit smarter at guessing paths.

j) ssh waits for a return, without a visible reason.
k) afterstep waits with an unnecessary message - that message is only usefull,
if you update from "< 1.4" to 1.4 or higher, but not for new
installations.
l) network configuration : i selected "no network". 
i suggest to create a dummy network device. that's a much smarter
setup, than aliasing the hostname to 127.0.0.1, which can create
problems IIRC.
j) afterstep crashed creating it's configuartion files. seems like it has
problems with 24bpp, the 8bpp and 16bpp files were created before
crashing
l) lilo configuration still does not detect msdos hrddisks, and create 
a default configuration, so you can boot lilo and dos.
i'm sure one o the other distributions wrote a program to do this,
so if it's gpl'ed, debian only needs to take their code.
m) i installed the fvwm2 windowmanager. this wm can make realy noce looking
windows, but the default setup is more than ugly. 
a linux newbie will runaway ...
n) the dpkg manpage : look at the -G parameter. isn't something missing ?

later i had some trouble with win*95 destroying the linux / partition.
only one directory inode was deleted, but this dir was /var/lib/dpkg/info ...
linux did not booted, and when repairing from the boot cdrom, i got :

no room in lost+found directo

Re: intent to take mawk and gawk

[James Troup]

Santiago Vila <[EMAIL PROTECTED]> writes:

> > > If nobody objects, I intent to take mawk and gawk.
> > 
> > I object.  I've talked with Christopher and I'm taking the
> > packages on a temporary basis (but as the real maintainer).
> 
> I object to taking a package in secret without announcing it here first,
> as I did.
> 
> Do we have the rules for taking an orphaned package?

Uh, first and foremost, mawk and gawk are *not* orphaned.  And what's
being done in secret?  I'm announced my intent in my previous message
to debian-devel (which you quote here).  Talking of doing things in
``secret'', did you communicate with the current maintainer of mawk
and gawk before announcing your intent to hijack them?

Also since when did we have restrictions on who maintainers passed
packages onto?  If I want to give ed to Martin Mitchell[1], I don't
expect for anyone to complain without extremely good reasons.  What
objections have you got to me maintaining mawk and gawk?

[1] Just an example, Martin doesn't want it, and I don't plan to give
it up RSN.

-- 
James


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

Re: Intent to package: uedit

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

I thought you had "zero intention to maintain a non-free package".
Have you changed your mind?

> To get maximum speed uedit will disable the
> wasteful multi-tasking behaviour of Linux and make it do the Right
> thing, DOS-style single-tasking.  Obviously neither X nor networking
> survive, yay!  Network users should stop wasting bandwidth and use a
> local machine.

I hope you will give it a priority of "extra", then.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNUeAKiqK7IlOjMLFAQHYFAP/RYE+FbjZI7wqtFV6zvz8waGvCjlwMtNO
LLIbR/y4J7EQBlbOjZ99elPCCy72KxmK2/YsTcJhQAJXe5Ag21AebKT+bcdWa3/P
YSmzWKusUPe1lYuVBFF/6N3AcWYkkAZ22ROC8YmrlWfgkpQFq74N51+WQC91cnoK
rtW51ebw9DQ=
=sy3h
-END PGP SIGNATURE-


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

Re: Intent to package: uedit

[Jules Bean]

--On Wed, Apr 29, 1998 7:50 pm +0100 "James Troup"
<[EMAIL PROTECTED]> wrote: 

> Hi,
> 
> I intend to package uedit.  I've always bemoaned the lack of a decent
> editor on Linux, but I've finally found one.  For all those of you
> who, like me, have long detested the bloated pig that is X11, you will
> rejoice to know that this editor is console based.

James is clearly joking.

(You are joking, aren't you, James?)

But the scary things is that uedit really does exist...

I suspect it doesn't really disable multi-user though ;)

Go read the author's page - it's quite amusing..

Jules

/+---+-\
|  Jelibean aka  | [EMAIL PROTECTED] |  6 Evelyn Rd|
|  Jules aka |   |  Richmond, Surrey   |
|  Julian Bean   | [EMAIL PROTECTED]|  TW9 2TF *UK*   |
++---+-+
|  War doesn't demonstrate who's right... just who's left. |
|  When privacy is outlawed... only the outlaws have privacy.  |
\--/



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

Re: Intent to package: uedit

[Igor Grobman]

O my god!! This is true.  I downloaded it, and the README is pretty much what 
James has written.  I tried starting it, and it managed to kill exmh, but not 
all of X exiting with "Setup Eror: Unable to Initialize Program".  What a 
pity, it failed to kill X :).

Um... I suddenly have a strange desire to destroy someone or something.


Igor, still recovering.


-- 
Proudly running Debian Linux! Linux vs. Windows is a no-Win situation
Igor Grobman   [EMAIL PROTECTED] [EMAIL PROTECTED] 



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

Maintainers and the Database

[Giuliano P Procida]

This mail message started out as a response to Marcus Brinkmann's
comment on the policy list:

> I think that [the multiple maintainer] issue can't be resolved
> properly ("we are stuck") without further input from all the other
> developers not participating on debian-policy.

I'm hardly a participant, but I do read it. This message is now mainly
about the database and only relates partly to the above. The real
questions are, IMO:

a) what is package ownership?

We need to know who put together a package, who to send bugs to and
who ping if the package needs to be updated. We need to know if a
package is orphaned (has no owner).

b) how well is this reflected in current practice (and policy)?
c) what changes are needed to improve the answer to b)?

I'm not touching these!

d) What about a database to handle some of this for us?

This is in progress and is what I ramble on about below (knowing
little about the existing db work).

*The Database*

It is important that the database reflect reality for it to be useful,
both in its design and in its content. This applies to all databases.
This is unexciting, but hopefully obvious.

  The Design

A database of Debian developers (package maintainers plus all those
helping with debian who do not actually emit .debs) is needed and in
preparation. Package ownership details are desired in the database.

Relational Databases 101 says you will need (at least) one relation
for the people and another for the packages. (It would be a bad design
to have an attribute "packages" which listed all their packages).

If each package has an attribute "owner" then there arises the problem
of what to put:

a) When there is no owner (orphaned). Answer: Easy, use NULL.

b) When there are multiple maintainers (maintainer group). Answer: say
   "oh dear", or enter only one of them (arguably incorrect), or
   create a fake maintainer which is actually a group (yuk yuk), or
   try and handle groups directly, in some moderately complicated
   fashion, OR:

If instead there is a separate relation for ownership linking people
and packages, then there is no problem with people having 0, 1 or more
packages or with packages having 0, 1 or more owners. Queries to list
orphaned packages, list a given person's packages, etc. are hardly any
more complicated than with the other design. Moreover, the data (and
schemas) are trivially convertible from the other design to this one.

Summary: it should not be a problem for the database what form of
"multiple maintainership" (if any) is eventually adopted.

* Could someone in the know say whether there is a separate ownership
* table? I am happy to give a hand with PostgreSQL hacking (I am in
* the process of setting up a (pg) db at work - a learning experience
* :-).

  The Content

Developer information should be at the control of the individuals and
I imagine this has been what most of the existing DB work has been on.

Package information is a different matter. One issue is what to do
when a package disappears for good, being deleted from the archive.
The corresponding entry in the database ought to be updated or deleted
to reflect this. Plenty of information can be extracted automatically
as each .deb arrives (including the _packager_ - via the PGP key).

Ownership information is a little more tricky (think NMUs, multiple
maintainer packages and orphaning) but it ought to be possible to
automate this to some extent.

Someone with ambition may want to do something to add summaries of
data in the bugs system.

* I am prepared to help with any of the miscellaneous scripting the
* above involves.

  DB Care

Once a design stabilises the db needs to be looked after in much the
same way that Guy (and helpers) look(s) after the archive. The web (or
whatever) interface is unlikely to be perfect initially and will need
maintainance.

  The "Maintainer:" field

This will probably be rather important in terms of generating data for
the db. It is supposed to be the canonical means of contact between
user and developer in relation to a given package. I know much less
about how this propagated and used by various things (bug db, bug
command, dinstall, dpkg-*). It is something you can mail (i.e., one or
more email addresses).

Whereas packages are nicely identified by their name. The same cannot
be said of developers and the "Maintainer:" field, at the moment. This
is unfortunate. Most email addresses found in the field correspond to
an entry in the PGP key ring and hence to real humans.

There are plenty of (technical) solutions to this problem and the with
luck a wider discussion of the "multiple maintainer" issue will fix
this as a consequence.

Enough rambling,
Giuliano Procida (Myxie)
-- 
mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] | public PGP key ID: 93898735
home: +44 1223 561237 / 547 Newmarket Road, Cambridge CB5 8PA, UK
work: +44 1223 332127 / Magdalene College, Cambridge CB3 0AG, UK
work: +44 1223 335333 / International Studies, Cambridge CB2 1QY, UK

Re: intent to take mawk and gawk

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On 29 Apr 1998, James Troup wrote:

> Uh, first and foremost, mawk and gawk are *not* orphaned.

What do you mean by orphaned, then? Perhaps we should agree on a common
definition of "orphaned".

> And what's being done in secret?  I'm announced my intent in my previous
> message to debian-devel (which you quote here).  Talking of doing things
> in ``secret'', did you communicate with the current maintainer of mawk
> and gawk before announcing your intent to hijack them?

I did not say I was to hijack them. (BTW: My dictionary does not have the
"hijack" word. I have to buy better one).

Yes, I communicated with him, but he did not answered until just a minutes
ago.

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCVAgUBNUeEwyqK7IlOjMLFAQFW9AP/V436id1PuXrhgWRsOOHl02zoqefaGpgW
sV7Z7XNpCqcSsdS1BpSOK0BfLVhPiD4B3a1tpuBN8mI1++HiCdR1lKChQ2Py1eGc
+mvviw5V6D0WP4bGlS5Zfx8sCST/egPKZpPxXnKX4FLWDGDd/KddcvZa2ffmPIXf
9lfFlgDqMPM=
=nDao
-END PGP SIGNATURE-


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

creating hamm cdroms

[Andreas Jellinghaus]

it's not an easy task. dpkg/dselect make everything complex, 
in fact i have no idea how these can work with the binaries split on two
cdroms. also, they don't work if only "frozen" is present, and not stable.
i have written Makefiles (much nicer then the old shell scripts) to create the
cdroms, but i have some open questions.

 - how to handle two binary cdroms.
 - how did you split debian on two cd's ? i would like to have a 2 cd official
   debian cd setp, so i can add a third "plus" cdrom with non-free, non-US,
   and fill the remaining space with mirrors (kernel, netscape, kde ...)

my experience with new mkisofs (with joilet supprt) is, that -x doesn't work.
i found a solution : create a new directory as cd root, and copy everything
into that dir useing hardlinks. this doesn't waste a log of disk space,
and makes severel things easier.

i would like to hear your experience.
i'm currently enhanceing my Makefiles, and will post them here.

andreas


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

debian 2.0

[Andreas Jellinghaus]

from a first look at debian 2.0 i'm disappointed.  ok, everything is moved to
glibc, and there are lots of new packages.  but where is the enhancement ?

 - with installing (n) dictionaries you are asked (n-1) time to select
the default one. simlimiar thing with programs who can view
 (there are only 2 or 3 programs, but lot's of
graphik formats).
 - windowmanmagers. what about nice looking default configurations ?
 - pam login doesn't use pam. passwd doesn't use pam. telnet doesn't use it.
unless most programs are unseing pam, it's useless. 
 - the default setting isn't very useable. ok, my reference is the new student
   which heard of linux, and want's to install it side by side with win*.
   maybe it's useable for sysadmins. but sysadmins can help themself, newbies
   not. so a config should be fool proof ...
 - most programs try a  "whole configuration in postinst" method.
   this is doesn't work in many cases : it's good for the sysadmin.
   but often a newbie has a problem, and someone sais "try xxx".
   so he installs xxx. but he can't config xxx, first he needs to read
   the README's and manual, and then he can configure it.
   even with nice config help, he first needs to read the manuals.
   maybe xxx doesnt solve his problem at all.
   or he only needs parts. cvs is an example : many people neither have a
   local cvsroot, nor are they running a pserver.
 - sure, we know that dselect is not user friendly, but what is with all other
   places ? one example : asking "do you want to make this the default
   windowmanager" is not a good solution, nor is "a new windowmanager will
   become (not) the default wm". the solution has two parts : 
   a) documentation "quick start - how to select your wm" and 
   b) windowmanager-config (i guess less that 15 lines of bash/dialog will
   do the job).
 
yes, debian has a lot of good features. but debian has several weak points,
and these seem to be exactly the same points already present in bo.
this worries me.

andreas


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

Re: Only m68k and i386 in hamm?

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

: Finally, realize that packages-wise, we probably rival RedHat's Alpha
: port---something on the order of 800+ packages are available on the
: Alpha.  However, that's *half* of the number available in Debian/i386.

That raises an interesting question, that I've thought about quite a bit...

What constitutes a "port" that is complete enough for distribution?  

I personally think that if all of the packages marked as 'standard' or higher
are there and working, it's good enough for me to think we should release it.
That is obviously a far cry from "everything", but my guess is we'll never 
have 100% occupancy of all packages on all platforms, even if for such reasons
as MILO only being used on Alpha, LILO on i386, and SILO on Sparc.  So, where
is it ok to draw the line?

One of the questions we ask ourselves at my place of daytime employment goes
something like:  "At what point is our drive for perfection no longer helping 
our customers, but in fact hurting them by causing the stuff we've done that 
does work to not be available to the folks who could use it and don't care 
about details at the margin?"  I think we should ask ourselves that here.  In
fact, it's a good question for the 2.0 release process overall.

I'd like to propose that if a non-i386 architecture has a reasonable 
installation process and base archive, plus .deb's for all packages marked 
as 'standard' or higher in the i386 tree (modulo obvious exceptions like lilo),
that it be considered ready for inclusion in a release.  

Thoughts?

Given the current state of the Alpha port, this objective may or may not be
attainable for a 2.0 release.  I don't currently have (much) time to help, 
though I have put a fair amount of time into the Alpha port personally in 
the past.  But on the debian-alpha list, I see some flailing since we don't 
have a solid definition of what needs to be present for a release to be 
considered ready, and without such a goal, it's hard to focus and concentrate 
effort on what needs to be done.

Bdale


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

Possible DoS attack with new IPlogger release

[Hugo Haas]

Hi.

The new version of IPlogger offers a new feature: when there is a TCP
connection attempt, "[EMAIL PROTECTED]" is now logged instead of "host".

However, if strobe is run on localhost, a connection to identd is done
at each connection, and then the auth service is disabled after about
60 connections:

Apr 28 22:10:56 voodoo inetd[121]: auth/tcp server failing (looping),
service terminated 

After a few minutes (say 15 minutes), inetd restarts the auth service.

This means that identd can be "killed" if a user runs strobe on the server.

As I do not really see how to solve the problem, except by disabling
this feature which is more or less the only difference between version
1.0 and version 1.1, I'd like to know if this problem is considered a
critical one or not. In other words, do I have to package this version
or not?

I have warned the author about this problem, but he seems to consider
it as a minor problem, so I don't expect a new version soon...

Regards,

Hugo

-- 
Hugo Haas <[EMAIL PROTECTED]> 
PGP2 key id 0x8a5af90d, fingerprint 45AB 8D24 B3E4 C9DD E85C 25C8 DB0B BFA3


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

Maybe alpha should be in hamm? (was: Re: Only m68k and i386 in hamm?)

[Michael Alan Dorman]

Bdale Garbee <[EMAIL PROTECTED]> writes:
> I'd like to propose that if a non-i386 architecture has a reasonable
> installation process and base archive, plus .deb's for all packages
> marked as 'standard' or higher in the i386 tree (modulo obvious
> exceptions like lilo), that it be considered ready for inclusion in
> a release.
>
> Thoughts?

As one of maybe two alpha-porters who have never taken their alpha
through the Debian installation process (my alpha has been running
some form of Debian/Alpha for more than a year, and thus predates the
install disks), I am wretchedly unqualified to speak to the first part
of your suggestion.

However, I think we could just about achieve everything marked
standard or higher.  Heck, we may already and not realize it.  And, in fact, I find that we basically have.  The
following would need to be dealt with:

net/lpr_5.9-26.1.dsc [standard:libc6]
editors/emacs19_19.34-16.dsc [standard:libc6:X]
base/gzip_1.2.4-27.dsc [required:libc6]
base/ld.so_1.9.7-1.dsc [required:n/a]
devel/cvs_1.9.26-3.dsc [standard:libc6]
base/kbd_0.95-12.dsc [required:libc6]
base/shadow_970616-1.1.dsc [required:libc6]
x11/xfree86_3.3.2-3.dsc [standard:libc6:X]
admin/cron_3.0pl1-44.dsc [important:libc6]
base/e2fsprogs_1.10-14.dsc [required:libc6]
utils/sharutils_4.2-5.dsc [standard:libc6]
shells/tcsh_6.07.02-7.dsc [standard:libc6]
admin/at_3.1.8-2.1.dsc [important:libc6]
libs/glibc_2.0.7pre1-4.dsc [required:libc6]
base/procps_1.2.7-1.dsc [required:libc6:X]
devel/egcs_1.0.2-0.7.dsc [standard:libc6]
devel/gdb_4.16.98-1.dsc [standard:libc6]
editors/emacs_19.34-13.dsc [standard:libc6:X]

I just did emacs19 today, ld.so doesn't apply, we're actually using a
more up-to-date egcs, gdb4.17 has actually been released so 2.0
shouldn't go out the door with a snapshot, and except for
glibc---which I've been having some problems with---the rest are
easily doable.

(Parenthetically, I think we should swap lprng for lpr, I'm not sure
why cvs is standard, and emacs_19.34 should be removed from the
archive)

> But on the debian-alpha list, I see some flailing since we don't
> have a solid definition of what needs to be present for a release to
> be considered ready, and without such a goal, it's hard to focus and
> concentrate effort on what needs to be done.

A very good point.  It's hard to know when you've achieved something
if you haven't picked out a measuring stick beforehand.

So what do people think of the status of the boot disks?

Mike.


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

Re: Maybe alpha should be in hamm? (was: Re: Only m68k and i386 in hamm?)

[James D. Freels]

I've just done an initial install on a Alpha machine that was
originally setup with RH 4.2.  I upgraded the machine to RH 5.0.  I
then reworked and did the initial install of Debian hamm on another
partition and am now duel-booting.  I have consideral experience with
Debian-i386, but do not consider myself an expert by any means.
Perhaps an above-average user.

I'd say you have a way to go.  The base disks are way out of date.  It
took considerable hacking to finally get the system current.

Not all packages in the hamm/binary-alpha will install.  There are
several packages which depend on ldso which is not available to
install.  

I guess it depends on how close you really are to the i386 release.  I
think for someone knowledgable, and a bit of work, an alpha release
could be possible.

I am running the Debian/hamm now on my system.  My biggest problem is
getting the required passwork server running which was built on
libc5 (which is not available under hamm).

>Bdale Garbee <[EMAIL PROTECTED]> writes:
>> I'd like to propose that if a non-i386 architecture has a reasonable
>> installation process and base archive, plus .deb's for all packages
>> marked as 'standard' or higher in the i386 tree (modulo obvious
>> exceptions like lilo), that it be considered ready for inclusion in
>> a release.
>>
>> Thoughts?
>
>As one of maybe two alpha-porters who have never taken their alpha
>through the Debian installation process (my alpha has been running
>some form of Debian/Alpha for more than a year, and thus predates the
>install disks), I am wretchedly unqualified to speak to the first part
>of your suggestion.
>
>However, I think we could just about achieve everything marked
>standard or higher.  Heck, we may already and not realize it. quinn-diff run> And, in fact, I find that we basically have.  The
>following would need to be dealt with:
>
>net/lpr_5.9-26.1.dsc [standard:libc6]
>editors/emacs19_19.34-16.dsc [standard:libc6:X]
>base/gzip_1.2.4-27.dsc [required:libc6]
>base/ld.so_1.9.7-1.dsc [required:n/a]
>devel/cvs_1.9.26-3.dsc [standard:libc6]
>base/kbd_0.95-12.dsc [required:libc6]
>base/shadow_970616-1.1.dsc [required:libc6]
>x11/xfree86_3.3.2-3.dsc [standard:libc6:X]
>admin/cron_3.0pl1-44.dsc [important:libc6]
>base/e2fsprogs_1.10-14.dsc [required:libc6]
>utils/sharutils_4.2-5.dsc [standard:libc6]
>shells/tcsh_6.07.02-7.dsc [standard:libc6]
>admin/at_3.1.8-2.1.dsc [important:libc6]
>libs/glibc_2.0.7pre1-4.dsc [required:libc6]
>base/procps_1.2.7-1.dsc [required:libc6:X]
>devel/egcs_1.0.2-0.7.dsc [standard:libc6]
>devel/gdb_4.16.98-1.dsc [standard:libc6]
>editors/emacs_19.34-13.dsc [standard:libc6:X]
>
>I just did emacs19 today, ld.so doesn't apply, we're actually using a
>more up-to-date egcs, gdb4.17 has actually been released so 2.0
>shouldn't go out the door with a snapshot, and except for
>glibc---which I've been having some problems with---the rest are
>easily doable.
>
>(Parenthetically, I think we should swap lprng for lpr, I'm not sure
>why cvs is standard, and emacs_19.34 should be removed from the
>archive)
>
>> But on the debian-alpha list, I see some flailing since we don't
>> have a solid definition of what needs to be present for a release to
>> be considered ready, and without such a goal, it's hard to focus and
>> concentrate effort on what needs to be done.
>
>A very good point.  It's hard to know when you've achieved something
>if you haven't picked out a measuring stick beforehand.
>
>So what do people think of the status of the boot disks?
>
>Mike.
>
>
>--
>To UNSUBSCRIBE, email to [EMAIL PROTECTED]
>with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>


-- 
/--\
|James D. Freels, P.E._i, Ph.D. |Phone:  (423)576-8645 |   | L | A |
|Oak Ridge National Laboratory  |FAX:(423)574-9172 | H | I | L |
|Research Reactors Division |work e-m: [EMAIL PROTECTED]| F | N | P |
|P. O. Box 2008 |home e-m: [EMAIL PROTECTED] | I | U | H |
|Oak Ridge, Tennessee 37831-6392|world's best neutrons | R | X | A |
\--/


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

Re: Intent to package: uedit

[Richard Braakman]

James Troup wrote:
> As to placement within the Debian archive, it will have to go to
> non-free as due to the haranguing and harassment of inhabitants of
> comp.os.linux.* the author is loathed to reveal his secrets in case
> sicko Linux-leechers try to steal his ideas, so there is no source.

I must object most strenuously to its placement.  The Debian Free
Software Guidelines fail to define "Source Code", but I believe
the definition given in the GNU General Public License is quite
adequate: "The source code for a work means the preferred form of
the work for making modifications to it".

Since the only modifications one might possibly want to make to
uedit all involve the use of the "rm" utility, which works just
*fine* on sources and executables alike, I see no obstacle to
placing this significant program in the main distribution.

Richard Braakman


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

Re: Conflicts between developers and policy

[Raul Miller]

Manoj Srivastava <[EMAIL PROTECTED]> wrote:
>  Well, policy means something which has been adopted by a body. Hace
>  we actually done so? Am I saying we interpret the contents of the
>  policy documents differently? no, but the significance of the policy
>  documents definitely shall change.

Er... debian-policy is a distillation of debian efforts for quite some
time. Until you decided that it was somehow bogus, I would have said
it was fairly well accepted as debian policy. [The exceptions would be
where people weren't aware of it.]

And, near as I can tell, the reason you becaome so combative about
debian policy being debian policy was that Ian Jackson made a statement
to the effect that it was sufficient for policy to be policy.

Frankly, it seems like you either weren't paying attention, or
didn't understand.

-- 
Raul


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

Re: installation report of hamm 26.4.

[Branden Robinson]

On Wed, Apr 29, 1998 at 09:22:20PM +0200, Andreas Jellinghaus wrote:

> f) xserver offered my to "configure now". this failed, because not everything
>   was installed, so it could not work.

Can you be more specific?

There is nothing in the xserver postinst that demands the presence of
xbase.  I assume makedev and libc6 were installed and configured.  Were
they?  They're both essential, so I assume they must have been.

> h) xbase: some files were already there, but empty (Xserver). maybe this has
>   todo with f). many people had problems with bo, when /etc/init.d/xdm
>   did exist, but was empty, and they did not press "I" to replace it.
>   now the same thing again ?

What version of xbase was this?  Sounds like it must be 3.3.2-3 or earlier.

If /et/X11/Xserver was empty, how did your machine know to look for the
Mach64 server when starting X (below)?

> h) xserver installation. the user needs your help !
>   i didn't know, what xserver i need, so i installed only vga16,
>   so XF86Setup will tell me more. result : fatal.
>   the first time it failed because mach64 server was not installed.

XF86Setup depends only on the VGA16 server.  XFree86 3.3.2-4 always backs
up the /etc/X11/XF86ConfConfig file. 

> this will confuse users !
>   i suggest to do an appropiate "echo xserver-|dpkg
>   --set-selection" call, save the default config, and ask the user
>   to run dpkg again and continue later.

This is a very poor solution.  I think 3.3.2-4 solves this.

> ok, so i had to care about this myself, and started xf86setup later again,
>   doing the whole configuration again... this time i got :
> 
> missing close-brace
> ("if" then script line 1)
> while compiling
>   "if {![getline]} { ..."
>   (file "/ ... /phase5.tcl" line 26)
>   invoked within "source /.../phase5.tcl"

This is harmless (as you can see, the XF86Config file is created anyway),
but fixed in 3.3.2-4.

> XF86Config was written, but Xserver was not modified.

Xserver is not modified by XF86Setup, it is modified by the xserver package
postinst.

> xdm-start-server was not listed in /etc/X11/config.
> calling xbase-configure did not help. this script should assist the user in
> such stuff, because the debian way to do these things is only known to some
> hackers.

In XFree86 3.3.2-4, you may invoke /usr/sbin/xbase-configure with the
"force" argument.

XFree86 3.3.2-4 ships with xdm configured to start a local server, if the
user configures XDM to run at all.

> ok, at least xbase-configure changed the xdm/Xserver file, after i added
> the "xdm-start-server" line.
> btw: this seems to be redundant information to me. 

All this is changed in XFree86 3.3.2-4.  The xdm-start-server option has
been placed in limbo, and nothing edits /etc/X11/xdm/Xserver anymore; it
must be edited by hand.  Detailed instructions are now inside that file to
facilitate the process.

-- 
G. Branden Robinson | If you wish to strive for peace of soul,
Purdue University   | then believe; if you wish to be a
[EMAIL PROTECTED]  | devotee of truth, then inquire.
http://www.ecn.purdue.edu/~branden/ | -- Friedrich Nietzsche


pgptdelocAqYq.pgp
Description: PGP signature

Re: xmem ?

[Chris Reed]

In article <[EMAIL PROTECTED]>,
David Welton <[EMAIL PROTECTED]> writes:
> I am, however, curious what happened to xmem, it seems to have slipped
> through the cracks of xcontrib and xproc.  Will it be packaged
> seperately?  Should it be part of one of those humongous X builds?
> 

The xmem program is actually xproc's xload with a different name. 
xcontrib's xload also has permissions rws--x--x which is pretty bad, and
unnecessary.

There's an xmem package available at
ftp://dura.sel.cam.ac.uk/pub/cr212/debian/xmem_1.11-1_i386.deb

(Disclaimer; I'm not (yet) a registered Debian developer)

-- 
 -- Christopher Reed, Selwyn College, Cambridge --
 E-Mail: [EMAIL PROTECTED]  WWW: http://dura.sel.cam.ac.uk/ [~cr212/]
 r2 T1 cSEL dCS hEn/Chi A4 S+ C*$+++L/UdP W+++ y# a VTsj (Cantab) 1.0 
"I know you don't love that guy cause I can see right through you"


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

Re: Conflicts between developers and policy

[Manoj Srivastava]

Hi,
>>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes:

Raul> Manoj Srivastava <[EMAIL PROTECTED]> wrote:
>> Well, policy means something which has been adopted by a body. Hace
>> we actually done so? Am I saying we interpret the contents of the
>> policy documents differently? no, but the significance of the
>> policy documents definitely shall change.

Raul> Er... debian-policy is a distillation of debian efforts for
Raul> quite some time. Until you decided that it was somehow bogus,

*I* decided it was bogus? This is rich. You have evidently ot
 being paying attention on Debian policy lists at all.

Raul> I would have said it was fairly well accepted as debian
Raul> policy. [The exceptions would be where people weren't aware of
Raul> it.]

This happens not to be the case. 

Raul> And, near as I can tell, the reason you becaome so combative
Raul> about debian policy being debian policy was that Ian Jackson
Raul> made a statement to the effect that it was sufficient for policy
Raul> to be policy.

Again, this happens not to be the case. I was perfectly happy
 letting policy be policy until a well respected senior Debian
 developer made statements to the effect "Go right ahead and
 violate policy. Thats what I do" 

And another respected developer chimed in with how their
 pacvkage would break if they followed policy, and so they have
 been happily ignoring it.

Where the hell were you then with this stuff about policy
 being ``generally accepted'' and all? huh? 


I started this effort to have policy more strongly ratified
 due to my alarm at "Go ahead and violate policy" advice, which, by
 the way, you did not object to. 

Your reason "let us leave things as they are, since we all
 know and respect policy" are demonstrably bogus. 

Raul> Frankly, it seems like you either weren't paying attention, or
Raul> didn't understand.

Selective memory is indeed useful. You, sir, are sadly behind
 the times here.

manoj

-- 
 "I do not feel obliged to believe that the same God who has endowed
 us with sense, reason, and intellect has intended us to forgo its
 use." Galileo
Manoj Srivastava  <[EMAIL PROTECTED]> 
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


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

Re: Pronouns (was Re: Proposed Constitution)

[Marcus Brinkmann]

On Tue, Apr 28, 1998 at 05:02:57PM +0100, Ian Jackson wrote:
> This discussion is ridiculous.
> 
> In my view singular `they' is perfectly correct.  If I can use it in
> my PhD thesis (with a footnote[1] and supporting references, and
> without any complaint from the examiners) then we can use it here.
>
> Furthermore, language is defined by use, not by prescription (try
> asking a linguist, rather than a schoolteacher).  Singular `they' is
> very well accepted practice in this speech community; in the contexts
> I have used it it is (I believe) clear, clean and unambiguous.

I hope you are well aware of the fact that a lot of people will not
understand it, and probably will ask you about it. I can tell you that most
german readers may be confused. I don't know about other countries, but I
assume the situation is not very different there.

> I will not change the current draft, and blustering here will not make
> me change my mind.  If you're so horribly bothered you'll have to
> propose an amendment; I wonder if you could find five sufficiently
> anal (and wrong) supporters.

Ian, I find your attitude arrogant and egocentric. Your constitution is hard
enough to read for non-native speakers, and if you don't want to rule out people
that don't have a Ph.D. in Oxford English, you probably want to reconsider
your position.

I will not make you the favour to propose a change, because I don't have the
time for kid games and name calling. I only ask you to have a footnote
explaining: If you need it in your Ph.D. to warrant this language, you
certainly want it in an internationally used document, too.

Remember that Linux as well as Debian is an international project.

Marcus


-- 
"Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ 
Marcus Brinkmann   http://www.debian.orgmaster.debian.org
[EMAIL PROTECTED]for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/   PGP Key ID 36E7CD09


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

Re: installation report of hamm 26.4.

[Andreas Jellinghaus]

> 
> > f) xserver offered my to "configure now". this failed, because not 
> > everything
> > was installed, so it could not work.
> 
> Can you be more specific?
> 
> There is nothing in the xserver postinst that demands the presence of
> xbase.  I assume makedev and libc6 were installed and configured.  Were
> they?  They're both essential, so I assume they must have been.

if [ -x /usr/sbin/xbase-configure ] ; then
  /usr/sbin/xbase-configure
fi

if xbase is unpacked, but not configured, then this will call xbase-configure,
and then you can say "ok, let's create a config file". but without x11 fonts,
this will not work. (if x11 fonts are unpacked, but not configured,
this won't work too - fonts.* files are not yet created ...).

remove that code, or depend on xbase. i suggest to remove the code.

> > h) xbase: some files were already there, but empty (Xserver). maybe this has
> > todo with f). many people had problems with bo, when /etc/init.d/xdm
> > did exist, but was empty, and they did not press "I" to replace it.
> > now the same thing again ?
> 
> What version of xbase was this?  Sounds like it must be 3.3.2-3 or earlier.

yes, that's ther version in hamm, that was on my mirror on sunday.

> If /et/X11/Xserver was empty, how did your machine know to look for the
> Mach64 server when starting X (below)?

i had to edit it...

> > h) xserver installation. the user needs your help !
> > i didn't know, what xserver i need, so i installed only vga16,
> > so XF86Setup will tell me more. result : fatal.
> > the first time it failed because mach64 server was not installed.
> 
> XF86Setup depends only on the VGA16 server.  XFree86 3.3.2-4 always backs
> up the /etc/X11/XF86ConfConfig file. 
> 
> > this will confuse users !
> > i suggest to do an appropiate "echo xserver-|dpkg
> > --set-selection" call, save the default config, and ask the user
> > to run dpkg again and continue later.
> 
> This is a very poor solution.  I think 3.3.2-4 solves this.

ok, will look at it, and then come back.

> > ok, so i had to care about this myself, and started xf86setup later again,
> > doing the whole configuration again... this time i got :
> > 
> > missing close-brace
> > ("if" then script line 1)
> > while compiling
> > "if {![getline]} { ..."
> > (file "/ ... /phase5.tcl" line 26)
> > invoked within "source /.../phase5.tcl"
> 
> This is harmless (as you can see, the XF86Config file is created anyway),
> but fixed in 3.3.2-4.
> 
> > XF86Config was written, but Xserver was not modified.
> 
> Xserver is not modified by XF86Setup, it is modified by the xserver package
> postinst.

but is this wise ? i mean - the normal user doesn't know which server he
needs, before is is running xf86setup to find out. and since the script
does a test with the new server, every user will now say "ok, it looks good.
lets make it the default config". at least i guess.

> > xdm-start-server was not listed in /etc/X11/config.
> > calling xbase-configure did not help. this script should assist the user in
> > such stuff, because the debian way to do these things is only known to some
> > hackers.
> 
> In XFree86 3.3.2-4, you may invoke /usr/sbin/xbase-configure with the
> "force" argument.
> 
> XFree86 3.3.2-4 ships with xdm configured to start a local server, if the
> user configures XDM to run at all.

yes, that's much better. thanks.

> > ok, at least xbase-configure changed the xdm/Xserver file, after i added
> > the "xdm-start-server" line.
> > btw: this seems to be redundant information to me. 
> 
> All this is changed in XFree86 3.3.2-4.  The xdm-start-server option has
> been placed in limbo, and nothing edits /etc/X11/xdm/Xserver anymore; it
> must be edited by hand.  Detailed instructions are now inside that file to
> facilitate the process.

thank you very much ! looks like you did a great ! job.
i will burn the next cd's in a few days, and will install again.

andreas


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

Re: first proposal for a new maintainer policy

[Dale Scheetz]

On 29 Apr 1998, Manoj Srivastava wrote:

> Hi,
> >>"Dale" == Dale Scheetz <[EMAIL PROTECTED]> writes:
> 
> Dale> The Policy Statement is a set of rules for the behavior of
> Dale> developers, set down by the "ruling body", sometimes referred to
> Dale> as "the government". When those rules are viewed as more
> Dale> important than the people participating, that view is a Fascist
> Dale> one.
> 
>   Please elucidate hw the laws of the united states, canada, the
>  united kindom, or indeed, any european union country (pardon
>  for missing your country here) does not fit the same criterion.

The Constitution of the United States speaks of the freedoms of the
individual and the responsibilities of the government. Many of the
amendments further expound on the individual freedoms a citizen has from
oppression by the powerful.

> 
>   If I wish to go out and help myself to the extra ``petty''
>  cash lying around in banks, I shall soon find whether the laws of the
>  land are considered more important than the people.
> 
Those laws are for the protection of individuals from those more powerful
groups who would deprive them of "life, liberty, and ..."

>   I guess the ANSI C standard is fascist too. Hmm.
> 
If you are an individual composed of C code then it is ;-)

>   manoj
>  amused
>  Is invoking hascism the same as invoking hitler in a discussion?

I don't think so, but please define hascism anyway ;-)

> -- 
>  "When I was a boy I was told that anybody could become president; I'm
>  beginning to believe it." Clarence Darrow

When I was in High School we learned that the Russian people voted in a
democratic election where there was only one candidate for President
provided on the ballot. Having already learned that our democracy was a
two party system providing two candidates for the ballot, it has always
seemed to me that the Russian system was more honest.

Luck,

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

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

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


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

Re: Maybe alpha should be in hamm? (was: Re: Only m68k and i386 in hamm?)

[James Troup]

Michael Alan Dorman <[EMAIL PROTECTED]> writes:

> [ ... ] ld.so doesn't apply [ ... ]

Upgrade your quinn-diff :-)  From 0.31's ChangeLog.main :-

| Sun Apr 12 21:33:14 1998  James Troup  <[EMAIL PROTECTED]>
| 
| * Packages-arch-specific (ldso): exclude alpha.

(Maybe it should also be excluded for the other glibc only
architectures too? I always welcome input on Packages-arch-specific as
I'm only qualified to speak for m68k (and then only barely))

-- 
James


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

Re: xfsft deb package

[Remco Blaakmeer]

On Sun, 26 Apr 1998, Stephen Carpenter wrote:

> -BEGIN PGP SIGNED MESSAGE-
> 
> A few days ago (maybe a week or so? I am too lazy to look back and
> check...and it doesn't REALLY matter)
> I mentioned an interest in xfstt which is listed as needing
> a new maintainer and got no reply herebut I was told
> in a separate discussion (which was the same one which
> prompted me to post here) I was told that it already has a new
> maintainer.
> Then I recived an anynomous message from someone who had read the thread.
> (I havn't gotten an anonymous message since annon.pennet.fi shut down)
> Saying that I should look into xfsft ..which is another (suposedly better)
> True Type font server for X.
> (BTW a number of days ago I expressed intrest in this on debian-mentors
> about this but recived no response...nor any other mail from that
> list which I am almost sure I subscribed to...is that adead list?)
> I have thought about it a bit more and I woul dlike to give this a try.
> has anyone else looked into this (or possibly already doing this?
> it is not listed as being worked on...)
> Unfortunatly this package is a little weird in one way...
> the distribution only contains some of the source code...
> the rest is from other packages (it si distributed as a patch)
> has anyone run into this situation before?
> This will require me to get the "Freetype" source code and 
> the X11 source code (it uses the X11 font server source)
> how should this be handled (esp when it comes to making the
> source ditribution with the tar.gz and the diffs and all)

If it is a patch to xfs that uses the freetype libs, I'd think it could be
incorporated into the xfs that is in the xbase package, but I wouldn't
care if it was implemented as a separate font server. Could you contact
Branden Robinson <[EMAIL PROTECTED]> (the XFree86 maintainer) about this?

Remco


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

Intent to package: xitalk

[Chris Reed]

   
xitalk is a useful program that enters itself into utmp and listens on a 
pty for talk requests/ write(1)s.  It can then be configured to start a 
ytalk session automatically (taking the username from the talk request) or 
perform some other action (e.g. play a sound).

I thought I'd seen a debian package of this about 6 months ago, but I can't 
see it anywhere now.

 -- Christopher Reed, Selwyn College, Cambridge --
 E-Mail: [EMAIL PROTECTED]  WWW: http://dura.sel.cam.ac.uk/ [~cr212/]
 r2 T1 cSEL dCS hEn/Chi A4 S+ C*$+++L/UdP W+++ y# a VTsj (Cantab) 1.0 
"I know you don't love that guy cause I can see right through you"



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

Re: Maybe alpha should be in hamm? (was: Re: Only m68k and i386 in hamm?)

[Michael Alan Dorman]

James Troup <[EMAIL PROTECTED]> writes:
> Michael Alan Dorman <[EMAIL PROTECTED]> writes:
> > [ ... ] ld.so doesn't apply [ ... ]
> Upgrade your quinn-diff :-)  From 0.31's ChangeLog.main :-

Yeah, but I've been meaning to feed back my changes in one block
rather than in dribs and drabs, no time, etc.

> (Maybe it should also be excluded for the other glibc only
> architectures too? I always welcome input on Packages-arch-specific as
> I'm only qualified to speak for m68k (and then only barely))

Probably?

Mike.


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

Re: Intent to package: xitalk

[Joey Hess]

Chris Reed wrote:
>
> xitalk is a useful program that enters itself into utmp and listens on a 
> pty for talk requests/ write(1)s.  It can then be configured to start a 
> ytalk session automatically (taking the username from the talk request) or 
> perform some other action (e.g. play a sound).
> 
> I thought I'd seen a debian package of this about 6 months ago, but I can't 
> see it anywhere now.

I tried to package this about 6 months ago and failed utterly getting it to
work (libc6 problem maybe? I forget) Good luck..

-- 
see shy jo


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