Re: bugs + rant + constructive criticism (long)

[Ethan Benson]

On Thu, Jan 04, 2001 at 12:41:24AM -0500, Adam McKenna wrote:
> > as for including other's in the Mail-Followup-To mutt only does this
> > if those users had used `lists' instead of `subscribe' indicating they
> > WANT to be CCed.  
> 
> There must be a bug in it somewhere, then, because I often see people getting
> added to Mail-Followup-To that shouldn't be there.  In fact, I personally 
> have been added to Mail-Followup-To by other Mutt users, and I don't use the 
> lists command at all.

in that case there would be something funny going on, here is my
theory:

you post to list, you M-F-To: is set to only the list

someone (Mr-Broken) with broken mailer uses reply-to-all which CCs you
anyway ignoring M-F-To.

mutt user uses list-reply to Mr-Broken's post, mutt sees you were CCed
and assumes you should be included since there is no M-F-To header.
mutt then sets the M-F-To header to include you for the benifit of
later list-replies.  

if this is the case the solution is fixing broken mailers, many of
them are Free software so why have patches to support M-F-To not been
made?

-- 
Ethan Benson
http://www.alaska.net/~erbenson/


pgpqtpqwUSa94.pgp
Description: PGP signature

Re: bugs + rant + constructive criticism (long)

[John Galt]

On Thu, 4 Jan 2001, Craig Sanders wrote:

> On Wed, Jan 03, 2001 at 09:53:04PM -0700, John Galt wrote:
> > > > In fact, the only thing the RFC says to do is to honor Reply-To: 
> > > > headers,
> > > > which I might note you didn't include in your message.
> > > 
> > > Why should I, when it would be no different from my From: header?
> > 
> > It would be in your case: 
> > 
> > Reply-to: debian-devel@lists.debian.org
> 
> no, that would make it difficult for people to reply privately to him.
> 
> Mail-Followup-To is the correct header to use.

Mail-Followup-To isn't even a registered header!  The closest thing to a
registry that RFC822 implies is in the hands of SRI International is

http://www.dsv.su.se/jpalme/ietf/mail-headers/

(jpalme is as much of a member as one can be of the IETF RFC822 WG)

which says that a "Followup-To:" header is from RFC 1036, but RFC 1036 is
for USENET messages, not email.  The only thing I can think of is that
somebody liked the usenet idea of the followup-to: and just appended a
mail on it.  Just because somebody breaks the standards does NOT mean that
everybody should.  

> > The difference between pine and mutt is that you KNOW the overflows in
> > pine
> 
> incorrect, again. the difference between mutt and pine is that mutt is
> a decent piece of free software that works and follows the relevant
> standards, while pine is a broken piece of non-free shit which doesn't.

Horsefeathers!  The Mail-followup-to: header is NOT a part of the relevant
standards!  

> > mutt allegedly shares code with pine...
> 
> since the source-code of both programs is readily available it should be
> easy enough to check this allegation.
> 
> 
> craig
> 
> --
> craig sanders
> 
> 
> 

-- 
Pardon me, but you have obviously mistaken me for someone who gives a
damn.
email [EMAIL PROTECTED]

Re: bugs + rant + constructive criticism (long)

[Adam McKenna]

On Wed, Jan 03, 2001 at 09:07:27PM -0900, Ethan Benson wrote:
> > have been added to Mail-Followup-To by other Mutt users, and I don't use 
> > the 
> > lists command at all.
> 
> in that case there would be something funny going on, here is my
> theory:
> 
> you post to list, you M-F-To: is set to only the list
> 
> someone (Mr-Broken) with broken mailer uses reply-to-all which CCs you
> anyway ignoring M-F-To.
> 
> mutt user uses list-reply to Mr-Broken's post, mutt sees you were CCed
> and assumes you should be included since there is no M-F-To header.
> mutt then sets the M-F-To header to include you for the benifit of
> later list-replies.  

Sounds like a reasonable scenario.

> if this is the case the solution is fixing broken mailers, many of
> them are Free software so why have patches to support M-F-To not been
> made?

I'd like to see someone convince that M-F-To fix Pine.  But I doubt you'll
have an easy time getting Crispin to apply a patch.  He won't even implement 
maildir, for christ sake, and patches for that have been around for over 2
years now.

--Adam

Re: bugs + rant + constructive criticism (long)

[Ethan Benson]

On Thu, Jan 04, 2001 at 01:18:40AM -0500, Adam McKenna wrote:
> > if this is the case the solution is fixing broken mailers, many of
> > them are Free software so why have patches to support M-F-To not been
> > made?
> 
> I'd like to see someone convince that M-F-To fix Pine.  But I doubt you'll
> have an easy time getting Crispin to apply a patch.  He won't even implement 
> maildir, for christ sake, and patches for that have been around for over 2
> years now.

pine is a lost cause anyway.  i was thinking of GNUs which seems to be
the other big offender of ignorage of M-F-To.  (i am not sure if it
respects Mail-Copies-To: never i just started adding that.)  

btw is it Mail-Copies-To: never or Mail-Copies-To: nobody ?  i have
seen both which is correct?  (assuming any MUA actually pays any
attention to this header anyway)

-- 
Ethan Benson
http://www.alaska.net/~erbenson/


pgpGg3g9t1U7S.pgp
Description: PGP signature

Re: bugs + rant + constructive criticism (long)

[Adam McKenna]

On Wed, Jan 03, 2001 at 09:23:23PM -0900, Ethan Benson wrote:
> On Thu, Jan 04, 2001 at 01:18:40AM -0500, Adam McKenna wrote:
> > > if this is the case the solution is fixing broken mailers, many of
> > > them are Free software so why have patches to support M-F-To not been
> > > made?
> > 
> > I'd like to see someone convince that M-F-To fix Pine.  But I doubt you'll
> > have an easy time getting Crispin to apply a patch.  He won't even 
> > implement 
> > maildir, for christ sake, and patches for that have been around for over 2
> > years now.
> 
> pine is a lost cause anyway.  i was thinking of GNUs which seems to be
> the other big offender of ignorage of M-F-To.  (i am not sure if it
> respects Mail-Copies-To: never i just started adding that.)  

Actually, I'm pretty sure that Gnus respects M-F-To.  The biggest offenders
in that arena seem to be PINE and the GUI MUA's.

> btw is it Mail-Copies-To: never or Mail-Copies-To: nobody ?  i have
> seen both which is correct?  (assuming any MUA actually pays any
> attention to this header anyway)

Don't know, I don't use it.

--Adam

ITP: aterm -- an x terminal emulator

[Chris Gray]

Package: wnpp
Severity: wishlist

Description:
aterm is based upon rxvt v.2.4.8 with add ons of 
Alfredo Kojima's NeXT-ish scrollbars. Fast transparency 
functionality, background lightening/darkening or/and 
tinting(coloring). Original idea of using ParentRelative
transparency mode belongs to Alfredo also, although code 
has been mostly reworked. It can also be integrated with
AfterStep libasimage for pixmap loading from various formats.

The licence is GPL.

If no one else is packaging this, I'd like to take it on.  I'm not a
maintainer yet, so I'll need a sponsor to upload it when it is ready.
I'll have it up on my apt-able site as soon as possible:

deb  http://www.cs.mcgill.ca/~cgray4 woody main
deb-src http://www.cs.mcgill.ca/~cgray4 woody main

Cheers,
Chris

-- 
Got jag?  http://www.tribsoft.com

Re: bugs + rant + constructive criticism (long)

[Ben Gertzfield]

> "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes:

Ethan> pine is a lost cause anyway.  i was thinking of GNUs which
Ethan> seems to be the other big offender of ignorage of M-F-To.
Ethan> (i am not sure if it respects Mail-Copies-To: never i just
Ethan> started adding that.)

Gnus definitely respects M-F-To.  I'm using it now, and it confirmed
that I wanted to obey M-F-To when I followed-up to your message.

Ben

-- 
Brought to you by the letters J and Q and the number 7.
"If you turn both processors off, you will have to reboot."
Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/

Re: ITP: aterm -- an x terminal emulator

[Branden Robinson]

On Thu, Jan 04, 2001 at 01:27:13AM -0500, Chris Gray wrote:
> Package: wnpp
> Severity: wishlist
> 
> Description:

Someone please close this bug once it gets a number from the BTS.

Package: aterm
Priority: optional
Section: x11
Installed-Size: 308
Maintainer: Jordi Mallach <[EMAIL PROTECTED]>
Architecture: i386
Version: 0.4.0-2
Provides: x-terminal-emulator
Depends: libc6 (>= 2.1.97), xlibs (>= 4.0.1-1)
Filename: dists/woody/main/binary-i386/x11/aterm_0.4.0-2.deb
Size: 91952
MD5sum: 397b191f85e3140aaf82da0a75a37266
Description: Afterstep XVT - a VT102 emulator for the X window system
 Aterm is a colour vt102 terminal emulator, based on rxvt 2.4.8 with
 some additions of fast transparency, intended as an xterm replacement
 for users who do not require features such as Tektronix 4014
 emulation and toolkit-style configurability. As a result, aterm uses
 much less swap space -- a significant advantage on a machine serving
 many X sessions. It was created with AfterStep Window Manager users
 in mind, but is not tied to any libraries, and can be used anywhere.

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


pgpovSvyoatZr.pgp
Description: PGP signature

Re: our broken man package

[Ethan Benson]

On Wed, Jan 03, 2001 at 03:23:03PM -0800, Joey Hess wrote:
> I'm concerned with some breakage in the man program. Here is an example:
> 
[snip examples]
> 
> This is because man runs via a wrapper that makes it run as user man
> (and makes root's pager run as user man too for some reason).
> 
> Related bugs: #74790, #60084, #58112, #42128.
> 
> I have never seen an explination of why this wrapper program makes man
> run as user man. If it just ran it as group man, everything would be ok.
> As bug #42128 suggests, /var/catman/ could be writable by group man,
> rather than user man.

the problem with this is you end up with the catman files owned by
whatever user reads whatever man page.  personally as a sysadmin i
don't want users gaining write permission to files in any more places
under /var then there already is (ahem texmf).  i am not certain if
there is potential security threats to users being able to write bogus
catman files, perhaps via groff tricks there is.  

IMO a setgid man with a group writable /var/catman is not any better
then a mode 1777 /var/catman.  (which is what slackware does btw)
OpenBSD took another tack on this problem and just did away with
cached man pages altogether.  (no suid or sgid man) 

-- 
Ethan Benson
http://www.alaska.net/~erbenson/


pgp1CiH8rxzJQ.pgp
Description: PGP signature

Re: bugs + rant + constructive criticism (long)

[Adi Stav]

On Wed, Jan 03, 2001 at 09:07:27PM -0900, Ethan Benson wrote:
> in that case there would be something funny going on, here is my
> theory:
> 
> you post to list, you M-F-To: is set to only the list
> 
> someone (Mr-Broken) with broken mailer uses reply-to-all which CCs you
> anyway ignoring M-F-To.
> 
> mutt user uses list-reply to Mr-Broken's post, mutt sees you were CCed
> and assumes you should be included since there is no M-F-To header.
> mutt then sets the M-F-To header to include you for the benifit of
> later list-replies.  

How about having the mailing list software add M-F-To headers to mails
that do not have it and do not have Reply-To, filling it with the
mailing list only? Might help at least some of the cases.



- Adi Stav

Re: Rambling apt-get ideas

[Matt Zimmerman]

On Fri, Dec 29, 2000 at 11:11:01PM +0100, [EMAIL PROTECTED] wrote:

> Why not look at this from a different perspective? I don't know if it may be
> useful or not for upgrading machines, but the multicast server would be a
> very nice thing for mass installations.

I still disagree.  Multicast is the wrong solution.  Multicast data is
basically equivalent to a cache with zero object TTL.  Packets (objects) are
stored (by a network device) until a client needs them (immediately), at which
point they are served (multicasted/broadcasted) and expired (discarded).  Why
not replace this with a _real_ cache, which can store objects for a
user-definable period of time, allowing for later operations to benefit from
the cache?

It _might_ be useful to use multicast for a system which would trigger a bunch
of daemons to all download the same data from the cache, but even this is
doubtful.  Unless you are dealing with many thousands of clients, the overhead
for sending individually-addressed packets to the clients is minimal.

This is definitely a "pull" problem rather than a "push" problem.  Say a system
is being installed in a new location, which has network connectivity, but no
user consoles (yet).  Why should the admin have to find a live terminal in
order to tell the server to initiate a multicast installation?  Why not just
have the bootstrap disk fetch the necessary data?

> Image large computer rooms at a lan with (usually) uniform hardware. If there
> was a package (say apt-getd) that could be installed on one, already
> running box, which lets you make a special boot disk. The machine that runs
> apt-getd has a way to get to a debian archive (be it local mirror, a set of
> cdroms - this would probably be a bit harder with cd swapping - or a mirror
> on the larger network that it is connected to).

Better to separate automatic system building/configuration (a very hard problem
with relatively little progress) from efficient hierarchical file distribution
(an easier problem, with many good, stable tools already released).

> You boot with the floppy that configures the network, apt-getd starts
> spawning multicast packets, the workstations pick them up and install them.
> Voilà! You just installed an entire network!

Also consider:

You boot with the floppy that configures the network, start downloading files
over TCP, the workstations install them.
Voilà!  You just installed an entire network!

This approach will also work with heterogenous hardware, which is an issue in
a majority of enterprises.

-- 
 - mdz


pgpM6hCEo7s6C.pgp
Description: PGP signature

Re: need headers for target architecture: asm/unistd.h

[Matt Zimmerman]

On Fri, Dec 29, 2000 at 11:24:26PM +0100, Andreas Schuldei wrote:

> I try to build a crosscompiler i386->arm (but also other archs). At one 
> point headerfiles for the target architecture are needed. Where could I find
> headerfiles for other archs? Are there development packages for this purpose?
> Who has done this before?

You can find them in the libc6-dev package (or equivalent) for the target
architecture.  Perhaps they should be split off into an Architecture: all
package, so that they can be installed for use in cross-compilation?

-- 
 - mdz

Re: need headers for target architecture: asm/unistd.h

[Matt Zimmerman]

On Sat, Dec 30, 2000 at 12:39:58PM +0100, Andreas Schuldei wrote:

> * Andreas Schuldei ([EMAIL PROTECTED]) [001229 23:24]:
> > I try to build a crosscompiler i386->arm (but also other archs). At one 
> > point headerfiles for the target architecture are needed. Where could I find
> > headerfiles for other archs? Are there development packages for this 
> > purpose?
> > Who has done this before?
> 
> Will desaster wait at the other end if I use the include files from the
> kernel?

Sometimes.  You should use the same asm/ headers as were used when compiling
the libc you are linking with.

-- 
 - mdz

Re: bugs + rant + constructive criticism (long)

[Craig Sanders]

On Wed, Jan 03, 2001 at 11:11:50PM -0700, John Galt wrote:
> On Thu, 4 Jan 2001, Craig Sanders wrote:
> > Mail-Followup-To is the correct header to use.
> 
> Mail-Followup-To isn't even a registered header!  The closest thing to a
> registry that RFC822 implies is in the hands of SRI International is

the thing about internet standards such as the RFCs is that they tell
you what you *must* do, and what you *must not* do. as long as you
follow those rules faithfully you are free to implement as many other
good ideas as you like.

> http://www.dsv.su.se/jpalme/ietf/mail-headers/
> 
> (jpalme is as much of a member as one can be of the IETF RFC822 WG)
> 
> which says that a "Followup-To:" header is from RFC 1036, but RFC 1036 is
> for USENET messages, not email.  The only thing I can think of is that
> somebody liked the usenet idea of the followup-to: and just appended a
> mail on it.  Just because somebody breaks the standards does NOT mean that
> everybody should.  

well done! it only took you a few years to catch on. that header has
been in common usage for several years.

btw, it's interesting that you mention Jacob Palme. take a look at the
following document written by him in November 1997:

http://www.ietf.org/proceedings/98dec/I-D/draft-ietf-drums-mail-followup-to-00.txt

Network Working Group   Jacob Palme
Internet Draft Stockholm University/KTH
draft-ietf-drums-mail-followup-to-00.txt
Expires: May 1998 November 1997


> > > The difference between pine and mutt is that you KNOW the
> > > overflows in pine
> >
> > incorrect, again. the difference between mutt and pine is that
> > mutt is a decent piece of free software that works and follows the
> > relevant standards, while pine is a broken piece of non-free shit
> > which doesn't.
>
> Horsefeathers!  The Mail-followup-to: header is NOT a part of the
> relevant standards!

that wasn't what i said, and i in no way meant to imply that failure to
implement an optional but well-documented and well-known header is what
makes pine broken. pine is broken in numerous other ways.

craig

--
craig sanders

Re: our broken man package

[Joey Hess]

Ethan Benson wrote:
> the problem with this is you end up with the catman files owned by
> whatever user reads whatever man page.  personally as a sysadmin i
> don't want users gaining write permission to files in any more places
> under /var then there already is (ahem texmf).  i am not certain if
> there is potential security threats to users being able to write bogus
> catman files, perhaps via groff tricks there is.  

I'll bet (have not verified) that you can already trick it into writing
bogus file by sticking trojan pages elsewhere in your manpath.

> IMO a setgid man with a group writable /var/catman is not any better
> then a mode 1777 /var/catman.  (which is what slackware does btw)
> OpenBSD took another tack on this problem and just did away with
> cached man pages altogether.  (no suid or sgid man) 

-- 
see shy jo

Re: bugs + rant + constructive criticism (long)

[Craig Sanders]

On Wed, Jan 03, 2001 at 11:15:23PM +0100, Sven Burgener wrote:
> On Wed, Jan 03, 2001 at 05:23:55PM +1100, Craig Sanders wrote:
> > the new 'testing' distribution (sid) should be even better - nearly
> > all the benefits of 'unstable' but tested to at least install properly
> > without error.
> 
> Wrong: unstable->sid; testing->woody.

yes, my mistake.  i don't know why i called it sid when i know it isn't.  a
brainfart.

my comments about the usefulness of the 'testing' distribution still
apply.

> Personally, I would recommend the use of 'testing' in a production
> environment, but not unstable. One doesn't always have the time to
> fix problems related to the distribution itself whilst working in a
> production environment.

i would recommend the use of either testing or unstable or stable
depending upon the particular requirements of the situation.

stable is good when you don't need or want any change at all.

testing is good when you want/need to be mostly up-to-date with the
latest versions but don't have the time to deal with packaging errors.

unstable is good when you want/need to be up-to-date and have both the
time and the skill to deal with any problems that may arise.



most people with a decent net connection will probably settle for using
'testing'however that won't be much use if nobody uses 'unstable' as
unstable packages won't get installed and tested, so bug reports won't
be filed, so unstable packages will move into testing without actually
having been tested by anyone.


craig

--
craig sanders

Re: bugs + rant + constructive criticism (long)

[Craig Sanders]

On Wed, Jan 03, 2001 at 09:23:23PM -0900, Ethan Benson wrote:
> btw is it Mail-Copies-To: never or Mail-Copies-To: nobody ?  i have
> seen both which is correct?  (assuming any MUA actually pays any
> attention to this header anyway)

'nobody' is correct.

'never' is deprecated but still observed by many MUAs.

from the draft of Mail-Copies-To posted to the usenet-format list on 6
Nov 2000 (Message-Id: <[EMAIL PROTECTED]>):


6.  Optional Headers

6.1.  Mail-Copies-To

   The Mail-Copies-To header indicates whether or not the poster wishes
   to have followups to an article emailed in addition to being posted
   to Netnews and, if so, establishes the address to which they should
   be sent.

   The content syntax makes use of syntax defined in [MESSFOR], but
   subject to the revised definition of local-part given in section 5.2.

  Mail-Copies-To-content= copy-addr / "nobody" / "poster"
  copy-addr = mailbox

   The keyword "nobody" indicates that the author does not wish copies
   of any followup postings to be emailed.

   The keyword "poster" indicates that the author wishes a copy of any
   followup postings to be emailed to him.

   Otherwise, this header contains a copy-addr to which the author
   wishes a copy of any followup postings to be sent.

NOTE: Some existing practice uses the keyword "never" in place
of "nobody" and "always" in place of "poster". These usages are
deprecated, but followup agents MAY observe them.



craig

--
craig sanders

Re: our broken man package

[Ethan Benson]

On Wed, Jan 03, 2001 at 11:53:37PM -0800, Joey Hess wrote:
> Ethan Benson wrote:
> > the problem with this is you end up with the catman files owned by
> > whatever user reads whatever man page.  personally as a sysadmin i
> > don't want users gaining write permission to files in any more places
> > under /var then there already is (ahem texmf).  i am not certain if
> > there is potential security threats to users being able to write bogus
> > catman files, perhaps via groff tricks there is.  
> 
> I'll bet (have not verified) that you can already trick it into writing
> bogus file by sticking trojan pages elsewhere in your manpath.

i just tried it, did not end up with a cached file.  

[EMAIL PROTECTED] eb]$ export MANPATH=/home/eb/test
[EMAIL PROTECTED] eb]$ find /var/cache/man -name 'bogus*'
[EMAIL PROTECTED] eb]$ ls -l /home/eb/test/man8/
total 8
-rw-r--r--1 eb   eb   5193 Jan  3 23:03 bogus.8
[EMAIL PROTECTED] eb]$ man bogus 
Reformatting bogus(8), please wait...
...
[EMAIL PROTECTED] eb]$ find /var/cache/man -name 'bogus*'


it also doesn't cache anything when pointing man directly at a
specific man page:

[EMAIL PROTECTED] eb]$ find /var/cache/man -name 'yaboot*'
[EMAIL PROTECTED] eb]$ man devel/ybin/man/yaboot.8 
Reformatting yaboot.8, please wait...
...
[EMAIL PROTECTED] eb]$ find /var/cache/man -name 'yaboot*'
[EMAIL PROTECTED] eb]$

and yes my caching does work as you can see for a normal man page:

[EMAIL PROTECTED] eb]$ man yaboot
Reformatting yaboot(8), please wait...
...
[EMAIL PROTECTED] eb]$ find /var/cache/man -name 'yaboot*'
/var/cache/man/cat8/yaboot.8.gz

-- 
Ethan Benson
http://www.alaska.net/~erbenson/


pgpKKDIEKxmZF.pgp
Description: PGP signature

Re: DEBIAN IS LOOSING PACKAGES AND NOBODY CARES!!!

[Brendan O'Dea]

On Sun, Dec 31, 2000 at 01:09:07PM +, Oliver Elphick wrote:
>Peter Palfrader wrote:
>  >> There is a further weird package disappearance in unstable: all mgetty
>  >> packages (execept mgetty-doc) are gone!
[...]
>  >> Hey, these are important packages.
>  >
>  >mgetty is not important, it's extra.
> 
>That may be, but where has it gone?

mgetty* got bitten by an old [pre-pool] dinstall bug, where uploads
without "unstable" in the changelog disappear from unstable:

  mgetty (1.1.21-3) stable; urgency=low

* make mgetty-fax's postinst create /var/spool/fax/outgoing/.last_run
  to close a potential symlink exploit by members of the fax group
  that is otherwise possible until that file is created

   -- Philip Hands <[EMAIL PROTECTED]>  Thu, 31 Aug 2000 19:05:13 +0100

See http://bugs.debian.org/77585 .

Regards,
-- 
Brendan O'Deabod@compusol.com.au
Compusol Pty. Limited  (NSW, Australia)  +61 2 9810 3633

Re: bugs + rant + constructive criticism (long)

[Manoj Srivastava]

>>"Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes:

 Ethan> pine is a lost cause anyway.  i was thinking of GNUs which
 Ethan> seems to be the other big offender of ignorage of M-F-To.  (i
 Ethan> am not sure if it respects Mail-Copies-To: never i just
 Ethan> started adding that.)

That just demonstrates you have no idea what you are talking about.

manoj

-- 
 Alan Turing thought about criteria to settle the question of whether
 machines can think, a question of which we now know that it is about
 as relevant as the question of whether submarines can swim. Dijkstra
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: bugs + rant + constructive criticism (long)

[John Galt]

On Thu, 4 Jan 2001, Craig Sanders wrote:

> On Wed, Jan 03, 2001 at 11:11:50PM -0700, John Galt wrote:
> > On Thu, 4 Jan 2001, Craig Sanders wrote:
> > > Mail-Followup-To is the correct header to use.
> > 
> > Mail-Followup-To isn't even a registered header!  The closest thing to a
> > registry that RFC822 implies is in the hands of SRI International is
> 
> the thing about internet standards such as the RFCs is that they tell
> you what you *must* do, and what you *must not* do. as long as you
> follow those rules faithfully you are free to implement as many other
> good ideas as you like.

True, but you aren't free to bitch at people who follow the RFC's for
their failures (Branden...).  In fact, the header Branden's bitching
about is an animal of a wholly different color: the Mail-copies-to: header

Oh, BTW, I decided in the middle of this thread to finally throw in a
reply-to header.  You managed to email both myself and the list, so the
reply-to won't prevent people from privately emailing Branden: it didn't
prevent you from CCing the list (it's Reply-to: [EMAIL PROTECTED],
FWIW)--you see, I DO prefer CCs of list mail: it allows me to pay extra
attention to list mail directed at me.
 
> > http://www.dsv.su.se/jpalme/ietf/mail-headers/
> > 
> > (jpalme is as much of a member as one can be of the IETF RFC822 WG)
> > 
> > which says that a "Followup-To:" header is from RFC 1036, but RFC 1036 is
> > for USENET messages, not email.  The only thing I can think of is that
> > somebody liked the usenet idea of the followup-to: and just appended a
> > mail on it.  Just because somebody breaks the standards does NOT mean that
> > everybody should.  
> 
> well done! it only took you a few years to catch on. that header has
> been in common usage for several years.
> 
> btw, it's interesting that you mention Jacob Palme. take a look at the
> following document written by him in November 1997:
> 
> http://www.ietf.org/proceedings/98dec/I-D/draft-ietf-drums-mail-followup-to-00.txt

Curious he doesn't have in his updated RFC2097 (the URL I used)... Well, I
was looking for it, I found it (with your help).  Still, M-F-T is designed
for GROUP replies, not individual--from 2.2

The "Mail-Followup-To" header can be inserted by the sender of a
message to indicate suggestions on where replies, intended for the
group of people who are discussing the issue of the previous message,
are to be sent. Here are some ways of constructing this header:

Individual replies are still covered by the Reply-to: header, which is the
second away in alphabetical order from 98Dec proceedings (Chris Newman
at Innosoft wrote it):

http://www.ietf.org/proceedings/98dec/I-D/draft-ietf-drums-replyto-meaning-00.txt

---paste---
2. Reply-To Current Practice

 The Reply-To header is currently used for the following purposes:
---...---

 (2) The author/sender can recommend an address or addresses to use
 instead of the "from" address for replies.

 (3) The author/sender can post to multiple mailing lists and
 suggest group replies go to only one of them.

 (4) When the author/sender is subscribed to a mailing list, he can
 suggest that he doesn't want two copies of group replies to
 messages he posts to the list.

 (5) A mailing list can suggest that the list is a discussion list
 and replies should be sent just to the list by default.
---end paste---

I believe that there is some bit of what this thread first started about
within those 4 items...

> Network Working Group   Jacob Palme
> Internet Draft Stockholm University/KTH
> draft-ietf-drums-mail-followup-to-00.txt
> Expires: May 1998 November 1997
> 
> 
> > > > The difference between pine and mutt is that you KNOW the
> > > > overflows in pine
> > >
> > > incorrect, again. the difference between mutt and pine is that
> > > mutt is a decent piece of free software that works and follows the
> > > relevant standards, while pine is a broken piece of non-free shit
> > > which doesn't.
> >
> > Horsefeathers!  The Mail-followup-to: header is NOT a part of the
> > relevant standards!
> 
> that wasn't what i said, and i in no way meant to imply that failure to
> implement an optional but well-documented and well-known header is what
> makes pine broken. pine is broken in numerous other ways.
>
> craig
> 
> --
> craig sanders
> 

-- 
Pardon me, but you have obviously mistaken me for someone who gives a
damn.
email [EMAIL PROTECTED]

Re: bugs + rant + constructive criticism (long)

[Ethan Benson]

On Thu, Jan 04, 2001 at 02:48:46AM -0600, Manoj Srivastava wrote:

>   That just demonstrates you have no idea what you are talking about.

oh please.  someone already pointed out to me that older versions of
Gnus ignored M-F-To but the current one does not.

go fuck off.

-- 
Ethan Benson
http://www.alaska.net/~erbenson/


pgpBNlHDjb9vb.pgp
Description: PGP signature

Re: bugs + rant + constructive criticism (long)

[Peter Makholm]

John Galt <[EMAIL PROTECTED]> writes:

PLEASE DON'T CC ME. I'M ON THE LIST

> FYI 28 (aka RFC 1855) is the standard.

Strictly speaking it's is only a standard if it is on the Standard
Track and RFC1855 isn't. It is only an informational RFC.

PLEASE DON'T CC ME. I'M ON THE LIST

Re: Anybody seen Loic Prylli lately?

[Christian Kurz]

On 01-01-04 Chuan-kai Lin wrote:
> Does anyone know where Loic has been lately (i.e., for the past two years
> or so)?  AFAIK his last package upload was in November 1998, and the mail
> I sent him about whether he needs help with mailx has generated no reply.
> Since mailx is important, if the maintainer is indeed MIA, somebody should
> take over this package and jove.  I would volunteer for mailx in the
> unlikely event that nobody else wants that package.

If you would have looked into unstable first, you would have noticed
that jove has been taken over by Cord Beermann, an upcoming new
maintainer and I had once a contact with Loic to talk with him about his
jove package. Now I'm waiting for his answer about mailx, so please wait
some time more, so that I be able to get an answer from him.

Ciao
 Christian
-- 
  Debian Developer and Quality Assurance Team Member
1024/26CC7853 31E6 A8CA 68FC 284F 7D16  63EC A9E6 67FF 26CC 7853

Re: Problem with start-stop-daemon and pidfile

[Matt Zimmerman]

On Wed, Jan 03, 2001 at 02:10:19AM +0100, Goswin Brederlow wrote:

> touch /var/run/debian-mirror.pid
> chown mirror.nogroup /var/run/debian-mirror.pid
> 
> touch /var/log/debian-mirror.log
> chown mirror.nogroup /var/log/debian-mirror.log

Please don't do this.  nogroup should not be the group of any files, just as
nobody should not be the owner of any files.

-- 
 - mdz

Re: bugs + rant + constructive criticism (long)

[Matt Zimmerman]

On Mon, Jan 01, 2001 at 11:06:18PM -0800, Erik Hollensbe wrote:

> apt-get and it's kin need more simple getopt-style flags that allow
> overriding of certain things, mainly conflicts. Also, an option to
> actually view what's being upgraded before you download 250 packages that
> are only going to break your system would be nice as well.

I assume you already are using apt-get's -u/--show-upgraded flag.  Beyond that,
check out apt-listchanges, in the package of the same name.  Currently, you
need to download the .deb's first, but even if there is a breakage, you would
have ended up downloading them eventually anyway.  Eventually, apt-listchanges
will be able to show changelogs before downloading any packages.

-- 
 - mdz

Re: bugs + rant + constructive criticism (long)

[Manoj Srivastava]

>>"Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes:

 Ethan> On Thu, Jan 04, 2001 at 02:48:46AM -0600, Manoj Srivastava wrote:
 >> That just demonstrates you have no idea what you are talking about.

 Ethan> oh please.  someone already pointed out to me that older
 Ethan> versions of Gnus ignored M-F-To but the current one does not.

Considering the mail-followup-to stuff was only introduced in
 a failed standards attempt in 1998, it is not surprising that
 versions of Gnus before that (not having the gift of prescience) did
 not honour that. 

 Ethan> go fuck off.

You prove my point. Resorting to invective is the last refuge
 of the incompetent. This is your second demonstration of incompetence
 in a public forum in 24 hours; and I suspect your drop in the
 estimation of the readers of this mailing list is far worse than any
 response in kind I could indulge in.

manoj
-- 
 There are times when truth is stranger than fiction and lunch time is
 one of them.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Unclean licences

[Pawel Wiecek]

Hello

One of the programs I'd like to package has somewhat unclean licence.
The readme file says only:

COPYRIGHT: This program is FREEWARE!

which I don't suppose is enough for us.

The webpage is a bit more descriptive and says:

   These programs are freeware, which means that they may be distributed
   freely.

Is this enough for us, or do I have to bug authors for a cleaner licence?

Pawel

-- 
 (___)  | Pawel Wiecek  <+48603240006>  http://www.coven.vmh.net/ |
< o o > | <[EMAIL PROTECTED]> GPG/PGP: www.coven.vmh.net/personal/pgpkey.html |
 \ ^ /  |  *   *   If you don't like the answer,   *   *  |
  (")   |  *   *   you shouldn't have asked the question.  *   *  |

Re: [Fwd: Bug#63511 acknowledged by developer(Bug#63511: fixed in glibc 2.2-7)]

[Eray Ozkural \(exa\)]

Russell Coker wrote:
> 
> I'm sure that Ben will welcome your contributions towards maintaining the
> libc6 package.  All you have to do is read the list of bugs, solve some, and
> send in patches.

I'm not trying to bash Ben. He did a wonderful work in resolving many
bugs and generally keeping up-to-date with the CVS and builds of
all architectures which is a difficult job. My suggestion is another:
give packages multiple developers and have a more formal way for others
to evaluate bugs... It wouldn't be wrong to have at least 2 developers
especially for important packages.

Thanks,

-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: [EMAIL PROTECTED]
www: http://www.cs.bilkent.edu.tr/~erayo

Re: bugs + rant + constructive criticism (long)

[Ethan Benson]

On Thu, Jan 04, 2001 at 03:34:26AM -0600, Manoj Srivastava wrote:

>   You prove my point. Resorting to invective is the last refuge
>  of the incompetent. This is your second demonstration of incompetence
>  in a public forum in 24 hours; and I suspect your drop in the
>  estimation of the readers of this mailing list is far worse than any
>  response in kind I could indulge in.

if only we could all be as perfect as you.   I has simply made the
statement that Gnus users were commonly ignoring M-F-To and rather
then kindly point out that old versions did but the current one no
longer has this problem like another poster did you had to be
insulting and condescending.  well i returned the favor.

-- 
Ethan Benson
http://www.alaska.net/~erbenson/


pgpBzEHyz3hjA.pgp
Description: PGP signature

ITP: crack

[Pawel Wiecek]

Hello.

I'd like to package CRACK, the well know password security checker.
It has a nice licence, derived from Artistic and is no doubt a useful tool
for an administrator.

  Pawel

-- 
 (___)  | Pawel Wiecek  <+48603240006>  http://www.coven.vmh.net/ |
< o o > | <[EMAIL PROTECTED]> GPG/PGP: www.coven.vmh.net/personal/pgpkey.html |
 \ ^ /  |  *  *  Join the army! Meet interesting, exciting people.  *  *  |
  (")   |  *  *And kill them.   *  *  |

Re: our broken man package

[Peter Makholm]

Lars Wirzenius <[EMAIL PROTECTED]> writes:

> On the other hand, we might want to copy the OpenBSD version instead
> of maintaining our own man. But I leave that to whoever maintains the
> packages.

We have alternatives on almost everything but dpkg and man. If someone
thinks it's worth the effort to make alternatives for these they
should do it. If there is a general agreement that the alternatives is
better than the original packages we just switch prioryties.

So simple is that.

Need server

[Michael Meskes]

Is there any apt-able server out there that is accessible with a better
bandwidth than ftp.debian.org (currently 468 bytes/sec) but still is
up-to-date?

ftp.debian.org has been very flaky for me for weeks. And neither
ftp.de.debian.org nor source.rfc822.org are up-to-date. I guess they have
the very same problem accessing ftp.debian.org during their mirror process.

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

Re: Unclean licences

[Peter Makholm]

"Pawel Wiecek" <[EMAIL PROTECTED]> writes:

>These programs are freeware, which means that they may be distributed
>freely.

Nope, we should explicitly have the rights to distribute and modify
the program.

What happened to libnss1-compat?

[Michael Meskes]

I have a commercial binary that needs this library. Yes, I can find it in
potato, but not in unstable. Is there a new package providing
libnss1-compat?

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

Re: [Fwd: Bug#63511 acknowledged by developer(Bug#63511: fixed in glibc 2.2-7)]

[Matt Zimmerman]

On Wed, Jan 03, 2001 at 10:20:11AM -0500, Ben Collins wrote:

> > I've just reported what I had thought, some many many months ago,
> > to be a problem. Of course, the maintainer has not done anything
> > about this report for 7 months, and then he closes it like that.
> > Not good.
> 
> Oh, and just to chime in on this little bit, I did not start maintaining
> glibc until Aug 31, 2000 (my first changelog entry). So no, I have not
> been sitting on this for 7 months. Get your facts straight.

And just to chime in, I appreciate the huge effort and many juicy changelog
entries that have gone into libc6 recently.

-- 
 - mdz

ITP: lovecalc

[Pawel Wiecek]

Hello

I'd like to package lovecalc (http://www.lovecalculator.com/).
Because of kinda unclean licence I'm not quite sure if it'll go into main or
non-free (this depends on whether I convince the author to write a more
precise one, I guess).

Pawel

-- 
 (___)  | Pawel Wiecek --- <[EMAIL PROTECTED]> <+48603240006> |
< o o > | WWW: http://www.coven.vmh.net/   [ Debian GNU/Linux developer ] |
 \ ^ /  |   GPG/PGP key:  http://www.coven.vmh.net/personal/pgpkey.html   |
  (")   |   *  What's apathy? I don't know and I don't care.  *   |

Re: [Fwd: Bug#63511 acknowledged by developer(Bug#63511: fixed in glibc 2.2-7)]

[Russell Coker]

On Thursday 04 January 2001 20:50, Eray Ozkural (exa) wrote:
> Russell Coker wrote:
> > I'm sure that Ben will welcome your contributions towards maintaining the
> > libc6 package.  All you have to do is read the list of bugs, solve some,
> > and send in patches.
>
> I'm not trying to bash Ben. He did a wonderful work in resolving many
> bugs and generally keeping up-to-date with the CVS and builds of
> all architectures which is a difficult job. My suggestion is another:
> give packages multiple developers and have a more formal way for others
> to evaluate bugs... It wouldn't be wrong to have at least 2 developers
> especially for important packages.

This is already being done for some packages.  Check the maintainer address 
on the gcc package for an example.

The thing that determines this is whether there are multiple people who are 
skillful and willing to work.

If you want to be the second developer for libc6 then start fixing some bugs!

-- 
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/   Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page

Re: Bug#81180: ITP: aterm -- an x terminal emulator

[Marcelo E. Magallon]

>> Chris Gray <[EMAIL PROTECTED]> writes:

 > Description:

 [4 ysabell:~] grep-available -s Package,Maintainer -P aterm
 Package: aterm-ml
 Maintainer: Jordi Mallach <[EMAIL PROTECTED]>

 Package: aterm
 Maintainer: Jordi Mallach <[EMAIL PROTECTED]>

 Please close bug#81180 as appropiate.

--
Marcelo

ITP: yardradius

[Francesco Lovergine]

I gonna package yardradius, see http://yardradius.sourceforge.net.
I'm the upstream author.

$Id: README,v 1.4 2001/01/02 09:41:19 kiavik Exp $

Yet Another Radius Daemon (YARD RADIUS) README File


This program is a RADIUS RFC compliant daemon which is derived from
original Livingston Enterprise Inc. RADIUS daemon release 2.1. It adds a
number of useful features to the LE daemon, i.e.

Control of simultaneous logins.
Support of Ascend, Cisco and USR boxes.
Extended daily/monthly/yearly accouting information on a per-user basis.
MD5 encrypted passwords support (both in passwd file and/or users file).
Expirations in shadow file.
Checking based on time-of-day, traffic and connection time.
Support of PAM authentication and accounting.
Binary form of accounting file.
GDBM formats for users and user stats databases.
Autoconfiguring capabilities of sources. 

It supports also all features of LE daemon, i.e.:

Proxy RADIUS
ActivCarda and iPass Support
Accounting Signatures Now Required
Vendor  Specific Attributes
Virtual Ports
Alternate Password File
Address Binding
Improved Messages
Enhanced Debugging

All sources are much cleaner than the original version of Livingston, and
require an ANSI C compiler. A lots of potential buffer overflows have
been corrected by means of massive use of snprintf().

All software is under BSD like license. 

-- 
Francesco P. Lovergine

Re: libapache-asp-perl - perl Apache::ASP - Active Server Pages for Apache with mod_perl.

[Piotr Roszatycki]

On 22 Dec 2000, Stephen Zander wrote:
> Piotr> ITO: libapache-asp-perl
> Piotr> ITO: libapache-filter-perl
> Piotr> ITO: libapache-ssi-perl
> Piotr> ITO: libcgi-pm-perl
> Piotr> ITO: libdbd-csv-perl
> Piotr> ITO: libhtml-clean-perl
> Piotr> ITO: libhtml-simpleparse-perl
> Piotr> ITO: libsql-statement-perl
> Piotr> ITO: libtext-csv-perl
> 
> I will happily pick all these up.

Ok, they're your.


-- 
Piotr Roszatycki | SD Specialist
Internetia Telekom Sp. z o.o.
Netia Holdings S.A. | PL 00-822 Warszawa, ul. Poleczki 13
tel. +48 (22) 648 45 00 wew. 2068

Re: [Fwd: Bug#63511 acknowledged by developer(Bug#63511: fixed in glibc 2.2-7)]

[Eray Ozkural \(exa\)]

Matt Zimmerman wrote:
> 
> > Oh, and just to chime in on this little bit, I did not start maintaining
> > glibc until Aug 31, 2000 (my first changelog entry). So no, I have not
> > been sitting on this for 7 months. Get your facts straight.
> 
> And just to chime in, I appreciate the huge effort and many juicy changelog
> entries that have gone into libc6 recently.

I do, too. I appreciate Ben's skills and effort. Sorry if there's
misunderstanding. For instance, there was this bug about fmemopen() and
a few days later, the fix from CVS was in debian. Amazing.

Thanks,

-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: [EMAIL PROTECTED]
www: http://www.cs.bilkent.edu.tr/~erayo

Re: [Fwd: Bug#63511 acknowledged by developer(Bug#63511: fixed in glibc 2.2-7)]

[Eray Ozkural \(exa\)]

Russell Coker wrote:
> 
> This is already being done for some packages.  Check the maintainer address
> on the gcc package for an example.
> 
> The thing that determines this is whether there are multiple people who are
> skillful and willing to work.
> 
> If you want to be the second developer for libc6 then start fixing some bugs!

Ahem! *choke* Perhaps, I must start with the (inaccurate) bug I'd
reported!!

I'll just determine the cause of that bug and see what I can do myself.

Thanks,

-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: [EMAIL PROTECTED]
www: http://www.cs.bilkent.edu.tr/~erayo

PGP/GPG transition + db.debian.org

[Pawel Wiecek]

How long does it take usually for a (GPG) key sent to keyring.debian.org
to show up in official keyring (and maintainers database)?
I'm waiting for my new GPG key to show up for quite a few weeks and it seems a
bit excessive to me :^)

BTW -- our web interface to developers database (http://db.debian.org/) seems
to be broken since a week or so... Both searching (goes back to index page)
and logging in (returns page redirected to itself) don't seem to work.

 Pawel

-- 
 (___)  | Pawel Wiecek --- <[EMAIL PROTECTED]> <+48603240006> |
< o o > | WWW: http://www.coven.vmh.net/   [ Debian GNU/Linux developer ] |
 \ ^ /  |   GPG/PGP key:  http://www.coven.vmh.net/personal/pgpkey.html   |
  (")   |  *   Never explain.  *  |

ITP: Rhythm Composer TK-707 (And suggestions for sound in debian)

[Eduardo Marcel Macan]

Yes, I've been in a packaging mood lately :)

I'd like to have Tk707 packaged. Tk707 is a software clone of the
Roland TR-707 rhythm composer, a drum machine.

It is written in C and Tk and it uses the alsa sequencer. I am using
it together with the latest alsa modules and lib (compiled from source)
so I'd need someone who uses the alsa drivers provided in woody to help
me get dependencies right and test it.

I am also using timidity++ as an alsa server doing software wavetable
synthesis compiled from sources, the debian package was not compiled
with this option. It would be nice if we had this option enabled in
timidity++ or a timidity-alsa package. (I haven't checked to see if
this was done lately).

alsa + timidity makes it possible do create really good sounding music
without having an expensive sound card. Jazz++ can also use alsa and 
timidity.  If we had alsa, timidity and jazz++ into debian enabled to
work together we would provide an almost complete MIDI music composition
environtment.

Someone tried to get jazz++ packaged (again) a while ago but I
have not seen it in unstable nor any news from the person trying to
do it...

Regards,

Eduardo.

Re: dpkg-statoverride vs. suidmanager

[Wichert Akkerman]

Previously Joey Hess wrote:
> Wichert Akkerman wrote:
> > This still leaves us with two problems:
> > 1. there is no 100% correct way to decide if something is an override
> >or not
> 
> They're flagged local or so arn't they?

Either `local' or 'user' in my suid.conf, but it could be anything
except the packagename basically.

Wichert.

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

Re: PGP/GPG transition + db.debian.org

[Peter Palfrader]

Hi Pawel!

On Thu, 04 Jan 2001, Pawel Wiecek wrote:

> How long does it take usually for a (GPG) key sent to keyring.debian.org
> to show up in official keyring (and maintainers database)?
> I'm waiting for my new GPG key to show up for quite a few weeks and it seems a
> bit excessive to me :^)

New keys sent to keyring.debian.org via gpg --send will take approximatly
forever. New keys have to be added my hand by the keyring maintainer and
this might long (up 2 12 months?) (see a thread here on -devel perhaps a
month or two ago).


> BTW -- our web interface to developers database (http://db.debian.org/) seems
> to be broken since a week or so... Both searching (goes back to index page)
> and logging in (returns page redirected to itself) don't seem to work.

[EMAIL PROTECTED] knows about this.

yours,
peter

-- 
PGP signed and encrypted messages preferred.
http://www.palfrader.org/


pgpo7LWgjJNJK.pgp
Description: PGP signature

Re: Need server

[Josip Rodin]

On Thu, Jan 04, 2001 at 11:01:43AM +0100, Michael Meskes wrote:
> Is there any apt-able server out there that is accessible with a better
> bandwidth than ftp.debian.org (currently 468 bytes/sec) but still is
> up-to-date?

There are almost two hundred public Debian mirrors, use them.

http://www.debian.org/misc/README.mirrors

-- 
Digital Electronic Being Intended for Assassination and Nullification

Re: bugs + rant + constructive criticism (long)

[Mark Brown]

On Wed, Jan 03, 2001 at 08:44:49PM -0500, Adam McKenna wrote:
> On Wed, Jan 03, 2001 at 08:41:06PM -0500, Branden Robinson wrote:

> > If I'm already replying to a list, I'm not going to waste bandwidth by
> > mailing you personally as well.

> So what you're saying is that you're purposely ignoring people's
> Mail-Followup-To when it suits you, while insisting that others abide by 
> yours?  That sounds kind of ridiculous to me.

OTOH, the behaviour in the absence of any Mail-Followup-To: should be to
reply to either the list or the sender but not both.

-- 
Mark Brown  mailto:[EMAIL PROTECTED]   (Trying to avoid grumpiness)
http://www.tardis.ed.ac.uk/~broonie/
EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/

Re: maybe ITP rsync mirror script for pools

[Ingo Saitz]

On Wed, Jan 03, 2001 at 06:14:05PM -0500, Adam McKenna wrote:
> On Wed, Jan 03, 2001 at 11:57:07PM +0100, Marco d'Itri wrote:
> > Please don't encourage private mirrors!
> 
> Debian itself encourages private mirrors.  Personally, I'd rather just
> download a new ISO every 3 months or so as new versions come out but the
> cdimage.debian.org pages steer people heavily toward mirroring and producing
> their own CD images with the debian-cd package.

I think you missed the point Marco d'Itri was talking about.
Downloading CD images is not different from keeping a private
mirror up to date. The private mirror even might save you some
bandwidth.

Also cdimage.debian.org suggests that you install from a public
mirror, if you have the bandwidth you'd also require to keep a
local mirror or download CD images.

Debian currently contains much more packages than anybody would
install. I doubt that even on "big" installations more than 50%
of all debian packages would be installed. Debian includes
additional tools (apt), that make accessing remote repositories
easier than finding packages by hand in a local mirror.

Thus a proxy would serve local machines much better than a local
mirror or CD images. For a single host I'd suggest running
"apt-get -d" overnight.

Ingo
-- 
16  Hard coded constant for amount of room allowed for
cache align and faster forwarding (tunable)

-- seen in /usr/src/linux-2.2.14/net/TUNABLE

Re: bugs + rant + constructive criticism (long)

[Erik Hollensbe]

THANK YOU. Finally, an answer that I can use.

I will look into contributing towards this package.

-- 
Erik Hollensbe <[EMAIL PROTECTED]>
Programmer, Powells Internet Division
"I respect a man who lets me know where he stands, even if he is wrong."
- Malcolm X

On Thu, 4 Jan 2001, Matt Zimmerman wrote:

> On Mon, Jan 01, 2001 at 11:06:18PM -0800, Erik Hollensbe wrote:
>
> > apt-get and it's kin need more simple getopt-style flags that allow
> > overriding of certain things, mainly conflicts. Also, an option to
> > actually view what's being upgraded before you download 250 packages that
> > are only going to break your system would be nice as well.
>
> I assume you already are using apt-get's -u/--show-upgraded flag.  Beyond 
> that,
> check out apt-listchanges, in the package of the same name.  Currently, you
> need to download the .deb's first, but even if there is a breakage, you would
> have ended up downloading them eventually anyway.  Eventually, apt-listchanges
> will be able to show changelogs before downloading any packages.
>
>

quota package and wishlist #67556

[Illo de' Illis]

The severity of bug #67556 (package quota) should be changed from wishlist to
important since it fixes a problem which makes the package unusable on big
endian architectures (getopt() returns int(-1) and not char(-1)). Or at least
it should be advisable to separate the getopt() bug from the rest and submit
it as important.

Ciao,
Illo.

-- 

Ilario Nardinocchi, [EMAIL PROTECTED] - Computer Science Adept since 1982
[EMAIL PROTECTED]   - Oy gevalt, I'm so ferklempt that I
   could plotz!
Know-nothing-bozo rule:
The views expressed above are entirely mine and do not represent the views,
policy or understanding of any other person or official body.

Re: What happened to libnss1-compat?

[Ben Collins]

On Thu, Jan 04, 2001 at 11:03:15AM +0100, Michael Meskes wrote:
> I have a commercial binary that needs this library. Yes, I can find it in
> potato, but not in unstable. Is there a new package providing
> libnss1-compat?

libnss1-compat would not compile cleanly with the latest glibc. So if
you need this, either keep it around from potato, or convince someone to
package it seperately.

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: Need server

[Michael Meskes]

On Thu, Jan 04, 2001 at 01:48:34PM +0100, Josip Rodin wrote:
> There are almost two hundred public Debian mirrors, use them.

Sure. But I was hoping someone would know a machine that a) is up-to-date
(the three machines outside the US I tried so far are not) and b) is
accessible pretty well (which ftp.debian.org is not).

As you might imagine trying 200 machines is not really funny. In fact I was
hoping someone would tell me that ftp.debian.org will be much better
accessible in the near future.

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

Re: ITP: crack

[Andreas Voegele]

Pawel Wiecek writes:

> I'd like to package CRACK, the well know password security checker.
> It has a nice licence, derived from Artistic and is no doubt a
> useful tool for an administrator.

Have you looked at the package john?  AFAIK john can do anything crack
can do.

Re: Need server

[Bart Schuller]

On Thu, Jan 04, 2001 at 02:56:41PM +0100, Michael Meskes wrote:
> On Thu, Jan 04, 2001 at 01:48:34PM +0100, Josip Rodin wrote:
> > There are almost two hundred public Debian mirrors, use them.
> 
> Sure. But I was hoping someone would know a machine that a) is up-to-date
> (the three machines outside the US I tried so far are not) and b) is
> accessible pretty well (which ftp.debian.org is not).

download.sourceforge.net

Does rsync too :-)

-- 
The idea is that the first face shown to people is one they can readily
accept - a more traditional logo. The lunacy element is only revealed
subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual]

Re: ITP: crack

[Mark Brown]

On Thu, Jan 04, 2001 at 03:04:07PM +0100, Andreas Voegele wrote:
> Pawel Wiecek writes:

> > I'd like to package CRACK, the well know password security checker.
> > It has a nice licence, derived from Artistic and is no doubt a
> > useful tool for an administrator.

> Have you looked at the package john?  AFAIK john can do anything crack
> can do.

john is a single process cracker - it can't distribute the load over
multiple CPUs and multiple machines.

-- 
Mark Brown  mailto:[EMAIL PROTECTED]   (Trying to avoid grumpiness)
http://www.tardis.ed.ac.uk/~broonie/
EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/

Re: PGP/GPG transition + db.debian.org

[Pawel Wiecek]

On Jan 4,  1:11pm, Peter Palfrader wrote:
> New keys sent to keyring.debian.org via gpg --send will take approximatly

Gosh...

> forever. New keys have to be added my hand by the keyring maintainer and

Emailed him as well...

> this might long (up 2 12 months?) (see a thread here on -devel perhaps a
> month or two ago).

I can't find it in the archive...

   Pawel

-- 
 (___)  | Pawel Wiecek --- <[EMAIL PROTECTED]> <+48603240006> |
< o o > | WWW: http://www.coven.vmh.net/   [ Debian GNU/Linux developer ] |
 \ ^ /  |   GPG/PGP key:  http://www.coven.vmh.net/personal/pgpkey.html   |
  (")   | Love isn't only blind, it's also deaf, dumb, and stupid.|

Re: Rambling apt-get ideas

[Vince Mulhollon]

With the raging flame war going on about MUAs, I'm embarassed to mail this
with lotus notes, but, hey, its all I have at work.

Back on topic, I would have thought that package distribution was a one
time shot.  Caches are for people who would otherwise download the
slashdot.org header graphic fifty times a day.  Whereas each individual
debian machine should only have to download the latest perl .deb once in
it's "life".  If I apt-get upgrade through my http cache, all I do is flood
the cache with megs of data I'll never download again.

I'm not sure about the overhead is minimal for less than a thousand
clients.  I have 18 or so debian workstations at work.  If it takes 5
minutes to transfer all the .debs to upgrade one machine, then I think it
would take a unicast system slightly less than 18*5 minutes (about 1 1/2
hours) to upgrade, vs 5 minutes for a multicast system to upgrade.  A
unicast upgrade could be an "start it and go to lunch" process whereas a
multicast upgrade would be a "get a cup of coffee" process.  If I had a
hundred machines to upgrade, the comparison would be even greater.  Yeah,
wasting 17*5 minutes is not the end of the world, but why not try harder to
do better?

The concept of the system I'm discussing, is one "master" machine downloads
the .deb via http.  Then it multicasts the .deb to all the other machines
at once.  All of them are on the same subnet so some variety of layer 2
multicast / broadcast would work, although it would be nice to go beyond
the subnet if necessary.

I agree that the discussion about new installs points out that sometimes,
"pull" based systems have an advantage.  I'm pointing out that sometimes,
"push" based systems have an advantage.  And I'm motiviated because I
believe my situation at work is one of those situations where "push" is the
better answer.





Matt

ZimmermanTo: debian-devel@lists.debian.org  

<[EMAIL PROTECTED]cc: (bcc: Vince 
Mulhollon/Brookfield/Norlight) 
rg>  Fax to:

Sent by: MattSubject: Re: Rambling apt-get 
ideas
Zimmerman   

<[EMAIL PROTECTED]  
 
t>  





01/04/2001  

01:45 AM









On Fri, Dec 29, 2000 at 11:11:01PM +0100, [EMAIL PROTECTED] wrote:

> Why not look at this from a different perspective? I don't know if it may
be
> useful or not for upgrading machines, but the multicast server would be a
> very nice thing for mass installations.

I still disagree.  Multicast is the wrong solution.  Multicast data is
basically equivalent to a cache with zero object TTL.  Packets (objects)
are
stored (by a network device) until a client needs them (immediately), at
which
point they are served (multicasted/broadcasted) and expired (discarded)

Re: bugs + rant + constructive criticism (long)

[Jim Lynch]

> 
> Date:Thu, 04 Jan 2001 11:06:43 +1100
> To:  Jim Lynch <[EMAIL PROTECTED]>
> cc:  Erik Hollensbe <[EMAIL PROTECTED]>, debian-devel@lists.debian.org,
>[EMAIL PROTECTED]
> From:Craig Sanders <[EMAIL PROTECTED]>
> Subject: Re: bugs + rant + constructive criticism (long)
> 
> On Wed, Jan 03, 2001 at 06:16:17AM -0800, Jim Lynch wrote:
> > If you want to advocate the use of unstable software, please be my
> > guest... but not on #debian. it changes daily, and can potentially
> > break every day, potentially disasterously. So -no-. It's NOT
> > appropriate to tell people to run servers on unstable software.
> 
> if i ever happen to be on #debian and someone has a problem where the
> best solution is to upgrade to unstable (either a full dist-upgrade or
> just selected packages) then i certainly will recommend exactly that.

So long as you warn the person about (1) general unstability and (2)
unstability produced by upgrading, no problem. Fail to do that (I don't
think you will) and you represent a problem. I will act in some way if
I see it.

> it is *always* appropriate to provide a good solution to a problem -
> whether it accords with your opinion or not.

That's fairly general, enough to be overbroad and out of this context
and in some other; in that other, broader context, of course I agree.

-Jim

Something has broken APT on my system...

[Heikki Kantola]

For few days (first experienced this on 1.1.) I've been trying to figure
out what's wrong with APT as whatever command I try, I get:

 Reading Package Lists... Error!
 E: Dynamic MMap ran out of room
 E: Error occured while processing emusic (NewVersion1)
 E: Problem with MergeList /var/lib/dpkg/status
 E: Unable to write mmap - msync (14 Bad address)
 E: The package lists or status file could not be parsed or opened.

Dpkg I can use fine, so the status file propably isn't corrupted. And
APT I haven't updated recently, but I have updated few other packages it
makes use of. The prime suspects I can think of are debconf (which has
touched /etc/apt/apt.conf) and Perl 5.6. The i686-optimised Libc could 
perhaps have something to do with this too.

Installed versions of the above mentioned packages are:
  apt0.3.19
  perl-5.6   5.6.0-6.2  
  debconf0.5.39 
  libc6-i686 2.2-8
and kernel is 2.2.18pre24.

And if you wonder why I'm not filing this is as a bug, that's because I 
don't like to pick some random package when I'm not sure where the problem
lies...

Ps. Could you please CC: answers to me as currently I'm not subscribing 
this list.
-- 
  *  H e i k k i   K a n t o l a  *  | Report all instances that you see
   IRC: Hezu | of spam abuse. Civilized people need
E-Mail: [EMAIL PROTECTED]| to treat their meat products with
   WWW: http://www.iki.fi/hezu/>| more respect  :) -- [EMAIL PROTECTED]

Re: bugs + rant + constructive criticism (long)

[Jim Lynch]

A hobby server? OK; sorry: I saw "server" and read that as "important
server". 

But in truth, you should be -filing- bugs against things you find
wrong, for the following reason: not all developers read debian-devel,
so your concerns, as important as they may be, may or may not reach
the responsible parties, and without a subject line more suggestive of
each problem (as in the subject line of this note), you can't
guarantee the right person will actually read the note. This erupted
into a mild flamewar (well, two if you count the one about the email
header issues wrt who to reply to), which some people will ignore, and
again this adds to the probability of the appropriate person reading
the note.

But, and yet again, you can't do much complaining about the dist in its
unstable form for the simple reason that you aren't seeing what it will
be like when it is stable. There will always be situations in unstable 
debian (like it or not) under which two packages that are supposed to
cooperate are out of sync, version-wise. In stable, that -shouldn't-
happen. If it does, it's a bug.

Perhaps the best thing to do when you find a version skew between two
packages, is to contact both maintainers, and ask them together what 
the situation is. Perhaps one has a package stashed somewhere that would
solve one or more of your problems; perhaps the two maints are unaware
of each other, and your note could then serve to encourage them to
begin working together on a solution. The usual thing that happens a
lot, is both packages were uploaded, but one didn't make it that day;
looking in incoming might reveal what you're looking for.

-Jim

Re: Need server

[Josip Rodin]

On Thu, Jan 04, 2001 at 02:56:41PM +0100, Michael Meskes wrote:
> > There are almost two hundred public Debian mirrors, use them.
> 
> Sure. But I was hoping someone would know a machine that a) is up-to-date
> (the three machines outside the US I tried so far are not) and b) is
> accessible pretty well (which ftp.debian.org is not).

Then you might want to see

http://www.debian.org/mirror/mirrors_full

and check the sites marked as `Push-Primary'.

> As you might imagine trying 200 machines is not really funny.

But you haven't bothered to try five percent of those. Why do you expect
others will bother to reply to your mail? :>

> In fact I was hoping someone would tell me that ftp.debian.org will be
> much better accessible in the near future.

That's everyone's hoping :) It was down for a few days in the last month,
even. :(

-- 
Digital Electronic Being Intended for Assassination and Nullification

Re: ITP: Rhythm Composer TK-707 (And suggestions for sound in debian)

[Enrique Robledo Arnuncio]

On Thu, Jan 04, 2001 at 10:04:55AM -0200, Eduardo Marcel Macan wrote:
> alsa + timidity makes it possible do create really good sounding music
> without having an expensive sound card. Jazz++ can also use alsa and 
> timidity.  If we had alsa, timidity and jazz++ into debian enabled to
> work together we would provide an almost complete MIDI music composition
> environtment.

The latest versions of jazz++ provide ALSA support by default. If you
have timidity configured as an ALSA server, the only thing you should
need in order to use it from jazz++ would be to select it as the
sequencer output in the jazz++ MIDI config menus.

I also think it would be a nice combination, but I have not tried it;
I have a midi soundcard.

> Someone tried to get jazz++ packaged (again) a while ago but I
> have not seen it in unstable nor any news from the person trying to
> do it...

Well, it was me, and I did package it, but I sent an ITP-delay message
some time ago, when a developer from the WxWindows team asked me not
to put into debian the the 1.68E version of the library, which is the
one jazz++ needs.

I spent some days trying to port jazz++ to the newest versions of the
WxWindows library, but I found it to be a really big task. I managed
to compile about half of the jazz++ source files, and I plan to put my
hands on it when I find the time, hopefully soon. If I fail to do the
port, I will probably try to put it into contrib.

Meanwhile, you can use some unofficial packages I made for WxWindows
1.68 and jazz++ ( The binaries where made for woody two months ago
or so...):

http://www.ieeesb.etsit.upm.es/~era/debian/jazz/

Or apt-get install jazz++ from (sources.list line)

deb-src http://www.ieeesb.etsit.upm.es/~era/debian ./


--- Enrique Robledo Arnuncio 
 
  ---

Re: Something has broken APT on my system...

[Matt Zimmerman]

On Thu, Jan 04, 2001 at 02:08:39AM +0200, Heikki Kantola wrote:

> For few days (first experienced this on 1.1.) I've been trying to figure
> out what's wrong with APT as whatever command I try, I get:
> 
>  Reading Package Lists... Error!
>  E: Dynamic MMap ran out of room
>  E: Error occured while processing emusic (NewVersion1)
>  E: Problem with MergeList /var/lib/dpkg/status
>  E: Unable to write mmap - msync (14 Bad address)
>  E: The package lists or status file could not be parsed or opened.
> 
> Dpkg I can use fine, so the status file propably isn't corrupted. And
> APT I haven't updated recently, but I have updated few other packages it
> makes use of. The prime suspects I can think of are debconf (which has
> touched /etc/apt/apt.conf) and Perl 5.6. The i686-optimised Libc could 
> perhaps have something to do with this too.

Have you tried removing the files under /var/state/apt/lists?  These are
what is being read during the "Reading Package Lists..." phase.  You should
do something like:

# mkdir /tmp/bad-apt-lists
# cp /var/state/apt/lists/* /tmp/bad-apt-lists
# apt-get update
# apt-get check

and see if the problem still occurs.  If it doesn't, then one of those files
may have been corrupted, and you should figure out which one and send the
smallest possible test case as a bug report against apt.

-- 
 - mdz

Re: Bug#81180: ITP: aterm -- an x terminal emulator

[Chris Gray]

> Marcelo E Magallon writes:
>> Chris Gray <[EMAIL PROTECTED]> writes:
> Description:

mem> [4 ysabell:~] grep-available -s Package,Maintainer -P aterm
mem> Package: aterm-ml
mem> Maintainer: Jordi Mallach <[EMAIL PROTECTED]>

mem> Package: aterm
mem> Maintainer: Jordi Mallach <[EMAIL PROTECTED]>

mem> Please close bug#81180 as appropiate.

Sorry, it was an honest mistake -- aterm is not it woody yet, but it
has been packaged so it doesn't have an ITP bug in wnpp.  I have
closed the bug.

Cheers,
Chris
(who is going to update to unstable right now)

-- 
Got jag?  http://www.tribsoft.com

ITP: libxml-simple-perl

[Gordon Matzigkeit]

XML::Simple is a Perl module that facilitates reading and writing Perl
data structures to XML.  It is especially useful for configuration
files.

It's licensed under the same terms as Perl.

-- 
 Gordon Matzigkeit <[EMAIL PROTECTED]>  //\ I'm a FIG (http://fig.org/)
Committed to diversity and freedom \// Try Emacs (http://fig.org/gnu/emacs/)

Re: Rambling apt-get ideas

[Matt Zimmerman]

On Thu, Jan 04, 2001 at 08:37:26AM -0600, Vince Mulhollon wrote:

> Back on topic, I would have thought that package distribution was a one
> time shot.  Caches are for people who would otherwise download the
> slashdot.org header graphic fifty times a day.  Whereas each individual
> debian machine should only have to download the latest perl .deb once in
> it's "life".  If I apt-get upgrade through my http cache, all I do is flood
> the cache with megs of data I'll never download again.

This would be true if you were only upgrading one system.  If you are upgrading
 systems, you need the same .deb  times.

> I'm not sure about the overhead is minimal for less than a thousand
> clients.  I have 18 or so debian workstations at work.  If it takes 5
> minutes to transfer all the .debs to upgrade one machine, then I think it
> would take a unicast system slightly less than 18*5 minutes (about 1 1/2
> hours) to upgrade, vs 5 minutes for a multicast system to upgrade.  A
> unicast upgrade could be an "start it and go to lunch" process whereas a
> multicast upgrade would be a "get a cup of coffee" process.  If I had a
> hundred machines to upgrade, the comparison would be even greater.  Yeah,
> wasting 17*5 minutes is not the end of the world, but why not try harder to
> do better?

If all of the systems can keep up with the 5 minute rate, and no packets are
lost, then the multicast method would probably be faster.  What happens,
though, when one of the systems can't keep up?  Perhaps its load goes up due to
some other job, or there is network congestion and a packet is lost?  There
must be additional protocol overhead to handle retransmissions, perhaps even on
a host-by-host basis.  The server must keep track of who has received what, and
tag and order all of the datagrams in order to do this.  Confirmation must be
received from each host about which datagrams it has received correctly.
Before you know it, you are reimplementing TCP in a 1-to-N transmission model,
and that would be very tricky to get right.

Multicast is designed for "best effort" datagram services like UDP, for
situations where loss is not a big problem (e.g. real-time streaming media), or
error correction and retransmission are handled by higher-level protocols.
Downloading of Debian packages requires a reliable transmission stream.

> The concept of the system I'm discussing, is one "master" machine downloads
> the .deb via http.  Then it multicasts the .deb to all the other machines
> at once.  All of them are on the same subnet so some variety of layer 2
> multicast / broadcast would work, although it would be nice to go beyond
> the subnet if necessary.
>
> I agree that the discussion about new installs points out that sometimes,
> "pull" based systems have an advantage.  I'm pointing out that sometimes,
> "push" based systems have an advantage.  And I'm motiviated because I
> believe my situation at work is one of those situations where "push" is the
> better answer.

There are many who would argue that IP multicast is a broken idea.  I am not
one of those, but I do believe that its uses are limited to a relatively small
problem space.  I believe that multicast is not well-suited to this particular
problem, but you are welcome to try it out.

-- 
 - mdz

Re: Important Note On Source-Only Uploads

[Santiago Vila]

Anthony Towns wrote:
> Basically: don't do them.

Cool! I will tag all pine bugs as "wontfix"...

Re: bugs + rant + constructive criticism (long)

[Mark Brown]

On Thu, Jan 04, 2001 at 07:27:57AM -0800, Jim Lynch wrote:

> But in truth, you should be -filing- bugs against things you find
> wrong, for the following reason: not all developers read debian-devel,
> so your concerns, as important as they may be, may or may not reach
> the responsible parties, and without a subject line more suggestive of

Or may see it but not remember about it when they update their package.

It's not like we have a bug tracking system purely for ornamentation -
it's there to help us track bugs.  Given a well defined mechanism for
bringing problems to people's attention it seems silly not to use it.

-- 
Mark Brown  mailto:[EMAIL PROTECTED]   (Trying to avoid grumpiness)
http://www.tardis.ed.ac.uk/~broonie/
EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/

Re: PGP/GPG transition + db.debian.org

[Peter Palfrader]

Hi Pawel!

On Thu, 04 Jan 2001, Pawel Wiecek wrote:

> On Jan 4,  1:11pm, Peter Palfrader wrote:
> >   (see a thread here on -devel perhaps a
> > month or two ago).
> 
> I can't find it in the archive...

http://lists.debian.org/debian-devel-0010/msg00683.html & Fups.

yours,
peter

-- 
PGP signed and encrypted messages preferred.
http://www.palfrader.org/


pgpFeVk2QwW9n.pgp
Description: PGP signature

Re: ITP: libxml-simple-perl

[Peter Palfrader]

Hi Gordon!

On Thu, 04 Jan 2001, Gordon Matzigkeit wrote:

> XML::Simple is a Perl module that facilitates reading and writing Perl
> data structures to XML.  It is especially useful for configuration
> files.
> 
> It's licensed under the same terms as Perl.

[EMAIL PROTECTED]:~$ dpkg -S XML/Simple
libxml-simple-perl: /usr/lib/perl5/XML/Simple.pm
[EMAIL PROTECTED]:~$ 

yours,
peter

-- 
PGP signed and encrypted messages preferred.
http://www.palfrader.org/


pgp4FXIv0SBmq.pgp
Description: PGP signature

Re: bugs + rant + constructive criticism (long)

[Steve Greenland]

On 03-Jan-01, 22:53 (CST), John Galt <[EMAIL PROTECTED]> wrote: 
> On Wed, 3 Jan 2001, Branden Robinson wrote:
> 
> > I didn't say there was.  Does "Mail-Copies-To:" begin with an X?
> 
> RFC 822 this time:
> 
> http://www.faqs.org/rfcs/rfc822.html
> 
> and Mail-Copies-To: fails to rear it's ugly head, so really should be
> under user-defined fields, which are supposed to be X-

Uh, there have been headers added since 822.

> > 
> > Why should I, when it would be no different from my From: header?
> 
> It would be in your case: 
> 
> Reply-to: debian-devel@lists.debian.org
> 
> would avoid the unnecessary CCs, which is what I assume you want to do.  

Wrong. This would break my MUA so that "reply" no longer sends mail back
to the originator, as it is supposed to do.

> The difference between pine and mutt is that you KNOW the overflows in
> pinemutt allegedly shares code with pine...

Extremely unlikely, as it originated from elm.

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

Re: our broken man package

[Branden Robinson]

On Thu, Jan 04, 2001 at 11:00:19AM +0100, Peter Makholm wrote:
> Lars Wirzenius <[EMAIL PROTECTED]> writes:
> 
> > On the other hand, we might want to copy the OpenBSD version instead
> > of maintaining our own man. But I leave that to whoever maintains the
> > packages.
> 
> We have alternatives on almost everything but dpkg and man. If someone
> thinks it's worth the effort to make alternatives for these they
> should do it. If there is a general agreement that the alternatives is
> better than the original packages we just switch prioryties.
> 
> So simple is that.

Well, I'll take a look at as many of these issues as I can this weekend,
when I re-package groff and man-db.

I've got some time on my hands; thanks to "testing", it will be almost
another week before XFree86 4.x gets in there.

-- 
G. Branden Robinson |Software engineering: that part of
Debian GNU/Linux|computer science which is too difficult
[EMAIL PROTECTED]  |for the computer scientist.
http://www.debian.org/~branden/ |


pgpQZCIjxuz6Y.pgp
Description: PGP signature

Re: ITP: Rhythm Composer TK-707 (And suggestions for sound in debian)

[Branden Robinson]

On Thu, Jan 04, 2001 at 10:04:55AM -0200, Eduardo Marcel Macan wrote:
> I'd like to have Tk707 packaged. Tk707 is a software clone of the
> Roland TR-707 rhythm composer, a drum machine.
> 
> It is written in C and Tk and it uses the alsa sequencer. I am using
> it together with the latest alsa modules and lib (compiled from source)
> so I'd need someone who uses the alsa drivers provided in woody to help
> me get dependencies right and test it.

Great, but what's the license?

If this is free software I'll be all over it; I've been needing something
like this for a long time.  So I'm perfectly willing to help; just email me
privately when you have something ready.

-- 
G. Branden Robinson |I must despise the world which does not
Debian GNU/Linux|know that music is a higher revelation
[EMAIL PROTECTED]  |than all wisdom and philosophy.
http://www.debian.org/~branden/ |-- Ludwig van Beethoven


pgpkVexBohWSC.pgp
Description: PGP signature

Re: ITP: Rhythm Composer TK-707 (And suggestions for sound in debian)

[Branden Robinson]

On Thu, Jan 04, 2001 at 04:34:25PM +0100, Enrique Robledo Arnuncio wrote:
> On Thu, Jan 04, 2001 at 10:04:55AM -0200, Eduardo Marcel Macan wrote:
> Well, it was me, and I did package it, but I sent an ITP-delay message
> some time ago, when a developer from the WxWindows team asked me not
> to put into debian the the 1.68E version of the library, which is the
> one jazz++ needs.
> 
> I spent some days trying to port jazz++ to the newest versions of the
> WxWindows library, but I found it to be a really big task.

Under the circumstances, I suggest uploading jazz++ statically linked
against the version of wxWindows that it needs.  This is a policy
violation, but an excusable and temporary one until either 1) Jazz++ is
ported to a version of wxWindows that its developers are willing to let out
into the wild, or 2) the wxWindows guy(s) change(s) his(/their) mind(s).

-- 
G. Branden Robinson |Any man who does not realize that he is
Debian GNU/Linux|half an animal is only half a man.
[EMAIL PROTECTED]  |-- Thornton Wilder
http://www.debian.org/~branden/ |


pgpWZzZogyXil.pgp
Description: PGP signature

Re: maybe ITP rsync mirror script for pools

[Goswin Brederlow]

> " " == Marco d'Itri <[EMAIL PROTECTED]> writes:

 > On Jan 02, Goswin Brederlow
 > <[EMAIL PROTECTED]> wrote:
>> So would there be intrest in a deb of the script coming with a
>> debconf interface for configuration, cronjob or ip-up support
>> and whatever else is needed to keep an uptodate mirror.
 > Please don't encourage private mirrors!

 > I have been the administrator of ftp.it.debian.org since a long
 > time, and I notice there are many sites doing nightly mirrors
 > for their own use.  Mirroring is free for them because it's
 > done at night when offices are empty and there is nobody
 > downloading porn, but the aggregated traffic is significant for
 > me!  They could save bandwidth and disk space just by using a
 > correctly configured squid cache.

 > -- ciao, Marco

First thats not my problem, sorry. I just provide the means to do it
efficiently.

People will mirror anyway and my script is for any partial mirrors
(which might be public or private, for a company or for people
burining CDs). I use it to heavily downcut the downloading time
(comfort) and to actually reduce traffic (because my modem is to slow
to keep an ftp mirror up-to-date).

If you don't want people to do nightly mirrors, tell them so, or deny
the service. Not providing a script for people needing one will only
make them write their own, probably less eficcient scripts.

MfG
Goswin

Re: Something has broken APT on my system...

[Heikki Kantola]

According to Matt Zimmerman <[EMAIL PROTECTED]>:
> Have you tried removing the files under /var/state/apt/lists?  

Nope.

> These are what is being read during the "Reading Package Lists..."
> phase.  
 
But this information revealed the reason for the behaviour I reported:
the problem spot was references to now defunct sunsite.tut.fi mirror in 
/etc/apt/sources.list. I removed those and everything was working fine 
again. I guess this is still worth a proper bug report for APT.
 
-- 
  *  H e i k k i   K a n t o l a  *  | Report all instances that you see
   IRC: Hezu | of spam abuse. Civilized people need
E-Mail: [EMAIL PROTECTED]| to treat their meat products with
   WWW: http://www.iki.fi/hezu/>| more respect  :) -- [EMAIL PROTECTED]

Re: bugs + rant + constructive criticism (long)

[David Greene]

On Wed, 3 Jan 2001, Branden Robinson wrote:

> The problem is L4M3RZ using that broken piece of non-free shit PINE, which
> doesn't appear to respect *any* conventions of netiquette.

Is there a free mailer to replace "that broken piece of non-free shit
PINE" that supports IMAP?

 -Dave

-- 

"Some little people have music in them, but Fats, he was all music,
 and you know how big he was."  --  James P. Johnson

Re: bugs + rant + constructive criticism (long)

[Tal Danzig]

On Wed, 3 Jan 2001 18:59:47 -0800, Joey Hess wrote:

>   
>   Please bear in mind that many of us have been running unstable since
>   before Debian was released (at all), and fondly remember many fun little
>   incidents like ld.so completly breaking. Tends to put minor breakage in
>   perspective.

Or the time that makedev wiped out my entire /dev directory. :)


-- 
/--\  /--\
| Tal Danzig  [EMAIL PROTECTED] |--| Linux by Libranet|
| Homepage:|--| The TOP Desktop  |
| http://awpti.org/~tal|--|  http://www.libranet.com |
\--/  \--/

Re: bugs + rant + constructive criticism (long)

[Antti-Juhani Kaijanaho]

On 20010104T100704-0600, Steve Greenland wrote:
> On 03-Jan-01, 22:53 (CST), John Galt <[EMAIL PROTECTED]> wrote: 
> > The difference between pine and mutt is that you KNOW the overflows in
> > pinemutt allegedly shares code with pine...
> 
> Extremely unlikely, as it originated from elm.

Pine also originated from elm, so theoretically it's possible (although
I think both are complete rewrites).

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

Re: bugs + rant + constructive criticism (long)

[Wichert Akkerman]

Previously Antti-Juhani Kaijanaho wrote:
> Pine also originated from elm, so theoretically it's possible (although
> I think both are complete rewrites).

mutt is a complete rewrite and shouldn't share core with elm.

Wichert.

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

ITP: Bakery

[Mariusz Przygodzki]

Package: wnpp
Severity: wishlist

I intend to package Bakery.

Package: bakery
License: GPL
URL: http://bakery.sourceforge.net/

Bakery is a C++ Framework for creating GNOME applications using Gnome-- 
(gnomemm) and Gtk-- (gtkmm).

I also maintain gtkmm and gnomemm packages.

-- 
Mariusz Przygodzki|  Good judgement comes from experience.
[EMAIL PROTECTED]  |  Experience comes from bad judgement.
http://www.dune.home.pl   |
GPG KeyID: 0x42FAD771 
GPG Fingerprint: 1990 F07B FFB4 BE0B FF26 10C2 BE2B 965C 42FA D771

Re: bugs + rant + constructive criticism (long)

[Antti-Juhani Kaijanaho]

On 20010103T212649-0600, Adam Heath wrote:
> Perl is a required package, there is no need to list the dependency.

That it is required is not relevant. That it is a virtual essential
package is.

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

Re: Need server

[Heiko Ordelt]

On Thu, Jan 04, 2001 at 11:01:43AM +0100, Michael Meskes wrote:

Hi!

> Is there any apt-able server out there that is accessible with a better
> bandwidth than ftp.debian.org (currently 468 bytes/sec) but still is
> up-to-date?
ftp.freenet.de seems to be very actually and it's fast too. Give it a try.

cu, Heiko

Re: bugs + rant + constructive criticism (long)

[Matt Zimmerman]

On Thu, Jan 04, 2001 at 11:45:50AM -0500, David Greene wrote:

> On Wed, 3 Jan 2001, Branden Robinson wrote:
> 
> > The problem is L4M3RZ using that broken piece of non-free shit PINE, which
> > doesn't appear to respect *any* conventions of netiquette.
> 
> Is there a free mailer to replace "that broken piece of non-free shit
> PINE" that supports IMAP?

Package: mutt
Priority: standard
Section: mail
[...]
Description: Text-based mailreader supporting MIME, GPG, PGP and threading.
 Mutt is a sophisticated text-based Mail User Agent. Some highlights:
[...]
  o Advanced IMAP client supporting Kerberos authentication (and in some
situations SSL encryption).
  o POP3 support.
[...]

-- 
 - mdz

Re: bugs + rant + constructive criticism (long)

[Daniel Burrows]

  (Not Cced :) )

On Wed, Jan 03, 2001 at 02:15:42PM -0500, D-Man <[EMAIL PROTECTED]> was heard 
to say:
> What if I set my Reply-To header to be the address I was sending To?
> How would you reply to me?  ;-)

  To make a totally pointless observation: mutt lets you override Reply-To
when you use the standard "reply" function.

  Daniel

-- 
/- Daniel Burrows <[EMAIL PROTECTED]> -\
| "But what the eagle does not realize is that it is participating in a crude |
|  form of natural selection.  One day, a tortoise will learn to fly."|
|   -- Terry Pratchett, _Small Gods_  |
\--- (if (not (understand-this)) (go-to http://www.schemers.org)) /

Re: bugs + rant + constructive criticism (long)

[Philip Brown]

[ Craig Sanders writes ]
> On Wed, Jan 03, 2001 at 11:26:25AM -0800, Philip Brown wrote:
> > And in the case of the debian mailing lists, you should "reply to" the
> > list.
> 
> bullshit.
> 
> some replies should go to the list, and some replies should be private.
> it's up to the person writing the reply to make that decision, not the
> list software.

But the primary point of a mailing list is for discussion ON THE LIST.
Do you want to disagree with that?
So headers should be optimized for group discussion.
Replying to individuals is a secondary function.


> setting reply-to back to the list just makes it difficult (or in
> some cases impossible) to reply privately. ...
> however reply-to munging by list software does have the
> serious disadvantage of replacing any Reply-To header created by the
> original author of a message.

So what, if the mailing software rewrites From: to have any reply-to
information from the original sender? Then the information is still
available.


> the Reply-To header exists for the *person* who originally sent the
> message to be able to direct replies to their preferred destination. it
> is not there so that mailing lists can screw with it.

So your argument is
 "A mailing list is not a person, so it can't use reply-to:".
Bad argument.

[http://faqs.org/rfcs/rfc822.html]

rfc822, section 4.4.3, EXPLICITLY MENTIONS 
"text message teleconferencing" groups 
  (eg mailing lists) as potential users of the reply-to header,
expressly for the purpose of having "reply" direct email to the list

And finally, example A.3.3 EXPLICITLY shows that "reply-to" is
NOT exclusively for "who wrote the message". It is for
"Where do you want replies to normally go to"

Re: bugs + rant + constructive criticism (long)

[John Galt]

On Thu, 4 Jan 2001, Steve Greenland wrote:

SG>On 03-Jan-01, 22:53 (CST), John Galt <[EMAIL PROTECTED]> wrote: 
SG>> On Wed, 3 Jan 2001, Branden Robinson wrote:
SG>> 
SG>> > I didn't say there was.  Does "Mail-Copies-To:" begin with an X?
SG>> 
SG>> RFC 822 this time:
SG>> 
SG>> http://www.faqs.org/rfcs/rfc822.html
SG>> 
SG>> and Mail-Copies-To: fails to rear it's ugly head, so really should be
SG>> under user-defined fields, which are supposed to be X-
SG>
SG>Uh, there have been headers added since 822.
SG>
SG>> > 
SG>> > Why should I, when it would be no different from my From: header?
SG>> 
SG>> It would be in your case: 
SG>> 
SG>> Reply-to: debian-devel@lists.debian.org
SG>> 
SG>> would avoid the unnecessary CCs, which is what I assume you want to do.  
SG>
SG>Wrong. This would break my MUA so that "reply" no longer sends mail back
SG>to the originator, as it is supposed to do.

Well, you replied to the list alone despite my reply-to, so I guess your
actions don't match your words...  

SG>
SG>> The difference between pine and mutt is that you KNOW the overflows in
SG>> pinemutt allegedly shares code with pine...
SG>
SG>Extremely unlikely, as it originated from elm.

Let's see:  Pine Is Nearly (no-longer lately...) Elm, you say that mutt
actually derives from elm, yet they don't share code.  Um, yeah, sure,
whatever.  BTW from the LG article about mutt...

http://www.ssc.com/lg/issue14/mutt.html

   Michael Elkins is a programmer who at one time was involved in the
   development of the venerable mail-client, Elm. He had some ideas which
   he would have liked to include in Elm but for whatever reasons the
   other Elm developers weren't receptive. So he struck out on his own,
   creating a text-mode mailer which incorporates features from a variety
   of other programs. These include other mailers such as Elm and Pine,
  
   as well as John Davis's Slrn newsreader. As an indication of the
   program's hybrid nature he has named it Mutt. Although the mailer
   began as an amalgamation of features from other programs, it has begun
   to assume an identity of its own.

Presumably, the Mutt team at least looked at Pine's implementation if for
no other reason than to see what to avoid.

SG>Steve
SG>

-- 
Pardon me, but you have obviously mistaken me for someone who gives a
damn.
email [EMAIL PROTECTED]

package pool and big Packages.gz file

[zhaoway]

hi,

[i'm not sure if this has been resolved, lart me if you like.]

my proposal to resolve big Packages.gz is through package
pool system.

add 36 or so new debian package, namely,

[a-zA-Z0-1]-packages-gz_date_all.deb

contents of each is quite obvious. ;-)
and a virtual unstable-packages-gz depends on all of them. finished.

apt-get update should deal with it.

1) as default, install packages-gz.deb, and finished. (against some policy ...)
2) otherwise, let user to choose from, that is a ui design... ;-)

release managment could just ;-) upload a woody-packages-gz_test-1_all.deb

episode I finished.

episode II involves the package pool deletion algorithms.

a package should only be deleted when no *-packages-gz debs reference it.

my 2'c

thanks for bear with me ;-)

zw

Re: our broken man package

[Colin Watson]

Ethan Benson <[EMAIL PROTECTED]> wrote:
>On Wed, Jan 03, 2001 at 11:53:37PM -0800, Joey Hess wrote:
>> I'll bet (have not verified) that you can already trick it into writing
>> bogus file by sticking trojan pages elsewhere in your manpath.
>
>i just tried it, did not end up with a cached file.  
>
>[EMAIL PROTECTED] eb]$ export MANPATH=/home/eb/test
>[EMAIL PROTECTED] eb]$ find /var/cache/man -name 'bogus*'
>[EMAIL PROTECTED] eb]$ ls -l /home/eb/test/man8/
>total 8
>-rw-r--r--1 eb   eb   5193 Jan  3 23:03 bogus.8
>[EMAIL PROTECTED] eb]$ man bogus 
>Reformatting bogus(8), please wait...
>...
>[EMAIL PROTECTED] eb]$ find /var/cache/man -name 'bogus*'

Yes, there's no MANDB_MAP entry in /etc/manpath.config for
/home/eb/test. 'MANPATH=/home/eb/test manpath -c' will tell you the
catpath corresponding to a given manpath.

I don't know if it's possible to subvert this.

-- 
Colin Watson [EMAIL PROTECTED]

mailing-list mgmt (was: Re: bugs + rant + constructive criticism (long))

[Thomas 'Mike' Michlmayr]

On Thu, Jan 04, 2001 at 10:43:05 -0800,
Philip Brown <[EMAIL PROTECTED]> wrote:
[...]
> But the primary point of a mailing list is for discussion ON THE LIST.
> Do you want to disagree with that?

partially. there are enough announce-only and moderated MLs.

> So headers should be optimized for group discussion.
> Replying to individuals is a secondary function.

not at all. replying to individuals is an essentail function that is no
less important than replying to the list. just because your MUA can't make
the distinction without major help does not mean that everybody else with
a capable MUA has to suffer.

and reply-to's on MLs are evil anyway:
http://www.unicom.com/pw/reply-to-harmful.html

[...]
> So what, if the mailing software rewrites From: to have any reply-to
> information from the original sender? Then the information is still
> available.

i'm still of the opinion that ML-software should have as minimal an impact
on mails as possible. munging From: or other headers is not what i consider
as minimal.

[...]
> And finally, example A.3.3 EXPLICITLY shows that "reply-to" is
> NOT exclusively for "who wrote the message". It is for
> "Where do you want replies to normally go to"

my ML-software do not have a builtin AI to determine where replies of a
specific recipient should normally go.

-- 
Thomas 'Mike' Michlmayr  | ignorami: n: The BOFH art of folding problem 
<[EMAIL PROTECTED]> |   lusers into representational shapes.



pgp7diJiLi44L.pgp
Description: PGP signature

Re: Need server

[Marco d'Itri]

On Jan 04, Michael Meskes <[EMAIL PROTECTED]> wrote:

 >ftp.debian.org has been very flaky for me for weeks. And neither
 >ftp.de.debian.org nor source.rfc822.org are up-to-date. I guess they have
 >the very same problem accessing ftp.debian.org during their mirror process.
{ftp,http}.it.debian.org is rsynced every night from ftp.uk.d.o, a
primary mirror, and has the best connection you can get in this country.
rsync access is available too.

I see you live in Germany, the nacamar mirror looked good too last time
I tried it.

If you want to see a list of the update timestamps of all known mirrors
look at http://attila.bofh.it/~md/ .

-- 
ciao,
Marco

Re: package pool and big Packages.gz file

[zhaoway]

[read my previous semi-proposal]

this has some more benefits,

1) package maintainer could upload (to pool) in whatever
frequency they like.

2) release is seperated from package pool which is a storage
system. and release is a qa system.

3) release could be managed through BTS on specific package-gz.deb
that surely would put much more burden on BTS, ;-)

4) if apt-get could deal it well, i hope all of sub-mirror'ing issue
will be gone easily. just apt-get install some-rel-packages-gz then
apt-get mirror (just like download and move ...)

my more 2'c ;-)

zw

Re: package pool and big Packages.gz file

[zhaoway]

On Fri, Jan 05, 2001 at 03:17:30AM +0800, zhaoway wrote:
> [read my previous semi-proposal]
> 
> this has some more benefits,
> 
> 1) package maintainer could upload (to pool) in whatever
> frequency they like.

in an ideal world, developer should upload to ''xxx-auto-builder'' ;-)

9i'm turning out to be crappy now. ;-)

bye,

mutt's history (was: Re: bugs + rant + constructive criticism (long))

[Thomas 'Mike' Michlmayr]

On Thu, Jan 04, 2001 at 11:49:45 -0700,
John Galt <[EMAIL PROTECTED]> wrote:
[...]
> Let's see:  Pine Is Nearly (no-longer lately...) Elm, you say that mutt
> actually derives from elm, yet they don't share code.  Um, yeah, sure,
> whatever.  BTW from the LG article about mutt...

AFAICT mutt does not share code with pine.

[...]
> Presumably, the Mutt team at least looked at Pine's implementation if for
> no other reason than to see what to avoid.

initial versions of mutt used the c-client library, that pine is also based
on. but once michael elkins (at that time the sole author) realized that
a number of mutt's goals [0] could not be achived with c-client, that part
of mutt was rewritten. since c-client is gone, no code of pine that i know
of is in mutt. all that must have happened in early 1996.

now, features is a different discussion. when i proposed the variable
keybinding feature to michael, i think i got the idea from pine. or at least
i wanted to accomodate some of our pine l^Husers who would refuse mutt with
its default keybindings. but the code is certainly michael's, based on my
prototype.


[0] most notably the PGP/MIME support. c-client and/or IMAP does evil things
to those mime-parts.

-- 
Thomas 'Mike' Michlmayr  | ignorami: n: The BOFH art of folding problem 
<[EMAIL PROTECTED]> |   lusers into representational shapes.



pgpGGc2uoUR9r.pgp
Description: PGP signature

Re: ITP: Rhythm Composer TK-707 (And suggestions for sound in debian)

[Eduardo Marcel Macan]

Oooops, sorry, I forgot telling it in my ITP.

It is covered by the GPL and its page is at:

http://www.vislab.usyd.edu.au/staff/chris/tk707/


On Thu, Jan 04, 2001 at 11:19:20AM -0500, Branden Robinson wrote:
> On Thu, Jan 04, 2001 at 10:04:55AM -0200, Eduardo Marcel Macan wrote:
> > I'd like to have Tk707 packaged. Tk707 is a software clone of the
> > Roland TR-707 rhythm composer, a drum machine.



> 
> Great, but what's the license?
> 
> If this is free software I'll be all over it; I've been needing something
> like this for a long time.  So I'm perfectly willing to help; just email me
> privately when you have something ready.

Re: mailing-list mgmt (was: Re: bugs + rant + constructive criticism (long))

[Philip Brown]

[ Thomas 'Mike' Michlmayr writes ]
> On Thu, Jan 04, 2001 at 10:43:05 -0800,
> Philip Brown <[EMAIL PROTECTED]> wrote:
> > So headers should be optimized for group discussion.
> > Replying to individuals is a secondary function.
> 
> not at all. replying to individuals is an essentail function that is no
> less important than replying to the list. just because your MUA can't make
> the distinction without major help does not mean that everybody else with
> a capable MUA has to suffer.

You are distorting facts.
You are not talking about "capable MUA"s, you are talking about 
"MUAs which happen to share the features I like".
Features which are not official standards like rfc822 is.


> > And finally, [rfc822] example A.3.3 EXPLICITLY shows that "reply-to" is
> > NOT exclusively for "who wrote the message". It is for
> > "Where do you want replies to normally go to"
> 
> my ML-software do not have a builtin AI to determine where replies of a
> specific recipient should normally go.

Very funny. But not relevant.

The primary purpose of mailing lists like debian-devel, is for discussion
ON THE LIST. This is implicitly a part of the debian
Developer's Reference, about "Dont Cc people on the mailing list unless
they specifically ask for one".
It also explicitly says, "Anyone who posts to a mailing list should read it
to see the responses."
[http://www.debian.org/doc/packaging-manuals/developers-reference/ch-servers.html#s-mailing-lists]

Therefore, replies, aka "responses" to email on debian-devel should
"normally go" to the list.

Re: console-tools vs kbd, fix listed in bug report?!

[Sam Vilain]

As pointed out to me, bug #71768 has a workaround to my problem listed
in it.  However, I find it quite appalling that a fix involving a one
character change to a source file, where the fix has been listed in
the bug report has not been pushed through, given its age.

The console-tools package has a huge number of bugs associated with
it, and given that it's a base package, that's not so good.

Is it possible for maintainers to share packages, perhaps?  Then these
small things can get sorted quicker.  Personally, I'd just love it if
the entire Debian core system was in CVS, with upstream updates being
merged in.  This would also give the advantage of being able to do
OpenBSD style fixing of code; eg, one person finds a particular type
of bad coding practice, looks for it and fixes it throughout the code
base, and mails the authors to let them know about that bad coding
practice. 

Or perhaps the bug tracking system just needs some rework to be a bit
nicer.  I'm sure some people here have used Remedy's Action Response
System in a reasonably large environment, so why not pick it's best
features and stick them in; like some decent querying capabilities and
borrow some of its interface.  Stick in the ability to assign bugs to
other people.  Perhaps even a standalone client.  Maybe even get some
"customer service" going, and draw up some guidelines for how long it
should take for bugs to be responded to, etc.

Cheers,
Sam.

On Sun, 31 Dec 2000 17:54:56 +
Sam Vilain <[EMAIL PROTECTED]> wrote:

> Hi there,
> 
> I'm using a non-standard keyboard that sends odd scancodes.  I wrote
> a startup script that does a whole heap of "setkeycodes" commands,
> but I've found that the version of "setkeycodes" in the
> console-tools package does not work with kernel version 2.2+.  The
> one with the "kbd" package works fine, but "kbd" seems to be a
> somewhat deprecated package.
> 
> I found a bug relating to this; entitled "console-tools: setkeycode
> does not use right IOCTL", which could be it:
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=53977
> 
> And one entitled "setkeycodes completely broken";
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=71768
> 
> Is there any news on a fix?
--
Sam Vilain, [EMAIL PROTECTED]WWW: http://sam.vilain.net/
GPG public key: http://sam.vilain.net/sam.asc

Re: our broken man package

[Joey Hess]

Lars Wirzenius wrote:
> They always re-format a manual page? This might be reasonable, actually.
> Groff is pretty fast, and most manual pages are short, so it shouldn't
> take too long even on older hardware.

I think it would take a while on my 386 for things like the zshall man page.
(Several hundred pages of documentation.)

> And, anyway, caching might be done in a cronjob: look at the pagesa in
> manpath every night, check which ones have been accessed since the past
> run, and format those. Then delete anything older than N days in the
> cache. When displaying, use the cached version only if it is newer than
> the source.

That's a good idea. Another route to take is to split man into the
rendering/caching bit and the command line man page lookup/processing/pager
executing bit. Only the former part of the program needs to run as user man,
and it could be a fairly small and more auditable peicve of code. This
would also happen to solve most of the reported bugs with the current
setup.

Though I think I like your idea better.

-- 
see shy jo