The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Interesting dpkg issue, plus thoughts...

On Sat, 12 Jul 1997, Bruce Perens wrote:

> From: Dale Scheetz <dwarf@polaris.net>
> > Klee says that a bug exists, not that this problem is that bug.
> 
> His discription was that the program used getlogin() to find the user name,
> and would fail in the way you described if there was no utmp entry present.

My first question would be, "Why isn't the utmp entry persent? It was on
the old system (assuming this is what is at fault).

Isn't this lack of a utmp entry going to "break" every program that uses
getlogin()?

I understand that Klee has choices of how to do this, but I see his fix as
a "work around" to the utmp problem.

> He said he would modify it to fall back on getuid().
> 
> > The fact that the same version of dpkg works on one system and fails on a
> > different system, strongly suggests that some other package...perl,
> > bash, something else...has changed its functionality in such a way as to
> > cause the dpkg script to fail.
> 
> There are many ways to exercise this bug. Probably running "script" would
> do it, because there would be no utmp entry for the pseudo-tty. Running in
> a mixed libc5 and libc6 environment might well do it, because it corrupts
> utmp with some versions of libc6. Running under kernel 2.1.43 seems to do
> it on my system sometimes, because 2.1.43 has broken the filesystem slightly.
> 
> > I thought that it was perfectly clear from the information that I
> > presented about this behavior that it wasn't a dpkg bug. That was the
> > premise of the rest of my discussion.
> 
> I understood your premise, but your premise was wrong. :-)
> 
It certainly wouldn't be the first time ;-) Actually I am willing to admit
that my example may actually be a bug in dpkg, but, even so, I don't see
that my premis is wrong. My premis is that we should stop trying to wiggle
out of the current Source Package Format simply because it doesn't work
the first time you try it. We should, certainly, be fixing bugs in dpkg
and it's friends, but not just because the framework doesn't suit a given
programming style. I find all the files that debmake wants to put into the
debian directory to be a clutter that hides the files I expect to find
there. I, personally, liked what the restriction of files in this
directory provided. That, however, is a personal issue. What concerns me
most about the current attitudes of some is the idea that dpkg is so
broken that we need to throw it away (and the Source Package Format with
it) and start over from scratch.

Waiting is,

Dwarf
-- 
_-_-_-_-_-_-                                          _-_-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (904) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

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


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .