Re: perl version depends

[John Lapeyre]

On Thu, 8 Oct 1998, Richard Braakman wrote:

dark>That "only" is a large source of packaging bugs.  In fact, the (IMO)
dark>most annoying upgrade problem in hamm was a pathname problem: two
dark>packages had moved to a different directory at the last minute, and
dark>the auto upgrade script hadn't been modified to match.
Also some complicated packages have perl paths hardwired in
relatively obscure places (eg pdl) , and these may not show up
immediatley. I agree that there is a good possibility that releasing slink
with half a perl upgrade could be a disaster.
If we set a policy on the paths within a day or two and then have,
say three weeks, and can count on people working hard, and allowing NMU's,
we can probably get the critical packages fixed (I don't know what they
are).  But doing it all in 7 days is not a good idea.

Re: installing in /usr/lib/perl5/debian .  I have an uneasy
feeling about it, but no concrete objections.  My guess is that Darrin has
a better idea about it than me.  It may be ok, I'll follow it if its set.
Just to summarize, I think we have to either go back to 5.004 , or
push the freeze back a couple of weeks.

John


John Lapeyre <[EMAIL PROTECTED]>
Tucson,AZ http://www.physics.arizona.edu/~lapeyre

Re: perl version depends

[John Lapeyre]

On Thu, 8 Oct 1998, Michael Stone wrote:
mstone>What I'm trying to say is "why doesn't perl look in /usr/lib/perl5
mstone>anymore?" Was this just a gratuitous change, or was there a reason for
mstone>breaking things? I can understand the change if there are modules that
mstone>work in 5.004 but not 5.005, at least from the upstream perspective, but
mstone>don't we already have a mechanism for handling conflicts that makes this
mstone>redundant? What does /usr/lib/perl5/5.005 buy us?

This is decided by the perl authors, not debian. Darrin can change
things and install whereever he likes and change the include path, but we
have to make sure it doesn't break things. So to the extent possible, we
stay with the official perl installation.  However, at least part of their
rationale for the new scheme is to allow multiple versions of perl, a
feature that debian is not interested in.
Why they (perl guys) did not leave /usr/lib/perl5 in the search
path is not clear to me. Perhaps because they assume that othe modules
will install in site_perl or local.  But systems with package managers,
like ours don't use these dirs.


John Lapeyre <[EMAIL PROTECTED]>
Tucson,AZ http://www.physics.arizona.edu/~lapeyre

Re: Freeze in 7 days??? (was Re: perl version depends)

[Gergely Madarasz]

On Thu, 8 Oct 1998, Santiago Vila wrote:

> 2) Are we really going to freeze slink in 7 days?

I dont think we should freeze until we have a broken libc in slink...

--
Madarasz Gergely   [EMAIL PROTECTED] [EMAIL PROTECTED]
  It's practically impossible to look at a penguin and feel angry.
  Egy pingvinre gyakorlatilag lehetetlen haragosan nezni.
HuLUG: http://mlf.linux.rulez.org/

Re: Freeze in 7 days??? (was Re: perl version depends)

[Gergely Madarasz]

On Fri, 9 Oct 1998, Gergely Madarasz wrote:

> On Thu, 8 Oct 1998, Santiago Vila wrote:
> 
> > 2) Are we really going to freeze slink in 7 days?
> 
> I dont think we should freeze until we have a broken libc in slink...
^
Hmpf... I meant while :)

--
Madarasz Gergely   [EMAIL PROTECTED] [EMAIL PROTECTED]
  It's practically impossible to look at a penguin and feel angry.
  Egy pingvinre gyakorlatilag lehetetlen haragosan nezni.
HuLUG: http://mlf.linux.rulez.org/

Re: perl version depends

[Michael Alan Dorman]

John Lapeyre <[EMAIL PROTECTED]> writes:
> However, at least part of their rationale for the new scheme is to
> allow multiple versions of perl, a feature that debian is not
> interested in.

Threaded perl and non-threaded perl are binary-incompatible at the
extension level, meaning most compiled extensions must be
distinguishable.

Furthermore, there was a lot of concern that most perl-only extensions
are not yet thread-safe.

Therefore, I believe, the decision was made to have all extensions,
etc, reside in a "arch-directory" that would distinguish between
thread and non-thread.

So, yes, I think Debian does have to honor this, and to make our perl
gratuitously different (which is to say, having it look in
/usr/lib/perl5) would be inviting calamity some time down the road.

I say this in full knowledge that I'm going to have to recompile a
heap of perl modules next week.  And I'm glad Darren didn't make a
thrperl yet, so we don't have to deal with that issue immediately.

Mike.

Reverting to Perl 5.004

[Darren Stalder]

-BEGIN PGP SIGNED MESSAGE-

I suspect that it's in the best interest of the freeze to revert to Perl 
5.004.  I'm currently uploading the 5.004.04-6 release to master's
Incoming.  I'll file a bug on ftp.debian.org that the 5.005 release
should be deleted and the 5.004 release installed.

I'll provide an ftp site for the 5.005 release until December when we
have the new release started.  Currently, it will have the 5.005.02-2
release in it.  My plans include putting the two extra paths in @INC.
It won't be released immediately since I want to do some experiments
first.

Perl module packagers who want to release 5.005 modules are welcome to
upload packages there.

It will be available at: .
Uploads are welcome at .

Darren
- -- 
<[EMAIL PROTECTED]>  <[EMAIL PROTECTED]> <[EMAIL 
PROTECTED]>
Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996
@ Sysadmin, webweaver, postmaster for hire. C/Perl/CGI/Pilot programmer/tutor @
@Make a little hot-tub in your soul.  @

-BEGIN PGP SIGNATURE-
Version: 2.6.3a
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBNh1fubQuaHP6LBjxAQH7IAQAlHW2cgUdRQT073fUqrdbqxJtnaiha2nG
JWFNZUASbRh3PuS4MzizJPplpFwDBYZDOeqLXvJ1HiyFavUqw7fqbdz7ksfebF0d
zemdv351a/GgP2dVWQCTmLhpCFqDC174B9fOqIQHkXRmCgwt9fPQ9csX9MggyAqy
FvJeVyAfqmI=
=IRGl
-END PGP SIGNATURE-

Re: Reverting to Perl 5.004

[Martin Schulze]

Darren Stalder wrote:
> I suspect that it's in the best interest of the freeze to revert to Perl 

Thanks.

> 5.004.  I'm currently uploading the 5.004.04-6 release to master's
> Incoming.  I'll file a bug on ftp.debian.org that the 5.005 release
> should be deleted and the 5.004 release installed.

Maybe that's not needed since, right after s/unstable/frozen/ there
will be a new unstable which is perfectly the correct place for the
new perl package.

Regards,

Joey

-- 
The only stupid question is the unasked one.

Consensus on source packages for ports?

[David Welton]

So, is there any consensus on how to upload source packages for ports?
I have some things like strace that I would like to upload for arm,
but the source is fairly different...  Hrmm... pondering.. maybe I can
get around it.. hrmmm

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

Debian GNU/Linux - www.debian.org

Re: PGP in the US (Re: formal documents)

[Raul Miller]

Gregory S. Stark <[EMAIL PROTECTED]> wrote:
> It might not be legal for someone to give him PGP or explain how
> crypto works even while he's in the US.

No, the regulations prohibit export.  If he's in the US, that's not
export.

As you mention, even if it was a problem, it would be a problem for
the exporter, not the user.

[That said, if you are a cryptographer and you want to talk to people
without having to get proof of their citizenship you might want to review
Berstein vs. US Dept. of State...]

-- 
Raul

Re: Uploaded tmpreaper 1.4.8 (source i386) to master

[Raul Miller]

Rob Browning <[EMAIL PROTECTED]> wrote:
> Now that sounds like a better idea if it would work, but just like
> the "touching idea", you'd have to make sure that all the relevant
> programs actually keep the file open, and don't just open it when they
> need it.

I think we can safely say that a program which leaves an unopened
file in /tmp for days, and expects it to never be deleted, is
buggy.

-- 
Raul

Re: FWD: Re: Linus is on a powertrip..

[Raul Miller]

Joey Hess <[EMAIL PROTECTED]> wrote:
> This is from the linux kernel mailing list. I find it pretty completly sums
> op my thoughts on all the new constitution and voting and policy voting
> stuff that we've been setting up. I haven't been vocal about this, but I
> think we've been moving in the wrong direction.

Perhaps.

Remember that a lot of the focus on debian is still: the individual
developer does the development.  Debian as a whole doesn't *do*
development, we do testing and coordination.

But probably this is meaningful for projects like dpkg.

> Of course, this came up on linux kernel because Linus is showing signs of
> burnout - just like Bruce burnt out. The benevolent dicator system isn't
> perfect.

Of course, Linus is now a father and has a full-time job. The demands
of which are likely to reduce his sense of humor for people saying that
it's too much work to send him a patch when he's getting so many that a
number of them drop on the floor, and even those that don't may sit in
his queue for a while.

-- 
Raul

Re: Back to RedHat

[Raul Miller]

[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Emacs should not be part of the 'basics' (I say this as an emacs user).

I think we should have a priority between "Standard" and "Optional",
perhaps named "Recommended".  These are packages which would be
"Standard", but for size.  Tex and a lot of X should also appear here.

-- 
Raul

Re: what's after slink

[Raul Miller]

> > On a related note, do we want to continue using names from pixar movies
> > now that Bruce is gone?

Justin Maurer <[EMAIL PROTECTED]> wrote:
> i see no reason not to. they are nice names, the only problem is that we
> may be running out of good ones (i admit, rc was a stretch)


Is this supposed to imply that there's something wrong with
"Mr. Potato Head"?


-- 
Raul

Re: expect trouble

[Raul Miller]

Paul Stevens <[EMAIL PROTECTED]> wrote:
> Ever since hamm, expect has been giving me serious trouble. It won't
> run cleanly when started from cron. This means that a lot of my
> expects scripts are broken. I use expect extensively for system
> maintanance and accounting (make sure servers run, upload websites and
> databases, etc)

I've had this problem too. I've been working around it by allocating a
high-numbered tty on the console and redirection descriptors 0, 1 and
2 to that tty.

[I tried doing a bug report on it a year or so ago, and even got a
response from Don Libes.  Of course, that was for the use of expect's
"interact" command, but basically he was saying that the behavior I was
describing was appropriate (after a rather minor change specifically to
support linux).  I kinda gave up on the bug-reporting side of things at
that point, as I just needed to get my stuff working.]

-- 
Raul

Re: Release Critical Bugs List

[Raul Miller]

Contrib and Non-free packages can't have release critical bugs --
they're not even an official part of debian.

-- 
Raul

Re: vat & tcl8.0.3

[Alex Romosan]

David Engel <[EMAIL PROTECTED]> writes:

> On Thu, Oct 01, 1998 at 12:27:17PM -0700, Alex Romosan wrote:
> > can somebody who know more about tcl (maybe even the tcl maintainer)
> > take a look at this? i appreciate any help. thank you.
> 
> I (the Tcl maintainer) don't have time to do this right now.  Sorry.
> 
okay, i posted this a week ago, and since then i've been trying to
find the solution, with no luck though. i've searched the usenet
archives at altavista/dejanews, read the comp.lan.tcl newsgroup. there
is no mention of this problem. what i've discovered so far is that
none of the mbone programs which use embedded tcl (sdr/vat/vic/nt these
are the ones i know of) work with the current 8.0.3. they all crash
with the same error message:

  invalid command name "tcl_findLibrary" 

they all work fine if downgrade to 8.0p2. i've tried compiling them
with tcl8.0p2-dev and then upgrading to 8.0.3 (as i said before) and
they don't work anymore.

i think this is a bug in tcl 8.0.3. i am willing to investigate this a
little bit further, but i need help. does anybody know of any programs
that use tcl translated to c and compiled into the executable? i want
to see if they work under tcl 8.0.3. all the mbone programs use the
same tcl2c(++) translator which might be the problem.

if we can't get this working by the freeze i propose we take these
packages out of the next stable release (i guess we won't have a
choice anyway). sorry to bother you all (and especially david) but i
need help (and i didn't really get any responses last time).

--alex--

-- 
| I believe the moment is at hand when, by a paranoiac and active |
|  advance of the mind, it will be possible (simultaneously with  |
|  automatism and other passive states) to systematize confusion  |
|  and thus to help to discredit completely the world of reality. |

Re: gdselect alpha 2

[Shaya Potter]

-Original Message-
From: Tom Lees <[EMAIL PROTECTED]>


>alpha 2 is released at http://www.lpsg.demon.co.uk/gdselect/


I was trying to compile it, had a little problem with some includes on glib,
which I overcame, but it seg faulted (or something like that, said glib
caught it) in the initial run and setup, this is on a system that has latest
gtk and glib, but is 100MB behind in other regards (been away from this
machine for a month, running apt tonite on it).

Shaya

boot-floppies, rewrite of help screens

[Marc Singer]

I spent some time rewriting the help screens for the rescue disk to
make them more comprehensible and to add information about using the
rescue disk to rescue a system.  I put the patch on master

  //master.debian.org/~elf/patches/boot-floppies_2.0.11_p1

Comments?

Re: vat & tcl8.0.3

[David Engel]

On Thu, Oct 08, 1998 at 08:10:09PM -0700, Alex Romosan wrote:
> David Engel <[EMAIL PROTECTED]> writes:
> 
> > On Thu, Oct 01, 1998 at 12:27:17PM -0700, Alex Romosan wrote:
> > > can somebody who know more about tcl (maybe even the tcl maintainer)
> > > take a look at this? i appreciate any help. thank you.
> > 
> > I (the Tcl maintainer) don't have time to do this right now.  Sorry.
> > 
> okay, i posted this a week ago, and since then i've been trying to
> find the solution, with no luck though. i've searched the usenet
> archives at altavista/dejanews, read the comp.lan.tcl newsgroup. there
> is no mention of this problem. what i've discovered so far is that
> none of the mbone programs which use embedded tcl (sdr/vat/vic/nt these
> are the ones i know of) work with the current 8.0.3. they all crash
> with the same error message:
> 
>   invalid command name "tcl_findLibrary" 

tcl_findLibrary is a new proc added in v8.0.3.  It is implemented in
the init.tcl startup script.  I suspect tcl2c needs to incorporate
this into it's version of init.tcl or equivalent since the libtcl8.0
library expects it to be present.

> if we can't get this working by the freeze i propose we take these
> packages out of the next stable release (i guess we won't have a
> choice anyway). sorry to bother you all (and especially david) but i
> need help (and i didn't really get any responses last time).

The upcoming freeze doesn't mean you can't fix bugs, especially
serious ones, like this.  It means that you can't introduce completely
new packages or major new versions of existing packages without good
reason.

David
-- 
David Engel
[EMAIL PROTECTED]

Re: Perl policy for managing modules ?

[warp]

Ok, after some thought, and fielding a LOT of perl questions on #debian,
I've come up with a more workable idea which gives us much better
handling for the next time something like this happens..

Rename perl to perl5.005, version 02-2 or such..
Then use the alternatives setup to decide which perl gets run when you
try to use just 'perl'..

At that point packages which are NOT subject to binary compatibility
issues can depend on perl5, and those which are can depend on perl5.005,
etc..

This allows us to both handle future perl upgrades cleanly, and allows
us to maintain more then one version of perl at any given time..

Any comments?

Zephaniah E, Hull..

On Thu, Oct 08, 1998 at 09:57:36AM -0400, Dan Jacobowitz wrote:
> > Le Thu, Oct 08, 1998 at 02:31:40AM -0700, Darren/Torin/Who Ever... écrivait:
> > > I do worry about what this might break as well.  Another option would be 
> > > to have /usr/lib/perl5/debian(/$arch)? be the first element of @INC and
> > > leave /usr/lib/perl5/$version(/$arch)? there with only the Perl
> > > installed files.  I'll ask on p5p if this will break things.
> 
> My question is, why are we so intent on removing the versioned
> component even though we have lost binary compatibility?  I understand
> that it requires some packaging changes, but the packaging can usually
> be easily rewritten to work for any version (use perl5/5.*/, etc.).
> 
> Dan
> 
> 
> --  
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 


pgpk4oO1Le4IK.pgp
Description: PGP signature

Re: kdelibs and contrib

[Russell Coker]

On Fri, 09 Oct 1998, Wichert Akkerman wrote:
>>
>Now that all of KDE has gone, we are left with one issue: kdelibs.
>From what I heard kdelibs is LGPL'd and can be distributed freely.
>This would mean that someone could reupload it and it will be
>accepted into contrib?

I think that the packages qt*, kdesupport*, and kdelibs* should be included
in non-free.  There's nothing in the policy to stop them and it just makes
things that much easier for Debian users who want to use KDE.

Re: suggestion - AntiVir for Linux

[Robert Woodcock]

[EMAIL PROTECTED] wrote:
>On Thu, 8 Oct 1998, Chris wrote:
>> Since when did linux get virus's   You'd only get them on a really
>> bad system - which debian is not (or if you did EVERYTHING as root).
>
>On a linux system exporting disk space to Windows machines, it is indeed
>practical to have an anti-virus able to report if your shares contains
>virii.

Just out of curiosity would anyone be interested in a mcafee virusscan
installer package in slink contrib? I have everything created, the only
thing I'd have to work on would be upstream upgrades (it currently doesn't
handle this at all) and then I'd write an intent to package and upload it.

I could probably squeeze it in before the freeze.

Thing is, Network Associates Inc. is axing the Mcafee engine in favor of Dr
Solomon soon.

However, it *is* the world's first self-replicating debian package :)
(build-uvscan makes full debs of the engine and datfiles, the engine deb
includes build-uvscan :)
-- 
Robert Woodcock - [EMAIL PROTECTED]
"Unix and C are the ultimate computer viruses" -- Richard Gabriel

Re: Release Critical Bugs List

[Joseph Carter]

On Fri, Oct 02, 1998 at 07:00:31PM -0400, Raul Miller wrote:
> Contrib and Non-free packages can't have release critical bugs --
> they're not even an official part of debian.

yeah yeah, the package ain't part of Debian anymore because of a lack of
license and no way to get the author to fix it.  =p  Sue me.  =>


pgppdwUlW6Dj8.pgp
Description: PGP signature

Re: gdselect alpha 2 (BUG Report)

[Steve Dunham]

"Shaya Potter" <[EMAIL PROTECTED]> writes:

> -Original Message-
> From: Tom Lees <[EMAIL PROTECTED]>
> 
> 
> >alpha 2 is released at http://www.lpsg.demon.co.uk/gdselect/

> I was trying to compile it, had a little problem with some includes on glib,
> which I overcame, but it seg faulted (or something like that, said glib
> caught it) in the initial run and setup, this is on a system that has latest
> gtk and glib, but is 100MB behind in other regards (been away from this
> machine for a month, running apt tonite on it).

This is due to a hard coded buffer size, see the end of this message:

Program received signal SIGSEGV, Segmentation fault.
0x4021a390 in   ()
(gdb) bt
#0  0x4021a390 in   ()
#1  0x8052460 in dpkgtag_mergetags (first=0x84919a0, t=0x83b2d08, flags=4, 
proc=0x804b210 ) at pkg.c:375
#2  0x804b466 in DoProcess (a=1, s=1) at main.c:111
#3  0x804b869 in ReadAvailStatus () at main.c:189
#4  0x804bba3 in main (argc=1, argv=0xbd54) at main.c:237
(gdb) up
#1  0x8052460 in dpkgtag_mergetags (first=0x84919a0, t=0x83b2d08, flags=4, 
proc=0x804b210 ) at pkg.c:375
375 if (!strcasecmp (p->name, p_name) &&
(gdb) p *p
$1 = {first_tags = 0x84a6778, name = 0x0, ver = 0x0, 
  descr_line1 = 0x84a68b8 "Guile-Gtk scheme interpreter (part of Gnome)", 
  descr = 0x84a6788 "Gnome is the \"GNU Network Object Model Environment\"\nIt 
is a project to build a complete, user-friendly desktop based entirely on free 
software.\nThis package contains the guile-gtk and gnomeg scheme in"..., 
  pri = dpkgpri_required, section = 0x0, source = 0x0, next = 0x84a68f0, 
  pkg_av = 0x0, pkg_stat = 0x0, deps = 0x0, dependents = 0x0, flags = 2, 
  data = 0x0, status = dpkgst_avail, selected = dpkgsel_unknown, 
  error = dpkgfl_ok}
(gdb) p p_name
$2 = 0x83b2d30 "libgdk-imlib1"

This happens when it's part of the way through processing the Status
file.  I checked both status and available and the "gnome-guile"
entry has a "Package: gnome-guile" line in both files.

I downloaded the cvs snapshot and checked out alpha_1, and it crashes
at the same spot (p_name="libgdk-imlib1", p->name=0, package in p is
gnome-guile).


Just checked the entry for gnome-guile package.  Noticed one
pecularity: the "Depends" line is 330 characters long.

I increased LINE_BUFSZ to 512 in tags.c, and the problem goes away.

A correct solution would be to fix tagfile_read_tags().  If there is
no "\n" terminating the string, then there is more to read.  (Unless
EOF.)


Steve
[EMAIL PROTECTED]

Intent to package intlfonts

[Milan Zamazal]

I'd like to package intlfonts for X available on GNU FTP.  They are
especially useful for Emacs.  Since this package is big, I'll probably
make several smaller binary packages from it.

Milan Zamazal

Re: Back to RedHat

[Ole J. Tetlie]

*-Raul Miller <[EMAIL PROTECTED]>
|
| [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
| > Emacs should not be part of the 'basics' (I say this as an emacs user).
| 
| I think we should have a priority between "Standard" and "Optional",
| perhaps named "Recommended".  These are packages which would be
| "Standard", but for size.  Tex and a lot of X should also appear here.

This has been on my wishlist too.

-- 
...Unix, MS-DOS, and MS Windows (also known as the Good, the Bad,
and the Ugly).   (Matt Welsh)
[EMAIL PROTECTED]   [-: .elOle. :-]   [EMAIL PROTECTED]

Intent to package: python-mxtexttools, python-mxcrypto

[Gregor Hoffleit]

I'd like to announce my intention to package two more python add-on
modules:

 Package: python-mxtexttools
 Version: 1.0.1-0
 Section: interpreters
 Priority: optional
 Architecture: i386
 Depends: libc6, python-base (>= 1.5)
 Installed-Size: 132
 Maintainer: Gregor Hoffleit <[EMAIL PROTECTED]>
 Description: Fast text manipulation tools for Python
  Fast text manipulation tools for Python.

 Package: python-mxcrypto
 Version: 0.1.0-0
 Section: non-US/interpreters
 Maintainer: Gregor Hoffleit <[EMAIL PROTECTED]> 
 Description: Generic SSLeay crypto wrapper type for Python
  A Python wrapper for the ciphers and hash functions in Eric Young's
  SSLeay library.



-- 
| Gregor Hoffleit admin MATHInet / contact HeidelNeXT |
| MAIL: Mathematisches Institut   PHONE: (49)6221 56-5771 |
|   INF 288, 69120 Heidelberg / Germany  FAX: 56-3812 |
| EMAIL: [EMAIL PROTECTED] (NeXTmail)|

Re: PGP in the US (Re: formal documents)

[Carey Evans]

Hamish Moffatt <[EMAIL PROTECTED]> writes:

> This reminds me of a joke; unfortunately I couldn't track it down
> in a quick look on altavista and I haven't any more time to look for it.
> In short, a man attends several days of a trade show and each day
> tells a security guard that today he will steal many things and yesterday
> he stole many good things. He is stealing ideas.

% fortune -m 'stealing ideas'
(computers)
%
There once was a man who went to a computer trade show.  Each day as
he entered, the man told the guard at the door:
"I am a great thief, renowned for my feats of shoplifting.  Be
forewarned, for this trade show shall not escape unplundered."
This speech disturbed the guard greatly, because there were millions
of dollars of computer equipment inside, so he watched the man carefully.
But the man merely wandered from booth to booth, humming quietly to himself.
When the man left, the guard took him aside and searched his clothes,
but nothing was to be found.
On the next day of the trade show, the man returned and chided the
guard saying: "I escaped with a vast booty yesterday, but today will be even
better."  So the guard watched him ever more closely, but to no avail.
On the final day of the trade show, the guard could restrain his
curiosity no longer. "Sir Thief," he said, "I am so perplexed, I cannot live
in peace.  Please enlighten me.  What is it that you are stealing?"
The man smiled.  "I am stealing ideas," he said.
-- Geoffrey James, "The Tao of Programming"
%

I've seen the entire Tao available to download somewhere.

-- 
 Carey Evans  http://home.clear.net.nz/pages/c.evans/

"So, do you steal weapons from the Army often?"
"Well, we don't get cable, so we have to make our own fun."

Re: lesstif

[Hamish Moffatt]

On Thu, Oct 08, 1998 at 11:15:09AM +0200, Michael Meskes wrote:
> I was right in that lesstif causes my problems. After reverting to the hamm
> version everything is fine again. So there either is a bug in lesstifg or an
> incompatibility.

Odd. I've recently been coding a simple Motif program for a university
assignment, and the versions in slink work ten times better than the one
in hamm. (Perhaps my program was buggy when I tried it though, but code
that didn't work on lesstifg from hamm did work on real Motif on Solaris.)


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

Re: Ratifying the constitution

[Ian Jackson]

(I've now caught up on debian-devel, barring my 7 articles marked to
return, of which this was one ...)

Guy Maor writes on the 10th of September:
> Yes, let's.
> 
> I am formally proposing version 0.8 of the constitution as given in
> .
> Although Ian has formerly proposed this version, any proposed
> amendments would stall the process due to his effective absence.
> 
> There are 357 unique entries in the Maintainers file.  Q is 9.9, K is
> 5.  We therefore need 5 seconds and a quorum of 30 votes.  Minimum
> discussion period is 2 weeks.

Thanks, Guy !  I was going to post to reduce the minimum discussion
period, but this is now unnecessary.  Would you like to call for a
vote now ?

Brian Basset mailed me to say that his mail problem was temporary, so
he'll be the Secretary, unless people have strong objections or he'd
like to give the job to someone else.  Alternatively, Brian may wish
to delegate his authority to one of the people who've been working on
voting software.

Ian.

Re: Ratifying the constitution

[Ian Jackson]

Buddha Buck writes ("Re: Ratifying the constitution "):
...
> That's not what it means.  It means that in order for an amendment to 
> automatically be accepted, you need to convince 6 people, Guy and the 
> five seconds.
> 
> If they don't like it, you can force it to a vote.  I think you require 
> seconds yourself inorder to do that, and then when it comes to a vote, 
> you have to have a 3:1 majority.

No, that's not true.  The 3:1 majority only applies to changing the
constitution once it's accepted, not to amendments.  A.6(7):

7.If a supermajority is required the number of Yes votes
  in the final ballot is reduced by an appropriate factor.
  ^^^

...
> 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
> Steve McIntyre, Jay Treacy, et al aren't realy doing the traditional 
> job of "seconds", which is to indicate that there is enough interest to 
> justify discussing an issue.  Seconds traditionally aren't even 
> recorded, just acknowledged as existing.  Here, they have a lot more 
> power than that.  They are recorded by name, their must be a minimum 
> number of them (mere existance isn't enough, there must be sufficient 
> strength), and they must approve any "friendly amendment".  Not only 
> that, but if the proposer should fail to perform his duties, one of the 
> seconds can assume that role (under the proper procedures).  It is 
> assumed that these five support the proposed constitution, not just 
> feel it merits discussion.  Seconds traditionally are allowed to argue 
> against a measure the seconded -- they may have wanted the issue to be 
> officially discused and killed.  This is not the role of Steve 
> McIntyre, Jay Treacy, etc.
> 
> I propose that the constitution be modified to replace the work 
> "second" (and affiliated declinations thereof) with the word "sponsor" 
> (and affiliated declinations thereof), when used to refer to the people 
> formally supporting a proposal brought forth under this constitution.
> ---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'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.

Re: Discussion - Proposed Constitution - voting part 2

[Ian Jackson]

Darren Benham writes ("Discussion - Proposed Constitution - voting part 2"):
> I've found another area that could cause problems in the vote counting area. 
> I've been running various sceanios and here's what I've found:
> 
> In point 5 of A.6. describes the STV method.  Basicly, if no one
> option has 1/2 the votes, The option that got the least number of
> votes is removed and every ballot that had that option listed as 1st
> prefered, will use thier 2nd prefered as 1st and 3rd prefered as
> 2nd.  If a ballot has had all of it's options disqualified (lets say
> they only voted a 1 in one option and left the others blank.. and
> that option gets disqualified), their "vote" has no options.  The
> Constitution doesn't state what to do with these ballots so they
> remain counted toward the "total half" needed by the winning option
> but they don't add any count to any option.  It's possible for this
> "no preference" to actually win the vote.  The constitution doesn't
> state what this would mean, either...  This is particularly possible
> in the cases where a Supermajority is needed.  Possible Options that
> wouldn't be far fetched: "no preference" = the default option or
> ballots with no preference don't count towards the "half" needed to
> win.

A.6(5)(iii):
  This elimination procedure is repeated, moving down ballot papers to
  2nd, 3rd, 4th, etc. preferences as required, until one option gets
  more than half of the `first' preferences.

It seems to me to be clear that the intent is that if a ballot has no
remaining preferences then it doesn't count when considering which
option might have "more than half of the `first' preferences".  Such a
ballot couldn't be said to have a "`first' preference" any more,
surely ?

> In point 8, where Quorum is talked about, it states that for an
> option to win, it must have X more votes for than vs. the default
> option.  Ok, there are two methods used to determine a winner if
> method one doesn't produce a winner (More people prefer this option
> against that option) we switch to the other method (STV).  These two
> methods can *often* result in different outcomes so the answer to
> this next question can make an important difference in the outcome
> of votes: If the first method produces a clear winner ( "4.  If
> there is any option which Dominates all others then that is the
> winner" and "2.  option A is said to Dominate option B if *strictly*
> more ballots prefer A to B than prefer B to A" emphasis mine), but
> fails to get the Quorum, do we still switch to the STV method ( "5.
> If there is now *more than one* option remainging STV will be
> applied to choose amongst those remaining" emphasis mine) of do we
> end the count there and declare the default option to have won?  I
> think the constitution implies that the vote ends there...

A.6(8):
   8.If a quorum is required, there must be at least that many votes
   which prefer the winning option to the default option.  If there
   are not then the default option wins after all. For votes requiring
   a supermajority, the actual number of Yes votes is used when
   checking whether the quorum has been reached.

The "winning option" here refers to the outcome of steps 1-7, clearly,
and 8 is intended to _modify_ the outcome.  So, if Concorde doesn't
produce a clear-cut answer we use STV amongst the remaining options,
and then we have a putative `winner'.  If this winner didn't actually
have enough ballots which prefer it to the default, then the default
option is declared the winner.  There's nothing saying we should go
and restart the ballot counting with STV instead, or something.  The
condition for using 4 or 5 is whether there is one option which
Dominates all the others, and 8 can't change the answer to that
question.

Ian.

Re: Contacting authors

[Ian Jackson]

Martin Schulze writes ("Contacting authors"):
> tonight I was thinking about implementing @authors.debian.org which
> would enable a way for us to get in touch with the upstream authors of
> some piece of software without the need of looking into the copyright
> file or digging in the source if the maintainer forgot to add the
> authors email into that file.
> 
> What do you think about it?
> 
> Example: [EMAIL PROTECTED] would redirect the mail to
> [EMAIL PROTECTED] who is the current developer of hypermail.

I'm sorry to say that I think this is a bad idea.  I think most
authors wouldn't want to be contacted in this way - I know that I in
my capacity as upstream author wouldn't.

Making it easy to contact the upstream author(s) in this way will
encourage our users to contact them directly, and many (most) of these
messages will be about Debian-specific things.  One of the main
reasons we have package maintainers is to filter bogus mail, so that
upstream authors don't get bombarded with questions and bug reports
about Debian.

Furthermore, the procedures and requirements for contacting upstream
authors vary greatly: in some cases the upstream author suggests use
of a mailing list, in others they're an individual, in some cases a
group.  Sometimes mail to this address will generate an automatic
response; sometimes it will bounce.  Packages vary in the conventions
expected when contacting the upstream author: for example, some
authors really like patches, others loath them.  I don't think we can
harmonise this (or that it would be desirable to do so), and we
shouldn't pretend to people that we have done by presenting a
harmonised interfac3e.

Clueful people who know that they want to contact the upstream authors
can read the details in /usr/doc - most packages include there the
upstream READMEs etc. which give instructions for contacting the
authors.

Thanks, and sorry to be negative,
Ian.

Re: perl version depends

[Raphael Hertzog]

Le Thu, Oct 08, 1998 at 08:54:46PM -0400, Michael Alan Dorman écrivait:
> Threaded perl and non-threaded perl are binary-incompatible at the
> extension level, meaning most compiled extensions must be
> distinguishable.

I think you're wrong. perl5.005 and perl5.005-thread are binary-compatible.
But in order to support threads, they had to break the 
binary-compatibility beetween perl5.004 and perl5.005. That's it.

> So, yes, I think Debian does have to honor this, and to make our perl
> gratuitously different (which is to say, having it look in
> /usr/lib/perl5) would be inviting calamity some time down the road.

Which in fact doesn't mean we cannot add /usr/lib/perl5 at the end
of @INC because architecture-dependant packages will be found 
before.

Cheers,
-- 
Hertzog Raphaël ¤ 0C4CABF1 ¤ http://www.mygale.org/~hra/

The freeze and IMMINENT 2.2.0p1!!

[warp]

In light of the perl issues (see my last message) and the message Linus
just sent off to linux-kernel about 2.1.125 and 2.2.0p1 could the freeze
be pushed back a week to see if we should QUICKLY re-target slink
towards 2.2.0?

Thanks.

Zephaniah E, Hull..


pgpL2Z9IpY4sx.pgp
Description: PGP signature

Re: kdelibs and contrib

[Raul Miller]

Wichert Akkerman <[EMAIL PROTECTED]> wrote:
> I hate replying to myself, but here we go..
> kdelibs is LGPL. As someone mentioned it does use some code derived
> from gettext (libintl.cpp), which is GPL. However the code was taken
> from a version modified for glibc2 where is was redistributed as LGPL.
> I'll put the exact copyright message below.

All this LGPL stuff should be documented in the copyright file.

LGPL is a perfectly acceptable license for us to distribute KDE
under -- if that's really the case.

-- 
Raul

Intent to package python-opengl and pcgi

[Gregor Hoffleit]

Then, I'd like to announce my intention to package python-opengl and 
pcgi. python-opengl depends on togl, which has not yet been packaged.

 Package: python-opengl
 Depends: mesag2, togl, python-tk
 Description: An Python interface for OpenGL, GLU, GLUT and Togl
  PyOpenGL provides bindings between the Python language and OpenGL and 
  related libraries.

 See also: 

 Package: togl
 Depends: mesag2, tk80
 Description: A Tk OpenGL widget
  Togl is a Tk widget for OpenGL rendering.Togl allows one to create and 
  manage a special Tk/OpenGL widget with Tcl and render into it with a C
  program. That is, a typical Togl program will have Tcl code for managing 
  the user interface and a C program for computations and OpenGL rendering. 

 Home page: http://www.ssec.wisc.edu/~brianp/Togl.html



 Package: pcgi
 Recommends: python-bobo
 Depends: python-net
 Description: Persistent CGI for Python
  Persistent CGI provides a transparent architecture for accessing 
  published web objects as long-running processes. Published objects may 
  be accessed on any server supporting CGI.
  Pcgi is designed to work with Bobo (the Python object publisher), 
  effectively turning a Bobo application into a fast, long-running web 
  application without requiring any changes to the application code.

 Home page: http://www.digicool.com/releases/pcgi/

Re: The freeze and IMMINENT 2.2.0p1!!

[J.H.M. Dassen \(Ray\)]

On Fri, Oct 09, 1998 at 06:40:54AM -0400, [EMAIL PROTECTED] wrote:
> In light of the perl issues (see my last message)

A bug report has been submitted to ftp.debian.org to put the previous
version back, which means the perl issues need not be dealt with in the
current development cycle.

> and the message Linus just sent off to linux-kernel about 2.1.125 and
> 2.2.0p1 could the freeze be pushed back a week to see if we should QUICKLY
> re-target slink towards 2.2.0?

I'm not aware of any software in slink that must be updated to work with 2.2
properly (with the exception of pcmcia-cs); slink currently runs fine with
2.1.x (which I suspect quite a few developers run).

If the release manager is willing to accept the 2.2 kernel and rebuilt
bootdisks during the freeze, I see no reason to postpone the freeze date.
Brian?

Ray
-- 
POPULATION EXPLOSION  Unique in human experience, an event which happened 
yesterday but which everyone swears won't happen until tomorrow.  
- The Hipcrime Vocab by Chad C. Mulligan 

When will the freeze happen ???

[Gregor Hoffleit]

Sorry, maybe I'm deaf or blind or my mail spool went to /dev/null, but I 
never saw a concrete date for the freeze in the last months. Can somebody 
enlighten me when it will happen ?

Gregor

Re: The freeze and IMMINENT 2.2.0p1!!

[Santiago Vila]

On Fri, 9 Oct 1998 [EMAIL PROTECTED] wrote:

> In light of the perl issues (see my last message) and the message Linus
> just sent off to linux-kernel about 2.1.125 and 2.2.0p1 could the freeze
> be pushed back a week to see if we should QUICKLY re-target slink
> towards 2.2.0?

I don't think this would be a good idea, even if we delay the freeze.

There are a lot of packages that would have to be recompiled for
Linux 2.2. This will take time and a lot of testing.

But if Linux 2.2 is released as stable in the near future, maybe we should
release Debian 2.2 soon after Debian 2.1. This way we would have more
time to think about the complex FHS move.

-- 
 "3a872f2b50d454b17721f21b6fd30055" (a truly random sig)

Re: Contacting authors

[Martin Schulze]

Ian Jackson wrote:
> Martin Schulze writes ("Contacting authors"):
> > tonight I was thinking about implementing @authors.debian.org which
> > would enable a way for us to get in touch with the upstream authors of
> > some piece of software without the need of looking into the copyright
> > file or digging in the source if the maintainer forgot to add the
> > authors email into that file.
> > 
> > What do you think about it?
> > 
> > Example: [EMAIL PROTECTED] would redirect the mail to
> > [EMAIL PROTECTED] who is the current developer of hypermail.
> 
> I'm sorry to say that I think this is a bad idea.  I think most
> authors wouldn't want to be contacted in this way - I know that I in
> my capacity as upstream author wouldn't.

> Making it easy to contact the upstream author(s) in this way will
> encourage our users to contact them directly, and many (most) of these
> messages will be about Debian-specific things.  One of the main
> reasons we have package maintainers is to filter bogus mail, so that
> upstream authors don't get bombarded with questions and bug reports
> about Debian.

How many maintainer are false contacted via the packages.debian.org
mechanism?  This mechanism was implemented a long time ago and I
guess that it's even documented on the web somewhere.

> Thanks, and sorry to be negative,

No problem.  That's why I've asked.  For me the question is
not "to do or not to do" anymore but "do it locally or let
other maintainers benefit from it".  Thus, a "stop that"
is ok, too.

You wouldn't want to implement any such mechanism?

Regards,

Joey

-- 
No question is too silly to ask, but, of course, some are too silly
to answer.   -- Perl book

Re: dpkg config files in /etc ?

[Thomas Gebhardt]

Hi,

> My general rule of thinking about it is:
> state is an opion within the program which can be changed and
> should be remembered next time.
> esp something which reasonably could change every time the program
> is used (it is concievable I have a CD today...in a month I am FTP
> upgrading)
> 
> this is not something which is meant to be changed "by hand"
> besides...

There are several packages that supply a -config script
to manipulate their config files because their config files are rather
complex (e.g., sendmail). The config files are, however, located
in /etc.

> the main rational for /var is to allow other partitions to be mounted
> read only...
> if this were stored in /etc/etc would HAVE to be mounted read-write
> 
> (though I supose given the nature of deslect you could argue everything
> excpet /home and /usr/local should be read-write...)

Yes, when I change the access method or the list of selected packages
I am almost certainly going to upgrade the system and therefore /etc
and /usr have to be mounted r/w anyhow.

My point is that the list of selected packages belongs to the *basic*
configuration of a debian system and it should be stored on /etc.

We have a whole bunch of different desktop debian machines and I
want to be shure that I can restore the state of each machine after
a disk crash. To rebuild a single system I need

* the knowledge of the physical disk layout
* a backup copy of /etc and /home
* a debian archive
* some information hidden in /var/lib/dpkg

It would be fine and consistent, if I could omit the last point.

Cheers, Thomas

Re: The freeze and IMMINENT 2.2.0p1!!

[Samuel Tardieu]

> "Santiago" == Santiago Vila <[EMAIL PROTECTED]> writes:

Santiago> There are a lot of packages that would have to be recompiled
Santiago> for Linux 2.2. This will take time and a lot of testing.

I can see pcmcia (28-Sep-98 is needed) and netutils (so that IPv6 is
supported), but not "a lot of packages".

Also, from a marketing point of view, it would be great to have the
first distribution using Linux 2.2 :-) Imagine the stickers on the CDs :)

  Sam
-- 
Samuel Tardieu -- [EMAIL PROTECTED]

Re: The freeze and IMMINENT 2.2.0p1!!

[Samuel Tardieu]

> I'm not aware of any software in slink that must be updated to work with 2.2
> properly (with the exception of pcmcia-cs); slink currently runs fine with
> 2.1.x (which I suspect quite a few developers run).

I do run 2.1.124 on my laptop and am really impressed by this
kernel. It uses less memory and runs smoother under heavy load than
any kernel I've ever used.

Moreover, it has never been so easy to configure my soundcard and IP
firewalling with ipchains is really comfortable compared to ipfwadm.

  Sam
-- 
Samuel Tardieu -- [EMAIL PROTECTED]

Re: The freeze and IMMINENT 2.2.0p1!!

[J.H.M. Dassen \(Ray\)]

On Fri, Oct 09, 1998 at 01:20:34PM +0200, Samuel Tardieu wrote:
> I can see pcmcia (28-Sep-98 is needed) and netutils (so that IPv6 is
> supported), but not "a lot of packages".

IIRC, libc6 doesn't support IPv6; you need a beta version for that. So this
is only an issue if we intend to release one of the libc6.1 using ports.
 
Ray
-- 
Tevens ben ik van mening dat Nederland overdekt dient te worden.

Re: Consensus on source packages for ports?

[Wichert Akkerman]

Previously David Welton wrote:
> So, is there any consensus on how to upload source packages for ports?
> I have some things like strace that I would like to upload for arm,
> but the source is fairly different...  Hrmm... pondering.. maybe I can
> get around it.. hrmmm

I would suggest first mailing the maintainer. Esp. in the case
of strace which is rapidly becoming a nightmare to support on all
architectures and different libc version.

Wichert. (who is the strace maintainer)

-- 
==
This combination of bytes forms a message written to you by Wichert Akkerman.
E-Mail: [EMAIL PROTECTED]
WWW: http://www.wi.leidenuniv.nl/~wichert/


pgpJ3fJJb9lDw.pgp
Description: PGP signature

Re: The freeze and IMMINENT 2.2.0p1!!

[Santiago Vila]

On 9 Oct 1998, Samuel Tardieu wrote:
> Santiago> There are a lot of packages that would have to be recompiled
> Santiago> for Linux 2.2. This will take time and a lot of testing.
> 
> I can see pcmcia (28-Sep-98 is needed) and netutils (so that IPv6 is
> supported), but not "a lot of packages".

Well, kernel-package is a single package but it would be surely
a lot of work, since there are a lot of new drivers.

We should base our distribution in stable software, not in betas.

Maybe we should wait for 2.0.36, not for 2.2.

-- 
 "33ca525b2c9f2cd0f9b40ef52e0d64f6" (a truly random sig)

contacting porters (was: Contacting authors)

[Paul Slootman]

On Thu 08 Oct 1998, Edward Betts wrote:
> 
> And while we are doing it how about implementing @m86k.porter.debian.org or
> @arm.builder.debian.org for the person who has recomplied the package on
> different machines (m86k, powerpc, alpha, arm, etc).

Now this _is_ a good idea! I've already asked on debian-alpha a couple
of times "who ported this package?".  I port a lot of alpha packages
myself, and don't always remember whether I did the current version or
maybe a previous version...

This list could be updated via the maor-installer thing (whatever also
sends the email message; that has all the info right there).

> > An easy way to implement this would be to simply add a line to the
> > source section of debian/control of each package like
> 
> Likewise with builder, or not? Would you need m86k-builder and arm-builder and
> powerpc-builder or would it be done differently?

It's there in the changes file... Note that this would imply that there
should also be a [EMAIL PROTECTED] which would usually
be the same as [EMAIL PROTECTED] (but not always! The
maintainer may use something else besides i386 as his platform).


Paul Slootman
-- 
home: [EMAIL PROTECTED] | work: [EMAIL PROTECTED] | debian: [EMAIL PROTECTED]
http://www.wurtel.demon.nl | Murphy Software,   Enschede,   the Netherlands

Re: Contacting authors

[Santiago Vila]

On Thu, 8 Oct 1998, Peter S Galbraith wrote:

> The author should get the credit, and more exposition...

Policy says /usr/doc//copyruight should say who written the
program. The credit should be already there.

> Or are we afraid that they might get bug reports that should go the the
> Debian bug tracking system?

Yes, I'm *very* afraid.

I fully agree with Ian and think it is not a good idea.

-- 
 "1afbf0651886aa5cfc2a65f0cac3e2d3" (a truly random sig)

important perl5.005 issues (was Re: perl version depends)

[Michael Alan Dorman]

Raphael Hertzog <[EMAIL PROTECTED]> writes:
> Le Thu, Oct 08, 1998 at 08:54:46PM -0400, Michael Alan Dorman écrivait:
> > Threaded perl and non-threaded perl are binary-incompatible at the
> > extension level, meaning most compiled extensions must be
> > distinguishable.
> I think you're wrong. perl5.005 and perl5.005-thread are binary-compatible.
> But in order to support threads, they had to break the 
> binary-compatibility beetween perl5.004 and perl5.005. That's it.

I think you should read the docs or follow the last couple of years of
the perl5 development mailing list, as I have, before you suggest you
know better than I.  From doc/perldelta.pod:

-8<-
=head2 Binary Compatibility

This version is NOT binary compatible with older versions.  All extensions
will need to be recompiled.  Further binaries built with threads enabled
are incompatible with binaries built without.  This should largely be
transparent to the user, as all binary incompatible configurations have
their own unique architecture name, and extension binaries get installed at
unique locations.  This allows coexistence of several configurations in
the same directory hierarchy.  See F.
->8-

> > So, yes, I think Debian does have to honor this, and to make our perl
> > gratuitously different (which is to say, having it look in
> > /usr/lib/perl5) would be inviting calamity some time down the road.
> Which in fact doesn't mean we cannot add /usr/lib/perl5 at the end
> of @INC because architecture-dependant packages will be found 
> before.

Possibly.  But, also from doc/perldelta.pod:

-8<-
=head2 Perl Source Compatibility

When none of the experimental features are enabled, there should be
very few user-visible Perl source compatibility issues.

If threads are enabled, then some caveats apply. C<@_> and C<$_> become
lexical variables.  The effect of this should be largely transparent to
the user, but there are some boundary conditions under which user will
need to be aware of the issues.  For example, C results in
a "Can't localize lexical variable @_ ..." message.  This may be enabled
in a future version.

Some new keywords have been introduced.  These are generally expected to
have very little impact on compatibility.  See L keyword>,
L keyword>, and L operator>.

Certain barewords are now reserved.  Use of these will provoke a warning
if you have asked for them with the C<-w> switch.
See L is now a reserved word>.
->8-

So, there is no guarantee that existing perl modules may not trigger
new warnings or other issues when run under the new perl.

So, IMNSHO, the smarter thing to do would be to not add /usr/lib/perl5
to @INC.

Mike.

Re: The freeze and IMMINENT 2.2.0p1!!

[Paul Slootman]

On Fri 09 Oct 1998, J.H.M. Dassen Ray" wrote:
> 
> > and the message Linus just sent off to linux-kernel about 2.1.125 and
> > 2.2.0p1 could the freeze be pushed back a week to see if we should QUICKLY
> > re-target slink towards 2.2.0?
> 
> I'm not aware of any software in slink that must be updated to work with 2.2
> properly (with the exception of pcmcia-cs); slink currently runs fine with
> 2.1.x (which I suspect quite a few developers run).

Isdnutils needs to be rebuilt; some of the structures passed in ioctl's
have changed. The important stuff from isdnutils refuses to run on 2.2
(you get a message about wrong versions, so at least it doesn't crash).

That said, it's trivial to rebuild (if perhaps a bit longwinded).


Paul Slootman
-- 
home: [EMAIL PROTECTED] | work: [EMAIL PROTECTED] | debian: [EMAIL PROTECTED]
http://www.wurtel.demon.nl | Murphy Software,   Enschede,   the Netherlands

Desperate need for a config tool

[Igor Mozetic]

I'm not a developer but would like to share my experience with
installing/using Debian and compare it to Windows 95/98. I'm a long
time Unix user (Sun, Apollo, HP), but not administrator, and started
to use/administer a Debian machine a year ago. Since then I
installed/upgraded Debian 2.0 on three machines. I found my system
(dual PPro) very stable, fast, with all the software I need running
well, easy to upgrade and maintain.

However, configuring it is a nightmare, especially in comparison to
Windows. I'm not a Windows user, but on a dual boot machine I needed
about 5 min. to set the proper time, configure the monitor, install
printer and ZIP drive, establish a PPP connection. On Linux I have to
read a lot of documentation (/usr/doc, man pages, HOWTOs, bug reports)
before I can set almost trivial things (like changing From: field
in the mail headers). Eventually, this usually involves changing 
just a line or two in configuration files, but may take hours/days 
to find out.

I installed and tried Webmin, and it looked like a great tool for
a non-experienced administrator. I didn't stay with it because
it has support just for Debian 1.3, and it isn't packaged for Debian.
So it doesn't give me any assurance that what it does to my config
files is in accordance with Debian 2.0 policy. However, a tool like
that, with Debian support (eg, all packages with config files
should register with it, like menu system) would certainly bring
Debian much closer to non-experienced users.

Now the obvious: "Why don't you do it?"
First, I lack the expertise, and second, such a tool really requires
to be accepted into the Debian policy. 
This note shouldn't be taken as a criticism to your great work, but
rather as a point of view of a grateful, non-expert user.
If anybody cares, I'm willing to give a detailed account of typical
configuration problems.

-Igor Mozetic

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: The freeze and IMMINENT 2.2.0p1!!

[Michael Stone]

Quoting J.H.M. Dassen Ray" ([EMAIL PROTECTED]):
> I'm not aware of any software in slink that must be updated to work with 2.2
> properly (with the exception of pcmcia-cs); slink currently runs fine with
> 2.1.x (which I suspect quite a few developers run).

Things like smbfsx that have 2.0 and 2.1 versions will need to be
consolidated. (Though that's not a big problem.)

Mike Stone

Re: The freeze and IMMINENT 2.2.0p1!!

[warp]

On Fri, Oct 09, 1998 at 02:07:15PM +0200, Santiago Vila wrote:
> On 9 Oct 1998, Samuel Tardieu wrote:
> > Santiago> There are a lot of packages that would have to be recompiled
> > Santiago> for Linux 2.2. This will take time and a lot of testing.
> > 
> > I can see pcmcia (28-Sep-98 is needed) and netutils (so that IPv6 is
> > supported), but not "a lot of packages".
> 
> Well, kernel-package is a single package but it would be surely
> a lot of work, since there are a lot of new drivers.

Actually it should not be that much work if its written to be expanded
(And if its not I'm not sure we should be using it in the first place)
> 
> We should base our distribution in stable software, not in betas.

Which is why I asked for another week to see IF we need to re-target,
instead of asking for a re-target now..
> 
> Maybe we should wait for 2.0.36, not for 2.2.

As I said, lets wait another week, and see where things have landed, if
2.0.36 is ready and 2.2.0 is still a bit away then we do 2.0.36, if
2.2.5 is out and looking stable..

Zephaniah E, Hull..
> 
> -- 
>  "33ca525b2c9f2cd0f9b40ef52e0d64f6" (a truly random sig)
> 
> 
> --  
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 


pgpD0mSk7AYDF.pgp
Description: PGP signature

Re: The freeze and IMMINENT 2.2.0p1!!

[warp]

On Fri, Oct 09, 1998 at 08:42:57AM -0400, Michael Stone wrote:
> Quoting J.H.M. Dassen Ray" ([EMAIL PROTECTED]):
> > I'm not aware of any software in slink that must be updated to work with 2.2
> > properly (with the exception of pcmcia-cs); slink currently runs fine with
> > 2.1.x (which I suspect quite a few developers run).
> 
> Things like smbfsx that have 2.0 and 2.1 versions will need to be
> consolidated. (Though that's not a big problem.)

Don't forget dhcp* and tleds, and who knows what other little things
which WILL come up when 2.2.x is out, ready for it or not..

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


pgp1NRiURaN6X.pgp
Description: PGP signature

Re: The freeze and IMMINENT 2.2.0p1!!

[Martin Schulze]

[EMAIL PROTECTED] wrote:
> In light of the perl issues (see my last message) and the message Linus
> just sent off to linux-kernel about 2.1.125 and 2.2.0p1 could the freeze
> be pushed back a week to see if we should QUICKLY re-target slink
> towards 2.2.0?

No, this would hold the release for at least two more months.

 . We have several kernel module package that need to be re-packaged.
 . We have to rework on the sound modules, possibly, I dunno.
 . We have to rework on the boot-floppies to cope with different
   and/or more modules etc.
 . We have to ensure that the new kernel headers won't infect
   various compilation of programs.
 . We might need to re-compile/re-package the libc.
 . We need to include new programs / packages to interfere with
   new kernel interfaces.
 . We need to review our documentation wrt the kernel (maybe, I duno)

All this can't be done in 6 days.

Linux 2.2 is a good candidate for the next unstable to play with.
I believe that it will be fun, but I also forsee that there will
be problems.

I hope our release manager won't jump on that train too quick.

Regards,

Joey

-- 
No question is too silly to ask, but, of course, some are too silly
to answer.   -- Perl book


pgpCyzcO0yeu8.pgp
Description: PGP signature

Re: The freeze and IMMINENT 2.2.0p1!!

[warp]

On Fri, Oct 09, 1998 at 03:05:17PM +0200, Martin Schulze wrote:
> [EMAIL PROTECTED] wrote:
> > In light of the perl issues (see my last message) and the message Linus
> > just sent off to linux-kernel about 2.1.125 and 2.2.0p1 could the freeze
> > be pushed back a week to see if we should QUICKLY re-target slink
> > towards 2.2.0?
> 
> No, this would hold the release for at least two more months.
> 
>  . We have several kernel module package that need to be re-packaged.

We have to do that anyways for 2.0.36..

>  . We have to rework on the sound modules, possibly, I dunno.

When did we get sound modules? With 2.2.0 we could actually have some!!

>  . We have to rework on the boot-floppies to cope with different
>and/or more modules etc.

We have to do that anyways for 2.0.36..

>  . We have to ensure that the new kernel headers won't infect
>various compilation of programs.

I thought that was part of the idea of the glibc 2 header stuff..

>  . We might need to re-compile/re-package the libc.

Nope, works fine here and with countless others..

>  . We need to include new programs / packages to interfere with
>new kernel interfaces.

We have ipchains in slink at the moment, so we are already leaning in
that direction..

>  . We need to review our documentation wrt the kernel (maybe, I duno)

See 2.0.36

> 
> All this can't be done in 6 days.

I did not ask it to be done in 6 days, I asked that we wait another week
so we can see if we need to re-target for 2.2.0, if its not looking like
it won't be out in a day or two at the end of this extra week then we
need to do nothing, on the other hand if it IS going to be out, then it
seems perfectly reasonable that we fully consider (and perhaps vote on)
re-targeting at 2.2.x..
> 
> Linux 2.2 is a good candidate for the next unstable to play with.
> I believe that it will be fun, but I also forsee that there will
> be problems.

If its not done for slink, then definitely for 2.2.. (2.2 for 2.2.x hmm)
> 
> I hope our release manager won't jump on that train too quick.

I hope our release manager won't jump on any track without fully
considering it..


Zephaniah E, Hull..
> 
> Regards,
> 
>   Joey
> 
> -- 
> No question is too silly to ask, but, of course, some are too silly
> to answer.   -- Perl book




pgp1WzMmclavg.pgp
Description: PGP signature

Re: The freeze and IMMINENT 2.2.0p1!!

[Wichert Akkerman]

Previously [EMAIL PROTECTED] wrote:
> Which is why I asked for another week to see IF we need to re-target,
> instead of asking for a re-target now..

Bogus argument. Kernels do not have a set release date, and 2.2 will take
a couple of weeks, esp. since there will probably be a couple of
pre2.2 kernels as well. 2.0.36 will very likely be finished during the
freeze and will not break any existing packages. I hope Brian will allow
that one in, especially since it includes a bunch of security fixes and
finally has working adaptec drivers.

Wichert.

-- 
==
This combination of bytes forms a message written to you by Wichert Akkerman.
E-Mail: [EMAIL PROTECTED]
WWW: http://www.wi.leidenuniv.nl/~wichert/


pgp1IZqeFk1Hk.pgp
Description: PGP signature

Re: The freeze and IMMINENT 2.2.0p1!!

[Wichert Akkerman]

Previously [EMAIL PROTECTED] wrote:
> We have to do that anyways for 2.0.36..

Only recompile, to work with 2.1 expect to fix a lot of code..

> When did we get sound modules? With 2.2.0 we could actually have some!!

 You did know we have alsa packages, right? And they
even work with both 2.0 and 2.1 kernels 
 
> >  . We have to rework on the boot-floppies to cope with different
> >and/or more modules etc.
> 
> We have to do that anyways for 2.0.36..

No, same as with hamm: default to one kernel and supply the sources and
images for 2.0.36 as well.
> 
> >  . We have to ensure that the new kernel headers won't infect
> >various compilation of programs.
> 
> I thought that was part of the idea of the glibc 2 header stuff..

Not everything can use that.. remember the hdparm disaster when we switched
to 2.0.35 ?

> Nope, works fine here and with countless others..

and 2.1 broke lots of packages last time I tried it, no to mention I got
errors when booting since route works differently now, ipfwadm is replaces
by ipchains, etc..

> If its not done for slink, then definitely for 2.2.. (2.2 for 2.2.x hmm)

That is a whole different thing.. 

> I hope our release manager won't jump on any track without fully
> considering it..

Remember the beginning/end of trainspotting? :)

Wichert.

-- 
==
This combination of bytes forms a message written to you by Wichert Akkerman.
E-Mail: [EMAIL PROTECTED]
WWW: http://www.wi.leidenuniv.nl/~wichert/


pgpfZ7McrhH1Y.pgp
Description: PGP signature

Re: suggestion - AntiVir for Linux

[Jeff Noxon]

On Fri, Oct 09, 1998 at 04:48:26AM -, Robert Woodcock wrote:
> Just out of curiosity would anyone be interested in a mcafee virusscan
> installer package in slink contrib? I have everything created, the only
> thing I'd have to work on would be upstream upgrades (it currently doesn't
> handle this at all) and then I'd write an intent to package and upload it.

I looked at this yesterday.  It appears to be an a.out executable.  I
don't have a.out/libc4 anymore, and I suspect I'm not alone.  Are you
aware of a newer version?  It would be nice to have a virus scanner on
my Linux machine, since I receive a lot of Windoze e-mail attachments
and have several Samba shares.

Regards,

Jeff

--
It's time to close windows and open source.
Linux is a trademark of Linus Torvalds.

Debian 3.0 and release goals

[Juergen A. Erhard]

-BEGIN PGP SIGNED MESSAGE-

In the release naming thread (I don't know whether it died down
already), there was a mention of 3.0 (right after 2.2, for one).

Now... I know `we'[1] don't want to set hard release goals anymore.
And I agree with that.

Someone (can't remember who) a while back mentioned something similar:

Define release goals for 3.0, and the release that happens to
implement exactly this is automatically named 3.0.

This might be confusing if we plan for an upcoming release 2.5 (or
whatever), which then happens to become 3.0.  But since we don't
really do that (we don't think of 2.1, but of slink, right?), it won't
really be.

When we get close to a implementing the stated release goals, we can
hint at it, like "The next release has a good chance of being 3.0."
(This would need an accompanying explanation on the whys and hows, or
a link to such).

Of course, this scheme works for major releases (a different X in X.Y)
only.

Bye, J

[1] I'm not a developer, but I'm identifying with Debian's goals
100%... *and* Debian makes even its users feel very much part of the
community.  This list in particular feels like sitting in the offices
at RedHat (for example), listening to shop-talk...

- -- 
Jürgen A. Erhard  eMail: [EMAIL PROTECTED]  phone: (GERMANY) 0721 27326
   MARS: http://members.tripod.com/~Juergen_Erhard/mars_index.html
  GNU Privacy Guard (http://www.d.shuttle.de/isil/crypt/gnupg.html)
  "No matter how cynical I get, I can't keep up."  -- Bruce Schneier

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQEVAwUBNhkqDgIG66LugGzRAQF6jwf/S5muUSSNay97ii2X8c1qFnPHCNT0DIYC
yV6csyT20Hm8EwG/zX171DBurkPEMsCxtQFDPOhjvjjVF0DSO+PKphZSbKfFzEie
5qZmGYW25vsiu8y1eOnwthUu1uEqf3VEVtb6bBA9yFCgcjTsyWC9ys57B2a8L1cZ
YSAqTCyFM4X1Kc7G2e6CWfsLQuubg/OId38G4YetUkBeaqb/CGWbrdyWxB4a6nxL
O4MeCpJhuTvxuz9zqKSgNC/KXanspNwpuYXUSVivkpeJmvLuFDkGXdFhNv5lCX+i
P+93yXyvYTahwsCSZHR99en81bcZBS/tp2eM1RT/FCLTS+oDvKaOyg=27
-END PGP SIGNATURE-

Re: suggestion - AntiVir for Linux

[Robert Woodcock]

On Fri, Oct 09, 1998 at 09:33:49AM -0500, Jeff Noxon wrote:
> On Fri, Oct 09, 1998 at 04:48:26AM -, Robert Woodcock wrote:
> > Just out of curiosity would anyone be interested in a mcafee virusscan
> > installer package in slink contrib? I have everything created, the only
> > thing I'd have to work on would be upstream upgrades (it currently doesn't
> > handle this at all) and then I'd write an intent to package and upload it.
> 
> I looked at this yesterday.  It appears to be an a.out executable.  I
> don't have a.out/libc4 anymore, and I suspect I'm not alone.  Are you
> aware of a newer version?  It would be nice to have a virus scanner on
> my Linux machine, since I receive a lot of Windoze e-mail attachments
> and have several Samba shares.

mercury:~$ ldd /usr/lib/neta/uvscan
libc.so.5 => /lib/libc.so.5 (0x4000c000)

That's what's in ftp://ftp.nai.com/pub/antivirus/unix/linux/nlxb318e.tar.
-- 
Robert Woodcock - [EMAIL PROTECTED]
"Unix and C are the ultimate computer viruses" -- Richard Gabriel

Re: Debian 3.0 and release goals

[Martin Schulze]

Please check out

http://www.debian.org/~joey/goals/index.html or
http://www.infodrom.north.de/~joey/Linux/Debian/master/goals/index.html

Regards,

Joey

-- 
No question is too silly to ask, but, of course, some are too silly
to answer.   -- Perl book

Re: suggestion - AntiVir for Linux

[Stephen J. Carpenter]

On Fri, Oct 09, 1998 at 09:33:49AM -0500, Jeff Noxon wrote:
> On Fri, Oct 09, 1998 at 04:48:26AM -, Robert Woodcock wrote:
> > Just out of curiosity would anyone be interested in a mcafee virusscan
> > installer package in slink contrib? I have everything created, the only
> > thing I'd have to work on would be upstream upgrades (it currently doesn't
> > handle this at all) and then I'd write an intent to package and upload it.
> 
> I looked at this yesterday.  It appears to be an a.out executable.  I
> don't have a.out/libc4 anymore, and I suspect I'm not alone.  Are you
> aware of a newer version?  It would be nice to have a virus scanner on
> my Linux machine, since I receive a lot of Windoze e-mail attachments
> and have several Samba shares.

I havn't downloaded it yet to look.

I did exchange e-mail with a contact at the company...they pointed me
to a web page...

unfortunatly the english version wasn't done and I don't Speak German

just this morning I got another e-mail...told to check the FTP Site and
given an FTP URL...
I will check it out when I get home.

If it is a.out then I think I may e-mail them and let them know that 
practically noone in the linux world uses it anymore (well ok...
I did make an a.out kernel recently...but I have an excuse..I was booting
a Sun Sparcstation through the network)

maybe ill offer them a Hamm CD ;)


-Steve
-- 
/* -- Stephen Carpenter <[EMAIL PROTECTED]> --- <[EMAIL PROTECTED]> 
*/
E-mail "Bumper Stickers":
"A FREE America or a Drug-Free America: You can't have both!"
"honk if you Love Linux"

Re: suggestion - AntiVir for Linux

[Stephen J. Carpenter]

On Fri, Oct 09, 1998 at 08:01:05AM -0700, Robert Woodcock wrote:
> On Fri, Oct 09, 1998 at 09:33:49AM -0500, Jeff Noxon wrote:
> > On Fri, Oct 09, 1998 at 04:48:26AM -, Robert Woodcock wrote:
> > > Just out of curiosity would anyone be interested in a mcafee virusscan
> > > installer package in slink contrib? I have everything created, the only
> > > thing I'd have to work on would be upstream upgrades (it currently doesn't
> > > handle this at all) and then I'd write an intent to package and upload it.
> > 
> > I looked at this yesterday.  It appears to be an a.out executable.  I
> > don't have a.out/libc4 anymore, and I suspect I'm not alone.  Are you
> > aware of a newer version?  It would be nice to have a virus scanner on
> > my Linux machine, since I receive a lot of Windoze e-mail attachments
> > and have several Samba shares.
> 
> mercury:~$ ldd /usr/lib/neta/uvscan
> libc.so.5 => /lib/libc.so.5 (0x4000c000)
> 
> That's what's in ftp://ftp.nai.com/pub/antivirus/unix/linux/nlxb318e.tar.

Thats a differnt virus scanner than what we were talking about and
what I will be packaging (if it turns out I am able...still need to get my
hands on it and evauate it)

-Steve

-- 
/* -- Stephen Carpenter <[EMAIL PROTECTED]> --- <[EMAIL PROTECTED]> 
*/
E-mail "Bumper Stickers":
"A FREE America or a Drug-Free America: You can't have both!"
"honk if you Love Linux"

Re: Reverting to Perl 5.004

[Brian White]

> > I suspect that it's in the best interest of the freeze to revert to Perl
> 
> Thanks.
> 
> > 5.004.  I'm currently uploading the 5.004.04-6 release to master's
> > Incoming.  I'll file a bug on ftp.debian.org that the 5.005 release
> > should be deleted and the 5.004 release installed.
> 
> Maybe that's not needed since, right after s/unstable/frozen/ there
> will be a new unstable which is perfectly the correct place for the
> new perl package.

Okay, great.  So, just to make sure I understand the final decision:

Perl 5.005 will be replaced in Slink with 5.004.  The new version will
remain in the next unstable.

Correct?

  Brian
 ( [EMAIL PROTECTED] )

---
In theory, theory and practice are the same.  In practice, they're not.

How can tell what priority a bug is?

[Dale E. Martin]

I maintain cdparanoia, which has bug #23236 filed against it.  This is an
alpha version of the software, and the bug is that a feature isn't yet
implemented.  I don't want this to keep this package out of the new
release, as its base functionality works extremely well.

Sorry if I'm missing something obvious!

Thanks,
Dale
-- 
+  finger for pgp public key  -+
| Dale E. Martin |  Clifton Labs, Inc.  |  Senior Computer Engineer|
| [EMAIL PROTECTED]|http://www.clifton-labs.com |
+--+

Does debian have an official "standard" scripting language ?

[Geoffrey L. Brimhall]

Just like debian has an official standard shell - bash, does debian have an
official scripting language ? 

If so, is it perl, python, etc ?

The reason I'm asking is largely questions of disk space - ie minimizing the
number of scripting languages installed on a system by writing a package which
depends on that scripting language.

This disk space may not be an issue though. Just wanted to know...

Thanks !
Geoff Brimhall

Re: Does debian have an official "standard" scripting language ?

[David Welton]

On Thu, Oct 08, 1998 at 02:09:48AM -0700, Geoffrey L. Brimhall wrote:
> Just like debian has an official standard shell - bash, does debian have an
> official scripting language ? 
> 
> If so, is it perl, python, etc ?

Yes, Bourne Shell :->  Bash implements most features of it, afaik.

I really wish we had a bit more minimalistic base, but I don't have
much time to work on it.  Having Perl as necessary is also kind of
ugly, IMO.  Oh well..

Back to the netwinder...
-- 
David Welton  http://www.efn.org/~davidw 

Debian GNU/Linux - www.debian.org

Re: How can tell what priority a bug is?

[Santiago Vila]

On 9 Oct 1998, Dale E. Martin wrote:

> I maintain cdparanoia, which has bug #23236 filed against it.  This is an
> alpha version of the software, and the bug is that a feature isn't yet
> implemented.  I don't want this to keep this package out of the new
> release, as its base functionality works extremely well.
> 
> Sorry if I'm missing something obvious!

If the distribution as a whole is better with the package in its current
state than without it at all, the bug may be downgraded to normal.

Whether you should do this yourlself, let the release manager to do it,
do it now, or do it just before the release, I don't know...

-- 
 "911512bc0090176227c78cb7bb8bc721" (a truly random sig)

Intent to package gqview

[Shaleh]

Unless someone else is working on this, I would like to package gqview.  It is
a DFSG GTK+ based Image browser that supports thumb nails and image viewing.  I
like it.  Small and fast -- even on this p75.

Re: Does debian have an official "standard" scripting language ?

[Santiago Vila]

On Thu, 8 Oct 1998, Geoffrey L. Brimhall wrote:

> Just like debian has an official standard shell - bash, does debian have an
> official scripting language ? 

Even if bash is essential, the "standard" shell is sh, not bash.
[ If you look at our shell scripts, most of them are /bin/sh, not
/bin/bash ].
 
> If so, is it perl, python, etc ?
> 
> The reason I'm asking is largely questions of disk space - ie minimizing the
> number of scripting languages installed on a system by writing a package which
> depends on that scripting language.
> 
> This disk space may not be an issue though. Just wanted to know...

The ones which are currently guaranteed to be on the system are sh, bash,
awk and perl (as well as all the other little ones, sed, ed, etc.),
because they are currently essential.

You are welcome to use any other scripting language as long as you put the
required Depends: line in your package, but using awk or perl has his
advantages (being disk space one of them).

-- 
 "38e7c67287a4859e04f1e64dc5719a5f" (a truly random sig)

Re: Discussion - Proposed Constitution - voting part 2

[Darren Benham]

On 09-Oct-98 Ian Jackson wrote:
> A.6(5)(iii):
>   This elimination procedure is repeated, moving down ballot papers to
>   2nd, 3rd, 4th, etc. preferences as required, until one option gets
>   more than half of the `first' preferences.
> 
> It seems to me to be clear that the intent is that if a ballot has no
> remaining preferences then it doesn't count when considering which
> option might have "more than half of the `first' preferences".  Such a
> ballot couldn't be said to have a "`first' preference" any more,
> surely ?
Actually, I've seen the STV method done in such a way that after a ballot
loses all it's "first preferences" it is still counted as a no-preference (ie.
as an abstention of sorts) hence my question.  I think any questions on this
can be settled by president but, as of yet, we don't have president so I
thought I'd ask.

> A.6(8):
>8.If a quorum is required, there must be at least that many votes
>which prefer the winning option to the default option.  If there
>are not then the default option wins after all. For votes requiring
>a supermajority, the actual number of Yes votes is used when
>checking whether the quorum has been reached.
> 
> The "winning option" here refers to the outcome of steps 1-7, clearly,
I've learned, the hard way, that "clearly" usually doesn't apply to things like
this.  They turn out to be worm holes to cause problems :(

> and 8 is intended to _modify_ the outcome.  So, if Concorde doesn't
> produce a clear-cut answer we use STV amongst the remaining options,
> and then we have a putative `winner'.  If this winner didn't actually
> have enough ballots which prefer it to the default, then the default
> option is declared the winner.  There's nothing saying we should go
> and restart the ballot counting with STV instead, or something.  The
Yes.  I saw my mistake as I was reading and rereading the constituion.  But
since nobody commented on the thread, I just let the matter drop instead of
correcting my assuptions to the list.

=
* http://benham.net/index.html  *
*  * -BEGIN GEEK CODE BLOCK- ---*
*Darren Benham * Version: 3.1   *
*  <[EMAIL PROTECTED]>  * GCS d+(-) s:+ a29 C++$ UL++> P+++$ L++>*
*  * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS--   *
*   Debian Developer   * PE++ Y++ PGP++ t+ 5 X R+ !tv b DI+++ D++   *
*  <[EMAIL PROTECTED]>  * G++>G+++ e h+ r* y+*
*  * --END GEEK CODE BLOCK-- ---*
=

[comp.os.linux.announce] COMMERCIAL: Debian User's Guide Second Edition $38.95

[Ben Gertzfield]

Just wondering, Dale, but why didn't you announce this to the Debian
lists as well as the c.o.linux.announce?

Ben

-- 
Brought to you by the letters M and J and the number 10.
"XTC versus Adam Ant -- which one will survive?" -- They Might Be Giants
Debian GNU/Linux -- where do you want to go tomorrow? http://www.debian.org/
I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox.
--- Start of forwarded message ---
From: LinuxPress Sales <[EMAIL PROTECTED]>
Newsgroups: comp.os.linux.announce
Subject: COMMERCIAL: Debian User's Guide Second Edition $38.95
Followup-To: comp.os.linux.misc
Date: Fri,  9 Oct 1998 09:04:35 GMT
Organization: none
Message-ID: <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-


   The Debian Linux User's Guide
   Second Edition
 +

October 7, 1998
For Public Release

Linux Press announces The Debian Linux User's Guide.

This newly released product is the second major effort at providing
a commercial version of Debian GNU/Linux.  Linux Press has seen that
Debian GNU/Linux has been well received for good reason by the Linux
community.  Linux Press felt Debian GNU/Linux could be further enhanced
by providing comprehensive documentation and technical support.

The result is The Debian Linux User's Guide, which includes the following:

 250 Page Book titled "The Debian Linux User's Guide"
 2 CD-ROM Debian "Official" GNU/Linux 2.0 Set
 1 CD-ROM with extra files 
 30 Days of E-mail Technical Support


1. OVERVIEW OF PRODUCT
- -  ---
Here is a summary of what areas are addressed with this book:

  Introduction
  Installation
Floppy Installation
CD-ROM Installation
FTP Installation
  dpkg
  dselect
  X11 Installation
  Networking
ppp configuration
  Compiling the Kernel
Building the Kernel
Modules   
  What Next?
  Common UNIX Commands
  Text Editors
  The Loop Device
  Multiple OS Installation
  Building Packages Files
  Linux as a Server
  Arguments
  Drop in Debian
  What is Free Software
  
2.  ORDERING INFORMATION
- -   
The price of this package is $38.95.  Orders can be placed the following
ways:

  Toll Free in the US --> 888-770-4330
  International Ordering ---> 707-773-4916
  Via FAX --> 707-765-1431
  Via E-mail ---> [EMAIL PROTECTED]
  Via secured web page -> http://www.linuxpress.com
  Via snail mail ---> See our mailing address at the end.
  
Shipping and handling charges for 2-Day service in the U.S. is $9.00
International Shipping and handling charges for U.S. Airmail is $9.00

3.  AVAILABILITY
- -   
This product will be available the week of October 19.  If
you have a Borders bookstore in your area, check with them.  You can also
check with your favorite Linux reseller as most are stocking this item.

4.  PERSONAL USE LICENSE
- -   
Linux Press is offering an HTML version of The Debian Linux User's Guide
at www.linuxpress.com  You are free to print and use this valuable
document for your personal use.  Links are included for both the Table of
Contents and the Index.  The complete book is included online.  We are
currently updating the HTML document to make it even more user friendly.

This will be available October 25.

5.  RESELLER INFORMATION
- -   
Linux Press
Phone Number: (707) 773-4916
 FAX: (707) 765-1431
  E-mail:  [EMAIL PROTECTED]
 Web Address:  http://www.linuxpress.com
Mail Address:  Linux Press
   P.O. Box 220
   Penngrove, CA 94951
   
Frank Kasper and Associates
Phone Number: (612) 942-0566
 FAX: (612) 942-5039
 Web Address:  http://www.kasper-cdrom.com
Mail Address:  Frank Kasper & Associates, Inc.
   7351 Washington Ave. So.
   Edina, MN 55439

- 
  Linux Press  *  P.O. Box 220  *  Penngrove  *  CA  *  94951  *  U.S.A.
  Toll Free Order: 888-770-4330  International & Business: 707-773-4916
  FAX: 707-765-1431  E-mail: [EMAIL PROTECTED]  Web: www.linuxpress.com



- -- 
This article has been digitally signed by the moderator, using PGP.
http://www.iki.fi/mjr/cola-public-key.asc has PGP key for validating signature.
Send submissions for comp.os.linux.announce to: [EMAIL PROTECTED]
PLEASE remember a short description of the software and the LOCATION.
This group is archived at http://www.iki.fi/mjr/linux/cola.html

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

iQCVAgUBNh3RpFrUI/eHXJZ5AQGKqgP9Hvp0VNJ/i99wBIJRGYATsglUj2yiHcC3
BPUWqbfwr9aXU41LGI9bNxGvlK06mYuyVXxISDDd1sqjH18aWk4ddguTpkoylCTs
gnpQ5ZAFKh6IiIG4YMr0m+JJbzL99S81FqGr3fx8G/Mjp6cQ73XLmglyAayHqtn+
BNmB02YrEZk=
=xmDz
-END PGP SIGNATURE-
--- End of forwarded message ---

Re: Does debian have an official "standard" scripting language ?

[Ole J. Tetlie]

*-"Geoffrey L. Brimhall" <[EMAIL PROTECTED]>
|
| Just like debian has an official standard shell - bash, does debian have an
| official scripting language ? 
| 
| If so, is it perl, python, etc ?
| 
| The reason I'm asking is largely questions of disk space - ie minimizing the
| number of scripting languages installed on a system by writing a package which
| depends on that scripting language.

This has been discussed, but not settled. Some love perl, some love
pyhton, some love both and some love none. I don't think there will
ever be a "standard" scripting language, but I guess perl is closest
at the moment, with perl-base being in the base system and all.

-- 
...Unix, MS-DOS, and MS Windows (also known as the Good, the Bad,
and the Ugly).   (Matt Welsh)
[EMAIL PROTECTED]   [-: .elOle. :-]   [EMAIL PROTECTED]

Perl

[Ole J. Tetlie]

I installed perl 5.005, but I understand that it has been revoked
and all packages in slink shall be built against perl 5.004,
is that so? Now where do I find 004? There's no perl in ftp.debian.org
and ftp.de.debian.org has 005.

thanks

-- 
Eschew obfuscation(go on; look them both up)
   (Brian White)
[EMAIL PROTECTED]   [-: .elOle. :-]   [EMAIL PROTECTED]

Re: How can tell what priority a bug is?

[Adam P. Harris]

[EMAIL PROTECTED] (Dale E. Martin) writes:
> I maintain cdparanoia, which has bug #23236 filed against it.  This is an
> alpha version of the software, and the bug is that a feature isn't yet
> implemented.

> I don't want this to keep this package out of the new
> release, as its base functionality works extremely well.
> 
> Sorry if I'm missing something obvious!

You are.  For one, the bug is only of normal severity.  Only bugs of
severity Important or greater will keep it out of the stable
distribution.

Moreover, if it's a bug in the upstream software, its not officially
your duty to fix it.  You can forward the bug report to the upstream
maintainers and mark the bug as "forwarded".

You should read the developers-reference materials and
/usr/doc/debian/bug*

.A. P. [EMAIL PROTECTED]http://www.onShore.com/>

Intent to package hp2pbm

[Camm Maguire]

Greetings!  The hp2pbm utility is implicitly called by mgetty-fax's
faxspool when given a HP PCL file.  Currently, this results in an
error on Debian.  I can't seem to find a license stipulation in the
sources; I'm beginning to think its public domain, and am attempting
to contact the author to clarify.  I'm thinking it would give a simple
way for people using mgetty-fax to use a 'magicfilter' filter as a
frontend to faxspool to send a variety of formats via fax.

-- 
[EMAIL PROTECTED] Camm Maguire
==
"The earth is one country, and mankind its citizens."  Baha'u'llah

X window logo

[Kenneth Scharf]

Whenever you start a program running under X11, the windows created
usually have the little 'X' logo in the upper left hand corner.  If
you are running RedHat linux however, the upper left hand corner of
the windows contains the RedHat logo (head with a red hat).  Why can't
it (under Debian) have the blue eyed penguin logo?




_
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

RE: yagirc bugs - new maintainer or not?

[Darren Benham]

If you don't get the original volunteer, I'll take it over.  I like and use
yagirc so I've got a stake in it being kept up-to-date.


On 08-Oct-98 David Welton wrote:
> I recall someone wanting to take over yagirc after I offered it up.
> Is this person still interested?  They ought to upload a new, up to
> date version with someo of these bugs fixed.  Otherwise, I'll try and
> do it.

=
* http://benham.net/index.html  *
*  * -BEGIN GEEK CODE BLOCK- ---*
*Darren Benham * Version: 3.1   *
*  <[EMAIL PROTECTED]>  * GCS d+(-) s:+ a29 C++$ UL++> P+++$ L++>*
*  * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS--   *
*   Debian Developer   * PE++ Y++ PGP++ t+ 5 X R+ !tv b DI+++ D++   *
*  <[EMAIL PROTECTED]>  * G++>G+++ e h+ r* y+*
*  * --END GEEK CODE BLOCK-- ---*
=

Re: Perl 5.005.02

[Andy Dougherty]

[ perl5.005_02's default library is now /usr/lib/perl5/perl5.005,
  and might change with 5.006, etc.]

> Any idea how to handle this properly ? Maybe we need a sort of perl
> policy : package will have to install file under /usr/lib/perl5/debian
> which would be a symlink to the current perl version ? But
> this does not solve all problems... Better idea ?

Yes.  Perl itself knows where it is installed.  Install .pm things into
$Config{'privlib'}.  From the shell command line, you can get this
same information with /usr/bin/perl -V:privlib.

Andy Dougherty  [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042

Re: Slashdot on the KDE stance

[Michael Meskes]

On Thu, Oct 08, 1998 at 10:53:23PM +0200, Francesco Tapparo wrote:
> Slashdot has posted an article about the decision to remove the KDE binaries
> right now.

Could someone please post the article or at least the complete URL?

Michael
-- 
Dr. Michael Meskes  | Th.-Heuss-Str. 61, D-41812 Erkelenz | Go SF49ers!
Senior-Consultant   | business: [EMAIL PROTECTED] | Go Rhein Fire!
Mummert+Partner |  private: [EMAIL PROTECTED]| Use Debian
Unternehmensberatung AG |   [EMAIL PROTECTED]| GNU/Linux!

Re: another problem maybe relate to lesstiffg

[Michael Meskes]

On Thu, Oct 08, 1998 at 03:01:58PM -0400, Steve Dunham wrote:
> Yup, I just noticed that my package, amaya, no longer works.  Layout
> problems: the widget holding the page doesn't show up.  I think we
> might need a newer (or older) version of lesstif in slink.

I absolutely agree. Did anyone already report this as a bug?

Michael
-- 
Dr. Michael Meskes  | Th.-Heuss-Str. 61, D-41812 Erkelenz | Go SF49ers!
Senior-Consultant   | business: [EMAIL PROTECTED] | Go Rhein Fire!
Mummert+Partner |  private: [EMAIL PROTECTED]| Use Debian
Unternehmensberatung AG |   [EMAIL PROTECTED]| GNU/Linux!

Re: Slashdot on the KDE stance

[David Welton]

On Fri, Oct 09, 1998 at 01:39:09PM +0200, Michael Meskes wrote:
> On Thu, Oct 08, 1998 at 10:53:23PM +0200, Francesco Tapparo wrote:
> > Slashdot has posted an article about the decision to remove the KDE binaries
> > right now.
> 
> Could someone please post the article or at least the complete URL?

http://slashdot.org - it's a pretty good source of Linux news.  The
comments have degraded though, don't bother with them..  Used to be
people like Alan Cox occasionally posted.. no more (afaik).

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

Debian GNU/Linux - www.debian.org

dpkg-dev: dpkg-shlibdeps doesn't work within fakeroot

[Roberto Lumbreras]

Package: dpkg-dev
Version: 1.4.0.30

$ dpkg-shlibdeps src/fortify; cat debian/substvars
shlibs:Depends=libc6 (>= 2.0.7u)

$ fakeroot dpkg-shlibdeps src/fortify; cat debian/substvars
shlibs:Depends=libc6, libc6 (>= 2.0.7u)
   ^  ^
:-?

Ideas??

PS: libtrick's fakeroot doesn't help at all, it kills rm :-(

Regards,
-- 
Roberto Lumbreras
[EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] & pgp 143BE391
Lander Internet, Madrid-Spain-UE; http://www.lander.es

Re: slashdot

[Shaya Potter]

-Original Message-
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
To: Debian Private <[EMAIL PROTECTED]>
Date: Friday, October 09, 1998 11:49 AM
Subject: Re: slashdot


>John Lapeyre writes:
>> Something that came up in the discussion.  Does anyone have any idea what
>> the U.S. legal system (or german or uruguayan for that matter) might
>> think about the GPL and static vs. dynamic linking ,etc.
>
>I think that the courts would permit dynamic linking to non-free libraries,
>but the point is controversial and I don't want to argue it here.
>
>You might have to write your own header files.


Better yet, what if Harmony was written to be binary compatable with Qt, you
could compile with Harmony, it wouldn't work well, till harmony implemented
all of Qt's class's, but you could just drop Qt in, and you'd have a working
system.  I've essentially come to the opinion that the GPL has no control
over dynamic linking b/c it's something a user does in the privacy of his
own home.

Shaya

Re: The freeze and IMMINENT 2.2.0p1!!

[Joseph Carter]

On Fri, Oct 09, 1998 at 03:05:17PM +0200, Martin Schulze wrote:
> Linux 2.2 is a good candidate for the next unstable to play with.
> I believe that it will be fun, but I also forsee that there will
> be problems.
> 
> I hope our release manager won't jump on that train too quick.

Agreed.  There are still problems in 2.1.x that NEED to be adressed and they
won't happen in a week or even two weeks.  Save it for the next release
which could be Debian 3.0 with full apt and 2.2.x kernel, among other
things.  (Provided all that works)


pgpNvdrJCvyNq.pgp
Description: PGP signature

Re: The freeze and IMMINENT 2.2.0p1!!

[Michael Meskes]

On Fri, Oct 09, 1998 at 01:18:46PM +0200, Samuel Tardieu wrote:
> I do run 2.1.124 on my laptop and am really impressed by this
> kernel. It uses less memory and runs smoother under heavy load than
> any kernel I've ever used.

I have to agree. 124 is great on my notebook too. I'm just compiling 125.

Michael

-- 
Dr. Michael Meskes  | Th.-Heuss-Str. 61, D-41812 Erkelenz | Go SF49ers!
Senior-Consultant   | business: [EMAIL PROTECTED] | Go Rhein Fire!
Mummert+Partner |  private: [EMAIL PROTECTED]| Use Debian
Unternehmensberatung AG |   [EMAIL PROTECTED]| GNU/Linux!

Re: The freeze and IMMINENT 2.2.0p1!!

[Michael Meskes]

On Fri, Oct 09, 1998 at 06:40:54AM -0400, [EMAIL PROTECTED] wrote:
> In light of the perl issues (see my last message) and the message Linus
> just sent off to linux-kernel about 2.1.125 and 2.2.0p1 could the freeze
> be pushed back a week to see if we should QUICKLY re-target slink
> towards 2.2.0?

Wouldn't it be better to just supply 2.2.0 and not make it the default
kernel? It will take some weeks until it is really stable I think.

Michael

-- 
Dr. Michael Meskes  | Th.-Heuss-Str. 61, D-41812 Erkelenz | Go SF49ers!
Senior-Consultant   | business: [EMAIL PROTECTED] | Go Rhein Fire!
Mummert+Partner |  private: [EMAIL PROTECTED]| Use Debian
Unternehmensberatung AG |   [EMAIL PROTECTED]| GNU/Linux!

Re: The freeze and IMMINENT 2.2.0p1!!

[Michael Meskes]

On Fri, Oct 09, 1998 at 03:05:17PM +0200, Martin Schulze wrote:
> No, this would hold the release for at least two more months.

Joey, that's exaggerated by a lot. But I agree with your reasoning-

>  . We have several kernel module package that need to be re-packaged.
>  . We have to rework on the sound modules, possibly, I dunno.

We won't have to if we provide both kernels. We just would also add two
packages for those modules compiled for both.

>  . We have to rework on the boot-floppies to cope with different
>and/or more modules etc.

Not needed under my approach.

>  . We have to ensure that the new kernel headers won't infect
>various compilation of programs.

Shouldn't be much of a problem.

>  . We might need to re-compile/re-package the libc.

No.

>  . We need to include new programs / packages to interfere with
>new kernel interfaces.

Don't we have them already?

Michael

-- 
Dr. Michael Meskes  | Th.-Heuss-Str. 61, D-41812 Erkelenz | Go SF49ers!
Senior-Consultant   | business: [EMAIL PROTECTED] | Go Rhein Fire!
Mummert+Partner |  private: [EMAIL PROTECTED]| Use Debian
Unternehmensberatung AG |   [EMAIL PROTECTED]| GNU/Linux!

Re: When will the freeze happen ???

[Michael Meskes]

On Fri, Oct 09, 1998 at 01:02:32PM +0200, Gregor Hoffleit wrote:
> Sorry, maybe I'm deaf or blind or my mail spool went to /dev/null, but I 
> never saw a concrete date for the freeze in the last months. Can somebody 
> enlighten me when it will happen ?

I doubt it's your fault. I never saw it either, except that I remember a
discussion three months ago. IMO the date should be published on devel or
private about two weeks before the date.

Michael
-- 
Dr. Michael Meskes  | Th.-Heuss-Str. 61, D-41812 Erkelenz | Go SF49ers!
Senior-Consultant   | business: [EMAIL PROTECTED] | Go Rhein Fire!
Mummert+Partner |  private: [EMAIL PROTECTED]| Use Debian
Unternehmensberatung AG |   [EMAIL PROTECTED]| GNU/Linux!

Re: The freeze and IMMINENT 2.2.0p1!!

[Michael Meskes]

On Fri, Oct 09, 1998 at 01:20:34PM +0200, Samuel Tardieu wrote:
> Santiago> There are a lot of packages that would have to be recompiled
> Santiago> for Linux 2.2. This will take time and a lot of testing.
> 
> I can see pcmcia (28-Sep-98 is needed) and netutils (so that IPv6 is
> supported), but not "a lot of packages".

But some cannot be ported at the moment: iBCS!

> Also, from a marketing point of view, it would be great to have the
> first distribution using Linux 2.2 :-) Imagine the stickers on the CDs :)

This can be done also if we provide 2.2 while keeping 2.0.35 the default.

Michael
-- 
Dr. Michael Meskes  | Th.-Heuss-Str. 61, D-41812 Erkelenz | Go SF49ers!
Senior-Consultant   | business: [EMAIL PROTECTED] | Go Rhein Fire!
Mummert+Partner |  private: [EMAIL PROTECTED]| Use Debian
Unternehmensberatung AG |   [EMAIL PROTECTED]| GNU/Linux!

Re: Intent to package gqview

[Michael Meskes]

On Fri, Oct 09, 1998 at 01:10:36PM -0400, Shaleh wrote:
> Unless someone else is working on this, I would like to package gqview.  It is
> a DFSG GTK+ based Image browser that supports thumb nails and image viewing.  
> I
> like it.  Small and fast -- even on this p75.

Great. Will you get it into slink before the freeze?

Michael
-- 
Dr. Michael Meskes  | Th.-Heuss-Str. 61, D-41812 Erkelenz | Go SF49ers!
Senior-Consultant   | business: [EMAIL PROTECTED] | Go Rhein Fire!
Mummert+Partner |  private: [EMAIL PROTECTED]| Use Debian
Unternehmensberatung AG |   [EMAIL PROTECTED]| GNU/Linux!

Re: X window logo

[Michael Meskes]

On Fri, Oct 09, 1998 at 11:16:27AM -0700, Kenneth Scharf wrote:
> Whenever you start a program running under X11, the windows created
> usually have the little 'X' logo in the upper left hand corner.  If
> you are running RedHat linux however, the upper left hand corner of
> the windows contains the RedHat logo (head with a red hat).  Why can't
> it (under Debian) have the blue eyed penguin logo?

Great idea IMO. Can we get that into slink?

Michael
-- 
Dr. Michael Meskes  | Th.-Heuss-Str. 61, D-41812 Erkelenz | Go SF49ers!
Senior-Consultant   | business: [EMAIL PROTECTED] | Go Rhein Fire!
Mummert+Partner |  private: [EMAIL PROTECTED]| Use Debian
Unternehmensberatung AG |   [EMAIL PROTECTED]| GNU/Linux!

Re: Slashdot on the KDE stance

[Michael Meskes]

On Fri, Oct 09, 1998 at 11:40:04AM -0700, David Welton wrote:
> http://slashdot.org - it's a pretty good source of Linux news.  The
> comments have degraded though, don't bother with them..  Used to be
> people like Alan Cox occasionally posted.. no more (afaik).

Yes, I know that. I was hoping for the full URL to not have to search
slashdor myself. Or is it on the main page?

Michael
-- 
Dr. Michael Meskes  | Th.-Heuss-Str. 61, D-41812 Erkelenz | Go SF49ers!
Senior-Consultant   | business: [EMAIL PROTECTED] | Go Rhein Fire!
Mummert+Partner |  private: [EMAIL PROTECTED]| Use Debian
Unternehmensberatung AG |   [EMAIL PROTECTED]| GNU/Linux!

Re: The freeze and IMMINENT 2.2.0p1!!

[David Welton]

On Fri, Oct 09, 1998 at 09:06:30PM +0200, Michael Meskes wrote:
> On Fri, Oct 09, 1998 at 06:40:54AM -0400, [EMAIL PROTECTED] wrote:
> > In light of the perl issues (see my last message) and the message Linus
> > just sent off to linux-kernel about 2.1.125 and 2.2.0p1 could the freeze
> > be pushed back a week to see if we should QUICKLY re-target slink
> > towards 2.2.0?
> 
> Wouldn't it be better to just supply 2.2.0 and not make it the default
> kernel? It will take some weeks until it is really stable I think.

Right, this sounds like the most reasonable course of action.

"We are supplying 2.2.0, but please be aware that it may cause
problems with your system, and some packages may not work with it."

Ciao,
-- 
David Welton  http://www.efn.org/~davidw 

Debian GNU/Linux - www.debian.org

Re: X window logo

[Ole J. Tetlie]

*-Kenneth Scharf <[EMAIL PROTECTED]>
|
| Whenever you start a program running under X11, the windows created
| usually have the little 'X' logo in the upper left hand corner.  If
| you are running RedHat linux however, the upper left hand corner of
| the windows contains the RedHat logo (head with a red hat).  Why can't
| it (under Debian) have the blue eyed penguin logo?

If I understand you correctly, this is up to each windowmanager.
Some wms can't have a penguin in the corner, but I see no
harm in changing the default for those that can. It should, however
be up to the maintainer of each wm.

-- 
The only way tcsh "rocks" is when the rocks are attached to it's feet
in the deepest part of a very deep lake. (Linus Torvalds)
[EMAIL PROTECTED]   [-: .elOle. :-]   [EMAIL PROTECTED]

Re: yagirc bugs - new maintainer or not?

[Ole J. Tetlie]

*-Darren Benham <[EMAIL PROTECTED]>
|
| If you don't get the original volunteer, I'll take it over.  I like and use
| yagirc so I've got a stake in it being kept up-to-date.

I'm here, working on 0.66 as we speak. This might be a good time to ask
a question. yagirc can now be built with gnome interface or
text interface. Should I make two packages, include both in one
package or just drop the non-gui?

-- 
A mathematician is a machine for converting coffee to theorems
  (Martin Schulze)
[EMAIL PROTECTED]   [-: .elOle. :-]   [EMAIL PROTECTED]

Re: yagirc bugs - new maintainer or not?

[David Welton]

On Fri, Oct 09, 1998 at 09:14:14PM +0200, Ole J. Tetlie wrote:
> *-Darren Benham <[EMAIL PROTECTED]>
> |
> | If you don't get the original volunteer, I'll take it over.  I like and use
> | yagirc so I've got a stake in it being kept up-to-date.
> 
> I'm here, working on 0.66 as we speak. This might be a good time to ask
> a question. yagirc can now be built with gnome interface or
> text interface. Should I make two packages, include both in one
> package or just drop the non-gui?

IIRC, the non-gui one is more a proof of concept, and, at least for
now, I think that most users of yagirc are interested in the GUI.
Non-gui people are most likely using epic, or something similiar:->>

Ciao,
-- 
David Welton  http://www.efn.org/~davidw 

Debian GNU/Linux - www.debian.org