Request for Help/Comments: fvwm95

[Daniel Martin]

fvwm95 is an ugly package and must die.

Here's the rationale:

fvwm95 is a fork off a version of fvwm2 that was current sometime in
1995.  That is, it's a fork off code that's over 10 years old.

Upstream disappeared from the net sometime in 1997.  There have been
no upstream changes in over 9 years.

fvwm95 is currently broken in a default etch setup because it can't
handle utf-8 locales.  It also was only changed the bare minimum
necessary in the X11R6 -> X11R7 transition.  The only way to make it
work is with a plain en_US or C locale.  (Well, other iso-latin-1
locales probably work too, and I've had reports that iso-latin-2
locales mostly work)

I have no desire to maintain this package any more, and I have a
moderately strong desire to see this package stripped from debian, as
its presence is just ugly crud on the archive.

Therefore, here's my proposal: I propose to write and maintain a set
of configuration files for the current fvwm that cause fvwm to look
and behave the way fvwm95 does now under a C locale.  The fvwm95
package will be transitioned to this new package.

Now, what do people think of this idea?

-- 
Daniel Martin <[EMAIL PROTECTED]>
This message represents my own views, and not those of the Debian
project or any current or past employer.


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

Re: Why weren't the GR voting mails sent to debian-devel-announce?

[Daniel Martin]

Oleksandr Moskalenko <[EMAIL PROTECTED]> writes:

> According to the chapter 3.3 of the Dev. reference the GR calls for votes
> should've been sent to the debian-devel-announce, but in reality they weren't.
> It seems that the only way to get those would be to subscribe to debian-vote
> or to trawl the debian-vote archives. Why is it so?

They weren't?  I got them, automatically filed in my
debian-devel-announce folder, and I'm not subscribed to debian-vote.

I suspect a local, rather than systemic, failure.


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

Re: can't update pbuilder to unstable

[Daniel Martin]

Brian May <[EMAIL PROTECTED]> writes:

> It is probably worth noting that I never modified the
> file in question: /etc/pam.d/other
>
> Is there anything I can do to update this pbuilder chroot?

For what it's worth, I wound up rebuilding my sid pbuilder chroot from
scratch.  (with pbuilder create)  However, first I needed to upgrade
my copy of debootstrap (to a version I compiled on sarge, since that's
what I'm running myself).

If you also happen to be running sarge (aka testing), you can get my
sarge backport of debootstrap 0.2.4 from:

http://www.snowplow.org/martin/debootstrap-sarge

The only changes from the real version are a bump backwards in version
number and a recompile to use the libc6 that's in sarge.

Re: [Fwd: False Representation at Google.com]

[Daniel Martin]

Glenn Maynard <[EMAIL PROTECTED]> writes:

> On Sat, Sep 06, 2003 at 01:34:32AM +0200, Adam Borowski wrote:
>> However, pulling that message from the list archives may be a good idea.
>> It's what Ava Driscoll asked for, and the big HTML links sure don't look
>> good on the Debian pages.
>
> Debian is not in the habit of editing its history (mailing list
> archives).  Don't start down that slope.

So we have to keep the spam?  Is that really part of the history?  (I
suppose that people occasionally reply to spam sent to debian lists,
and some of the resulting conversation is amusing, so perhaps)

However, if we were to remove the spam from the list archives, we
certainly wouldn't want to give the impression that it's being done
because this person asked us to improve his google vanity search.
I seem to remember another case of someone wanting his mailing list
posts purged so that his google vanity search would give the results
he wanted; this person had actually participated in the discussions he
now wished his name removed from, and we rightly told him that he was
nuts.

So does anyone feel like running spamassassin retroactively over old
mailing list archives, manually checking the results, and coming up
with a list of stuff to wipe out?  Short of an exercise like that, I
guess I can see where removing this spam could be something that would
get pushed later.

Re: debconf review of cvsd (was Re: stop abusing debconf already)

[Daniel Martin]

Joey Hess <[EMAIL PROTECTED]> writes:

>  - cvsd/listen:
>s/cvsd will listen on/on which cvsd will listen/ 
>   # Avoid dangling preposition

This is an English usage question of the sort that will get the
English and Linguistics departments at some universities to start
leaving nasty notes on each others' blackboards.

Suffice it to say that I, as a native speaker of American English,
think that the standard written English folks get this one wrong -
prepositions at the of sentences are something up with which we should
put.  We should acknowledge English's Germanic heritage and that it
too has separable verbs.

However, this an unbelievably side issue even for -devel.

Re: Bug#189347: stop the "manage with debconf" madness

[Daniel Martin]

Emile van Bergen <[EMAIL PROTECTED]> writes:

> In most cases, the only feature that's used (and needed) of XML that it
> stores a tree of attribute/value pairs.
> 
> Given limited effort, I am absolutely convinced that it should be
> possible to come up with a more robust, well defined, simple(!), user
> and implementor-friendly(!), do-one-thing-and-do-it-well way of doing
> that.
> 
> Not by starting from "we've got HTML which is being (ab)used for ad-hoc
> RPC purposes, let's make a more general SGML application to do that"
> which became XML, but starting from the simple requirement stated above:
> storing and transmitting nested trees of attribute/value pairs with a
> *limited* number of possible data types. 

I personally must say that I find the format of apt.conf satisfies
this goal admirably.  It also easily allows one to easily override
some specific settings while leaving the rest in place.

For example, here's an apt.conf that I used when I was preparing an
upgrade CD for a machine that sat in a benighted place without network
access:

  Dir "/"
  {
// Location of the state dir
State "var/lib/apt/" 
{
   status "/home/martind/lazarus/status";
};

Cache "/home/martind/lazarus/aptchive";
  };

  Debug::NoLocking "true";

Perhaps it has a few too many quoted strings, semicolons, and braces
for some people's taste, but it has the very distinct advantage that
it's already implemented in a program that's already on every Debian
machine.

Then there's always the format Sun came up with for java's .properties
files, which definitely wins the simplicity award, evne if trailing
spaces can sometimes bite the unwary.

Re: /usr/{share/man,bin} vs /usr/X11R6/{man,bin} (policy 12.8.7)

[Daniel Martin]

"John H. Robinson, IV" <[EMAIL PROTECTED]> writes:

> all the footnote says is that imake Does The Right Thing, which is why
> it is exempted.

See, now I read it as "imake doesn't quite do the right thing, really,
but it's imake, so we'll let it slide - fixing it everywhere is
officially deemed not worth the hassle"

Re: The harden-*flaws packages.

[Daniel Martin]

Martin Schulze <[EMAIL PROTECTED]> writes:

> Please see the thread summarized in 
> :
> 
> Policy for Woody Point-Releases. [4]Several [5]developers [6]would
> [7]like to add new packages and updates to their packages to the
> recently released stable distribution of Debian. Adding new packages
> and random updates to the stable distribution, however, would nullify
> the entire idea of having a stable release, Joey [8]explained. Hence,
> the same policy as before will be used for point-releases of woody.

Yes, but how does this apply to a package that does nothing but
conflict with existing packages?  (As is the case with most of the
harden-* packages)

Agreed, _random_ updates would be a bad thing.  However, what the
maintainer is proposing here is updates that are driven by DSAs.
Although I find it a slight stretch, one could easily argue that the
updates to the harden-*flaws packages are security updates.

These updates share another feature with security updates.  Imagine
the package netostrich, which helps you bury your head in the sand
remotely.  Now, suppose the upstream authors discover a flaw in the
2.0 series of netostrich prior to version 2.33 which allows random
network users to bury other people's heads in the sand.  Sarge soon
contains 2.34 with the security fix, yet woody contains 2.29.1 with a
backported fix.  Then there would similarly need to be two
harden-remoteflaws; one for woody, which conflicts with netostrich
prior to 2.29.1, and one for sarge, which conflicts with netostrich
prior to 2.34.  The harden-*flaws update has to be backported along
with the backported fix to netostrich.

Now, if we want the harden-remoteflaws package to be at all useful, it
needs to be updated along with DSAs...

Hrm.  The more I think about this the more I wonder if maybe the
harden-*flaws packages make much sense in stable at all.  If someone
is apt-get'ing from security.debian.org, they're already replacing
vulnerable versions with fixed ones.  If someone is updating from a
point release CD, the same thing applies.  The only case where I can
see it making sense is with someone following testing with most of
their packages on hold (they really want a stable system, and only
upgrade a package when they need to).  Am I missing a scenario?

Re: PERL MAINTAINERS SUCK - COMPLETE MORONS

[Daniel Martin]

Matt Zimmerman <[EMAIL PROTECTED]> writes:

> Well, if someone would like to configure the MTA that runs bugs.debian.org to
> send CC's of all bug mail to another address, ...

You mean something other than signing up for debian-bugs-dist and
parsing the resulting traffic?

I realize that debian-bugs-dist isn't the same as getting the _input_
to the BTS, but if you want to maintain the same bug tracking numbers
you'll want the BTS to process the mail first in any case.

Re: Kernel Sends 7E ?

[Daniel Martin]

"Derrick (Thrawn01)" <[EMAIL PROTECTED]> writes:

> the devices running embedded Initiate a communication with the Linux
> server. Our Daemon on the Linux box responds with
> 
> a single packet containing the Transaction information. directly after that
> packet the Linux box sends a packet containing , 8 bytes,
> 
> ( in hex ) " 7E".

Are you using TCP, UDP, or some completely different protocol
entirely?  Also, can you get a network trace of the packet in
question?

One way to get such a trace is to run this command (as root) on your
linux box before starting the embedded Dos client:
   tcpdump -i eth0 -s 5000 -x > outfile.txt
(replace eth0 with the appropriate interface name) Then, after your
client runs, interrupt this with a Ctrl-C and edit outfile.txt down to
only the relevant packet.

> The Embed DOS interprets this as a response from our daemon, resulting in a
> miscommunication.
> 
> We are positive that our daemon is not sending the "7E" 's We believe that
> it's originating from the Kernel.

More details about the packet in question could at the very least
narrow this down to which part of the kernel is responsible.

Re: dwww: cat and file (pipe race condition)

[Daniel Martin]

[EMAIL PROTECTED] (Ulf Jaenicke-Roessler) writes:

>  It seems, that the problem only occurs with longer (more than 1 chars)
>  files. Looking for the cause of this problem, I found that the line
>  "$decompress $file | file -b - | magic2mime" in dwww-convert is responsible.

Well, if I do a 
$process | file -b - | magic2mime

where "$process" is anything that produces a large amount of output
slowly, then the process is killed by a SIGPIPE in short order.

If, however, I do:
$process | (file -b -; cat >/dev/null) | magic2mime
then it seems that the process runs happily (that is, no signals) to
completion.

However, this may not be what you really would want.  (Since waiting
for process to finish could cause the webserver to time out)  What
your problem may be is that somehow the cat process is not receiving
the SIGPIPE signal; I would then try to see about rewriting the dwww
script so that it does.  (I'm not sure how to do this, since the bash
manpage seems to imply that one can't change which signals are ignored 
by the shell).

You could test whether cat is ignoring the SIGPIPE signal by sending
the dangling cat process such a signal and seeing if it dies.

Re: apt-get cron job

[Daniel Martin]

Peter Cordes <[EMAIL PROTECTED]> writes:

>  I use this line in /etc/crontab on my woody system:
> 42 6* * sun root/usr/bin/apt-get update ; /usr/bin/apt-get -q -d -y 
> -u dist-upgrade ; /usr/bin/apt-get autoclean
> 

I use a similar but much more complicated method to acheive a similar
result.  My situation is that I have only a dialup line and
furthermore share the line with three other people.

First, the cron job:

0 3 * * 6-7 /usr/sbin/pppd call providerapt maxconnect 7200
0 2 * * 1-5 /usr/sbin/pppd call providerapt maxconnect 10800

That says to do downloading from 3-5 am on weekends and from 2-5 am on 
weeknights.  Then, I have in /etc/ppp/ip-up.d/providerapt the contents 
of /etc/ppp/ip-up.d/provider plus the line
   ipparam apt-get

Then finally, in /etc/ppp/ip-up.d/local_aptget I have:
#!/bin/sh
#
if echo "$PPP_IPPARAM" | grep 'apt-get'; then 
  (
http_proxy="http://localhost:80/";
export http_proxy
apt-get -y update
apt-get -y -d -f dselect-upgrade
poff
  ) > /var/local/apt-get.log 2>&1 &
fi

Actually, that isn't completely correct; I have a local web proxy
(that is, close to the other end of my ppp line, but with a fast
connection to the net) that I like to load with what I'm going to get
before I go and get it, so that makes things a bit more complicated.

I should at some point put all of my local configurations up on a web
page somewhere; I'd done that once, but got busy with other things and 
didn't keep it up to date.

Re: RBL report..

[Daniel Martin]

Nils Jeppe <[EMAIL PROTECTED]> writes:

> On Sat, 25 Mar 2000, Jason Gunthorpe wrote:
> 
> > ORBS deserves special mention because of their insane hit count, I don't
> > know what that is about but ORBS would block 10% of the mails we get. I
> > think it is without question that the majority of those blocks are
> > legitimate mails. ORBS is also almost completely inclusive of the RSS and
> > RBL.
> 
> ORBS blocks all open relays. A lot of people have open relays. Since open
> relays still do not have any reason for existence other than admin
> ignorance, the "correct" way here would be to block all open relays and
> then fix the mail servers. ORBS really cuts down on spam, the accounts I
> have protected by ORBS usually only get one type of spam: that is spam
> resent via mailing lists.

ORBS BLOCKS MORE THAN OPEN RELAYS.
Sorry to shout, but I've been bitten by ORBS before.
It blocks open relays *or machines which relay for open relays*.

This means that since my campus's smarthost trusts any machine inside
jhu.edu to send mail out (and why shouldn't it?), an open realy
anywhere on campus can cause all mail going through the smarthost to
be blocked.

To repeat: ORBS does not block only mail that came through open
relays, it blocks mail that came through servers that have in the past 
served open relays.  It allows a single open relay on a mail network
to cause the entire mail network to be blocked.  It is to my mind an
inordinately severe response to the problem.

Re: Bug#60399: crashes on installation

[Daniel Martin]

Brian May <[EMAIL PROTECTED]> writes:

> False conclusion #1: now, it seems to crash regardless of if mandb is
> running or not. ARGGHH!! However, I have left in that in the message,
> in case it gives anybody else some ideas.

I seem to remember once upon a time that man would crash and burn if
one somehow had a corrupt index.bt file.  Could it be that a partially
completed install produces such a corrupt file (i.e. could it be that
whatever mandb does in the background is rebuilding this, and being
only half-way done means the resulting file seems corrupt), and that
an existing but corrupt index file causes havoc?

I would suggest backing up all your index.bt files, rm'ing them and
then attempt installing again (this should be doable with
   tar czf index.bt.tar.gz `find /var/cache/man -name index.bt`
   rm `find /var/cache/man -name index.bt`
)

If you discover that you can make the install succeed when you have
rm'ed your index.bt files, and yet fail again when you restore
them...

Re: netstd split results in loss of functionality

[Daniel Martin]

Hamish Moffatt <[EMAIL PROTECTED]> writes:

> Hi,
> 
> Why doesn't netstd depend: on all the packages it previously included?
> When upgrading to potato, tftpd functionality is lost because the new
> netstd only suggests it. And the parameters to tftpd have changed
> and the new package does not update the inetd entry.

Speaking of which, where did netdate go?  I've been wondering for a
while what happened to it.

Re: a Chinese version of X-window system for Linux available

[Daniel Martin]

liug <[EMAIL PROTECTED]> writes:

> Dear Sir,
> I am not sure whether this is the right place to post
> this mail.
> We have developed a Chinese version of X-window system
> several years ago, and now we have developed one for
> Linux, 

> I am wondering whether our product could be integrated
> into or bundled with
> the new Debian Linux release.
> We also have some document and screen shot of our
> product.
> Please do not hesitate to contact us if we can help.
> We are looking forward to your answer.

Has anyone contacted these people, or forwarded the message on to the
Debian-Chinese people?

Re: Debian coding style?

[Daniel Martin]

[EMAIL PROTECTED] (Zygo Blaxell) writes:

>   "Why 78 characters per line of code?"  
>   "Because the laser printer wants that."
>   "Why does the laser printer want that?"  
>   "Uhhh...because IBM made a business decision in the 1950's?"

I will actually point out that although the exact number 80 is
arbitrary, the general number "about 80" is not.

The issue is that that's the number of characters/line that looks good
to the human eye - typesetters know this; open a book and count.  Too
much longer than that (say, 200 columns) and it becomes difficult when 
tracking your eye all the way back to the left to find the right row.

This is remembered vaguely from an introduction I saw once to writing
(I think) LaTeX style files, talking about classic beginner mistakes.
Short lines are good.

Of course, I suppose one could then say "but code lines that stick out
past the 80th column are mostly indentation - your eye is only
tracking back 40 characters".  Well, that's true, but the eye tracking 
issue does help to explain why a printer (designed, most likely, for
printing text that's not mostly indentation) would pick some number
near 80 as its line length

Re: Debian coding style?

[Daniel Martin]

Joseph Carter <[EMAIL PROTECTED]> writes:

> > for (int nI=0; nI<10; nI++) ...
> 
> Anybody who does that willingly must be shot.  =>

No, no; no need for violence.  Anyone who does that is already
suffering enough at their own hands and doesn't need external help.

Seeking Helmut Geyer

[Daniel Martin]

Helmut Geyer is listed as the maintainer for xxgdb and bzip - xxgdb
hasn't had a maintainer upload since when bo was frozen, and bzip's
last maintainer upload was longer ago than that.  Mail sent to his
listed address goes unanswered, but maybe that's because I only waited 
a week.  Is he still with us?

Helmut, are you out there?

This is being CC:'ed to Martin Mitchell in the vague hope that he has
contacted Helmut more recently than summer of 1997, as he did the last 
NMUs of both xxgdb and bzip.

Re: New logo strategy

[Daniel Martin]

Jules Bean <[EMAIL PROTECTED]> writes:

> On Mon, 25 Jan 1999, Steve Greenland wrote:
> 
> > On 25-Jan-99, 19:06 (CST), Wichert Akkerman <[EMAIL PROTECTED]> wrote: 
> > > I agree with James Treacy's observation that we will probably need two
> > > logos: one logo with a liberal license that people can just freely, and
> > > another, more restricted logo for things like official CD's and so.
> > > To phrase this in another way: we will have a logo that everyone can
> > > slap onto their webpage, t-shirts, posters, etc., and a logo that can be
> > > used for `official' products, like CD's made using our own iso-images.
> > 
> > Sorry, I think this is a bad idea:
> > 
> > 1. We have to agree on *two* logos :-).
> > 
> > 2. Far more importantly, it fractures the identity of the logo, which
> > is one of the major points of *having* a logo.
> > 
> > 3. It creates a first-class and second-class logo.
> 
> Nah.
> 
> A 'submission' to the contest is a pair of logos.  Linked to each
> stylistically, one of them says 'official' or something.

Or, we could have a contest to decide a basic logo and then design a
"variation on the theme" ourselves for the official logo.

Actually, I kind of liked cap'n blue eye; then again, I also liked the 
platypus more than a penguin.  Actually, hmmm - a Debian platypus...

If we are going to have a gimp.org done contest, I would like to see
that the rules allow people to use things that are not gimp, but that
are DFSG free software.  I find the command-line pnm tools very useful 
in manipulating images, and it would be nice if I could use them.  It
would also be nice if I could use xpaint, or something else that
allows me to draw simple straight lines and ellipses - freehand
drawing with the mouse is very difficult.

NMU of xxgdb

[Daniel Martin]

I've prepared an NMU of xxgdb - I believe that this fixes all
outstanding reported bugs against it.  I'm contacting you two as one
of you is the listed maintainer of xxgdb, and the other of you did the
libc6 NMU for hamm.  I'm cross-posting to debian-devel in case anyone
else had been looking at fixing up xxgdb after my last thread on it.
Unless I hear objections, I will upload it (to potato only; this
contains more new code than is healthy in a deep freeze) in a bit over
a week.

I converted it over to using debhelper, so the diff is actually quite
large for an NMU - also, I made enough changes to the actual source so 
that it no longer needs changes to X include files to compile - I
didn't quite do this as cleanly as I would have liked to, but it's a
starting point.

Of slightly more general interest, I wrote a new debhelper script to
package xxgdb - dh_installxaw.  It's basically just a modified copy of 
dh_installmenu that installs xaw-wrappers files and adds the
appropriate commands to the postinst and postrm.  It's in the debian/
subdirectory of this NMU.  (I'm also forwarding it to
[EMAIL PROTECTED])

Until I upload it to INCOMING, you can access this .deb from:
http://master.debian.org/~fizbin/

It's lintian-clean; take that for what it's worth.

Re: xxgdb should get pulled

[Daniel Martin]

"J.H.M. Dassen" <[EMAIL PROTECTED]> writes:

> On Thu, Jan 21, 1999 at 11:28:29 -0500, Daniel Martin wrote:
> > Is my only other choice for a graphical debugger the "lesstif-induced
> > segfault" ddd?
> 
> Glad to see my work is appreciated. Perhaps this is where I need to point
> you to the power of having the source? You could e.g. try fixing LessTif
> and/or DDD rather than bitch about it, fix xxgdb, package up UPS, gdbtk,
> tgdb, or deet; or (if you're not fully on the straight and narrow) use
> Motif-linked DDD binaries, or buy Motif and build a Motif-linked DDD for
> Debian, or package up KDbg, or Code Medic.

Part of the problem of having a development model in which the primary 
reward for work is ego gratification (assuming one buys all of ESR's
"Homesteading the Noosphere") is that developers tend to get
emotionally attached to their packages, much in the same way that
academics develop an emotional attachment to their theories or
results.

I have yet to learn how to navigate this area, and am often surprised
at how strongly an offhand comment is taken.  (I've discovered myself 
suddenly CC:ed in a thread on the ddd-devel list which is apparently
speculating about what this lesstif bug might be - when I get it
reproducing reliably, I'll make a real bug report)

Yes, I am grateful that DDD exists and is packaged for Debian, and
that the form it is packaged in allows me to keep one more non-free
package off my system.  Yes, I understand that maintaining a package is
difficult; the most complicated packaging I have to deal with is mixed 
Tcl and C code - I don't even want to imagine what is involved in
getting ddd, ddd-smotif and ddd-dmotif out of the same source.

Also, I appreciate the names of the other debuggers.  I'm looking
closely at Code Medic now.  (Though I'm surprised it isn't already on
the wnpp list)

xxgdb should get pulled

[Daniel Martin]

This probably isn't necessary, as I just filed an important and a
grave bug against the package, but I thought I'd declare that xxgdb
should really be pulled.  It doesn't work at al in a libc6
environment, it hasn't been uploaded by its ostensible maintainer
since bo was in frozen, and the last NMU for it was just a libc6
recompile for hamm.

In essence, it doesn't work at all - just segvio's as soon as you open 
anything.  (this is the grave bug)  Also, it fails to build from
source.  (this is the important bug)

So this is a last chance for developers who actually use xxgdb to
counter my assertion that currently it's just wasted space on the
archives.  Does _anyone_ use it?  Is my only other choice for a
graphical debugger the "lesstif-induced segfault" ddd?

Re: what's after slink

[Daniel Martin]

Ben Gertzfield <[EMAIL PROTECTED]> writes:

> > "Kenneth" == Kenneth Scharf <[EMAIL PROTECTED]> writes:
> 
> Kenneth> After you freeze slink, what will be then name of the new
> Kenneth> 'unstable' release (debian 2.2 or 3.0 that is).
> 
> I think 'woody' would be an appropriate nickname. :)

I've been wondering why this wasn't tried before; it seems such an
obvious choice.  Perhaps CD distributors don't want to advertise
"Debian woody"?

Does anyone have a script of toy story or something that would tell us 
the names of the other "characters"?  I'd like to go with that thing
that looked like binoculars with feet.

Re: Serious performance bug in Perl

[Daniel Martin at cush]

"Darren/Torin/Who Ever..." <[EMAIL PROTECTED]> writes:

> -BEGIN PGP SIGNED MESSAGE-
> 
> Daniel Martin, in an immanent manifestation of deity, wrote:
> >My... it's been a while since I was investigating perl internals
> >(writing C code that was callable from perl) - at least two years,
> >which somehow seems much longer.
> >
> >Well, I'll have my machine download the perl source tonight and see
> >what I can see...
> 
> Thanks for taking a look at this.  I won't have time to do so until
> Tuesday; it being Solstice Weekend and all.
> 
> Darren

Ok, I've looked at it.

I really don't know quite what to do with this.  On the one hand,
automatically reading the shadow password entries is desireable since
it keeps old scripts working without knowing whether shadow passwords
are being used or not.  On the other hand, doing a getspnam for every
getpw* call causes serious performance issues.

The solution, as I said before, seems to be invoking some kind of
magic on the scalar that's second in the list returned by getpw*.
(what traditionally is the encrypted password field)

Here's the problem:
Perl has various kinds of builtin magics, but all of them do highly
specialized things, such that adding a new kind of builtin magic
necessitates changes in several different places, and any new "shadow
password entry" magic type might be incompatible with future versions
of perl.  Now there are two types of magic reserved for use by
extensions, but I'm loathe to use them since it's hard to avoid name
conflicts with those magics; also, changing getpw* mucks with perl's
internal code and the docs seem to suggest that internal perl
procedures shouldn't use those types of magics.  (Admittedly, a bit of
"U"-type magic might serve as a temporary fix, and may be the best
(read: most easily implemented) solution at the moment)

Now, add to that the fact that it wouldn't be all that hard to write a 
perl module (called, say, "ShadowPasswd") that would provide
replacement getpw* functions (yes, one can replace perl builtin
functions with ones from modules), as well as proper getsp* functions, 
and could handle the magic nicely so that getspnam isn't called
unnecessarily through a tied scalar.  (I am aware of the "Shadow"
module written for 5.003 that provides some small interface to getsp*
- this would do more)  This really seems the cleanest solution, and
may indeed be easier to implement than the U-magic method.  (Note that 
with this, it would even be possible to create a shadow-aware
setpwent; I still need to think out the details and implications of
that, though)

The only problem now is that scripts would have to say "use
ShadowPasswd;" or they wouldn't have shadow password support - this
could potentially break many scripts.  So, some might say that the
solution is to have getpw* autoload the ShadowPasswd module; if I
could figure out how to do this, I'd say that this is the solution we
should shoot for.  Unfortunately, I got lost somewhere in the perl
source code and couldn't find my way to how that might be done.

Also, is the Cc: list on this mail too broad?  Should someone else be
getting these messages too?  Should this be taken off debian-devel?

DANIEL


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

Re: Serious performance bug in Perl

[Daniel Martin at cush]

Ben Gertzfield <[EMAIL PROTECTED]> writes:

> >>>>> "Daniel" == Daniel Martin at cush <[EMAIL PROTECTED]> writes:
> 
> Daniel> It's a perl thing.  I can almost guarantee it.  The
> Daniel> problem is perl's shadow password support and it's getpw*
> Daniel> functions.  Whenever these functions are called (and
> Daniel> assigned to a variable; if you just call them and discard
> Daniel> the value immediately this doesn't happen), perl attempts
> Daniel> to look up the shadow password entry associated with the
> Daniel> given struct passwd *, and this takes a while - especially
> Daniel> since the /etc/shadow file is closed immediately after
> Daniel> each fetch. 
> 
> This is probably because the patch that allows Debian's Perl to
> use getspnam() and friends is pretty new and untested.
> 
> Is there any way you can look at
> http://www.rosat.mpe-garching.mpg.de/mailing-lists/perl-porters/1998-03/msg01574.html
> and see if the patch there can be made better?
> 
> Let's try to fix this problem.

My... it's been a while since I was investigating perl internals
(writing C code that was callable from perl) - at least two years,
which somehow seems much longer.

Well, I'll have my machine download the perl source tonight and see
what I can see...


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

Re: Serious performance bug in Perl

[Daniel Martin at cush]

Chris Fearnley <[EMAIL PROTECTED]> writes:

> On Thu, Jun 18, 1998 at 12:38:45PM -0500, Richard Kaszeta wrote:
> > Christopher J. Fearnley writes ("Re: Serious performance bug in Perl"):
> > >to call it (instead of the default perl - 5.004.04-6).  Performance
> > >improved several hundred-fold.  So I believe the problem is either in
> > >perl or libc6.
> > >
> > >Any suggestions on how to resolve this?  As I said before the slowdown
> > >seems to occur in the get_current_uids subroutine (and possible
> > >get_current_gids).  Which has a loop on getpwent (and getgrent).
> > >
> > >Can anyone else duplicate this behavior?
> > 
> > I can duplicate this behavior.  Performance gets exponentially better
> > if I move my NIS password records into the local password file.  So in
> > my case I am tempted to blame libc6's NIS performance (which in other
> > circumstances I have found to be rather slow anyways)
> > 
> > Are you running NIS?
> > 
> > -- 
> > Richard W Kaszeta   Graduate Student/Sysadmin
> > [EMAIL PROTECTED]   University of MN, ME Dept
> > http://www.menet.umn.edu/~kaszeta

It's a perl thing.  I can almost guarantee it.  The problem is perl's
shadow password support and it's getpw* functions.  Whenever these
functions are called (and assigned to a variable; if you just call
them and discard the value immediately this doesn't happen), perl
attempts to look up the shadow password entry associated with the
given struct passwd *, and this takes a while - especially since the
/etc/shadow file is closed immediately after each fetch.  (Which could 
be because perl is doing something like a getspnam call each time - of 
course, since it's doing these getspnam calls in order, one might think
that perhaps libc6 should be smart enough to not close and re-open
/etc/shadow each time, but maybe perl surrounds the getspnam calls
with setspent() and endspent() calls or somesuch for security
reasons).

This clearly seems to be a case that calls for a bit of magic (as in
magic variables that invoke arbitrary code each time they're
referenced) - the second element of the list returned by getpw* should
be a magic scalar, which is looked up only when asked for.  Could be
an idea that gets forwarded upstream.

In any case, at the moment you should be able to speed adduser up
considerably by modifying the get_current_uids routine as follows:

sub get_current_uids {
my(@uids, $uid);
my($olduid);
$olduid = $<;
$< = $>;
$> = ((getpwnam "nobody")[2]);
setpwent;
push @uids, $uid while defined($uid = (getpwent)[2]);
endpwent;
$> = $<;
$< = $olduid;
@uids;
}

(This should work even if adduser is made an suid script executable by
only a certain group)

This still causes (you can see with an strace) many attempts to open
/etc/shadow, but they're all denied so the whole process is much faster.

For what it's worth, I made libc5 and libc6 C programs that just
called getpwent or getspent repeatedly - both blazed through my 1000
user passwd and shadow files in well under 0.05 sec each, though the
libc5 one was about twice as fast on getpwent and the libc6 one was
about twice fast on getspent.  Go figure.


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

Re: Packages marked as Obsolete

[Daniel Martin at cush]

Matthias Klose <[EMAIL PROTECTED]> writes:

> >  *** x11  Opt tkdesk   1.0b4-2.1   
> 
> this package could use blt8.0-unoff

Actually, it can't, but that's because other bits of tkdesk are
incompatible with tcl/tk 8.0.  As the upstream source of tkdesk comes
with its own blt, that's getting used.

There'll be a package of this in incoming certainly before the end of
the week, hopefully tomorrow.


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

Re: source packages and censorship

[Daniel Martin at cush]

Raul Miller <[EMAIL PROTECTED]> writes:

> Daniel Martin at cush <[EMAIL PROTECTED]> wrote:
> > What about a pine-installer package?
> > 
> > This would be similar to the netscape3 and netscape4 packages of old - 
> > the user would be asked in the preinst to put the pine .orig.tar.gz,
> > the .diff.gz and the .dsc files into /tmp (or $TMPDIR); if those files 
> > weren't there the preinst would bomb out, aborting installation.
> 
> We didn't have the right to distribute the netscape3 and netscape4
> packages.  We do have the rights to distribute qmail and pine sources.
> 
> I don't think it's wise (good for the people who use debian) to discard
> that ability (which we currently have).

I don't quite understand what ability it is that you think would be
discarded.  The ability to distribute everything needed to compile and 
install pine all at once?  I don't see how this would not be
accomplished by a pine-installer that asked to optionally download the 
required files.  Or are you perhaps imagining the creation of some
non-official Debian CD that would have the pine-src package on it - it 
shouldn't be too hard to program in a few alternative locations for
the pine installer to look in before deciding that it should download
the programs, and it could always ask the user for an alternative
location before deciding to do the download.  (the dangers of
attempting to guess the source tree by looking at dpkg internals
aside)

Is there some kind of "pride in Debian" issue that makes it desireable
to put everything needed for pine into .debs, or is there some hidden
benefit I'm not seeing to a pine-src package that a pine-installer
doesn't provide?

Let me lay out my opinion of the differences of the effects of the two
methods:

Method pine-src:
---
- the user who hasn't discovered debian-user or ftp.debian.org, but
just has an official CD (and barring some unexpected marketing,
official Debian CDs will be much more numerous than CDs mixing in
non-free stuff) will conclude that pine isn't available for Debian.
- the user on a high-enough speed connection to be using dselect's ftp
method will see "pine-src" in the menu and conclude that that's what
they need to install pine.
- the pine-src package will be a huge thing to download each time a
new pine .diff.gz is released.  (the "three .debs" way seems
incredibly convoluted, especially when a pine-installer can do the
whole thing in a much cleaner fashion)
- various people will get very upset about having the pine source
twice on debian mirrors - a bit superfluous, no?

Method pine-installer:
--
- the user with an official CD will see the "pine-installer" package
and will conclude correctly that pine has been packaged for Debian but 
that 
- the user on a high-enough speed connection to be using dselect's ftp
method will see "pine-installer" or somesuch in the menu, note the
description and choose to install it.  Since the description will have 
said "this package will go fetch the pine source package if it's not
already avaliable", the user will not be surprised when prompted with:
  Pine source not found; enter the location of the file
  pine_3.96L-*.dsc or press enter to get the latest version from
  ftp.debian.org []
(if the pine-installer is daring enough to parse
/var/lib/dpkg/methods/ftp/vars this could be the ftp site the user had 
been using)
- The pine package won't get updated each time a new .diff.gz comes
out, unless a new pine-installer package also comes out.  This is a
slight inconvenience to the pine-installer maintainer.

I don't think that the ability of a user to install pine using no
knowledge other than that obtained by running dselect off the official
CD should be discarded.  I really think that getting pine-something
into contrib (and therefore onto the Official CD) is an important
goal, if having pine around is an improtant ease-of-use issue.

Hmmm... what if the pine installer package contained the .diff.gz and
.dsc files?  This might still be an inconvenience to the
pine-installer maintainer, but not much; I _think_ that the pine
license allows the distribution of DFSG-free patch files, but this
would also be something to look at.  (I mean, I know that the license
allow the redistribution of patchfiles, but does it allow someone to
take code found in a patchfile and use it elsewhere?  I think not,
which would make the .diff.gz non-free, wouldn't it?)  If including
the .diff.gz forces the installer into non-free, then there's no point 
in doing it that way.


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

Re: source packages and censorship

[Daniel Martin at cush]

I think someone already proposed this idea, and it was immediately
ignored, so I'm going to suggest it again:
What about a pine-installer package?

This would be similar to the netscape3 and netscape4 packages of old - 
the user would be asked in the preinst to put the pine .orig.tar.gz,
the .diff.gz and the .dsc files into /tmp (or $TMPDIR); if those files 
weren't there the preinst would bomb out, aborting installation.  (the 
documentation displayed in dselect would have to mention this too).

The postinst would then do the unpacking and compiling in an
appropriate subdir. of /usr/src and tell the user (who may have never
used dpkg outside of dselect) how to run "dpkg -i". (or do the
unpacking only, and tell the user how to do the compiling, etc.)

I think people should look at this solution more closely; not only
does it mitigate the concerns of the "my god we can't have source in
binary package form" crowd, but the resulting package could be placed
in _contrib_, instead of being non-free like the pine-src package
would have to be.  Then, someone who just got the Debian CD and
entered dselect would find "pine-*" on the list of packages, and
wouldn't have to go out wandering the net to find out how to get pine; 
the package would say "go download the source from " in the
preinst when they tried to install it.  This would improve the ability 
for the naive user to install pine more than a pine-src package that
the user could only find by going to the ftp site.  The less the user
needs to search to figure out what to do, the better.

I suggest that a pine-installer package is a superior solution from
both the "make source .debs for non-free packages" point of view and
from the "source .debs over my dead body" point of view.


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

Re: bzip2 for source packages?

[Daniel Martin at cush]

James Troup <[EMAIL PROTECTED]> writes:

> Michael Alan Dorman <[EMAIL PROTECTED]> writes:
> 
> > Might I suggest that using it for source packaging would be
> > appropriate, though?
> 
I seem to remember that there was some legal problem with using bzip2
in the US - software patent, that sort of thing.  Is this true is it
just FUD?


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

Re: New fvwm95 into unstable

[Daniel Martin at cush]

Manoj Srivastava <[EMAIL PROTECTED]> writes:


>   Personally, I am inclined to think that if your release fixed
>  bugs, and introduced not too many new features, it should go
>  into frozen.


And now it's just done that - 2.0.43b-4 is in incoming heading for
frozen, but you probably saw that on debian-devel-changes.


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

Re: New fvwm95 into unstable

[Daniel Martin at cush]

Manoj Srivastava <[EMAIL PROTECTED]> writes:

> Hi,
> >>"Daniel" == Daniel Martin at cush <[EMAIL PROTECTED]> writes:
> 
> Daniel> I'd also recommend that people upgrading directly from bo
> Daniel> upgrade to this package instead of the one in frozen, as this
> Daniel> package's preinst cleans up the old bo config. files (the name
> Daniel> of the config. files changed), but only if it can determine
> Daniel> that they're unmodified, which can only happen if the
> Daniel> previously installed version was the bo one.
> 
>   Unfortunately, that is not an option for many people, Think
>  CD-ROM. Why can't this improvement be made to frozen as well? (just
>  the preinst, not any upstream changes?)

Well...
hmm.
I suppose I could package up an fvwm95 whose only difference over the
version currently in frozen would be the enhanced preinst.  What I'd
really like is to put the -3 fvwm95 that I just uploaded into frozen;
however, I'm loathe to put anything into frozen as a new developer
unless I have some kind of consensus behind me - when I posted near
the end of last week to debian-private and then debian-devel about
whether I could put -3 into frozen, I got no response and took this
to mean I had no consensus backing me.

I suppose I should also point out at some point that making this
change is not as simple as using the -3 preinst in the current -2
package, since the configuration file name changed from
system.fvwm95rc-menu in -2 to system.fvwm95rc in -3 due to other
improvements.  Not that it still wouldn't be easy to make a preinst
that does the right thing, it's still not just trivial.

That said, however, I'm amenable to doing something like this, because 
I dislike the idea of leaving people who get hamm off CDs or who don't
follow -changes lists with obsolete files on their system.

Now, what's most desirable in this case?
1) Upload a new fvwm95_2.0.43b-3 that is essentially the same as
fvwm95_2.0.43b-2 but with the "Distribution: " header set to frozen
and a better preinst?  Would this wipe out the fvwm95_2.0.43b-3 in
slink, or would something be left in a screwed state?

2) Petition someone to have the -3 fvwm95 moved into frozen?  (Again,
this is my preferred course of action, but I'm treading on uncertain
ground)

3) Create a fvwm95_2.0.43b-4 that is essentailly -2 with a better
preinst and "Distribution: frozen", and a -5 with 
"Distribution: unstable" that is essentially identical to the
currently existing fvwm95_2.0.43b-3?

(For those of you following at home who don't understand why
fvwm95_2.0.43b-3 wasn't put into frozen in the first place, let me
attempt to explain by saying that -3 as compared to -2 has a patch
which closes some annoying bugs and allows the configuration to be
reworked - -3 handles configuration files the way fvwm2 does, which is
completely different from (and much saner than) the old (<= 2.0.43b-2)
way of handling fvwm95 configuration.  This change could be considered
as large as an upstream change introducing new features, and even
though I've tested it and it runs fine on my system, I still didn't
want to put it into frozen because of this.)


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

What exactly belongs in frozen?

[Daniel Martin at cush]

I had originally posted this to debian-private, but in the interest of 
getting more feedback (and timely feedback, since if this is going
into frozen it needs to go *soon*) I'm re-posting it here.  (It
probably belongs here anyway, as it's not really a closed
maintainers-only issue, but more of a "how debian works" issue).

What exactly determines if a new version of a package should go into
frozen or unstable?  All I've heard is "bug fixes in frozen;
everything else in unstable".

Actually, though I guess I'd appreciate answers to the general
question, what I'd really like is an answer for my specific case:
I'm a new Debian maintainer and have just taken over fvwm95.  I have
packaged up a new version but have not uploaded it because I can't
decide if it's frozen or unstable:

The main change in this package was that a long-standing "feature" of
the upstream source has been fixed (I actually had done this about a
week before bug 20866 came in, but it's essentially the same code
change) so that Read statements can be used sanely in the
configuration files.  As a natural improvement, the configuration 
has now been made to resemble that of fvwm2 extremely closely. (with
.hook files all over the place)

Points for putting it into unstable:
 * this package does the configuration of fvwm95 completely
   differently from before; this may be considered a new feature.

 * this is by a new maintainer who re-wrote all the control scripts
   (from skeletons, but still) himself

Points for putting it in frozen:
 * this package closes several (well, three) bugs related to
   workarounds for the Read problem.

 * the old style of configuring fvwm95 was so kludgy and allowed
   for so little user customization that it could have been
   considered a reasonably important bug.  (The fvwm95 configuration
   was the single thing I thought RedHat 5 did hands-down better than
   Debian 1.3.1)

 * the name of the config. files changed between fvwm95 2.0.42a (the
   version in bo) and fvwm95 2.0.43b (the current version).  The
   package currently in frozen (2.0.43b-2) makes no allowances for
   this change of names; my new (2.0.43b-3) does - however, if people
   upgrade first to (2.0.43b-2) and then to (2.0.43b-3) configuration
   files that weren't modified won't automatically get switched to the 
   new names.  That is, upgrading to my new version after upgrading
   from bo to 2.0.43b-2 leaves certain old config. files (named
   /etc/X11/fvwm95/*fvwm2rc95) on one's system, even if one hasn't
   changed a thing.  On the other hand, if the system config. files
   were never touched, upgrading directly from bo to my version clears 
   out the old files.  This makes my version preferable over the
   version currently in frozen for people upgrading directly from bo.

 * This isn't new upstream source. (than the version currently in
   frozen)

I'd like to see this in frozen, just because it irks me to have RedHat 
be vastly superior to official Debian on any point.


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