Re: Possible GIMP contest for new Debian logo

[Nils Lohner]

Sorry, this probably belongs on -devel... I'll post it there too.  About 
the design, I personally like the penguin for Debian GNU/Linux, have 
something similar for Hurd (meaning a red profile of a GNU head or 
something) and something different (maybe plain nice graphical text?  
There was a nice one in the previous set of submissions...) for the Debian 
one.

Nils.

In message <[EMAIL PROTECTED]>, Nils Lohner 
writes
:
>
>Actually, one more 'real' point in this discussion... we should really 
>have 3 logos.  One for Debian (the project), one for Debian GNU/Linux, 
and
>one for Debian GNU/Hurd... the Debian one should symbolize the project, 
>and the other two should be somehow related to it and/or each other.  
>Debian is not just Linux anymore, at least not since Hurd came along, 
just
>like Linux isn't just i386 any more.
>
>Just a few cents worth of thoughts (at a penny apiece, that's a few! :)
>
>Nils.

Re: Getting Slink compatible with Linux-2.2.0

[Jason Gunthorpe]

On Tue, 26 Jan 1999, Gergely Madarasz wrote:

> > But is that specific problem Debian/slink related..? That is, does it work
> > correctly with potato?
> 
> No, it does not work correctly with potato either. It seems to be a
> general incompatibility with 2.2

2.2 did something bizzar to how the packet filter code needs to work,
nothing that used that mechanism will work anymore. Anyone made sure that
libpcap works?

Jason

Re: Uploaded util-linux 2.9g-6 (source i386) to master

[Jason Gunthorpe]

On Wed, 27 Jan 1999, Vincent Renardias wrote:

> Ok, so if we really want a Debian 2.1 that is 100% kernel 2.2.x
> compatible it needs this package to be included in frozen.
> I've just uploaded it in Incoming/ 10 minutes ago.
> Non-developers can also access it at http://www.ldsol.com/~vincent/
> (NB: there are _2_ binary packages to install: util-linux and mount.)

We also need working DHCP and BOOTP support in Slink otherwise those
people cannot use 2.2 kernels - potatos DHCP package has support for 2.2
(and 2.0) but I don't know about bootp.

Jason

Re: Uploaded util-linux 2.9g-6 (source i386) to master

[Vincent Renardias]

On Wed, 27 Jan 1999, Eric Delaunay wrote:

> Vincent Renardias wrote:
> [There is text before PGP section.]
> > 
> > Ok, so if we really want a Debian 2.1 that is 100% kernel 2.2.x
> > compatible it needs this package to be included in frozen.
> > I've just uploaded it in Incoming/ 10 minutes ago.
> > Non-developers can also access it at http://www.ldsol.com/~vincent/
> > (NB: there are _2_ binary packages to install: util-linux and mount.)
> 
> Is this release providing fdisk for SUN disklabels?
> (thus making my sparc-fdisk obsolete ;-) )

It may:

# l util-linux-2.9g/disk-utils/*sunlabel*
-rw-r--r--   1 500  500 20813 Dec 12 01:16 
util-linux-2.9g/disk-utils/fdisksunlabel.c
-rw-r--r--   1 500  500  2493 Oct  8 21:38 
util-linux-2.9g/disk-utils/fdisksunlabel.h
#

Not having a sparc aroud I can't test it, but I'd be interested to know...
(NB: those files are used by fdisk, but not cfdisk)

Cordialement,

-- 
- Vincent RENARDIAS  [EMAIL PROTECTED],pipo}.com,{debian,openhardware}.org} -
- Debian/GNU Linux:   http://www.openhardware.orgLogiciels du soleil: -
- http://www.fr.debian.orgOpen Hardware: http://www.ldsol.com -
---
-"Microsoft est à l'informatique ce que le grumeau est à la crépe..." -

Re: New logo strategy

[Ben Gertzfield]

> "Wichert" == Wichert Akkerman <[EMAIL PROTECTED]> writes:

Jules> Whilst I have no objections to such a change in rules, I am
Jules> baffled that anyone could prefer xpaint to gimp, even for
Jules> drawing straight lines and ellipses.

Wichert> Why is this a change in rules? I've never seen it written
Wichert> anywhere that you are obliged to use the gimp. I wouldn't
Wichert> even know how to check what tool was used.

I believe the GIMP contests specify that you need to use GIMP for
creating the image. But you're right, there's really no way to check
that.

Ben

-- 
Brought to you by the letters S and V and the number 5.
"Tahiti is not in Europe."
Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/
I'm on FurryMUCK as Che, and EFNet/Open Projects IRC as Che_Fox.

Re: New logo strategy

[Wichert Akkerman]

Previously Jules Bean wrote:
> Whilst I have no objections to such a change in rules, I am baffled that
> anyone could prefer xpaint to gimp, even for drawing straight lines and
> ellipses.

Why is this a change in rules? I've never seen it written anywhere that
you are obliged to use the gimp. I wouldn't even know how to check what
tool was used.

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/


pgpZN60Bm22KW.pgp
Description: PGP signature

Re: What's needed for kernel 2.2

[Wichert Akkerman]

Previously Peter S Galbraith wrote:
> kerneld is replaced by something else, etc.

Kerneld is replaced by a kernel thread, so it has become obsolete. The
modutils package in slink has been able to handle that change for quite
a while now.

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/


pgpIPWqFX6Ndb.pgp
Description: PGP signature

Re: Uploaded util-linux 2.9g-6 (source i386) to master

[Eric Delaunay]

Vincent Renardias wrote:
[There is text before PGP section.]
> 
> Ok, so if we really want a Debian 2.1 that is 100% kernel 2.2.x
> compatible it needs this package to be included in frozen.
> I've just uploaded it in Incoming/ 10 minutes ago.
> Non-developers can also access it at http://www.ldsol.com/~vincent/
> (NB: there are _2_ binary packages to install: util-linux and mount.)

Is this release providing fdisk for SUN disklabels?
(thus making my sparc-fdisk obsolete ;-) )

Thanks in advance.

-- 
 Eric Delaunay | "La guerre justifie l'existence des militaires.
 [EMAIL PROTECTED] | En les supprimant." Henri Jeanson (1900-1970)

Uploaded util-linux 2.9g-6 (source i386) to master

[Vincent Renardias]

Ok, so if we really want a Debian 2.1 that is 100% kernel 2.2.x
compatible it needs this package to be included in frozen.
I've just uploaded it in Incoming/ 10 minutes ago.
Non-developers can also access it at http://www.ldsol.com/~vincent/
(NB: there are _2_ binary packages to install: util-linux and mount.)

Needless to say that before to be eventually included in frozen, this
package must be _heavily_ tested. So if you're currently running the
frozen distribution, please install this package and report any problem
you may find.

NB: back in June 1996, I decided to switch from Slackware to Debian
because Debian 1.1 (codename: buzz ;) was the very first to be kernel
2.0.x ready. So I hope having Debian 2.1 kernel 2.2.x ready will attract a
lot a new users to Debian. ;)


Cordialement,


-BEGIN PGP SIGNED MESSAGE-

Format: 1.5
Date: Tue, 26 Jan 1999 23:51:57 +0100
Source: util-linux
Binary: mount util-linux
Architecture: source i386
Version: 2.9g-6
Distribution: frozen unstable
Urgency: low
Maintainer: Vincent Renardias <[EMAIL PROTECTED]>
Description: 
 mount  - Tools for mounting and manipulating filesystems.
 util-linux - Miscellaneous system utilities.
Changes: 
 util-linux (2.9g-6) frozen unstable; urgency=low
 .
   * modify mount.8 manpage to warn that nosuid is useless
 if something like suidperl is installed.
 (doesn't fix the critical bug #31980 reported on suidperl,
 but at least warn about its existance)
   * add missing manpages (ramsize,rootflags,swapdev)
   * #32414: changed a 'rm' into 'rm -f' so the source
 package builds cleanly.
   * also target the upload for frozen since this is the only missing
 package to be able to safely use kernels 2.2.x:
 To the FTP/Release maintainers:
   util-linux_2.9g has been introduced in unstable on Dec, 31st 98;
   so far I received no bug reports about it except for the missing
   manpages. Also compared to the 2.7.1 version from frozen, this
   package fixes _57_ bugs. (see www.debian.org/Bugs/db/pa/lutil-linux.html)
Files: 
 daa3db9865807c86ffbb8a1c6f2e1324 640 base required util-linux_2.9g-6.dsc
 ab409a6ac5a775a4b04b8e27f6c86933 566655 base required 
util-linux_2.9g.orig.tar.gz
 d75a0ca19b0bec55651ce8bb74ebf0ec 56118 base required util-linux_2.9g-6.diff.gz
 79f7761089e22bdc97dc3675d2f2aa79 280246 base required 
util-linux_2.9g-6_i386.deb
 9e61af15227fccfc6bab1f85a167f643 63826 base required mount_2.9g-6_i386.deb

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: noconv

iQCVAwUBNq5Ojg+bo1sI1mwpAQGb9wQAi4vAop9d+QFismEhI4CHlpyANXLKv6G0
NlYDejkvWj50ozL8zQNmIoFSTcNuR4Vwyui+k4x7cd2VrYzXoioN6BiL+5YWZQIA
tZbrRYFTsT6oqZjqj4yVnDCQoXqrkKd1EXFR3fO28BRtETqRPoUQWlxeyHcJVhvc
s5kJRm/wTbY=
=JwEY
-END PGP SIGNATURE-

Re: Release notes for slink

[Branden Robinson]

On Mon, Jan 25, 1999 at 10:28:56PM +, [EMAIL PROTECTED] wrote:
> How about adding that the xvidtune program is in the xf86setup package?  Some
> users may be confident enough about their X configuration not to bother
> installing xf86setup, and then miss xvidtune.

As of version -9, xvidtune is back in xbase-clients.  I'm getting ready to
release -9.

-- 
G. Branden Robinson  |   You can have my PGP passphrase when you
Debian GNU/Linux |   pry it from my cold, dead brain.
[EMAIL PROTECTED]   |   -- Adam Thornton
cartoon.ecn.purdue.edu/~branden/ |


pgpv2HP6H7xPJ.pgp
Description: PGP signature

Re: Why /var/www? (Was: Where does 'www-data' come from?)

[Steve Lamb]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, 26 Jan 1999 22:22:36 GMT, Marc Haber wrote:

>On Tue, 26 Jan 1999 09:26:05 -0800, you wrote:
>>Major services generally get a root entry from me.  Some people
>>think it is ugly but there is some purity in cd'ing to /www/somebusinesssite/

>It outright violates the fhs, though.

Sure, and?  That was on my system and it is a symlink.  I'm not a big
supporter of FHS or the other fs standard because both contain things in
places I don't consider them proper.

- -- 
 Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
 ICQ: 5107343  | main connection to the switchboard of souls.
- ---+-
-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.0 (C) 1997 Pretty Good Privacy, Inc

iQA/AwUBNq5Dh3pf7K2LbpnFEQKKtACfYZrTf3YOrJAD3q/ywbh7PchKnUQAmwfl
nnz81nb6YXq2aUECSZqYfx1G
=+oTY
-END PGP SIGNATURE-

Re: Why /var/www? (Was: Where does 'www-data' come from?)

[Josip Rodin]

On Mon, Jan 25, 1999 at 10:23:34PM -0500, Michael Stone wrote:
> Quoting Juergen A. Erhard ([EMAIL PROTECTED]):
> > I personally thing either the ftp hierarchy should go to /var/ftp, or
> > the www data should move to /home/www (the latter I'd prefer).
> 
> /home/(ftp|www) is just plain ugly. (It's a real pain when you're trying
> to share nfs home dirs between web servers, for example.) I use /var/ftp
> on my own system (well, actually /var/local/ftp...)

I'd suggest /var/{ftp,www}. Anonymous ftp user is a 'user', but a
semi-system one, and it shouldn't be in /home.

--
enJoy -*/\*- http://jagor.srce.hr/~jrodin/

Re: Why /var/www? (Was: Where does 'www-data' come from?)

[Marc Haber]

On Tue, 26 Jan 1999 09:26:05 -0800, you wrote:
>Major services generally get a root entry from me.  Some people
>think it is ugly but there is some purity in cd'ing to /www/somebusinesssite/

It outright violates the fhs, though.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber  |   " Questions are the | Mailadresse im Header
Karlsruhe, Germany  | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature  | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

Re: What's needed for kernel 2.2

[Raul Miller]

Remco van de Meent <[EMAIL PROTECTED]> wrote:
> Because I, like every other user should do, read the documentation, and thus
> read you need util-linux 2.9g. And if it works for you with lower versions,
> does it always work? Yes, maybe, no, maybe not. I don't even want to take
> the risk of 'yes it works most of the time, but sometimes it doesnt', with
> kernel-things.

It's probably worth noting in the package description that this copy
is not hacked.

2.9h has a bunch of new code and may or may not be stable (it will take
weeks to find out).

-- 
Raul

Re: Getting Slink compatible with Linux-2.2.0

[Raul Miller]

Marcelo E. Magallon <[EMAIL PROTECTED]> wrote:
> a) If you DO NEED a > 128 MB swap file you are in serious trouble.

Not if you have 2G ram.

-- 
Raul

Re: Way, way off-topic

[John Hasler]

I wrote:
> On the contrary.  The "military", at least in the US and the UK, act in
> accordance with the laws of their respective nations, which require them to
> obey the civilian governments.  It is those governments, not the
> "military", that are signatories to treaties (not that I know of any that
> require nuclear disarmament).

Joseph Carter writes:
> Just keep telling yourself that..  =>

That it is governments, not the military, that are signatories to treaties?
That is simply a fact.

That the "military", at least in the US and the UK, obey the civilian
governments?  I believe that to be true, but it does not follow that I
approve of all that they do.  It is disingenuous to say "That fascist
military did [name your favorite nastiness]" when you know that they were
carrying out government policy.  In the case at hand if the UK is signatory
to a treaty which requires that it destroy its nuclear weapons then the
responsibility for failing to comply lies with Parliament, not the UK
military.

In those nations where the military are not subservient to the civilian
government they are the government, and thus are carrying out government
policy whatever they do.
-- 
John HaslerThis posting is in the public domain.
[EMAIL PROTECTED]  Do with it what you will.
Dancing Horse Hill Make money from it if you can; I don't mind.
Elmwood, Wisconsin Do not send email advertisements to this address.

Re: Getting Slink compatible with Linux-2.2.0

[Remco van de Meent]

Joey Hess wrote:
> I'm forced to agree. Support for swap partitions > 128 mb is a new
> feature; a mkswap that doesn't support it isn't a major incompatability.
> Few people will need the feature anyway, and if they do need it the simple
> workaround is to use multiple 128 mb partitions.

Okay, reading the emails people sent me, I think I didn't make clear what I
meant.

It is not that I claim "you need this and that to compile and/or run a 2.2
kernel". I say "the requirements speak of this and that to compile and/or
run a 2.2 kernel". Are those requirements not entirely correct? Probably,
most likely they are not minimal requirements. But, hey, the kernel
documentation, the place where I personally would look when I want to run
that kernel, states I need such versions of software.

Now you can make choices between two things, being a Debian supporter: 1)
Debian should listen to those requirements, and get their upcoming release
compatible in the sense that when I, as a user, try to figure out if my
newly installed Debian slink system supports 2.2 kernels, looking at the
documentation; or 2) wait for the users to come and ask if Debian 2.1
(slink) is compatible. And not once. Not twice. I'd go for at least one
hundred times. And yes, then it will be put in some faq that 'some' users
don't read.

Thus, I'm not talking about putting new features in the frozen distribution,
I'm talking of makeing it both the users out there, and the people helping
those users, easier when slink gets released and questions about Linux-2.2
come up.. Maybe I'm totally wrong with my expectations on what people will
do when they want Linux-2.2 on their slink system, who knows. Do you?


Thanks for everyones time,
 -Remco

Re: filters: Licence problems

[Edward Betts]

On Tue, 26 Jan, 1999, Marcus Brinkmann wrote:
> This one is easy. Install this as your cron job:
> 
> grep straying /bin/cat; touch /bin/cat; free /bin/cat

$ grep straying /bin/cat; touch /bin/cat; free /bin/cat
touch: /bin/cat: Permission denied
 total   used   free sharedbuffers cached
Mem: 63396  62344   1052  40640   2432  42020
-/+ buffers/cache:  17892  45504
Swap:64476 24  64452

-- 
GNU does not eliminate all the world's problems, only some of them.
-- The GNU Manifesto

Re: What's needed for kernel 2.2

[Remco van de Meent]

Hamish Moffatt wrote:
> > I just discovered, unfortunately, that you need the util-linux package
> > from potato (unstable). Rest of the things in slink are fine with
> > 2.2.0!!
> 
> Why's that? I'm using the one from slink with 2.2.0 and it works just
> fine. I've been running 2.2.0-pre6 for a couple of weeks and just upgraded
> to 2.2.0 last night.

Because I, like every other user should do, read the documentation, and thus
read you need util-linux 2.9g. And if it works for you with lower versions,
does it always work? Yes, maybe, no, maybe not. I don't even want to take
the risk of 'yes it works most of the time, but sometimes it doesnt', with
kernel-things.

You cannot say 'oh with this particular package, versions dont matter',
don't you think?

This is not meant as a disagreement to your 'claim', it's just that I think
it isn't wise not to listen to such requirements in general... that's also
the main reason I started the thread about slink/2.2.0.


bye,
 -Remco

Re: Getting Slink compatible with Linux-2.2.0

[Tim \(Pass the Prozac\) Sailer]

On Tue, Jan 26, 1999 at 01:33:01PM -0800, Steve Lamb wrote:
> On Tue, 26 Jan 1999 16:21:56 -0500, Tim \(Pass the Prozac\) Sailer wrote:
> 
> >I have about 50 machines with all 4 DIMM slots filled with 128M sticks.
> >I have *8* 128M swap partitions, and it's not enough since the (*&[EMAIL 
> >PROTECTED]
> >users run programs that average a 1.2G footprint. For me, it's just a
> >management issue.
> 
> So, can I have a shell account?  I swear, you won't notice me and my
> 15-20mb of usage, honest!  ;)

:) If you can get an account at bnl.gov, I'll gladly give you an account
on there. Maybe you'd like an account on the quad xenon machines we're
playing with? They have *only* 1.5GB RAM, but they are evaluation units.
:)

Tim

-- 
 (work) [EMAIL PROTECTED] / (home) [EMAIL PROTECTED] - http://www.buoy.com/~tps
  "Paranoia is a heightened state of awareness."
  -- Anon
** Disclaimer: My views/comments/beliefs, as strange as they are, are my own.**

Re: Getting Slink compatible with Linux-2.2.0

[Bob Nielsen]

On Tue, Jan 26, 1999 at 08:36:53PM +0100, Remco van de Meent wrote:

> I just tried to match the Changes file from Linux-2.2.0 with the slink 
> distribution, and was happy to find out that almost every requirement 
> mentioned in that file is fullfilled by the packages (versions) in slink. 
> However, one dependancy isn't resolved: util-linux. Linux-2.2.0 wants 
> util-linux 2.9g, but the one in slink is 2.7.1. Potato does have 2.9g.  The 
> main difference between them is the mkswap utility (support for swapfiles 
> 128M). 

Changes says that net-tools 1.49 is required.  It says to use 'hostname
-V' to determine the version, but this does not work.  'route -V' in both
slink and potato indicate that the net-tools version is 1.45.  

Is an upgrade needed here?  I haven't noticed any problems with this, but
I'm not familiar with the specific differences between 1.45 and 1.49.
 
Bob


Bob Nielsen Internet: [EMAIL PROTECTED]
Tucson, AZ  AMPRnet:  [EMAIL PROTECTED]
DM42nh  http://www.primenet.com/~nielsen

-- Forwarded message --
Date: Tue, 26 Jan 1999 14:13:04 -0700 (MST)
From: Bob Nielsen <[EMAIL PROTECTED]>
To: debian-user@lists.debian.org
Subject: Re: new kernel release

I see that Documentation/CHANGES says that net-tools 1.49 is required.  It
says to use 'hostname -V' to determine the version, but this does not
work.  'route -V' in both slink and potato that the net-tools version is
1.45.  Is an upgrade needed here?

Bob


Bob Nielsen Internet: [EMAIL PROTECTED]
Re: Getting Slink compatible with Linux-2.2.0Tucson, AZ
AMPRnet: [EMAIL PROTECTED]
DM42nh  http://www.primenet.com/~nielsen

Re: Getting Slink compatible with Linux-2.2.0

[Joey Hess]

Marcelo E. Magallon wrote:
> I'm forced to ask: what for?

I'm forced to agree. Support for swap partitions > 128 mb is a new feature;
a mkswap that doesn't support it isn't a major incompatability. Few people
will need the feature anyway, and if they do need it the simple workaround
is to use multiple 128 mb partitions.

-- 
see shy jo

Re: Getting Slink compatible with Linux-2.2.0

[Vincent Renardias]

On Tue, 26 Jan 1999, Remco van de Meent wrote:

> In my more than honest opinion, I think util-linux 2.9g should be included
> in slink. Developments in the computer business are going fast, as everyone
> knows, and on the day slink will get released, I think a lot of people who
> are going to upgrade to slink, also want to have the newest kernel, 2.2.
> That's why slink should be compatible with Linux-2.2, otherwise it is quite
> a bit outdated at the moment of release. There is a major difference between
> not being compatible with the latest major kernel release, and not including
> the latest patchlevel of some software thingie.
> 
> An option would be to backport the mkswap utility into util-linux 2.7.1.x,
> but I'd rather prefer including 2.9g. Why? Because
> linux/Documentation/Changes states that 2.9g is necessary. And that's the
> file people will look in, when they want Linux-2.2. They're not going to
> look at /usr/doc/util-linux/README.Debian. At least, that would be my guess.
> 
> Also, Stephen Crowley noted that new dhcp-packages should be included in
> slink, because the ones that currently are in slink ain't compatible with
> Linux-2.2 either, but maybe he can explain that himself :)
> 
> Brian et al., I hope you want to reconsider the point of including newer
> versions of some packages in slink, even at this moment when the fridge is
> working at maximum power...

Speaking as the maintainer of util-linux (I adopted it 2 weeks ago):

Including the current (2.9g-5) util-linux from unstable in frozen is a Bad
Idea(tm). This version has several big packaging issues. If you want a
util-linux 2.9 in frozen, please wait at least until tomorrow so I can
upload a version to fix the most obvious bugs (notably the few missing
manpages).

Cordialement,

-- 
- Vincent RENARDIAS  [EMAIL PROTECTED],pipo}.com,{debian,openhardware}.org} -
- Debian/GNU Linux:   http://www.openhardware.orgLogiciels du soleil: -
- http://www.fr.debian.orgOpen Hardware: http://www.ldsol.com -
---
-"Microsoft est à l'informatique ce que le grumeau est à la crépe..." -

Re: Getting Slink compatible with Linux-2.2.0

[Steve Lamb]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, 26 Jan 1999 16:21:56 -0500, Tim \(Pass the Prozac\) Sailer wrote:

>I have about 50 machines with all 4 DIMM slots filled with 128M sticks.
>I have *8* 128M swap partitions, and it's not enough since the (*&[EMAIL 
>PROTECTED]
>users run programs that average a 1.2G footprint. For me, it's just a
>management issue.

So, can I have a shell account?  I swear, you won't notice me and my
15-20mb of usage, honest!  ;)

- -- 
 Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
 ICQ: 5107343  | main connection to the switchboard of souls.
- ---+-
-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.0 (C) 1997 Pretty Good Privacy, Inc

iQA/AwUBNq40jXpf7K2LbpnFEQLV3wCgzga30ILohFMQjIouRoL2jt1pBMwAoLIS
Mq4yjxtjXKvP2qofyYOEdxKF
=NNHt
-END PGP SIGNATURE-

Re: What's needed for kernel 2.2

[Hamish Moffatt]

On Tue, Jan 26, 1999 at 07:59:29PM +0100, Remco van de Meent wrote:
> I just discovered, unfortunately, that you need the util-linux package from
> potato (unstable). Rest of the things in slink are fine with 2.2.0!!

Why's that? I'm using the one from slink with 2.2.0 and it works just fine.
I've been running 2.2.0-pre6 for a couple of weeks and just upgraded to
2.2.0 last night.


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: Getting Slink compatible with Linux-2.2.0

[Tim \(Pass the Prozac\) Sailer]

On Tue, Jan 26, 1999 at 03:03:14PM -0600, Marcelo E. Magallon wrote:
> I'm forced to ask: what for?
> 
> a) If you DO NEED a > 128 MB swap file you are in serious trouble.  You
>should get more ram; the induced cost of extremely slow operation is much
>higher than that of two lousy DIMMs.

I have about 50 machines with all 4 DIMM slots filled with 128M sticks.
I have *8* 128M swap partitions, and it's not enough since the (*&[EMAIL 
PROTECTED]
users run programs that average a 1.2G footprint. For me, it's just a
management issue.

Tim

-- 
 (work) [EMAIL PROTECTED] / (home) [EMAIL PROTECTED] - http://www.buoy.com/~tps
  "Paranoia is a heightened state of awareness."
  -- Anon
** Disclaimer: My views/comments/beliefs, as strange as they are, are my own.**

Re: Getting Slink compatible with Linux-2.2.0

[Steve Lamb]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, 26 Jan 1999 15:03:14 -0600, Marcelo E. Magallon wrote:

>c) The argument "something on the kernel wants it" doesn't hold. For that
>   matter, the kernel wants coda, and that's in project/experimental. What
>   did you say?  That coda is not essential?  Neither is a huge swap file.

Or, to put it in a slightly different way.  Just because the kernel can
*USE* something does not mean that the kernel *NEEDS* it to run.  

Running a slink/potato system here:

[EMAIL PROTECTED]:/home/morpheus}ud -d
- - Uptime for teleute -
Now  : 2 day(s), 08:19:33 running Linux 2.2.0-final
One  : 26 day(s), 21:36:39 running Linux 2.1.126, ended Fri Jan 22 00:31:03
1999
Two  : 2 day(s), 08:18:53 running Linux 2.2.0-final, ended Tue Jan 26
13:18:15 1999
Three: 1 day(s), 01:26:40 running Linux 2.2.0-final, ended Sun Jan 24
04:32:36 1999

- -- 
 Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
 ICQ: 5107343  | main connection to the switchboard of souls.
- ---+-
-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.0 (C) 1997 Pretty Good Privacy, Inc

iQA/AwUBNq4yh3pf7K2LbpnFEQLD4wCg42X0VkUhIvQCuDJNuLybfcjhJfsAoKI3
v26i/mlRoErJ5GH1hBHDLzrA
=ChIO
-END PGP SIGNATURE-

Re: libtool & rpath

[Hamish Moffatt]

On Tue, Jan 26, 1999 at 02:51:03PM +0100, Santiago Vila wrote:
> On Wed, 27 Jan 1999, Hamish Moffatt wrote:
> > an easy fix for that? Splitting the packages is a possibility, but
> > libgeda is of absolutely no use on its own yet, and I don't think there
> > is anything for a libgeda-dev.
> 
> I have found this in the policy:
> 
> 4.3 Shared libraries
> 
>Packages involving shared libraries should be split up into several
>binary packages.
> 
> 
> This suggests that the split is mandated by policy.

There is absolutely no value in splitting the package at this point in time.
In the future, there will be.


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: Getting Slink compatible with Linux-2.2.0

[Marcelo E. Magallon]

On Tue, Jan 26, 1999 at 08:36:53PM +0100, Remco van de Meent wrote:

> I just tried to match the Changes file from Linux-2.2.0 with the slink
> distribution, and was happy to find out that almost every requirement
> mentioned in that file is fullfilled by the packages (versions) in slink.
> However, one dependancy isn't resolved: util-linux. Linux-2.2.0 wants
> util-linux 2.9g, but the one in slink is 2.7.1. Potato does have 2.9g. The
> main difference between them is the mkswap utility (support for swapfiles
> 128M).

I'm forced to ask: what for?

a) If you DO NEED a > 128 MB swap file you are in serious trouble.  You
   should get more ram; the induced cost of extremely slow operation is much
   higher than that of two lousy DIMMs.

b) I've been running 2.1.x kernels for ages (ok, not that much, circa 80,
   give or take a couple of releases) at home, where I have a hamm box (with
   bits and pieces from slink and potato).  The only thing that I know I had
   to upgrade because of the 2.1.x kernels was ppp.  The other non-hamm
   stuff I have on that box is there because I need it, not because the
   kernel wants it.  There's a hamm box right in front of me running 2.2.0
   and as far as I can tell, it's quite happy with it.  The box I'm sitting
   at follows slink, and it's also running 2.2.0 very happily.

c) The argument "something on the kernel wants it" doesn't hold. For that
   matter, the kernel wants coda, and that's in project/experimental. What
   did you say?  That coda is not essential?  Neither is a huge swap file.


Marcelo

Re: Getting Slink compatible with Linux-2.2.0

[Gergely Madarasz]

On Tue, 26 Jan 1999, Remco van de Meent wrote:

> Gergely Madarasz wrote:
> > Another problem: bootpc from the netstd package does not work with 2.2.
> > Btw the kernel has bootp support itself, but it can't be used with pnp
> > network cards which need isapnp initialization. So my network setup which
> > used bootp breaks with 2.2...
> 
> But is that specific problem Debian/slink related..? That is, does it work
> correctly with potato?

No, it does not work correctly with potato either. It seems to be a
general incompatibility with 2.2

-- 
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/

Getting Slink compatible with Linux-2.2.0

[Remco van de Meent]

Hi,

With this message, I know I'm going to touch a rather sensitive subject, but
however, I think it's worth it.

I just tried to match the Changes file from Linux-2.2.0 with the slink
distribution, and was happy to find out that almost every requirement
mentioned in that file is fullfilled by the packages (versions) in slink.
However, one dependancy isn't resolved: util-linux. Linux-2.2.0 wants
util-linux 2.9g, but the one in slink is 2.7.1. Potato does have 2.9g. The
main difference between them is the mkswap utility (support for swapfiles >
128M).

In my more than honest opinion, I think util-linux 2.9g should be included
in slink. Developments in the computer business are going fast, as everyone
knows, and on the day slink will get released, I think a lot of people who
are going to upgrade to slink, also want to have the newest kernel, 2.2.
That's why slink should be compatible with Linux-2.2, otherwise it is quite
a bit outdated at the moment of release. There is a major difference between
not being compatible with the latest major kernel release, and not including
the latest patchlevel of some software thingie.

An option would be to backport the mkswap utility into util-linux 2.7.1.x,
but I'd rather prefer including 2.9g. Why? Because
linux/Documentation/Changes states that 2.9g is necessary. And that's the
file people will look in, when they want Linux-2.2. They're not going to
look at /usr/doc/util-linux/README.Debian. At least, that would be my guess.

Also, Stephen Crowley noted that new dhcp-packages should be included in
slink, because the ones that currently are in slink ain't compatible with
Linux-2.2 either, but maybe he can explain that himself :)

Brian et al., I hope you want to reconsider the point of including newer
versions of some packages in slink, even at this moment when the fridge is
working at maximum power...


Kind regards,
 -Remco

Re: Getting Slink compatible with Linux-2.2.0

[Remco van de Meent]

Gergely Madarasz wrote:
> Another problem: bootpc from the netstd package does not work with 2.2.
> Btw the kernel has bootp support itself, but it can't be used with pnp
> network cards which need isapnp initialization. So my network setup which
> used bootp breaks with 2.2...

But is that specific problem Debian/slink related..? That is, does it work
correctly with potato?


 -Remco

Re: LSH (GPL'd SSH)

[Daniel Quinlan]

J.H.M. Dassen wrote:

>> Another freeness issue (albeit a relatively minor one) is that currently
>> lsh requires scsh (which is non-free) for the generation of include files
>> (they are pregenerated in the tarball; the scsh scripts are needed only
>> for development). It would be nice if someone could modify them to work
>> with a free Scheme implementation (say Guile), or reimplement them in
>> another free scripting language (perl, python etc.).

Ben Collins <[EMAIL PROTECTED]> writes:

> Good point, I saw that, but forgot about it. The TODO/TASKLIST mentions
> and idea about using Guile, so that would seem the best way to go.

If the scripts are generated using a more common scripting language (like
perl), then you're more likely to have developers work on it.

- Dan

Re: Getting Slink compatible with Linux-2.2.0

[Gergely Madarasz]

On Tue, 26 Jan 1999, Remco van de Meent wrote:

> Also, Stephen Crowley noted that new dhcp-packages should be included in
> slink, because the ones that currently are in slink ain't compatible with
> Linux-2.2 either, but maybe he can explain that himself :)

Another problem: bootpc from the netstd package does not work with 2.2.
Btw the kernel has bootp support itself, but it can't be used with pnp
network cards which need isapnp initialization.
So my network setup which used bootp breaks with 2.2...

Greg

-- 
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: the Great X Reorganization, package splits, and renaming

[Santiago Vila]

Raul Miller wrote:
> We'll have to keep around the empty xfnt* packages indefinitely (should they
> need to be created) until a better solution is available, no matter what.

Surely a small set of *empty* packages will not be a great problem
in terms of disk sapce in master.

> I think you missed the bit where Branden was promissing to make the empty
> xfnt* packages wherever they were actually needed (for people to be able
> to upgrade smoothly).

Well, I think *nobody* will want to keep the old packages around if the
new ones replace the old ones, even if they have the same functionality.
This is the reason why dselect's default behaviour is to "upgrade
everything".

So the dummy packages in slink for all the packages that changed its
name will be already useful for all the people who want to have a
system having only packages from slink.

-- 
 "162b1be882bb12616188e0421a73d019" (a truly random sig)

Re: the Great X Reorganization, package splits, and renaming

[Santiago Vila]

Oops, sorry. Bad formatting, here is the right one:

I have a computer lab with 20 Debian machines. Suppose I want to upgrade
them to slink and I want the new font packages to be installed (like most
people will also want). Do you mean that I should enter dselect and select
them by hand on each of them? Do you claim that it is better that I *have*
to do it by hand?

-- 
 "d7dda0344ad6ba2560d35acdfe002aa4" (a truly random sig)

Re: the Great X Reorganization, package splits, and renaming

[Santiago Vila]

On Tue, 26 Jan 1999, Branden Robinson wrote:

> I reiterate my challenge.  Demonstrate to me a manner in which a
> hamm system upgraded to slink, which keeps the old X font and static
> library packages, will be broken.

Oh, I forgot to tell you something:

I have a computer lab with 20 Debian machines. Suppose I want to upgrade
them to slink and I want the new font packages to be installed people will
want). Do you mean that I should enter dselect and select them by hand on
each of them? Do you claim that it is better that I *have* to do it by
hand?

-- 
 "786c6eabac4a441ad37cd4fe8214e6da" (a truly random sig)

Re: the Great X Reorganization, package splits, and renaming

[Raul Miller]

Santiago Vila <[EMAIL PROTECTED]> wrote:
> With the current state of things, a Debian system which is upgraded by
> dselect from hamm to slink, from slink to potato, from potato to potato+1,
> and from potato+1 to potato+2 may have, say, X version 5.5, and xfonts
> version 3.3.2.3-2.
> 
> Do you think this may be of any good?
> Don't you agree that we should try to avoid it?

What you described, in itself, is not a problem.

We'll have to keep around the empty xfnt* packages indefinitely (should they
need to be created) until a better solution is available, no matter what.

I think you missed the bit where Branden was promissing to make the empty
xfnt* packages wherever they were actually needed (for people to be able
to upgrade smoothly).

I think you have a valid point about the way dselect will present the
information.  dselect presenting package entries which say why they're
obsolete (or depreciated) would be more user friendly than what it
presents as the default for missing packages.

-- 
Raul

Intent to package: pcd2html

[Andreas Tille]

Hello

I would like to package my self written script system pcd2html  which
creates commented HTML pages from a Kodak Photo CD using user
supplied options for convert from ImageMagick and describing text.

Informations are available at

   http://www.physik.uni-halle.de/~e2od5/debian/pcd2html.html

The result of this script system can be shown at

   http://www.physik.uni-halle.de/~e2od5/island/pcd_1998

which presents 104 shots from two holidays in Iceland.
Hope that pcd2html will be useful for you and may be you will
enjoy the images, too.

Kind regards

 Andreas.

Re: the Great X Reorganization, package splits, and renaming

[Santiago Vila]

On Tue, 26 Jan 1999, Branden Robinson wrote:

> I reiterate my challenge.  Demonstrate to me a manner in which a
> hamm system upgraded to slink, which keeps the old X font and static
> library packages, will be broken.

I hope you will agree that sometimes we have to think about the future.

With the current state of things, a Debian system which is upgraded by
dselect from hamm to slink, from slink to potato, from potato to potato+1,
and from potato+1 to potato+2 may have, say, X version 5.5, and xfonts
version 3.3.2.3-2.

Do you think this may be of any good?
Don't you agree that we should try to avoid it?

-- 
 "83835090bf2dd62c42b79e7cf5db4081" (a truly random sig)

Re: What's needed for kernel 2.2

[Remco van de Meent]

Peter S Galbraith wrote:
> > modutils, gcc, binutils, libc5, libc6, ldso, procps, sysutils, psmisc,
> > hostname, loadlin, shellutils, autofs, nfs-server, bash, ncpfs,
> > pcmcia-cs, ppp, util-linux.
> > 
> > If you get the versions of these packages that are in the currently
> > frozen Debian distribution (slink), then they'll suffice.
> 
> Great!  Thanks!
> Knowing slink pacakages are enough is great news!

I just discovered, unfortunately, that you need the util-linux package from
potato (unstable). Rest of the things in slink are fine with 2.2.0!!

Apologies,
 -Remco

Re: the Great X Reorganization, package splits, and renaming

[Santiago Vila]

Branden Robinson:
> [...]
> Only now do you seem to be concerned.

No, this has been a frequently asked question for some time in
debian-user. I should probably add it to the Debian FAQ.

Please, note that I'm not blaming you for not having thought about this
problem *in advance*. I just want to see it solved in *whatever* way.

> [...]
> > Upgrading a system from hamm to slink should make the system to be in the
> > same state as if slink had been installed from scratch.
> > 
> > Otherwise, Debian will become just a W95 clone very soon (have you ever
> > asked yourself why people reinstall W95 so often?).
> 
> This is a straw-man argument.  Isolate one criterion -- if we don't meet
> that by YOUR standard, we're no better than Windows 95.

The W95 case was just an example.

The upgrade *should* be smooth. This is not my criterion, it is one of
the things that Debian has promised to our users, and it is something the
users expect from us.

> [...]
> I reiterate my challenge.  Demonstrate to me a manner in which a
> hamm system upgraded to slink, which keeps the old X font and static
> library packages, will be broken.

Well, I have already said that the fact that the harm is not immediate
does not mean that it is less broken.

However, if you want something immediate, here it is: dselect will show
the old packages as being "obsolete". This will cause a lot of
confusion, a lot of questions to answer and a lot of time lost for
everybody.

And of course a lot of fear about Debian, since people will think that we
change names gratuitously without a good reason to do so, and more
important, without implementing a good renaming mechanism *first* in dpkg.

Are you trying to tell me that it is *better* that the X packages do *not*
upgrade automatically? (I hope not).


Put it simply: You have, as X maintainer, the right to rename the packages
as you want. However, once they are renamed, we have a problem, they do
not upgrade automatically, as everybody expects. Then we have two choices:

1. Do whatever we can with existing tools so that the X packages are
effectively automatically upgraded.

2. Do nothing.



Is your word final in that you are not convinced that we should make
whatever is needed to ensure that the X packages are automatically
upgraded, as the rest of the system is?

[ Maybe I should post an "intent to package" message then and stop this
 discussion ].

Thanks.

-- 
 "a378a07a477f4abbab1735772121291f" (a truly random sig)

Re: What's needed for kernel 2.2

[Remco van de Meent]

Peter S Galbraith wrote:
> Will some guru tell us what critical packages we need to update in order
> to use 2.2 ?

I'm not a guru I guess, but I can cut&paste something from
linux/Documentation/Changes:

- Kernel modules 2.1.121   ; insmod -V
- Gnu C  2.7.2.3   ; gcc --version
- Binutils   2.8.1.0.23; ld -v
- Linux libc5 C Library  5.4.46; ls -l /lib/libc.so.*
- Linux libc6 C Library  2.0.7pre6 ; ls -l /lib/libc.so.*
- Dynamic Linker (ld.so) 1.9.9 ; ldd --version or ldd -v
- Linux C++ Library  2.7.2.8   ; ls -l /usr/lib/libg++.so.*
- Procps 1.2.9 ; ps --version
- Procinfo   15; procinfo -v
- Psmisc 17; pstree -V
- Net-tools  1.49  ; hostname -V
- Loadlin1.6a
- Sh-utils   1.16  ; basename --v
- Autofs 3.1.1 ; automount --version
- NFS2.2beta37 ; showmount --version
- Bash   1.14.7; bash -version
- Ncpfs  2.2.0 ; ncpmount -v
- Pcmcia-cs  3.0.6 ; cardmgr -V
- PPP2.3.5 ; pppd -v
- Util-linux 2.9   ; chsh -v

Those are in these Debian packages:

modutils, gcc, binutils, libc5, libc6, ldso, procps, sysutils, psmisc,
hostname, loadlin, shellutils, autofs, nfs-server, bash, ncpfs, pcmcia-cs,
ppp, util-linux.

If you get the versions of these packages that are in the currently frozen
Debian distribution (slink), then they'll suffice.


HTH,
 -Remco

Re: Way, way off-topic was: Re: Debian logo & its license

[Joseph Carter]

On Tue, Jan 26, 1999 at 10:33:30AM -0600, John Hasler wrote:
> > You've forgotten something.  The military act as if they are above any
> > laws.  (If they cared about obeying laws, they would be disarming nuclear
> > weapons under their international treaty obligations)
> 
> On the contrary.  The "military", at least in the US and the UK, act in
> accordance with the laws of their respective nations, which require them to
> obey the civilian governments.  It is those governments, not the
> "military", that are signatories to treaties (not that I know of any that
> require nuclear disarmament).

Just keep telling yourself that..  =>

-- 
"I'm working in the dark here."  "Yeah well rumor has it you do your best
work in the dark."
   -- Earth: Final Conflict

Licenses for non-software works, and the definition of software, and , the new DFSG

[Jules Bean]

Hi,

In response to an issue on -legal, I am reopening the debate on how free
those parts of debian which are not software (or not precisely software)
should be.

IMO, this debate should be conducted on -policy, and I ask all replies to
this message to trim the CC: line.

This issue was discussed in length on policy last year.

One such thread is

'Free Software Needs Free Documentation', which begins at

http://www.debian.org/Lists-Archives/debian-policy-9808/msg00042.html


Another thread 'Start for a discussion about free documentation in Debian'
begins with

http://www.debian.org/Lists-Archives/debian-policy-9808/msg00052.html

Four or five other threads follow - please use the list-archives browser
if you have a web browser capable of it.

Being biased, I like the summary I gave in

http://www.debian.org/Lists-Archives/debian-policy-9808/msg00254.html

*Please*, if you have strong views on this subject, at least skim the
above threads, and those which follow on related issues, before entering
the debate. It was very drawn out last time.  It is an important issue,
and I don't think we should vote on a new DFSG which doesn't address it. 

Allow me to summarise some points of fact and some points of view:

1) Technical documentation should be 'free' in the GPL sense.
  This was widely held by all participants in the debate.

2) 'Artistic works' need not be free.
  This suggested to us the creation of a new section in debian,
'verbatim', in which works in certain classes could be distributed.
The line between documentation and 'works of art' may not be clear,
and there may be a mixture in one document.

3) Licenses are generally not free
  This is more or less a fact, actually.  The GPL does not give the
permission to modify, notwithstanding the fact that some other licenses
are very clearly derived works.

4) Some good, 'free' software has non-free documentation
  This poses a dilemma for our principles.

Our conclusions, IMO, should be included either in the new DFSG, if we
accept it, or incorporated into the current, if not.

Jules

..putting on flame suit...

/+---+-\
|  Jelibean aka  | [EMAIL PROTECTED] |  6 Evelyn Rd|
|  Jules aka | [EMAIL PROTECTED]  |  Richmond, Surrey   |
|  Julian Bean   | [EMAIL PROTECTED]|  TW9 2TF *UK*   |
++---+-+
|  War doesn't demonstrate who's right... just who's left. |
|  When privacy is outlawed... only the outlaws have privacy.  |
\--/

Re: Why /var/www? (Was: Where does 'www-data' come from?)

[Steve Lamb]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 25 Jan 1999 22:23:34 -0500, Michael Stone wrote:

>/home/(ftp|www) is just plain ugly. (It's a real pain when you're trying
>to share nfs home dirs between web servers, for example.) I use /var/ftp
>on my own system (well, actually /var/local/ftp...)

Personally I put them where I have drive space and symlink /ftp and /www
to them.  Major services generally get a root entry from me.  Some people
think it is ugly but there is some purity in cd'ing to /www/somebusinesssite/

- -- 
 Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
 ICQ: 5107343  | main connection to the switchboard of souls.
- ---+-
-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.0 (C) 1997 Pretty Good Privacy, Inc

iQA/AwUBNq36rXpf7K2LbpnFEQICfwCdGzgKpPOJd/Utw4c3FmfKNj5meisAn1U7
Y5uwtBmP8jYMUYGaut4BZxql
=aGZI
-END PGP SIGNATURE-

Re: New logo strategy

[Darren Benham]

On 26-Jan-99 Randy Edwards wrote:
>One question I had was out of the two options you list above, which
> category do you see our present logo falling into: the liberal license or the
> official logo?  Or would this new logo contest be used to choose logos for
> both categories?
> 
Because of the current (but expired) logo license, it would fall under the
"official logo" but the contest would offer suggestions for both.

-- 
=
* http://benham.net/index.html <><  *
*  * -BEGIN GEEK CODE BLOCK- ---*
*Darren Benham * Version: 3.1   *
*  <[EMAIL PROTECTED]>  * GCS d+(-) s:+ a29 C++$ UL++> P+++$ L++>*
*   KC7YAQ * 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-- ---*
=


pgpHNmIVuwtBY.pgp
Description: PGP signature

What's needed for kernel 2.2

[Peter S Galbraith]

Will some guru tell us what critical packages we need to update
in order to use 2.2 ?

kerneld is replaced by something else, etc.

I guess that if I'm asking that means I should wait for a proper
Debian upgrade.  Or does kernel-image-2.2.0-i686_2.2.0-1_i386.deb
have all the dependencies sorted out?

Thanks!
-- 
Peter Galbraith, research scientist  <[EMAIL PROTECTED]>
Maurice Lamontagne Institute, Department of Fisheries and Oceans Canada
P.O. Box 1000, Mont-Joli Qc, G5H 3Z4 Canada. 418-775-0852 FAX: 775-0546
6623'rd GNU/Linux user at the Counter - http://counter.li.org/ 

Way, way off-topic was: Re: Debian logo & its license

[John Hasler]

Andrew writes:
> You've forgotten something.  The military act as if they are above any
> laws.  (If they cared about obeying laws, they would be disarming nuclear
> weapons under their international treaty obligations)

On the contrary.  The "military", at least in the US and the UK, act in
accordance with the laws of their respective nations, which require them to
obey the civilian governments.  It is those governments, not the
"military", that are signatories to treaties (not that I know of any that
require nuclear disarmament).
-- 
John HaslerThis posting is in the public domain.
[EMAIL PROTECTED]  Do with it what you will.
Dancing Horse Hill Make money from it if you can; I don't mind.
Elmwood, Wisconsin Do not send email advertisements to this address.

Processed: Need a check for suid applications

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 28850 general
Bug#28850: gettext: security problem when used in setuid programs
Bug reassigned from package `gettext, libc6' to `general'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Ian Jackson
(administrator, Debian bugs database)

Re: New logo strategy

[Raul Miller]

Jules Bean <[EMAIL PROTECTED]> wrote:
> Whilst I have no objections to such a change in rules, I am baffled that
> anyone could prefer xpaint to gimp, even for drawing straight lines and
> ellipses.

gimp won't run on smaller machines.

Also, there's Rick Hohensee's caligraphic patch for (if I recall
correctly) xpaint.  [Or is there a calligraphic module for the gimp?]

-- 
Raul

Re: I'm a concerned about slink. specifically jdk1.1, idraw, and xaw-wrappers

[Dale E. Martin]

"Guenter Geiger" <[EMAIL PROTECTED]> writes:

> ... and it is solved now :)
> 
> Actually I have to say, if I would have been the one who was supposed to fix 
> the
> bug, it would have taken me another hundred days, and probably I would have 
> lost
> my last hair upon this ...
> 
> But luckily, the upstream maintainer found the problem, which was related to 
> the
> egcs c++ compiler.
> 
> On another point, there is no other distribution which is featuring idraw,
> drawtool,
> flipbook and the InterViews library together with all the vector drawing
> libraries and Unidraw within ivtools.
> Just dropping that package because it was (temporarily) not possible to
> draw arrows seemed not appropriate to me ..

Thanks for chasing this bug down.  I realize that idraw is ancient and
probably old news, but I _do_ use it frequently as I like that it
generates/reads(its own subset of) postscript.  Arrows seem to be in most
anything that I want to draw, so that was limiting its usefulness to me
significantly. :-)

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

Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

[Jakob 'sparky' Kaivo]

This is getting WAY out of hand here. How about this:

The mail spool MUST be accessible through /var/mail AND /var/spool/mail,
and spool files MUST take the form /var/{spool/}mail/$LOGNAME. Either
/var/mail or /var/spool/mail, or both, MAY be symbolic links to another
directory. It is RECOMMENDED that /var/mail be the actual directory and
/var/spool/mail be the symbolic link. At some point use of /var/spool/mail
may become deprecated.

+-++
| Jakob 'sparky' Kaivo|  [EMAIL PROTECTED] |
| NoDomainName Networks   |http://www.nodomainname.net |
| AtDot E-mail Services   |   http://www.atdot.org |
+-++

Re: the Great X Reorganization, package splits, and renaming

[Branden Robinson]

On Tue, Jan 26, 1999 at 12:42:18PM +0100, Santiago Vila wrote:
> Can you *guarantee* that the package now called xfonts-base will *always*
> have the same functionality and will always be *identical* to the one
> called xfntbase in hamm?
> 
> Can you *guarantee* that the package now called xlib6g-static will
> *always* have the same functionality and will always be *identical* to the
> one called xslibg in hamm?
> 
> I don't think you can, unless you have a crystal ball.

I don't have to.  If and when a package has non-practically-identical
contents (I fear not qualifying it, for I'm sure you'd file a critical
bug against xfntbase for not having the same changelog.Debian as
xfonts-base) from its predecessor, if dpkg/apt have not implemented
brains sufficient to account for package renaming, I will implement your
ham-fisted solution, *for the affected package(s) only*.  I did this very
thing for xbase.

> But then it could be too late. Sorry but this is vaporware.

If changes in the font and static library packages haven't happened by the
time potato is released, it still doesn't matter, for the same reasons it
doesn't matter now.

> It is not wise at all to rely on features that have not been implemented
> yet. As Joseph Carter says: "Show me the code or get out of my way".

I'm not relying upon them.  Hamm and older systems upgrading to slink break
in no particular fashion because of the existence of the new packages.

> BTW: I see a contradiction here... If you and Branden are so sure that
> package ranaming will be implemented in dpkg for potato, why does not
> Branden just postpone all the package renamings to potato to do it the
> right way?

Because it's too late.  They've already been renamed.  If I had
appreciated the difficulties this would have caused me four months
ago when I first drafted my proposal, I would have renamed only two
packages -- xbase and xfntbig.  I would have let the rest wait for more
support infrastructure from our packaging system.  I was much less
aware of dpkg's limitations at the time.  The X Strike Force webpage
has been up for almost a year, and has contained detailed plans of the
X reorganization as long as I've had them.  Only now do you seem to be
concerned.

> Frankly, I'm very suprised how low do you value the userfriendliness of
> the system, the smoothness of the upgrades and the overall quality of
> Debian. I can't accept "I create a problem today and will fix it
> tomorrow" or worse "problem? what's the problem?".

Yes, I'm certain if one tallies up all the outstanding bug reports I've
managed to fix in X, some of the new functionality I've managed to develop,
and Marcus Brinkmann's XF86Config diagnostic tool, one could easily reach
the conclusion that I don't give a damn about the user friendliness, smooth
upgrades, or overall quality of Debian.

> Upgrading a system from hamm to slink should make the system to be in the
> same state as if slink had been installed from scratch.
> 
> Otherwise, Debian will become just a W95 clone very soon (have you ever
> asked yourself why people reinstall W95 so often?).

This is a straw-man argument.  Isolate one criterion -- if we don't meet
that by YOUR standard, we're no better than Windows 95.

Are you a university student?  I suggest a course in critical thinking.

I reiterate my challenge.  Demonstrate to me a manner in which a
hamm system upgraded to slink, which keeps the old X font and static
library packages, will be broken.  What programs will break?  What
statically-linked X clients will they be unable to build, or in what
manner will these clients differ from their counterparts build with
xlib6(g)-static?  What fonts from the xfnt* packages will they be
missing out on if they don't install the corresponding xfonts*- package?

I've levelled this challenge before, and you've only been able to reply
with more flamage and illogic.  I told you, demonstrate a significant practical,
functional drawback to leaving the old packages in place and I will
implement the bizarre pseudo-packages.

These are the practical, important considerations.  I, too, would like
people's systems to be rid of the old packages.  But I'm not going to
pervert the packaging system to do it without some more cause to do so.

-- 
G. Branden Robinson  |Convictions are more dangerous enemies
Debian GNU/Linux |of truth than lies.
[EMAIL PROTECTED]   |-- Friedrich Nietzsche
cartoon.ecn.purdue.edu/~branden/ |


pgpZYWSzabHyb.pgp
Description: PGP signature

Re: Debian booth at linuxworld, volenteers wanted

[Dale E. Martin]

Joey Hess <[EMAIL PROTECTED]> writes:

> Oh, it's in San Jose California, March 1-4th.

Thanks.  Then I can't volunteer, although I frequently seem to find myself
in San Jose :-)

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

Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

[Manoj Srivastava]

Hi,
>>"Ted" == Theodore Y Ts'o <[EMAIL PROTECTED]> writes:

 Ted> I keep hearing people claim that distribution folks are saying "ick",
 Ted> but I haven't heard any technical reasons besides, "Moving spool
 Ted> directories is hard".

Fine. Here are a few.

I, and a number of other sysadmins, have a partition for /var,
 and mount /var/spool on it. The understanding has always been that
 */spool/ directories contain data that may grow unpredictably.  If I
 use log rotation, and purge old logs regularly, /var remains a more
 or less static in size, apart from the spool directories.  One has
 little control over the size of the spool directories. So, one puts
 the spool directory on another partition. 

This has been standard practice in OS's derived from BSD, I
 think (I know we used to do it on Ultrix, in the good old days).

Another factor is wehen the spool directories are used for
 USENET or mail, there are a large number of small files with a high
 turnover; one some file systems one may tweak parameters to make the
 file system better suited for spools. (This is certainly less true
 for mail than for news, but still)

I have generally put large partitions for spool, and prefer
 not to have an overfull spool partition bring down the system.

 Ted> When I and others have pointed out that moving the spool
 Ted> directory isn't required; just a symlink, I have heard dead
 Ted> silence.  So the lack of technical discussion, but just a
 Ted> stony-silence "No!" is rather disappointing as far as I'm
 Ted> concerned.

I have no objections to a compatibility link in /var/mail, or
 to modifying code to look in both places.

 Ted> I think we should require that new applications use /var/mail,
 Ted> and that backwards compatibility symlinks should exist.


While the new FHS is trying for conformance with other unices,
 we should also consider rtadition (traditionally, /var/spool/mail has
 been the location for Linux boxes)

Why can't we get compatibility with the so called other unices
 just by putting in a sym link in /var/mail, and leaving the spool
 directory where it is?

 Ted> If we must back out /var/mail (for no good technical reason that I can
 Ted> determine), then at the very least I think we should state that there
 Ted> that for all compliant distributions, /var/mail *MUST* be a valid way of
 Ted> reaching the spool directory (i.e., there should be a symlink there, or
 Ted> where the spool directory actually lives) and that it be permissible for
 Ted> applications to use /var/mail to find the mail directory (but that
 Ted> applications that want to keep using /var/spool/mail would not be
 Ted> considered obsolete).

I think this is a reasonable compromise.

 Ted> At least that way applications that want to use the same dirctory as the
 Ted> vast majority of other Unix systems will work without needing a special
 Ted> case for Linux.  However, I would much rather see us adopt the full,
 Ted> correct solution, rather than this half-measure.

This is the first rationale I have seen for actually going to
 /var/mail, other than ``those other unices do it'', and I think a
 symlink shall address all those concerns quite well. I suppose there
 sould also be an argument that the mail spool is not really a spool,
 but a message queue still qualifies for being on the spool partition.
 (trying to move my mail spool directory to /var/mail may well fail on
 some of my machines due to file system getting overfull)

I have not being following the FHS list, so these opinions may
 well be un informed.

manoj
-- 
 +#if defined(__alpha__) && defined(CONFIG_PCI) /* The meaning of
 life, the universe, and everything. Plus this makes the year come out
 right. */ year -= 42; +#endif (From the patch for 1.3.2:
 (kernel/time.c), submitted by Marcus Meissner)
Manoj Srivastava <[EMAIL PROTECTED]>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

Re: Debian logo contest, step 2

[M.C. Vernon]

On Tue, 26 Jan 1999, Wichert Akkerman wrote:

> 
> I just got word back from Sven Riedel, the guy in charge of organizing
> gimp contests. He was happy with our request, and was willing to organize
> the whole thing. The contest will start in februari, after the current
> contest (dreams) ends. Details and submissions will be at the usual
> site: http://contest.gimp.org/ .

What exactly has been asked for?

Matthew

-- 
Elen sila lumenn' omentielvo

[EMAIL PROTECTED],
Steward of the Cambridge Tolkien Society
Selwyn College Computer Support
http://www.cam.ac.uk/CambUniv/Societies/tolkien/
http://pick.sel.cam.ac.uk/

Need a check for suid applications

[Santiago Vila]

reassign 28850 general
thanks

This bug is now fixed in gettext_0.10.35-7.

However, somebody should check that every suid application in slink which
is statically linked against gettext is recompiled with the new gettext.
(Maybe doing "gettextize -f -c").

Thanks.

-- 
 "6525d3e1b6548dd210c536bf09bde00b" (a truly random sig)

Re: New logo strategy

[Jules Bean]

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

Whilst I have no objections to such a change in rules, I am baffled that
anyone could prefer xpaint to gimp, even for drawing straight lines and
ellipses.

Try fiddling with the selection tools, and the 'path' or 'pen' tool.

(And use layers lots..)

Jules

/+---+-\
|  Jelibean aka  | [EMAIL PROTECTED] |  6 Evelyn Rd|
|  Jules aka | [EMAIL PROTECTED]  |  Richmond, Surrey   |
|  Julian Bean   | [EMAIL PROTECTED]|  TW9 2TF *UK*   |
++---+-+
|  War doesn't demonstrate who's right... just who's left. |
|  When privacy is outlawed... only the outlaws have privacy.  |
\--/

Re: libtool & rpath

[Martin Mitchell]

Santiago Vila <[EMAIL PROTECTED]> writes:

> On Wed, 27 Jan 1999, Hamish Moffatt wrote:
> 
> > an easy fix for that? Splitting the packages is a possibility, but
> > libgeda is of absolutely no use on its own yet, and I don't think there
> > is anything for a libgeda-dev.
> 
> I have found this in the policy:
> 
> 4.3 Shared libraries
> 
>Packages involving shared libraries should be split up into several
>binary packages.
> 
> This suggests that the split is mandated by policy.

Actually, I think this section of policy should be reviewed. There are
some limited situations (and this is one) where there is no point to have
a separate shared library package, but it does make sense to compile a
program with shared libraries.

Martin.

FreeHow to check for free space in perl?

[Eduardo Marcel Macan]

I am trying to  write a perl script that needs to make some
calculation based on free space in several partitions. What's the best
method for checking the free space in a file system using perl? Without
using backticks and unix commands, is there any better mean to do it?

--
Eduardo Marcel MacanCore Technologies Informatica LTDA
[EMAIL PROTECTED]   Suporte e Desenvolvimento Unix/Linux. 
[EMAIL PROTECTED]   Debian GNU/Linux Developer
Visite-nos em http://thecore.com.br

Debian logo contest, step 2

[Wichert Akkerman]

I just got word back from Sven Riedel, the guy in charge of organizing
gimp contests. He was happy with our request, and was willing to organize
the whole thing. The contest will start in februari, after the current
contest (dreams) ends. Details and submissions will be at the usual
site: http://contest.gimp.org/ .

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/


pgp8afAJShCZn.pgp
Description: PGP signature

Intend to package simulpic

[Samuel Tardieu]

Source: simulpic
Section: otherosfs
Priority: optional
Maintainer: Samuel Tardieu <[EMAIL PROTECTED]>
Standards-Version: 2.4.0.0

Package: simulpic
Architecture: any
Depends: ${shlibs:Depends}
Description: Microchip PIC device simulator
 This software allows to simulate the execution of any program on a Microchip
 family microcontroller device.

-- 
Samuel Tardieu -- [EMAIL PROTECTED]

Re: New logo strategy

[Daniel Martin]

Jules Bean <[EMAIL PROTECTED]> writes:

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

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

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

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

[HERT] ANNOUNCE: linux auditd daemon 1.10

[Anthony C . Zboralski]

Greetings,

We have just released auditd version 1.10 for linux.

Auditd  is  part  of the linux kernel auditing toolkit. It
will capture auditing trails created by the kernel  audit­
ing  facility from /proc/audit, filter them, and save them
in specific log files.  For the moment, auditd  only  sup­
ports the -t option, which enables audit trails timestamp­
ing. Other command line options will  probably  be  imple­
mented in the next releases to add more flexibility to the
package.

Comments, suggestions, and critics are welcome.

http://www.hert.org/projects/linux/auditd/auditd.tar.gz
ftp://ftp.hert.org/pub/linux/auditd/auditd.tar.gz

PGP signatures:
http://www.hert.org/projects/linux/auditd/auditd.tar.gz.asc
ftp://ftp.hert.org/pub/linux/auditd/auditd.tar.gz.asc

PGP key:
http://www.hert.org/HERT_PGP.key
ftp://ftp.hert.org/pub/HERT_PGP.key

MD5sum:
ae160eb8d50ff3e87a11d27434af48d0  auditd-1.10.tar.gz

here is the README file:

LINUX AUDIT Daemon: 
MANDATORY AUDITING FOR LINUX 

by Marcus Wolf <[EMAIL PROTECTED]>, Promisc Security
Copyright (C) 1999 Hacker Emergency Response Team
http://www.hert.org/linux/auditd

Audit Daemon is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.

Audit Daemon is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with GNU CC; see the file COPYING.  If not, write to
the Free Software Foundation, 59 Temple Place - Suite 330,
Boston, MA 02111-1307, USA.  


INSTALLATION

# vi Makefile
# vi audit.h
# make
# make install
# ./kpatch
# cd /usr/src/linux
# make zlilo
# echo "/usr/sbin/auditd" >> /etc/init/rc.daemons
# reboot


INFORMATION

o /proc/audit

This is where the kernel audit facility sends its raw
  trails information. It is in ascii format, but you may have
  problems converting network byte order addresses to n&d ips
  manually. :) 

o /sbin/auditd [-t]

The audit daemon captures audit trails from /proc/audit,
  filters them following its filtering rules, formats them, and
  outputs them to a log file. The "-t" option will force auditd
  to apply timestamps to the audit trails.

o /etc/security/audit.conf

The audit configuration file keeps the auditd filtering
  rules. It enable the administrator to filter trails by flag, 
  uid, and pid. 

- Multiple flags can be specified on a single line;
- Only one pid can be specified by line;
- Only one uid can be specified by line;
- Both flags, uids and pids can be replaced by a
  '*' mask;


NOTES/BUGS/TODO

- The next release will probably include audit trails
  routing to other hosts (similar to syslogd), and
  piping to commands;
- If you find any bug, please contact me at:

Markus Wolf <[EMAIL PROTECTED]>



pgpJV7uJ5lzoF.pgp
Description: PGP signature

Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

[Ben Collins]

On Tue, Jan 26, 1999 at 01:27:13PM +, Alan Cox wrote:
> > I'll give you one solid reason, uniformity across unix platforms is a
> > must have if unix, especially free unices, are going to succesfully
> 
> If we are in marketing mode let me point out we are not Unix in the first
> place and that C:\> is the standard 

s/Unix/Unix-Like/ for clarification.

> > I don't see a connection between /var/spool/mail or /var/mail and
> > home directories or priviliedges. IOW, how does one lend itself better
> > to the task at hand?
> 
> Modern mail systems dont use a mail spool in general. Or when they do they
> use a format different to "tradition"

Obviously every admin and 'modern' mail system is going to want to do
things their way. Our goal is hopefully to put standard on where it
_should_ be and where the default system should have it. What the admin or
third party mail systems do after that is completely beyond the scope of
the distributions. If our contention is that we cannot forsee what will
become of future mailing systems then maybe we should be arguing whether
or not we should have a "standard" or should we have a scope of acceptible
implementations.

> > well as far as the system is concerned. What we need to decide is, do
> > we want to go with the standard, or make a new standard simply because
> > we don't want to change?
> 
> Is the purpose of the FHS to make Linux run after and blindly copy things
> from Unix platforms or to provide a best Linux platform ?

The same could be argued for both sides of this double-edged sword. Not
everyone is going to be pleased with the outcome, right now I'd say the
opinions are split even. We can either stick with what we have to suit our
definiton of a mail spool, or to please the cross-platform admins, go with
the old tradition to have a uniform setup. Where is the compromise here
that we need?

-- 
--- -  -   ---  -  - - ---   
Ben Collins <[EMAIL PROTECTED]>  Debian GNU/Linux
UnixGroup Admin - Jordan Systems Inc. [EMAIL PROTECTED]
-- -- - - - ---   --- -- The Choice of the GNU Generation

Re: libtool & rpath

[Santiago Vila]

On Wed, 27 Jan 1999, Hamish Moffatt wrote:

> A package I maintain uses libtool. To remove the rpath stuff, I 
> apply this patch to configure.in. Now lintian tells me that the executables
> have rpath set too! Is there an easy way to fix that?
> 
> Also, because this package (geda) includes a library, debhelper
> is generating an shlibs file for it. But then the package ends up
> depending on itself, because of the shlib:Depends expansion. Is there
> an easy fix for that? Splitting the packages is a possibility, but
> libgeda is of absolutely no use on its own yet, and I don't think there
> is anything for a libgeda-dev.

I have found this in the policy:

4.3 Shared libraries

   Packages involving shared libraries should be split up into several
   binary packages.


This suggests that the split is mandated by policy.

-- 
 "76d7bdb03d71ca6f1ed20d2f430c2567" (a truly random sig)

Re: New logo strategy

[Wichert Akkerman]

Previously Steve Greenland wrote:
> 1. We have to agree on *two* logos :-).

No, we have to agree on a *set* of logos: we simply request that each
submission consists of two logos.

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/


pgpRfS7epuT9U.pgp
Description: PGP signature

libtool & rpath

[Hamish Moffatt]

A package I maintain uses libtool. To remove the rpath stuff, I 
apply this patch to configure.in. Now lintian tells me that the executables
have rpath set too! Is there an easy way to fix that?

Also, because this package (geda) includes a library, debhelper
is generating an shlibs file for it. But then the package ends up
depending on itself, because of the shlib:Depends expansion. Is there
an easy fix for that? Splitting the packages is a possibility, but
libgeda is of absolutely no use on its own yet, and I don't think there
is anything for a libgeda-dev.


thanks,
Hamish

--- geda-19981117.orig/configure.in
+++ geda-19981117/configure.in
@@ -35,6 +35,19 @@
 dnl Initialize libtool
 AM_PROG_LIBTOOL

+# Turn around -rpath and -lc problems with libtool 1.0c
+# This define should be improbable enough to not conflict with anything
+case ${host} in
+  *-pc-linux-gnu)
+AC_MSG_RESULT([Fixing libtool for -rpath problems.])
+sed < libtool > libtool-2 \
+  -e 's/^hardcode_libdir_flag_spec.*$/hardcode_libdir_flag_spec=" 
-D__LIBTOOL_IS_A_FOOL__ "/' \
+  -e '/^archive_cmds="/s/"$/ \\$deplibs"/'
+mv libtool-2 libtool
+chmod 755 libtool
+  ;;
+esac
+
 dnl Initialize maintainer mode
 AM_MAINTAINER_MODE


-- 
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: new snapshot

[Rafael Laboissiere]

[I am cross-posting this to debian-devel and to the plplot mailing lists.]

Hi Geoffrey,

Thanks for the announcement of this much awaited new snapshot of PLplot.
Being the maintainer of both plplot and octave-plplot packages for Debian
GNU/Linux, I would like to add some comments to your message:

> "GF" == Geoffrey Furnish <[EMAIL PROTECTED]> writes:

GF> I have put up a new snapshot on dino.ph.utexas.edu.  You can get it
GF> via anonymous ftp to dino.ph.utexas.edu.  The new snapshot is 
GF> plplot/snapshots/plplot-990122.tar.gz

GF> [...]

GF> I just want to assure people that PLplot is not dead [...] In
GF> short, PLplot is in a very real sense of the word, a healthy,
GF> thriving tool, that is helping many researchers around the world,
GF> do their job.  [...]

My intention in making the Debian packages for Debian was exactly to
increase the visibility of the PLplot project.  I am particularly
interested in seeing PLplot replacing GNUplot for Octave.  At any rate, it
is a very nice package for general scientific plotting.

Unfortunately, it is not possible to include your new snapshot in the
upcoming Debian release (2.1), because we are now at the deep freeze stage.
Anyway, I think that will not have enough free time in the near future
(say, until March) to generate the packages.  If any Debian developer is
interested in this work, she/he should feel free to do a non-maintainer
release of the packages.  Any modifications in the autoconf files needed
for Debian will be contributed back to the PLplot project.

Cheers, and keep up the good work,

--
Rafael Laboissiere -- Debian Developer
Institut de la Communication Parlee | Email: [EMAIL PROTECTED]
UPRESS A CNRS 5009 / INPG   | Voice: +33 4.76.57.48.49
46, av. Felix Viallet   |   Fax: +33 4.76.57.47.10
F-38031 Grenoble CEDEX 1 France |   URL: http://www.icp.inpg.fr/~rafael

Re: linux 2.2.0: "System is 666kB"

[Peter Eades]

Thanks for the binary but...
when trying to boot with it the kernel uncompreses, gives the message
booting kernel and then stops. My machine is a cyrex 686 200. Does the
binary only work for intell chips? I noticed that specific suport for
non intell chips is a feature of 2.2.0. I guess this means I have to
compile my own for now then. Maybe a plain old fashioned i386 binary

Thanks for the effort anyway
Pete


Johnie Ingram wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> 
> Hm, now theres a worrisome compile message.  :-)
> 
> Anyway, for you early adopters, I've made source and debs available at:
> 
> ftp.netgod.net/linux/v2.2
> 
> Heres the checksums:
> 
> ca629746d5baa1f3024a780312c96e28  kernel-doc-2.2.0_2.2.0-1_all.deb
> 40d6ddb94ac0c0239a2a5b16818cbbdb  kernel-headers-2.2.0_2.2.0-1_i386.deb
> 9079f07787cdeba5649b8daa651746ea  kernel-image-2.2.0-i686_2.2.0-1_i386.deb
> 2be1baad527126c18d73f93f709758e1  kernel-source-2.2.0_2.2.0-1.diff.gz
> 35fa180e872cd6180ae0cab22730938f  kernel-source-2.2.0_2.2.0-1.dsc
> 98354d9bbe92ded9bdf3255b41319e19  kernel-source-2.2.0_2.2.0-1_all.deb
> be94a0187a3ac4ad41442f967ddb11c3  kernel-source-2.2.0_2.2.0.orig.tar.gz
> 
> - -  PGP  E4 70 6E 59 80 6A F5 78  63 32 BC FB 7A 08 53 4C
> 
>__ _Debian GNU Johnie Ingram <[EMAIL PROTECTED]>  mm   mm
>   / /(_)_ __  _   ___  __"netgod" irc.debian.org  mm mm
>  / / | | '_ \| | | \ \/ / m m m
> / /__| | | | | |_| |>  <  Yes, I'm Linus, and I am your God. mm   mm
> \/_|_| |_|\__,_/_/\_\   -- Linus, keynote address, Expo 98   GO BLUE
> 
> -BEGIN PGP SIGNATURE-
> Version: 2.6.3a
> Charset: latin1
> 
> iQCVAwUBNq1GthCswmGWXGp9AQGvqwP9G+9Fly7F61WBtBohQ8Rm3dhICZaMxikJ
> 7XL4wBrFvgXaW2HHAVSMgoK3QJMKbHYCsOvYHGqQF+OvC7XySgNxmSCG6/3kwnUd
> 7OVnWma6giQEhJ2lYVeQZXx/y9aNQkm/I48jDJwvGPRJ95smTUvjmkRsY/Yl9Zq7
> 7UKSeLnYQaU=
> =LEbq
> -END PGP SIGNATURE-
> 
> --
> Unsubscribe?  mail -s unsubscribe [EMAIL PROTECTED] < /dev/null

Re: the Great X Reorganization, package splits, and renaming

[Hamish Moffatt]

On Tue, Jan 26, 1999 at 12:42:18PM +0100, Santiago Vila wrote:
> Upgrading a system from hamm to slink should make the system to be in the
> same state as if slink had been installed from scratch.

Indeed. All of my systems have remnants of base and timezone remaining.
(Actually I just discovered that one of my systems has deinstalled
timezone and no timezones at all).

> Otherwise, Debian will become just a W95 clone very soon (have you ever
> asked yourself why people reinstall W95 so often?).

Yes, I just reinstalled mine last week, because it can't handle any
decent sized hardware upgrade without reinstallation. Today I nearly
reinstalled NT, just because it's so damn slow after much use.


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: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

[Hamish Moffatt]

On Tue, Jan 26, 1999 at 07:19:20AM -0500, Ben Collins wrote:
> 
> I'll give you one solid reason, uniformity across unix platforms is a
> must have if unix, especially free unices, are going to succesfully
> dominate the market. Sun/AIX/HP-UX/OSF/SCO are not going to change,
> but we could prove our willingess and ability to ensure these uniformities.
> 

Mail spool location is really the least of the problems in inter-UNIX
compatibility. Why do you think autoconf-generated configure scripts
check so many things?

Application vendors probably shouldn't hardcode ANY location. On one
system I use at the university where I study, email is kept in
~/.inbox. Vendors need to make things configurable anyway to support
configurations like that.


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: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

[Alan Cox]

> I'll give you one solid reason, uniformity across unix platforms is a
> must have if unix, especially free unices, are going to succesfully

If we are in marketing mode let me point out we are not Unix in the first
place and that C:\> is the standard 

> I don't see a connection between /var/spool/mail or /var/mail and
> home directories or priviliedges. IOW, how does one lend itself better
> to the task at hand?

Modern mail systems dont use a mail spool in general. Or when they do they
use a format different to "tradition"

> well as far as the system is concerned. What we need to decide is, do
> we want to go with the standard, or make a new standard simply because
> we don't want to change?

Is the purpose of the FHS to make Linux run after and blindly copy things
from Unix platforms or to provide a best Linux platform ?

Alan

Re: New logo strategy

[Jules Bean]

On Mon, 25 Jan 1999, Steve Greenland wrote:

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

Nah.

A 'submission' to the contest is a pair of logos.  Linked to each
stylistically, one of them says 'official' or something.

Jules


/+---+-\
|  Jelibean aka  | [EMAIL PROTECTED] |  6 Evelyn Rd|
|  Jules aka | [EMAIL PROTECTED]  |  Richmond, Surrey   |
|  Julian Bean   | [EMAIL PROTECTED]|  TW9 2TF *UK*   |
++---+-+
|  War doesn't demonstrate who's right... just who's left. |
|  When privacy is outlawed... only the outlaws have privacy.  |
\--/

Re: LSH (GPL'd SSH)

[Ben Collins]

On Tue, Jan 26, 1999 at 12:50:52PM +0100, J.H.M. Dassen wrote:
> On Mon, Jan 25, 1999 at 16:49:57 -0500, Ben Collins wrote:
> > NOTE: For those that are on the ball, they do seem to be considering
> > removing idea from the base source and having it as a seperate module
> > (similar to GnuPG's approach).
>
> Another freeness issue (albeit a relatively minor one) is that currently lsh
> requires scsh (which is non-free) for the generation of include files (they
> are pregenerated in the tarball; the scsh scripts are needed only for
> development). It would be nice if someone could modify them to work with a
> free Scheme implementation (say Guile), or reimplement them in another free
> scripting language (perl, python etc.).

Good point, I saw that, but forgot about it. The TODO/TASKLIST mentions
and idea about using Guile, so that would seem the best way to go.

--
--- -  -   ---  -  - - ---   
Ben Collins <[EMAIL PROTECTED]>  Debian GNU/Linux
UnixGroup Admin - Jordan Systems Inc. [EMAIL PROTECTED]
-- -- - - - ---   --- -- The Choice of the GNU Generation

Re: New logo strategy

[Randy Edwards]

> I agree with James Treacy's observation that we will probably need two
> logos: one logo with a liberal license that people can just freely, and
> another, more restricted logo for things like official CD's and so.

   This seems like a logical solution.  Having the official "Debian" logo
could perhaps be more generic, thus used to deal with the issue of what
happens if Debian eventually becomes largely a hurd distribution or takes some
other unknown directional turn in the future.

   One question I had was out of the two options you list above, which
category do you see our present logo falling into: the liberal license or the
official logo?  Or would this new logo contest be used to choose logos for
both categories?

-- 
 Regards,| Why would anyone want to run an operating
 .   | system that is open source and is developed
 Randy   | by hundreds of hackers worldwide? Find out
 ([EMAIL PROTECTED]) | why at http://www.golgotha.net/why-linux/

Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

[Ben Collins]

On Mon, Jan 25, 1999 at 10:33:27PM -0800, Joseph Carter wrote:
> On Mon, Jan 25, 1999 at 07:09:34PM -0500, Kragen Sitaker wrote:
> > > If we must back out /var/mail (for no good technical reason that I can
> > > determine), then at the very least I think we should state that there
> > > that for all compliant distributions, /var/mail *MUST* be a valid way of
> > > reaching the spool directory (i.e., there should be a symlink there, or
> > > where the spool directory actually lives)
> >
> > If you include this change, will using ~/Mailbox violate the FHS?  Does
> > it already?  Should it?  Should we require symlinks from
> > /var/mail/$USER to ~$USER/Mailbox?
>
> I still want to know what /var/mail gains us over /var/spool/mail.  I've
> asked many times of many people and all I have gotten back is that it's
> an issue of style or that mail isn't a spool (which I disagreed with)..
> I am curious for the answer to this, so far I have heard "/var/mail is
> good and we all know it's good but the dists don't agree."  So I ask in
> front of all of everybody in the hopes that maybe the answer will make
> sense, what technical reason is there for change now?


I'll give you one solid reason, uniformity across unix platforms is a
must have if unix, especially free unices, are going to succesfully
dominate the market. Sun/AIX/HP-UX/OSF/SCO are not going to change,
but we could prove our willingess and ability to ensure these uniformities.


> If you want my opinion as I am SURE everybody does, /var/anything/mail is
> probably a bad plan from a least privileges standpoint.  Qmail users are
> not the only people out there with ~/Mailbox setups and there are good
> reasons why, starting with security.  The only argument against this I
> have ever seen is that not all mail users have home directories.  While
> my machine is single-user and this isn't a problem for me, I have seen a
> few solutions to it.

I don't see a connection between /var/spool/mail or /var/mail and
home directories or priviliedges. IOW, how does one lend itself better
to the task at hand?

Since there is no real concrete reason to use /var/mail over
/var/spool/mail except for meeting a standard filesystem concept
(which is, uh, what we are trying to do) then maybe people need to look
at it from that stand point instead "what's better about it". We could
put mail in /usr/var/mymail/whereIwantit/ and it would work just as
well as far as the system is concerned. What we need to decide is, do
we want to go with the standard, or make a new standard simply because
we don't want to change?

--
--- -  -   ---  -  - - ---   
Ben Collins <[EMAIL PROTECTED]>  Debian GNU/Linux
UnixGroup Admin - Jordan Systems Inc. [EMAIL PROTECTED]
-- -- - - - ---   --- -- The Choice of the GNU Generation

Re: xxgdb should get pulled

[J.H.M. Dassen]

On Fri, Jan 22, 1999 at 16:34:58 -0500, Daniel Martin wrote:
[my rant deleted]

> I have yet to learn how to navigate this area, and am often surprised
> at how strongly an offhand comment is taken.

Smilies might have helped. In this case, your comment really triggered me. I
seldomly flame, but in this case, I felt it was justified.

> I'm looking closely at Code Medic now.  (Though I'm surprised it isn't
> already on the wnpp list)

The problem with Code Medic is that it is fit for "contrib" at best; I don't
recall its license, but it depends on a GUI library that's non-free ("not
for commercial use" IIRC).

Ray
-- 
Tevens ben ik van mening dat Nederland overdekt dient te worden.

Re: LSH (GPL'd SSH)

[J.H.M. Dassen]

On Mon, Jan 25, 1999 at 16:49:57 -0500, Ben Collins wrote:
> NOTE: For those that are on the ball, they do seem to be considering
> removing idea from the base source and having it as a seperate module
> (similar to GnuPG's approach).

Another freeness issue (albeit a relatively minor one) is that currently lsh
requires scsh (which is non-free) for the generation of include files (they
are pregenerated in the tarball; the scsh scripts are needed only for
development). It would be nice if someone could modify them to work with a
free Scheme implementation (say Guile), or reimplement them in another free
scripting language (perl, python etc.).

Ray
-- 
Tevens ben ik van mening dat Nederland overdekt dient te worden.

Re: the Great X Reorganization, package splits, and renaming

[Santiago Vila]

On Tue, 26 Jan 1999, Avery Pennarun wrote:

> On Mon, Jan 25, 1999 at 02:18:56PM +0100, Santiago Vila wrote:
> 
> > On Mon, 25 Jan 1999, Branden Robinson wrote:
> > 
> > > You have yet to explain what will BREAK if people continue to use the old
> > > font packages.  Not in the future, RIGHT NOW.
> > 
> > Oh, you have yet to explain why a clock bomb is *not* a bad thing.
> > "Surely, it will exploit, but not now" ;-)
> 
> But it won't.  I agree with Branden on this point.  What's the problem,
> other than that you think someday it will explode?  I think it won't.  Who
> wins?

Maybe I didn't explain well:

Can you *guarantee* that the package now called xfonts-base will *always*
have the same functionality and will always be *identical* to the one
called xfntbase in hamm?

Can you *guarantee* that the package now called xlib6g-static will
*always* have the same functionality and will always be *identical* to the
one called xslibg in hamm?

I don't think you can, unless you have a crystal ball.

> My guess is that by the time potato is released, some kind soul will have
> implemented package renaming in dpkg.

But then it could be too late. Sorry but this is vaporware.

It is not wise at all to rely on features that have not been implemented
yet. As Joseph Carter says: "Show me the code or get out of my way".

BTW: I see a contradiction here... If you and Branden are so sure that
package ranaming will be implemented in dpkg for potato, why does not
Branden just postpone all the package renamings to potato to do it the
right way?


Frankly, I'm very suprised how low do you value the userfriendliness of
the system, the smoothness of the upgrades and the overall quality of
Debian. I can't accept "I create a problem today and will fix it
tomorrow" or worse "problem? what's the problem?".

Upgrading a system from hamm to slink should make the system to be in the
same state as if slink had been installed from scratch.

Otherwise, Debian will become just a W95 clone very soon (have you ever
asked yourself why people reinstall W95 so often?).

-- 
 "771ffa7eca98abefb0b0a12f36d4dc17" (a truly random sig)

Re: getting kernel 2.2 into slink

[Randy Edwards]

[EMAIL PROTECTED] wrote:
> I think it would be great for Debian to get 2.2 in to slink, even if it is
> priority extra.

   I agree it should be included.  We can change the priority so it's not
automatically installed and warn people that it is experimental/might break
things in dselect's description.

-- 
 Regards,| Debian GNU/ __  o  http://www.debian.org
 .   |/ / _  _  _  _  _ __  __
 Randy   |   / /__  / / / \// //_// \ \/ /
 ([EMAIL PROTECTED]) |  // /_/ /_/\/ /___/  /_/\_\
 http://www.golgotha.net | because lockups should only be for convicts.

Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

[Alan Cox]

> But I don't think the FHS should be specifying the actual location of
> the files at all.  True, the FHS should not cause too much pain for the

Ok good we agree on this 

> The only thing that really matters is what pathnames applications can
> count upon to work.  Given that the rest of the world is moving to

Right now every package you build for linux assumes /var/spool/mail. I dont
actually care what the rest of the world is doing. From a rather brutal 
point of view _we_ are becoming the rest of the world.

> /var/mail, I think it would be good for us to start a gradual migration
> to /var/mail.  The extra symlink doesn't cost anything, and gradually
> moving applications over to use /var/mail really doesn't cost much
> either.

By the time we migrate to /var/mail and annoy alll the vendors - netscape,
applix, zmail and the like the old style unix mail format will be dying.

It seems to be pain for the sake of it. If all the Linux vendors already
used /var/mail and you said "lets use /var/spool/mail" I'd be equally
opposed.

Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

[t . sippel-dau]

The keyboard of Kragen Sitaker emitted at some point in time:
> 
> On Mon, 25 Jan 1999, Theodore Y. Ts'o wrote:
> > If we must back out /var/mail (for no good technical reason that I can
> > determine), then at the very least I think we should state that there
> > that for all compliant distributions, /var/mail *MUST* be a valid way of
> > reaching the spool directory (i.e., there should be a symlink there, or
> > where the spool directory actually lives)
> 
> If you include this change, will using ~/Mailbox violate the FHS?  Does
> it already?  Should it?  Should we require symlinks from
> /var/mail/$USER to ~$USER/Mailbox?

Hmm, and a mandatory symlink form $LOGNAME/Mailbox to /var/mail/$LOGNAME,
and we will have established FHS compliant systems as those "where email
won't work any more".

N.B. your phrasing was not POSIX compliant, tut, tut, tut. A good example
how technically simple and conceptually irrelevant changes (from USER to
LOGNAME) are still extremely dificult to achieve in practice.

> Switching a single one-user system to ~/Mailbox is easy, btw.
> Switching a single multi-user system to ~/Mailbox is likely to cause a
> certain amount of pain.

Pain of no real benefit to the end user, as long as "it works".

>  Distributing applications to millions of
> people, some of whom use one convention, and some of whom use another,
> is surely asking for trouble.

Yes, it is. arguing about it will make mpore pain.

Thomas

*   Why not use metric units and get it right first time, every time ?
*
*   email: cmaae47 @ imperial.ac.uk

Re: linux 2.2.0: "System is 666kB"

[Remco van de Meent]

Enrique Zanardi wrote:
> (BTW, is kernel-headers still needed? libc6-dev ships with a full set of
> headers, doesn't it?)

Right, but those are for 2.0.36 and the ones that come with 2.1/2.2 are
different (and yes, I need those new ones thus I have to manually edit the
things in /usr/include everytime that libc6-dev gets upgraded).


 -Remco

Re: linux 2.2.0: "System is 666kB"

[Enrique Zanardi]

On Mon, Jan 25, 1999 at 11:39:07PM -0500, Johnie Ingram wrote:
> Hm, now theres a worrisome compile message.  :-)
> 
> Anyway, for you early adopters, I've made source and debs available at:

What about uploading everything but the kernel-image package for Slink,
now that Bryan has said he will accept them?

(BTW, is kernel-headers still needed? libc6-dev ships with a full set of 
headers, doesn't it?)

--
Enrique Zanardi[EMAIL PROTECTED]

Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

[Florian La Roche]

> At least that way applications that want to use the same dirctory as the
> vast majority of other Unix systems will work without needing a special
> case for Linux.  However, I would much rather see us adopt the full,
> correct solution, rather than this half-measure.

How can changing from /var/spool/mail to /var/mail be a "full solution"
for the next years to come?
Many people think that the mail-dir solution that e.g. qmail and mutt
support is the real solution for the future. Maybe future Linux distributions
want to ship that as a default? They couldn't be compliant with this
standard even though they use a more modern mail-storing setup.
The change from /var/spool/mail can be done on any system with an
"ln -s spool/mail /var/mail". Why mix up all Linux users instead of
keeping this a local solution anybody can do?

So maybe any standard should not say something about the mail spool dir?

Florian La Roche

Re: Reality check! [was: Re: Debian goes big business?]

[Enrique Zanardi]

On Tue, Jan 26, 1999 at 09:33:16AM +1100, Craig Sanders wrote:
> hamm was released with a pre-selections wrapper, where you could chose
> certain sets of pre-selected packages. it works, but could use some
> improvement and probably needs to be updated for slink - there's a good
> place for you to expend your energy if you care about this.

I has been updated for slink months ago (thanks to Stephane Bortzmeyer).
Now we are just polishing the lists for the non-i386 architectures. 
 
Thanks,
--
Enrique Zanardi[EMAIL PROTECTED]

Re: dpkg port to HP-UX

[Hamish Moffatt]

On Tue, Jan 26, 1999 at 02:22:13AM -0700, Bdale Garbee wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> 
> > Hmmm. swinstall (HP-UX native I think) seems to support dependencies.
> > It's pretty ugly though and I don't know if there's a command line version.
> 
> Yes, you can drive swinstall from the command line.  It's not pretty, but it
> works.
> 
> Unfortunately, there's no real equivalent to "debhelper" for SD...  and it
> could sorely use the help...  :-)

I'm yet to experience the pleasure of building a package for HP-UX;
fortunately, it's quite likely that I'll manage to avoid it completely. :-)


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

Intend to package gnat-glade

[Samuel Tardieu]

GLADE is the implementation of the Distributed Systems Annex for GNAT,
the GNU Ada95 compiler.

Since there already is a GLADE (a Gtk GUI builder), I will call the
package gnat-glade since this is really a GNAT add-on.

  Sam
-- 
Samuel Tardieu -- [EMAIL PROTECTED]

Re: dpkg port to HP-UX

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

> Hmmm. swinstall (HP-UX native I think) seems to support dependencies.
> It's pretty ugly though and I don't know if there's a command line version.

Yes, you can drive swinstall from the command line.  It's not pretty, but it
works.

Unfortunately, there's no real equivalent to "debhelper" for SD...  and it
could sorely use the help...  :-)

Bdale

Re: Release notes for slink

[A . J . Gray]

On Thu, Jan 14, 1999 at 04:20:51PM +, Robert Woodcock wrote:
> Many of you are painfully aware that there are some issues in slink that are
> impractical to correct before release.
> 

> 
> xbase -> xbase
>twm
>xterm
>xbase-clients
>xdm
>xf86setup
How about adding that the xvidtune program is in the xf86setup package?  Some
users may be confident enough about their X configuration not to bother
installing xf86setup, and then miss xvidtune.

Andrew

Re: Debian logo & its license

[A . J . Gray]

On Sun, Jan 24, 1999 at 07:26:19AM -, Robert Woodcock wrote:
> Avery Pennarun wrote:
> >What if someone gets hold of the Linux kernel and uses it to guide nuclear
> >missiles?  (Well, at least they have to share their changes with us :))
> 
> Only if they distribute the control systems :>
You've forgotten something.  The military act as if they are above any laws.
(If they cared about obeying laws, they would be disarming nuclear weapons
under their international treaty obligations)

Sorry to be political.

Andrew

Re: I'm a concerned about slink. specifically jdk1.1, idraw, and xaw-wrappers

[Guenter Geiger]

Dale E. Martin wrote
> Then I tried to use idraw, which I've used in the past a _bunch_ of times.
> It keeps segmentation faulting on me, and so I went to look at
> bugs.debian.org and the bug report about this is over 100 days old.

... and it is solved now :)

Actually I have to say, if I would have been the one who was supposed to fix the
bug, it would have taken me another hundred days, and probably I would have lost
my last hair upon this ...

But luckily, the upstream maintainer found the problem, which was related to the
egcs c++ compiler.

On another point, there is no other distribution which is featuring idraw,
drawtool,
flipbook and the InterViews library together with all the vector drawing
libraries and Unidraw within ivtools.
Just dropping that package because it was (temporarily) not possible to
draw arrows seemed not appropriate to me ..


Guenter

Re: New logo strategy

[M.C. Vernon]

On Mon, 25 Jan 1999, James A. Treacy wrote:

> I'd like to thank Wichert for taking on this thankless task.
> 
> I'd also like to ask that we set strict criteria for what constitutes a
> logo. I don't feel like going back through the archives, but the criteria
> I remember off the top of my head are:
> 
>   Works in B+W (the official version may, of course, be in color)
> 
>   Works both with and without text at the bottom (Debian GNU/Linux).
>   You can ignore this point if Debian is an integral part of the logo.
> 
>   Not too detailed so it works in low resolution.
> 
> I have the feeling I missed something important. If so, I'm sure someone will
> point out my oversight. :)

It should also not be linux-specific (this is my suggestion) - we do have
debian GNU/Hurd you know :)

Matthew

-- 
Elen sila lumenn' omentielvo

[EMAIL PROTECTED],
Steward of the Cambridge Tolkien Society
Selwyn College Computer Support
http://www.cam.ac.uk/CambUniv/Societies/tolkien/
http://pick.sel.cam.ac.uk/

unsibscribe

[Dmitry Shishkin]

Hello ,



Best regards,
 Dmitry  mailto:[EMAIL PROTECTED]

Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

[Joseph Carter]

On Mon, Jan 25, 1999 at 07:09:34PM -0500, Kragen Sitaker wrote:
> > If we must back out /var/mail (for no good technical reason that I can
> > determine), then at the very least I think we should state that there
> > that for all compliant distributions, /var/mail *MUST* be a valid way of
> > reaching the spool directory (i.e., there should be a symlink there, or
> > where the spool directory actually lives)
> 
> If you include this change, will using ~/Mailbox violate the FHS?  Does
> it already?  Should it?  Should we require symlinks from
> /var/mail/$USER to ~$USER/Mailbox?

I still want to know what /var/mail gains us over /var/spool/mail.  I've
asked many times of many people and all I have gotten back is that it's
an issue of style or that mail isn't a spool (which I disagreed with).. 
I am curious for the answer to this, so far I have heard "/var/mail is
good and we all know it's good but the dists don't agree."  So I ask in
front of all of everybody in the hopes that maybe the answer will make
sense, what technical reason is there for change now?

If you want my opinion as I am SURE everybody does, /var/anything/mail is
probably a bad plan from a least privileges standpoint.  Qmail users are
not the only people out there with ~/Mailbox setups and there are good
reasons why, starting with security.  The only argument against this I
have ever seen is that not all mail users have home directories.  While
my machine is single-user and this isn't a problem for me, I have seen a
few solutions to it.



> Switching a single one-user system to ~/Mailbox is easy, btw.
> Switching a single multi-user system to ~/Mailbox is likely to cause a
> certain amount of pain.  Distributing applications to millions of
> people, some of whom use one convention, and some of whom use another,
> is surely asking for trouble.

And then you have people who use MH or Maildir instead of traditional
mbox.  The only way to REALLY deal with it sanely is to read $MAIL and
see what it says, I suspect.

-- 
"I'm working in the dark here."  "Yeah well rumor has it you do your best
work in the dark."
   -- Earth: Final Conflict

Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

[Theodore Y. Ts'o]

   From: Alan Cox <[EMAIL PROTECTED]>
   Date: Tue, 26 Jan 1999 00:15:37 + (GMT)

   > but I haven't heard any technical reasons besides, "Moving spool
   > directories is hard".  When I and others have pointed out that moving
   > the spool directory isn't required; just a symlink, I have heard dead
   > silence.  So the lack of technical discussion, but just a stony-silence
   > "No!" is rather disappointing as far as I'm concerned.

   One simple one - I want my mail on the spool disk. Its in the grows
   randomly, mostly crap, doesnt cause hassle if it fills for a while
   category

But I don't think the FHS should be specifying the actual location of
the files at all.  True, the FHS should not cause too much pain for the
certain obvious and common partition layouts, but once we enter the
realm of server systems, there's no guarantee where the mountpoints
might end up falling.  For example, I might want the mail files on /u1,
and the printer spool files in /u2 --- in which case there will probably
a number of symlinks in /var and /var/spool.  

The only thing that really matters is what pathnames applications can
count upon to work.  Given that the rest of the world is moving to
/var/mail, I think it would be good for us to start a gradual migration
to /var/mail.  The extra symlink doesn't cost anything, and gradually
moving applications over to use /var/mail really doesn't cost much
either.

- Ted

Re: New logo strategy

[Avery Pennarun]

On Mon, Jan 25, 1999 at 09:11:47PM -0600, Steve Greenland wrote:

> On 25-Jan-99, 19:06 (CST), Wichert Akkerman <[EMAIL PROTECTED]> wrote: 
> > I agree with James Treacy's observation that we will probably need two
> > logos: one logo with a liberal license that people can just freely, and
> > another, more restricted logo for things like official CD's and so.
> > To phrase this in another way: we will have a logo that everyone can
> > slap onto their webpage, t-shirts, posters, etc., and a logo that can be
> > used for `official' products, like CD's made using our own iso-images.
> 
> Sorry, I think this is a bad idea:
> 
> 1. We have to agree on *two* logos :-).

It's actually a good idea, and solves quite a few problems with the
licensing issues.

The "liberal" logo is something cool-looking that says "Debian" in some way,
that everyone can plaster all over CD's, books, web pages, and so on.

The "restricted" logo is more like a certification -- think "Intel Inside"
and "Yes! It works with Netware" here.  Visions of little swirlies.  It
would only be allowed to appear on official merchandise that is certified to
really be Debian, like official CD's.  This one is probably black and white,
and quite simple, and says something like "Certified Debian."

Notice how Novell's logo is quite different from the "Yes!" logo, and how
"Intel Inside" is very different from Intel's logo.

And guys, when worrying about licensing issues, remember that unless we get
these things trademarked, anyone who produces a rather similar looking
certification graphic will be free to use it wherever they want.  You can
only use copyright law to sublicense the _exact_ image file and derived
works, NOT similar-looking art.  (But if it uses the word "Debian" it's
probably covered under other trademarks.  IANAL.)

Have fun,

Avery

Re: the Great X Reorganization, package splits, and renaming

[Avery Pennarun]

On Mon, Jan 25, 1999 at 02:18:56PM +0100, Santiago Vila wrote:

> On Mon, 25 Jan 1999, Branden Robinson wrote:
> 
> > You have yet to explain what will BREAK if people continue to use the old
> > font packages.  Not in the future, RIGHT NOW.
> 
> Oh, you have yet to explain why a clock bomb is *not* a bad thing.
> "Surely, it will exploit, but not now" ;-)

But it won't.  I agree with Branden on this point.  What's the problem,
other than that you think someday it will explode?  I think it won't.  Who
wins?

My guess is that by the time potato is released, some kind soul will have
implemented package renaming in dpkg.  In that case, all future releases of
Debian will have the problem solved.  In slink, there's no problem other
than your supposed "time bomb," the existence of which is arguable at best.

> I propose a solution (which is the only *viable* solution, since we can't
> guarantee that dpkg will be changed), and you say it's uglier than the
> hell.

It is ugly.  Twiddling with dpkg in the xbase package (tell dpkg to select
all xfonts packages corresponding to the installed xfnt packages) kind of
appeals to me, but I'll respect Branden if he doesn't want to try it,
particularly while slink is in deep freeze.

(Specifically: we could do it sort of like the "menu" package does,
postponing the activity until after dpkg releases its lock.  It won't fix
things immediately, but the changes will show up next time through dselect.)

> > It would compound the error to reverse the name change.

Yup.

Very sorry for posting a "me too" message, but I thought it might be needed.
(I suspect that the infamous Debian "silent majority" effect is kicking in
again.)

Have fun,

Avery