Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying

[Buddha Buck]

Raul Miller wrote:
On Wed, May 21, 2003 at 09:57:13PM +1200, Nick Phillips wrote:
 

I don't believe that it's acceptable for an otherwise beaten option
to win due the the otherwise winning option being discarded due
to a quorum requirement, as John suggests might happen.
   

Under the proposed system, we would do exactly the same thing for otherise
winning options being discarded due to a supermajority requirement.
What makes this behavior acceptable for supermajority requirements and
unacceptable for quorum requirements?
To my knowledge, the only issue here is that other voting systems [for
example, those indicated by Roget's Rules of Order] have defined quorum
in terms of number of voters present and do not collect votes if quorum
is not met
I've not been following this thread too closely (between trying to get 
work done, trying to get plants into the ground, and trying to spend 
time with my SO, I've been too busy to pay close attention to Debian 
politics), but I've two questions:

1) Has anyone developed standard terminology for:
 a) The proposed amendment to the Debian Constitution formally offered 
by Manoj
 b) The proposed amendment to (a) above as offered by John

2) Would an amendment to (a) to the following effect be acceptable and 
clear up nomenclature issues:

Replace A.6.2-4 in the proposed amendment with:
2.  Procedural Definitions
a. V(A,B): For any options A and B, V(A,B) is defined as the number
of ballots cast that rank option A higher than option B
b. margin of A over B: The margin of A over B M(A,B) = V(A,B)-V(B,A)
Note that M(A,B) = -M(B,A)
c. defeats: For any options A and B, A defeats B if and
 only if M(A,B) > 0
d.  Acceptable:  An option A other than the default option is
 considered "acceptable" if and only if M(A,default) >= R, where
 R is the "quorum requirement" for the vote.
e. Superacceptable: An option A with a supermajority
requirement of N:M is considered superacceptable if and only if
M*V(A,default) > N:V(default,A).
f.  Pairwise defeat:  A pairwise defeat is an ordered pair of
 options (A, B) where A defeats B.
g.  "weaker" A pairwise defeat (A,B) is considered weaker than
 pairwise defeat (C,D) if V(A,B) < V(C,D)
3. Dropped options
a. Any non-default option A which is not acceptable is dropped
b. Any option A with a supermajority requirement which is not
superacceptable is dropped.
4. Create a list of all pairwise defeats (A,B), where neither A nor B 
are dropped, sorted by V(A,B).

with related changes elsewhere to use these definition.

Re: bugs + rant + constructive criticism (long)

[Buddha Buck]

Lars Wirzenius said:
> There isn't even any need to put anything in the headers. From
> Debian Developer's Reference, section 4.1 Mailing lists:
> 
> When replying to messages on the mailing list, please do not send
> a carbon copy (CC) to the original poster unless they explicitly
> request to be copied. Anyone who posts to a mailing list should read
> it to see the responses.
> 
> Eray routinely ignores this. It's one more indication that he's not
> mature enough to be a developer.

A lot of people ignore it, if the CC:s I've gotten over the years are 
any indication.  I don't mind getting CC:'s myself, but it does get odd 
when I continue to receive CC:s after thread drift.
 
-- 
 Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: dueling banjos

[Buddha Buck]

At 01:18 PM 12-26-2000 -0800, Ben Gertzfield wrote:
> "Kim" == Kim Richards <[EMAIL PROTECTED]> writes:
Kim> could you please mail me sheet music for dueling banjos
This is about the third or fourth time we've gotten this request.
Does anyone know why? :) (Here's an earlier one I found.)
I just did a Google search on "duelling banjos debian" and came up with 
nothing -- just two hits to our archives from the "dualling banjos" thread 
that happened one of the previous times we got this strange request.

Re: NSA's Secure Linux Distribution

[Buddha Buck]

At 04:38 PM 12-22-2000 -0500, Jacob Kuntz wrote:
from the secret journal of Brent Fulgham ([EMAIL PROTECTED]):
> No doubt most of you have seen the NSA's secure linux posting
> on Slashdot this morning.
>
> Looking at:
> http://www.nsa.gov/selinux/docs.html
>
> there appears to be several utilities that have been updated
> to provide enhanced security.
>
> Should we be merging these patches into Debian, assuming they
> appear to be compatible with our policy, etc.?
>
unless we have a policy against security, it should be fine. :) it's all
gpl.
I'd take a close look at what they did before deciding to integrate their 
patches in.

The goals of the NSA in doing this may not be suitable for Debian.  I'm not 
talking about paranoia concerning the NSA putting back-doors into 
everything; I'm taking as given that they are being honest and upfront 
about what they are doing and why.  But...

Here is a quote from their "overview" page 
(http://www.nsa.gov/selinux/index.html):

Security-enhanced Linux is not an attempt to correct any flaws that may 
currently exist in Linux. Instead, it is simply an example of how 
mandatory access controls that can confine the actions of any process, 
including a superuser process, can be added into Linux. The focus of this 
work has not been on system assurance or other security features such as 
security auditing, although these elements are also important for a secure 
system.
In addition, while they provide 15 new or modified system utilities, they 
also provide 36 new system-calls, and require a custom kernel to handle the 
system.

On their to-do list are the following items:
Port the kernel patches to the latest 2.2 kernel
Port the kernel patches to the 2.4.0 kernel
Port the utility patches to the latest versions of the base utilities
so I'm not even sure we -could- apply their patches, even if we wanted to.

--
jacob kuntz
[EMAIL PROTECTED]
underworld.net/~jake
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian and KDE: Appology

[Buddha Buck]

At 10:14 AM 9/8/00 -0400, Michael Alan Dorman wrote:
Paul Seelig <[EMAIL PROTECTED]> writes:
> But RMS speaking like *this* is rather unappropriate and IMHO quite
> insulting.  I wonder if the author of ncftp who was hurting the GPL by
> using readline and who subsequently put ncftp under GPL as consequence
> of complaints was asked to beg for being forgiven as well?  I guess
> not, it was just retroactively considered legal, right?  Is this then
> just treatment of the KDE developers?  Definitely not!
The situation does differ somewhat: ncftp's violations were resolved
by actions taken by ncftp's author.  KDE's violations were resolved by
actions taken by Troll Tech, _not_ actions taken by KDE developers.
In addition, when it was pointed out to ncftp's author, he acknowledged the 
issue and resolved it.  When it was pointed out to KDE, they denied that 
there was a problem (and -still- deny that there was a problem).

So whether you think the request for an apology is appropriate or not,
using the events surrounding ncftp as a basis for saying RMS is
applying a double standard is dubious, because the resolutions came
about through very different means.
And the actions of the FSF in both cases is identical:  when the issue was 
resolved, the FSF dropped any potential legal claim against the violators 
they may have had.  That action in both cases is consistent with the FSF's 
stated goals, and RMS's stated ethical position.


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

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

Re: Problems with mail system? [Fwd: Returned mail: User unknown]

[Buddha Buck]

> On Wed, Sep 06, 2000 at 09:58:49PM -0500, Branden Robinson wrote:
> > On Thu, Sep 07, 2000 at 01:08:17PM +1100, Timshel Knoll wrote:
> > > <<< 550 mail from :::216.250.196.10 rejected: administrative 
> > > prohibition (failed to find host name from IP address)
> > > 
> > > Is there any way to get this fixed?
> > 
> > No.  The MTA at the destination host is trying to tell you that dialup
> > trash like yourself isn't welcome on *THEIR* Internet, under the reasoning
> > that they're stopping spammers by refusing connections from machines with
> > characteristics like yours (dynamically assigned IP, perhaps, or simply no
> > reverse DNS record), and that any legitimate non-spam traffic is too
> > inconvenient to deal with.
> 
> We know your opinions on the DUL, Branden, but that's not what the error
> says.
> 
> It says, in plain English, "failed to find host name from IP address".

It says in plain English, "administrative prohibition (failed to fine 
host name from IP address)"

Perhaps it's from being too geeky myself, but Branden's explanation 
(the recipient of the error message is not welcome on *THEIR* Internet 
under the reasoning that they're ... refusing connections from machines 
with characteristics like [his] (...simply no reverse DNS record)) 
sounds like a fairly direct and accurate translation of "admisitrative 
prohibition (failed to find host name from IP address)".

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

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



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

Re: ITP lame

[Buddha Buck]

At 07:40 PM 9/5/00 +0200, Bart Schuller wrote:
What frustrates me is that there's software that's
- useful
- free
- legal (at least for quite a few millions of people)
but not officially available for Debian.
I understand fully that using the name "non-US" for patent-encumbered
software is wrong. However, the machine pandora.debian.org is in an
excellent position to also host a "non-Software-Patents" section of the
archive, which can again be subdivided in main, contrib and non-free.
If we do that, I suggest that "non-Software-Patents" is a bad 
name.  Perhaps "patented" is a better name.

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

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

Re: imap mailbox killer

[Buddha Buck]

At 08:21 AM 8/31/00 -0400, Richard A Nelson wrote:
On Thu, 31 Aug 2000, Juhapekka Tolvanen wrote:
>
> There might be bug in either Pine or IMAP(D) or both.
Both... I had to manually delete several messages in Pine 4.21 folders
and I don't use IMAP
I don't use pine or imap, but the school hosting my mailbox uses imap.
The behavior I saw:
Using POP to copy new mail to my workstation at work (running Eudora) 
seemed to cause ipop3d to crash without properly cleaning up -- $MAIL.lock 
still around, messages not marked as old, etc.  Telnetting in, and mucking 
around in $MAIL by hand revealed the messages preceeded by nulls.  Elm read 
the mailbox fine, but treated the messages preceeded by nulls as 
continuations of the previous messages.  Eudora, getting the messages from 
POP3, also read the messages fine, but again with the broken messages 
tacked on to the preceeding messages.  Manually deleting the nulls wasn't a 
reliable way to fix the problem.

My school uses imap, but I didn't -directly- invoke it in this process.  It 
may have been invoked by their mailer behind the scenes, though.

Re: imap mailbox killer

[Buddha Buck]

> Package: imap
> Version: 4.7c-1
> Severity: important
> 
> On Thu 31 Aug 2000, Paul Slootman wrote:
> 
> > Yuck. Smells like a serious buffer overflow somewhere.
> 
> Upon a quick glance, there indeed appears to be no checks at all
> for buffer overflows. A buf of 8k is allocated into which the
> From:, Status:, X-Status, and X-Keywords: headers are placed,
> with simple 
> 
>   sprintf (buf + strlen (buf),"...
> 
> commands. So having extremely long X-Keywords in mail messages
> will screw things up. Double yuck.
> 
> This is in imap-4.7c/src/osdep/unix/unix.c BTW.
> 
> See the original message and the accompanying thread in debian-devel,
> archive/latest/67244 , Message-ID <[EMAIL PROTECTED]> from
> Cristian Ionescu-Idbohrn <[EMAIL PROTECTED]>

This definately needs to be passed upstream...  My mailbox was screwed 
up as well, and I get my mail from a Solaris box, not a Debian one.

> 
> 
> Paul Slootman
> -- 
> home:   [EMAIL PROTECTED] http://www.wurtel.demon.nl/
> work:   [EMAIL PROTECTED]   http://www.murphy.nl/
> debian: [EMAIL PROTECTED]  http://www.debian.org/
> isdn4linux: [EMAIL PROTECTED]   http://www.isdn4linux.de/
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

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

Re: How many CDs in potato?

[Buddha Buck]

At 01:52 PM 8/15/00 -0700, Steve Bowman wrote:
On Tue, Aug 15, 2000 at 01:01:49PM -0400, Peter S Galbraith wrote:
>
> [snip]
>
> The strange part is that _some_ contrib packages are scattered
> across the 3 CDs, but not all of the packages.  For example, lyx
> is _not_ there.  Only 83 packages are included:
I think you'll find that the ones that are missing depend on non-free.
Lyx for example depends on libforms0.89 .  Apt is used by debian-cd to
set up the build and apt doesn't like broken dependencies.
Why would a package be in contrib if it didn't depend on non-free?  I 
thought that that was the current definition of contrib: DFSG-free, but 
requires something from outside of main (e.g., contrib or non-free).


Steve
--
Steve Bowman  <[EMAIL PROTECTED]> (preferred)
Buckeye, AZ   <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
  
Powered by Debian GNU/Linux 
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: seeking new maintainer: lilo

[Buddha Buck]

--On Saturday, January 30, 1999, 12:35 AM +0100 "Bernd Eckenfels"
<[EMAIL PROTECTED]> wrote: 

> Hello,
> 
> who would liek to take the lilo package over?

I might, but I have a couple of questions/concerns...

I am not registerred as a developer.  If that is an immediate show-stopper,
then so be it.  I want to be a developer, but I haven't yet crossed the i's
and dotted the t's.

Since I have no experience with maintaining a package, would lilo be a good
one to start with?  I know that if I blow it, I might seriously hose many
other people's machines, but I don't expect that to happen.  (The -first-
machine I would hose would be my own, so...)

> 
> There are a few pending bugs, most of the dealing with the lack of an
> intelligent install script (which should be included in the bootfloppies,
> too).
> 
> Greetings
> Bernd

What hack in ld.so?

[Buddha Buck]

In the thread on -rpath that is currently taking place on the 
debian-devel mailing list (quick summary:  Debian developers say that 
-rpath should -not- be the default on Linux systems; libtool developers 
say that -rpath should be the default on all systems), Alexandre Oliva 
has repeatedly referred to an "incomplete hack" on the ld.so, either on 
linux systems or on Debian systems.

I would appreciate it if he would explain in detail what this hack is 
supposed to be.

>From what he describes, it sounds like he thinks that the linker was 
modified to special-case the libc5/libc6 transition, to allow us to 
move old libraries that depended on libc5 into a special directory, and 
replace them with libraries that depended on libc6.  He thinks the 
behavior is something like this:

program foo depends on libfoo and libc6.  ld.so searches /usr/lib for a 
compatable libfoo, and find it.  It then loads /usr/lib/libfoo and 
/lib/libc6 into memory.

program bar, on the otherhand, depends on libfoo and libc5.  Instead of 
searching /usr/lib, ld.so recognises that bar was linked with libc5, 
and so special-case searches /usr/lib/libc5-compat -first-, before 
searching /usr/lib.  Finding a libfoo in /usr/lib/libc5-compat, it 
links that in.  It does not search /usr/lib at all then, and thus does 
not link in the libc6 version of libfoo

This breaks in the presence of -rpath, because rpath tells it to use 
/usr/lib/libfoo, and that overrides the hacked special case libc5 for 
programs.

This is not how I understand how the ld.so linker works on Linux 
systems.  My understanding is that it caches the locations of all known 
versions of the libraries, and makes an intelligent decision as to 
which version to load.  I think that it handles foo and bar above like 
so:

program foo depends on libfoo and libc6.  ld.so checks its cache, and 
finds /usr/lib/libfoo (which in turn depends on libc6), and 
/usr/lib/libc5-compat/libfoo (which in turn depends on libc5).  Faced 
with both possible libraries, it decides that loading /usr/lib/libfoo 
is a better choice than /usr/lib/libc5-compat/libfoo.  I'm not sure 
offhand why it decides so -- does it know that libc5 and libc6 are 
incompatable versions of the same library (different sonames), or does 
it feel that loading two libraries (libfoo, libc6) is better than 
loading three (libfoo, libc5, libc6).

program bar, on the otherhand, depends on libfoo and libc5.  again, 
ld.so checks its cache, and again finds /usr/lib/libfoo and 
/usr/lib/libc5-compat/libfoo, Faced with a similar decision as last 
time, it again chooses, this time feeling /usr/lib/libc5-compat/libfoo 
is a better choice.

This breaks in the presense of -rpath, because with rpath, bar is not 
dependent on libfoo, but on /usr/lib/libfoo.
-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: Call for mascot! :-)

[Buddha Buck]

> "Edward John M. Brocklesby" <[EMAIL PROTECTED]> writes:
> 
> > I don't think so - Octopi can't fly!
> 
> Someone who obviously hasn't read RFC 1925...

RFC1925 asserts that under appropriate circumstances, -pigs- can fly.  
It makes no comment on the aerodynamic properties of cephalopods.
 
> -- 
> James
> "Never trust trucks"



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

Re: DFSG v2 Draft #5

[Buddha Buck]

> -BEGIN PGP SIGNED MESSAGE-
> 
> 
> On 25-Jan-99 Buddha Buck wrote:
> > I have two comments...
> > 
> >> 3.2. Misrepresentation of Authors 
> >> --
> > ...
> >> 3.6.2. Versioning and Renaming 
> >> ---
> > 
> > Are these two clauses redundant?  And should 3.6.2 be interpreted to 
> > extend to other identifiers besides name or number (such as icon used 
> > in a GUI to identify the software, or a logo affiliated with the 
> > software)?
> No, the first refers to using the author's name (such as Buddha Buck or Darren
> Benham).  The second refers to the name of the software it's self (grep or
> sendmail).

I should have seen that... What confused me about 3.2 was the mention 
of "trademarks" in connection with what may be restricted.

OK, then what about my second question about those parts...

Should other identifiers, like icons or logos affiliated with a 
software, be able to be restricted in the same way as names?

I can write a DFSG-compliant license that says "If you distribute 
derived works of the WidgetFactory game, they must not be named 
'WidgetFactory'."  That is allowed by 3.6.2.  Could I go farther to say 
in addition "...and they must be modified to use a different logo that 
those included in the WidgetFactory*.xpm source files."  The purpose is 
the same as requiring a name-change: to protect the integrity of the 
"original" software.


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

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

Re: DFSG v2 Draft #5

[Buddha Buck]

I have two comments...

> 3.2. Misrepresentation of Authors 
> --
> 
>  The license may restrict the use of names and trademarks of the
>  copyright holders in association with modifications of the original
>  software.
> 
>  
> 
>the copyright holders even to promote something derived from the
>  original software>
...
> 3.6.2. Versioning and Renaming 
> ---
> 
>  Modified software may be required to use a version number or name
>  different than the official release.
> 

Are these two clauses redundant?  And should 3.6.2 be interpreted to 
extend to other identifiers besides name or number (such as icon used 
in a GUI to identify the software, or a logo affiliated with the 
software)?

Second...


[EMAIL PROTECTED] said:
> 3.3. License of Derived Works  --
...
>  The license may also require the license of modified and derived
>  software be restricted to the same license or to any license that
>  meets these software has the choice of license as long as they
> meet
>  these guidelines.

>   
...

This looks like the result of a bad cut-and-paste job.  I have tried, 
and I can't even understand what it was supposed to mean.  Could this 
be clarified in the final version?

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

Re: Debian logo & its license

[Buddha Buck]

> On Sat, Jan 23, 1999 at 11:44:06PM -0800, Joey Hess wrote:

> > We shouldn't license our logo by any license that does not comply with the
> > DFSG. To do so would be hypocritical.
> > 
> Not true. It's the Debian Free SOFTWARE Guidelines. A logo is not software.
> It may well be that we want a logo whose use is restricted so that we can have
> some control over the quality of items that it is associated with.

More to the point, a logo is more like a name than software.  Its 
purpose is to identify something, not make it work.

We have DFSG software in Debian which has the license requirement that 
if a modified version fails to pass a particularly stringent, non-DFSG 
conformance test, it may not use a particular name to identify it.  The 
ability to require renaming a program because the authors don't want a 
broken fork detracting from their reputations has been a part of the 
DFSG for a long time, and I didn't think that it was under dispute.  
Should not the author have the same control over other identifying 
marks (like logos) which are associated with the software?  I don't 
think that that violates the spirit of the DFSG. If it violates the 
letter, then I think it should be looked into.

> It appears that what we really need are two logos: one with a relatively open
> license and second with a more restricted one. The open one would be used on
> web pages, etc. An example where a more restricted license would be 
> appropriate
> is letting it only be used on CDs that pass a test suite guaranteeing that the
> CD set is 'good enough'.

I agree.  I would suggest that the two be closely linked in form...  To 
use our current logo as an example, have the plain line-art penguin as 
the "open" logo, and the penguin in the center of a scalloped-edged 
annulus (as if it were in the center of a seal) as the restricted logo. 
 Both scale well, both are distinctive, and both are similar enough to 
tell that they are both related.  (I thought of suggesting the word 
"certified", "approved", or similar into the suggested logo, but words 
don't scale well, can be hard to read, imply things they probably 
shouldn't, and are language-specific.)


> 
> Jay Treacy
> 


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

Re: Intent to package rolldice, blackjack

[Buddha Buck]

> -BEGIN PGP SIGNED MESSAGE-
> 
> rolldice is a virtual dice roller that takes in a string on the command
> line in the format used by some fantasy role playing games like Advanced
> Dungeons & Dragons[1] and returns the result of the dice rolls.
> 
> [1] Advanced Dungeons & Dragons is a registered trademark of TSR, Inc.

Is the trademark still held in TSR's name?  Or is AD&D a registered 
trademark of Wizards of the Coast?


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

Re: Debian goes big business?

[Buddha Buck]

Ben Pfaff said:
> Laurent Martelli <[EMAIL PROTECTED]> writes:
> 
>What about non-developper users ? Shouldn't they have a word to say,
>even if they can't or do not have the time to contribute with code ? 
> 
> They should have `a word to say', and they do--they can subscribe to
> Debian lists and give their feedback and advice, which developers are
> free to follow or ignore.  But they do not, and should not, IMO, have
> the privilege of voting or otherwise setting policy.  Users are not
> developers and shouldn't presume to be.

Until they go through the procedure of registerring as a developer.  
Then they can presume all they want.

On that note:  Are there any developers in the Buffalo, NY area who 
would be willing to meet with me to exchange key signatures?

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

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

Re: Follow-up

[Buddha Buck]

>   Further versions of this proposal will be posted on the WWW, and the address
> of such revisions will be posted to both -devel and -dpkg.

Please don't do this.  It is not easy for everyone on these lists to 
access material on the WWW.  From past experience with other groups, it 
really breaks up continuity to discuss in email a document that exists 
solely on WWW.

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

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

Re: Debian appears to be ancient

[Buddha Buck]

> John Hasler <[EMAIL PROTECTED]> writes:
> 
>Edward Betts writes:
>> Are you sure it was /usr/doc/copyright/base ?
> 
>hasler/~ ll /usr/doc/copyright/base
>total 2
>-rw-r--r--   1 root root 1197 Dec 31  1969 debian.README
> 
> So what package does it come from, then, and what version?  

It's in the "base" package, which on my system is version 1.1.0-14.  
The package itself was split a long time ago into several other 
packages, but because it contains several hard-to-upgrade files (e.g., 
/dev/*), it can't be removed from systems which contain it.  The 
upgrade would totally trash the system.

Newer installs don't have that problem, it's just the older installs.

> It's also not in Contents-i386 for stable, frozen, or unstable AFAICT.
-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs

[Buddha Buck]

James Troup said:
> Joey Hess <[EMAIL PROTECTED]> writes:
> 
> > James Troup wrote:
> > Why does a binary-only NMU give you the right to skip waiting, while
> > a normal NMU does not? Why are they different?
> 
> Because I'm not forcing my changes on anyone but the architecture I'm
> uploading for.  If I'm wrong in some drastic way, only m68k suffers.

How does that differ from -any- binary-only NMU, regardless of 
architechture?  If binary-only NMU's for i386 are bad, why are 
binary-only NMUs for m68k OK?

The only -real- problem I see with normal NMUs is that then the i386 
and m68k binaries are built from different source packages, and I don't 
know if our archiving system has a way of dealing with that.
 
> You're also forgetting the vast majority of our fixes fall into two
> categories:
> 
> 1) Fixing lame packaging bugs.
> 2) Portability fixes.

Both of which, regardless of architecture, are bugs.  If there is a 
lame packaging bug that prevents easy porting, it should be dealt with 
as a bug -- and if that calls for a NMU, then it should be a normal NMU.

Portability fixes are the same way.

> In both cases it's hard for a maintainer to turn round and say, "No,
> your fix is wrong, I wanted the package to be unbuildable from source"
> or "No, get some real hardware, I don't want this package to be
> portable", or "No, that's not the right fix for $ARCH, you should do
> this instead".

Then they probably won't, and if you are lucky, the next Maintainer 
Upload will include the changes made for your NMU.

What is the procedure for normal NMU's in place to ensure that 
necessary bug-fixes get rolled into the next MU anyway?

> > Binary-only and normal NMU's are the same thing,
> 
> No they're not.  Why do you insist on this obvious falsehood?

Why are the different?  Aside from Binary-only apparantly breaking 
current policy?
 
> [ ... ]
> 
> > Do you want the ports to remain forever second class citizens, or do you
> > want them to eventually mature to be equal with i386?
> 
> Will you please get off your high horse and stop being so incredibly
> condescending?  It doesn't help in anyway whatsoever and without some
> facts to back up your anti-non-i386 rants, it's really rather
> pointless.  What exactly makes us second class citizens (your wishes
> aside)?

The only think that I know of that makes ports second-class citizens is 
you claiming that because you are different, you should follow 
different rules.

I don't think Joey is anti-non-i386, but that he instead wants everyone 
to play by the same rules.

> > > All ports needs to make a lot of changes because so many source
> > > packages are broken.  It's got little or nothing to do with the
> > > newness of the port (if you look at the {binary-,}NMU's and bug
> > > reports, they aren't predominantly from the new ports, but rather the
> > > older ones (m68k && alpha)).
> > 
> > Broken source package has nothing to do with a port at all.
> 
> Of course they bloody do; we have to build them.  And the breakage I'm
> talking about, is the sort of breakage which doesn't show up for 99.5%
> of i386/source maintainers.

Just because they don't show up most of the time, they are still 
broken.  And they should be fixed, regardless of if it was found by the 
m68k people, the PPC people, the PalmPilot people, or the i386 people.

> > > Eh?  Define ``standard'', please?  I rather hope you don't mean "what
> > > i386 uses".
> > 
> > I mean that we should converge on using the same build environment and build
> > mechanisms (and NMU mechanisms) for all architectures, and until we do, the
> > ports are going to remain second class citizens.
> 
> Ehm, so all the architectures using glibc 2.1 are second class
> citizens?  If I didn't know better, I'd think you were just using this
> issue as an excuse to vent some anti-non-i386 feelings you seem to
> have.

I think he was referring to Procedures and Policy, not which 
compiler/libraries you use.

A source package which doesn't compile out-of-the-box in the standard 
Debian environment (egcs2.9, gcc2.7, libc6/libc++2.9, binutils2.9, etc 
for i386, glibc2.1 plus whatever compiler/libraries/binutils is used 
for m86k, and so forth) has a bug -- unless it is specifically 
architechture dependent.  It's not a bug with the m68k version only, 
it's a bug, plain and simple.  If it fails on m68k because the 
maintainer unconsiously thought that All The World's an i386, then the 
source package still needs to be changed -- and Procedures and Policy 
should allow that.

I don

Re: The freeze and IMMINENT 2.2.0p1!!

[Buddha Buck]

> Quoting Avery Pennarun ([EMAIL PROTECTED]):
> > Slink is a badly-needed cleanup release.  Don't hold it back for any
> > package.
> 
> What needs to be cleaned up? Hamm's running fine here. Slink definately
> adds value, but I don't think it's something we desperately need _now_.

What needs to be cleaned up is our reputation for taking a -long- time 
between releases.  That is the major (if not -only-) release goal for 
Slink.  As such, it IS something we desperately need _now_.

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

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

Re: Ratifying the constitution

[Buddha Buck]

> Buddha Buck writes ("Re: Ratifying the constitution "):
> ...
> ...
> > Out of curiosity, how formal does a proposed amendment have to be.  I 
> > mean, will this work for an amendment proposal?  (And if so, I'd like 
> > to propose it:
> > 
> > --Amendment Proposal
[replace "seconds" with "sponsor"]
> > ---End Amendment Proposal-
> > 
> > Or should I replace the second paragraph with a context diff of the 
> > constitution text, with the exact changes I want?
> 
> I don't think there's any lack of formality in your proposed
> amendment, except that it's not clear from your message that you
> actually are making this proposal.

I would have made it, except:

1.  Guy indicated that he didn't see the distinction between "second" 
and "sponsor" significant enough to warrant changing the text, and 
declined to accept my amendment as "friendly".

2.  Given that it is an esoteric point of procedure, and that I felt 
that few people cared about it, I didn't think I could find the support 
to force the issue as an "unfriendly" amendment.

3.  Although I state my opinion occasionally, and hopefully make good 
points more often than bad, I am not officially a developer, and thus 
technically have no standing to propose or vote on resolutions, 
amendments, etc.  So in order to push the issue, I would have to find a 
developer who felt strongly enough about the issue to officially 
propose it for me.  No one seemed to care, so I didn't look hard for 
someone.

> I'd be perfectly happy with your amendment, but shan't second it
> myself just now, because there's an extra week's delay involved from
> the point where Guy accepts the amendment (I'd reduce the minimum
> discussion period).
> 
> If Guy does accept this amendment I want to submit another (or have
> Guy incorporate it):
> 
>  After A.1(5) add:
> 
>  6. The proposer of a resolution may make changes to correct minor
>  errors (for example, typographical errors or inconsistencies) or
>  changes which do not alter the meaning, providing noone objects
>  within 24 hours.  In this case the mininum discussion period is not
>  restarted.
> 
> (This change of the word `seconder' to `sponsor' might well have
> fallen under this proposed amendment.)
> 
> Ian.
> 
> 
> --  
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

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

Re: ideas underlying policy

[Buddha Buck]

ame questions multiple times (when
> upgrading packages, or when putting the same configuration on many
> systems), and we sometimes don't meet our goal of having packages "just
> work" without requiring any configuration.
> 
> Ideally, there should be a simple way to tell someone how to find
> documentation on an issue they're interested in. In practice, we're
> still working on that... One advantage of following standards is that we
> can take advantage of existing documentation.
> 
> Furthermore, there's a world outside of Debian, and a lot of development
> happens which is focussed on other distributions. In an ideal world,
> it would be simple to incorporate much of work into Debian. We don't
> want to sacrifice too many of our gains to make this happen, but it's
> something to think about.
> 
> And, of course, as we incorporate new pieces of software, we sometimes
> encounter situations which had never been encountered before, or
> problems we thought we could avoid.
> 
> It's important to understand policy when putting together a package.
> If you find yourself having to do something which seems to conflict
> with policy -- where it seems like you should do things differently,
> please include a comment to that effect in your package's change log,
> and please file a bug report against policy. [insert more detail here.]
> 
> Also, if you have experience in writing portable software, in
> adminstering large systems, or if you just have time to help resolve
> some of our issues, you might try your hand at solving some of our
> long-term goals. Development requires talented individuals, and an
> elegant solution benefits us all. [Please be careful, though: these
> problems are a bit subtle.]
> 
> Ultimately, we're trying for a distribution that makes sense. Policy is
> a step in that direction.
> 
> 
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

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


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

Re: Conflicts between developers and policy

[Buddha Buck]

The text under discussion, as written by Philip Hands and Buddha Buck, 
and posted in total by Manoj Srivastava is:

___
   Policy should be followed, except where a discussion about the 
clause in
   question is still ongoing, in which case the maintainer may indulge 
in a
   policy violation if they feel it is a technically superior
   approach.

   When policy is being violated in this manner, this fact should/must
   be documented in the bug tracking system, on the appropriate Debian
   mailing lists, and in the changelog of the package violating
   policy, including information on what policy is being violated, and
   why.  Any permanantly accepted policy violations (such as the
   dynamic library managing programs being shipped statically linked)
   should/must be documented in the policy manual, including an
   explanation of why the policy exception was granted.
__

Concerning the first paragraph, Raul Miller commented:
> Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> >Policy should be followed, except where a discussion about the clause in
> >question is still ongoing, in which case the maintainer may indulge in a
> >policy violation if they feel it is a technically superior
> >approach.
> 
> Hmm..  this is actually an important and interesting concept.
> 
> In effect, you've elevated "a technically superior approach" to policy
> status, and delegated all of policy to a mere plan for achieving that.
> 
> What you've left out is what the technically superior concept 
> approaches.
> 
> Could you perhaps suggest what it is that could be used to distinguish
> between worthwhile and non-worthwhile forms for technical genius?

Your objection is to the use of the admittedly subjective criteria "if 
they feel it is a technically superior approach."  Would the (slightly) 
more objective criteria "if they feel that strict adherence to the 
policy would jeopardize system integrity or weaken package usability."?

I don't know if that quite captures what we want, but it is an idea.

Also, when I said "should/must", I meant one or the other, but I wasn't 
sure which would be appropriate.  Upon reflection, I think they should 
be "must"s.





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


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

Re: Conflicts between developers and policy

[Buddha Buck]

> 
> You seemed (to my tired eyes) to be accusing people of objecting to:
> 
>   Policy should be followed, except where a discussion about the clause in
>   question is still ongoing, in which case the maintainer may indulge in a
>   policy violation if they feel it is a technically superior approach.

I would add another clause to the effect of:

When policy is being violated in this manner, this fact should/must 
be documented in the bug tracking system, on the appropriate Debian 
mailing lists, and in the changelog of the package violating policy, 
including information on what policy is being violated, and why.  Any 
permanantly accepted policy violations (such as the dynamic library 
managing programs being shipped statically linked) should/must be 
documented in the policy manual, including an explanation of why the 
policy exception was granted.

> James Troup, Dale Scheetz, or anyone else have a problem with this ?
> 
> My only objection was that there was no need to include a clause like that in 
> policy, because it is self evident.  This discussion has conclusively proved
> me wrong about that, so lets put such a clause in policy.

9 times out of 10, policy disputes (about anything, in any 
organisation) arise because what was self-evident to one is not 
self-evident to another.  That's one reason why I like complete 
documentation, even if it says stupid and obvious stuff, because it 
probably isn't stupid and obvious to someone else.


> 
> Cheers, Phil.
> 

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


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

Re: License advice

[Buddha Buck]

I am not a lawyer either, but...

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

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

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

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

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

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


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

Re: Taking over production of emacs20 package.

[Buddha Buck]

> I think the number one question we need to address is whether we want
> to support running Xemacs and GNU emacs at the *same* time.

Yes, we do want to support running both Emacsen.  I don't see how 
dropping one for the other can even be considered a viable option.

> If we do not, it becomes more difficult for users to test out the
> other, but it becomes much easier to maintain the emacs setup. I do
> not believe that one can sensibly in the longer *use* both, though
> people maintaining stuff for both versions obviously will have the
> need to test it on both.

This argument is perhaps valid for a single-user home Debian system, 
but it is not acceptable for a multiuser environment.  Having Debian 
dictate that ISP's, universities, or corporation use a single emacsen 
because we don't want to support more than one is rediculous.

My university, on the CS department machines (running Solaris, not 
Debian GNU/Linux), currently maintains two versions of XEmacs, at least 
one of GNU Emacs, multiple Netscapes, both GCC and the Sun CC, and both 
the GNU fileutils and the Sun equivilants.  This type of mixed system 
is not uncommon in large installations.

Even with a single user the argument has weak points.  This past week, 
there were several times when I had both XEmacs and GNU Emacs frames 
open simultaneously.  And then in a third window, start vi.  While this 
abuse of editors is unusual, there are times when I can definately see 
the use of multiple versions of the same basic editor, even for a 
single user.  Jove for quick edits, XEmacs for normal programming and 
other editing jobs, and Xemacs-MULE for foreign language processing (if 
I can ever figure out how to input text in kana and kanji, I'd be 
happy).


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


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Editor wars considered harmful

[Buddha Buck]

> On Mon, 23 Jun 1997, Bruce Perens wrote:
> 
> yes, there should be a veritable plethora of editors available for
> installation AFTER the base system is up and running. The more the
> better.
> 
> The base system should have ae (or similar newbie editor like pico) and
> the smallest possible implementation of vi that works.
> 
> If something has to go to make room for it on the disks, then so be it.

I think it is more important to support all reasonable install methods 
on the base disks (including dpkg-ftp via ppp) than to include vi.  
Personally, I prefer vi to pico or ae, but I can deal with either one 
for as long as it takes for me to get the system up to the point where 
I can install vi or Emacs.

> The reason for installing vi is that it is THE standard editor for all
> unixes. It is the one editor which is guarranteed to be on ANY unix
> system.

Learning vi was handy the day I had to do some work on an old Xenix 
installation on a TRS-80 Model III (with a 5MB hard drive).  I was able 
to do the work I needed to do in ed, since vi -wasn't- available.  If 
any editor had a claim as the one editor which is guaranteed to be on 
ANY Unix system, it would be ed.

> 
> Having a version of vi (no matter how primitive) available for initial
> system config and install is essential.

Having some editor (no matter how primitive) available for initial 
system config and install is essential.  Having that editor be vi 
isn't.  Ae is nice in that it tells the basic editing commands on the 
top portion of the screen.  Someone who isn't used to -any- Unix editor 
would like that much more than the initial "beep" mode of vi (where you 
press any key, and it beeps at you).  -I- would prefer vi, but I know 
vi.  If I didn't know vi, I'd prefer ae or pine.
> 
> craig
> 
> --
> craig sanders
> networking consultant  Available for casual or contract
> temporary autonomous zone  system administration tasks.

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


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Simple policy question...

[Buddha Buck]

> Okay, so say some random person who has installed Debian wants XEmacs 19.15
> because he needs some feature.  This seems like a reasonable request...  He
> could get it from the Hamm distribution, except that would mean he'd need
> libc6...and he doesn't want to do that, because he's heard that it will
> affect the stability of his system.

Then that person needs to be corrected.  I don't know if libc6 will 
affect the stability of his system, but I do know that xemacs19 (the 
xemacs package in hamm currently) doesn't rely on libc6, but rather is 
still libc5.

I also know that installing libc6 will only affect programs that use 
libc6, not ones that use libc5.  I currently have libc4, libc5, and 
libc6 installed on my system.  I run programs that are compiled for all 
three libraries.  So far, no problems that can be traced to libc6.

What I would do, if I were he, is go into dselect, put everything on 
hold, point dselect at hamm, flag xemacs19 for install, then look at 
the dependancy conflicts dselect complains about.  If he wants 
xemacs19, then he can mark for install or upgrade any packages from 
hamm that xemacs19 requires.  I don't know if there are any, since 
xemacs19 is compiled against libc5, xlib6 (3.2), ncurses3.0, xpm4.7, 
zlib1, libjpeg6a, libdb1, libgdbm1, libpng1, all of which are, as far 
as I know, available in 1.2.

> 
> What then can he do besides compile it himself?  If the answer is only
> compile it himself...is there a way we can add a special update directory
> for 1.3, that will have later versions of programs, and people can
> optionally tell dselect to look there?

I don't know what you mean here...
> 
> Or am I missing a big part of the picture?
> 
> Thanks,
> Sam
> 
> Message from joost witteveen ([EMAIL PROTECTED]) on 6-13-97:
> > > Okay, I know that before 1.3 was released, for a long time period the only
> > > changes that were being accepted were updates that fixed bugs.  Updates 
> > > that
> > > only provided new features were not allowed.
> > > 
> > > Now that 1.3 has "shipped", are updates allowed to replace old packages, 
> > > or
> > > are replacment packages still only allowed that fix specific bugs?  (In
> > > particular I'm wondering whether we will see Xemacs 19-15 and XFree 3.3 in
> > > 1.3.)
> > 
> > Situation of 1.3 is still more-or-less unchaged: only really serious
> > bugfixes can go in 1.3.1, after (we have been promised) two weeks
> > of testing. 
> > 
> > XFree 3.3 has important security fixes, and there seems to be no other
> > way to close the security holes currently in debian 1.3.0 than to include
> > Xfree 3.3, so there is a chance that will be included. I'm much less
> > sure about XEmacs 19.15 though, although I believe it also does fix
> > stuff.
> 
> 
> 
> -- 
> VA Research Linux Workstations| The VArServer 4000 File Server
>   |   Four 200Mhz Intel Pentium Pro 
> CPUs
> http://www.varesearch.com | 512MB 60ns EDO ECC/100 GB Raid-5
> Sam Ockman - (415)934-3666, ext. 133  | Linux - $44,339
> 
> 
> --
> TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
> [EMAIL PROTECTED] . 
> Trouble?  e-mail to [EMAIL PROTECTED] .
> 

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


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: cygwin.dll license (was Re: FreeQt ?)

[Buddha Buck]

tricky to subvert a structure from within, and that is why 
the GPL is so tricky to interpret.

However, it is item 4) that is the key, and the GPL has (to my 
knowledge) never been tested in court.

Perhaps it is time for a GPL version 3?  But would it/could it be any 
clearer?

> 
> Jason
> 

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


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: a.s.r manpages

[Buddha Buck]

> I am about to create a package (in fact it's ready) with
> alt.sysadmin.recovery man pages (things like lart, sysadmin, etc.)
> So, first of all I'd like to check if there are no other people working on
> it and if the others think this should be put into Debian.
> And another question - I'm not sure if my choice of games section is
> proper... Yes, I know it will be distribution maintainer who'll put it in
> some correct place, but I'd like to have a good section put in the
> package...

Personally, I question placing them in the main distribution at all 
(including non-free and contrib).  I have nothing wrong with the 
contents (if available, it would be installed on my system rather 
quickly), but rather the unwanted publicity it could cause.

A.s.r is a rather selective place.  Whilst those who read and post to 
it like it the way it is, and don't want lusers (read the other 
postings in this thread fora one-line description of lusers) there, 
there is little they can do about it.  Already, one must wave a dead 
chicken to successfully post to the group, and one of the entries in 
the groups FAQ is that reposting ASR material to alt.best.of.internet 
or similar groups (like rec.humor or rec.humor.funny) is highly frowned 
upon.  So far, it's worked.  The S/N is rather high, even with the 
traffic it gets.  (Granted, the group has a relatively odd definition 
of "signal", bit there are worse groups -- what counts as noise on 
alt.religion.kibology, anyway?)  But there is a noticable dip in S/N 
when the group gets publicity.

I would prefer keeping the package -out- of the distribution, and 
mentioning on a.s.r that it is available, even if that would be 
considered useful information.

> 
>Paul
> 

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


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Conflict between Packages file and actual files

[Buddha Buck]

> Dale Scheetz <[EMAIL PROTECTED]> writes:
> 
> > This is a continuous problem. I don't know why ftp.debian.org takes so
> > long to get in sync with master, but the problem simply propogates from
> > there to all the additional mirrors. Debian is the only distribution I
> > know that depends so heavily on the accuracy of one file.
> 
> This sounds like a locking problem to me. 
> 
> If the archive on master changes while the mirror to ftp.debian.org is
> running, then the packages file will obviously differ from the
> contents of the archive. This can continue down the chain of
> mirrors. 
> 
> Assuming no locking takes place, then differences become increasingly
> likely as the time taken to update the mirror increases. Another
> source of this is if the packages file on master is not updated
> immediately after a package is added. These problems will presumably
> settle if the archive is unchanged for a couple of days.

I think its a combination of these two.  I think that the archive on 
master being updated asynchronously with the package file is a problem 
(it leads to an inconsistant archive, for one thing), and I think that 
ftp.debian.org mirroring without locking is a problem.

Is there any reason why the following can't be done, and why it can't 
be automated:

1)  New packages are placed in the archive, without deleting the old 
versions.  This way, the existing Packages file and the archive remain 
consistant -- if the Package file says it's there, it's there.

2)  A new Packages file is generated by a script that only adds the 
newest version of duplicate packages.  It would be nice if this also 
generated a list of older versions of duplicated packages for the next 
step, but that list could also be generated as part of step one.  Since 
the only files listed in this new Package file are in the archive, 
consistancy is maintained.

3)  Delete old version of updated packages. Since these are no longer 
listed in the Packages file, they can be deleted without ruining the 
consistancy of the Packages file.

If this could be automated and run at a set time, then "locking" could 
be achieved by scheduling it at a time when ftp.debian.org -won't- be 
mirroring it.  That way, ftp.debian.org is maintained as consistant.  
Similarly, if the mirroring could be achieved in the same order (new 
files, Packages, delete old files), then even during mirrors, 
ftp.debian.org would be consistant.


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


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: using dselect with hamm/non-free, hamm/contrib

[Buddha Buck]

> Joey Hess <[EMAIL PROTECTED]> writes:
> 
> > dpkg-ftp downloads the Packages files ok using this, but when I go to
> > download, it can't find the files:
> 
> Actually you should use
> 
> distribution base: .../debian/dists/unstable
> section list: main non-free contrib
> 
> Use unstable or frozen or stable in the distribution base.

Even with this, I can't get it to work.  I'm running into the same 
problem Mr. Hess reported.  Using dir: /debian dist: unstable, I have 
been able to get hamm, but no combination I've tried has allowed me to 
get hamm/non-free or hamm/contrib.  I can get the packages files, but 
not the packages themselves.

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


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Bug#4457: popclient conflicts with netstd

[Buddha Buck]

> Michael Shields wrote:
> > 
> > > Suggestions:
> > > 
> > > 1) Remove popclient from netstd, or
> > > 2) Update the popclient in netstd and eliminate the separate package.
> > 
> > I had already packaged and uploaded popclient before noticing this.
> > I'm not sure it needs to be in netstd; if we take it out, I can
> > trivially upload another version that Replaces: netstd.
> 
> I'll remove it from the netstd package. There is one open bug report
> against the popclient in netstd. I'll reassign it to the popclient
> package to make sure it won't get lost.
> 
That sounds good...  However, please -DON'T- mark popclient as Replaces: 
netstd.  As far as I understand, Replaces should only be used when one package 
completely replaces another's functionality, and I don't thing popclient 
replaces all of netstd.

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

Bug#4446: usr/games/fortune needs recompilation

[Buddha Buck]

> Package: fortune
> Version: 2.1-1
> 
> The /usr/games/fortune executable is a.out rather than ELF.  Either a
> dependency upon the old a.out libraries should be added, or the
> executable should be recompiled.
> 

The executable should be recompiled.  There are a few outstanding bugs on the 
fortune package, some dating back over a year, that could easily be fixed by a 
repackaging.  I could be wrong, but it seems as if the maintainer has abandoned 
it.


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

Bug#4457: popclient conflicts with netstd

[Buddha Buck]

Package: popclient, netstd
Version: 3.05-1, 2.07-1

The netstd package provides popclient 2.21, and the popclient package 
provides popclient 3.05.  These two versions aren't completely 
compatable.

Neither package conflicts with the other, yet both provide 
/usr/bin/popclient, /usr/man/man.1/popclient.1, and 
/usr/doc/copyright/popclient.

Dselect is still configured to automatically override conflicts like 
this, so when I installed the popclient package, I had to modify my 
scripts, and when I installed a new version of the netstd package, I 
had to remodify my scripts.

Suggestions:

1) Remove popclient from netstd, or
2) Update the popclient in netstd and eliminate the separate package.

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


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

Re: /usr/local (again)

[Buddha Buck]

> I'd like some (easy) way of storing answers to questions. The
> questions and answers could be shared between packages, when
> suitable. One such question would be whether the local admin
> wants to allow creation of the empty directories in /usr/local.
> 
> If we want to be ambitious, we'll create a fancy language for
> defining the user interaction. Something similar to dialog, but
> something that is not tied to text terminals, so that it can
> later be extended to X as well. It's a big project, of course,
> and not something that should be undertaken lightly.

I know that the Linux kernel has already solved that problem with their 
configuration setup programs -- they have three interfaces (text-based, 
curses based, and Tcl/Tk based) running off the same script, to 
generate the configuraton file.  It also allows you to edit the 
configuration using the same tools, by reading and parsing its own 
output.  It also allows the definition of arbitrary complex things and 
has the ability to handle interactions between items.

Could this be adapted for our needs?  It might not be perfect, but it 
-is- a start.  Some modifications I could see being necessary would be 
to create a way of handling separate config scripts for each package 
that need them, and a few other minor issues.


> 
> Getting answers to these questions before unpacking anything
> would probably be a good idea.
> 

This is useful for global options (what to do with /usr/local, for instance), 
but what about package-related options?

Or are we thinking of two separate (but related) problems?

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

Bug#4339: no free pine package available

[Buddha Buck]

> I rarely use pine myself (usually only when I have to read some
> MIME-encrypted mail :-), but I know it's quite popular.  It would
> be a pity if we can't ship a MIME-aware mailer with the standard
> distribution.

How odd...

I seem to have a /usr/bin/exmh, and exmh isn't in my /usr/local/bin.  I 
consider exmh to be the most MIME-aware mailer I've had the pleasure to 
use.  If it isn't in my /usr/local/bin, ., ~/bin, or 
/usr/local/openwin.bin, but I'm using it on my system, then it must be 
part of the Debian distribution, or my system is really messed up...

Exmh is an optional package in the mail section.  According to dselect, 
it depends on tk41, tcl75, mh, and metamail.  Metamail is a general 
package to handle MIME types unknown to your mailer.  Most of the 
mailers out there (including pine) use metamail transparantly.  
However, exmh is very MIME-aware on its own.  It will automatically 
display enriched-text correctly, handle multipart MIME messages well 
(both multipart/mixed and multipart/alternative), and integrates well 
with PGP.

> 
> Marek
> 

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

Bug#4145: ld.so is a.out?!

[Buddha Buck]

> Package: ldso
> Version: 1.7.14-4
> 
> [EMAIL PROTECTED] /lib>file ld.so*
> ld.so:Linux/i386 demand-paged executable (QMAGIC), stripped
> ld.so.1.7.14: Linux/i386 demand-paged executable (QMAGIC), stripped
> 
> Looks like ld.so is still a.out. This is very annoying, because it means
> that the a.out kernel module is most always loaded:

Of course, ld.so isn't used by ELF programs to load shared libraries, 
ld-linux.so.1 is.  ls.so is used only by a.out programs, so offhand, I 
don't see a problem with it being a.out.  In fact, it might not work if 
it was ELF (I'm not sure of that lastpart)

bash$ file ld*
ld-linux.so.1:  ELF 32-bit LSB shared object, Intel 80386, version 1
ld-linux.so.1.7.14: ELF 32-bit LSB shared object, Intel 80386, version 1
ld.so:  Linux/i386 demand-paged executable (QMAGIC), 
stripped
ld.so.1.7.14:   Linux/i386 demand-paged executable (QMAGIC), 
stripped

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