Re: Getting current keymap

2000-09-14 Thread Yann Dirson
On Wed, Sep 13, 2000 at 10:47:09AM +0200, Torsten Landschoff wrote:
   3) S30checkfs.sh fails and bails out into a shell (using sulogin).
 
 Currently the keyboard mapping is loaded in S05keymaps-lct.sh and I think 
 that's a good thing.

Thanks, good point.  I'll put this rationale into console-data's README.Debian.

Best regards,
-- 
Yann Dirson[EMAIL PROTECTED] |Why make M$-Bill richer  richer ?
debian-email:   [EMAIL PROTECTED] |   Support Debian GNU/Linux:
| Cheaper, more Powerful, more Stable !
http://ydirson.free.fr/ | Check http://www.debian.org/


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



RFP: vtgrab: monitoring the VC's of another machines

2000-09-14 Thread Michael Bramer
Package: wnpp
Severity: wishlist

thanks

from the web-page (http://people.redhat.com/twaugh/vtgrab/):

  What is it?
 
   This is a utility for monitoring the screen of another machine. 
   It only works for text consoles: for X, the idea is to use VNC
   instead.
 
  Where is it?
   
   Here: http://people.redhat.com/twaugh/ftp/vtgrab/ (c)  .

  How does it work?
   
   It's only a prototype at the moment. Read this protocol
   specification (c)   to find out how it's supposed to work.

  Known bugs
   
   It can cause X to hang during a console switch. Someone who
   understands how X uses the VT_xxx ioctls probably should look at
   this.


Gruss
Grisu
-- 
Michael Bramer  -  a Debian Linux Developer http://www.debian.org
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
»A train station is a station where trains stops.
 But what are workstations?«


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



Re: Bug#71237: cdparanoia: cannot use cdparanoia 'out of the box' as a non-root user.

2000-09-14 Thread Remco Blaakmeer
On Tue, 12 Sep 2000 [EMAIL PROTECTED] wrote:

 
 Hmmm. No package called `scsidev' exists in Debian (potato|woody).
 Pointer?

Oops. scsidev is a part of the scsitools package.

Remco
-- 
qn195-66-31-144:  11:00pm  up 8 days, 23:14,  6 users,  load average: 2.03, 
1.49, 1.69


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



too funny to not pass on...

2000-09-14 Thread Seth Cohn
from debian-freshmeat, where we are talking about setting up the new DFMR
(Debian Freshmeat Repository)
Seth:
b) apt-get able, so it's a ftp and/or http site, and a
single line to stick into etc/apt/sources.list
Jeff Covey of freshmeat:
this would rock.
hhos
we'll have to work with the apt coding crew to get ready for the day
osdn decides they could be selling ad space here.
# apt-get install mod_foo
Reading Package Lists... Done
Building Dependency Tree... Done
Contacting ad server... Done
/\
|   This download is brought to you by Cisco Systems.|
| BUY OUR ROUTERS!  BUY OUR ROUTERS!  BUY OUR ROUTERS!  BUY OUR ROUTERS! |
| http://www.cisco.com/ |
\/
/hhos

Seth again:
Debian was brought to you today by the letters J, K, and the number 5.

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


Re: determining if we're using db.h from libc6 or libdb2?

2000-09-14 Thread Darren/Torin/Who Ever...
Domenico Andreoli, in an immanent manifestation of deity, wrote:
i don't know how much what i'm going to say would be of help, but if you added
a new check in configure.in in order to let your source know what kind of db.h
you have? you could be pretty sure that your sources are getting compiled the
right way.

Well, I'd need to know how to detect it.  I'm assuming that this isn't a
bundled module with configure.  I can't just detect for db2.4 since that
just happens to be the version included in glibc2.[01].  The user might
just have that version installed.

I suppose that I could have configure write a C program that included
db.h and linked with -ldb.  If it failed, try including db2/db.h and
if that worked, then I've isolated the problem in configure.

Darren
-- 
[EMAIL PROTECTED]http://www.daft.com/~torin/ [EMAIL PROTECTED][EMAIL 
PROTECTED]
Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-206-ELF-LIPZ
@ Sysadmin, webweaver, postmaster for hire. C/Perl/CGI/Pilot programmer/tutor @
@Make a little hot-tub in your soul.  @


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



Webmin: we're almost there

2000-09-14 Thread Jaldhar H. Vyas

Of course the moment I decided to upload 0.80 they released 0.81.  Luckily
most of the modifications survived intact.  I'm just fixing up a few
little things.

-- 
Jaldhar H. Vyas [EMAIL PROTECTED]


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



Re: mp3 encoding patents.

2000-09-14 Thread Bart Schuller
On Wed, Sep 13, 2000 at 12:57:10PM -0700, Sean 'Shaleh' Perry wrote:
 On 13-Sep-2000 [EMAIL PROTECTED] wrote:
  Sorry to bring up this subject again.
  I just wanted to know that can't mp3 encoders be distributed from a non-us
  site where the policies are much more relaxed ?
  
 the patents are held in Germany.  This restricts us because most countries in
 Europe accept them.

We would have a mirroring problem in any case, but that would still not
rule out hosting them in (and for) countries that don't allow these
kinds of patents.

Speaking for the Netherlands: you can't patent maths/software here.
European patents are also not automatically valid here, you still have
to apply for the patent. However, there's a fast track for european
patents, so the application could just be a formality. What happens if
such a formality clashes with the local laws is an interesting question.

Searching the Dutch patent database, I couldn't find the relevant
patents, but that might be because I don't know which are the relevant
patents. Anyone have some numbers?

http://nl.espacenet.com/ for Dutch patents, replace the nl with a
different country code if you're interested.

Oh, and of course IANAL.

-- 
The idea is that the first face shown to people is one they can readily
accept - a more traditional logo. The lunacy element is only revealed
subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual]


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



Re: determining if we're using db.h from libc6 or libdb2?

2000-09-14 Thread Domenico Andreoli
On Wed, Sep 13, 2000 at 02:38:07PM -0700, Darren/Torin/Who Ever... wrote:
 Domenico Andreoli, in an immanent manifestation of deity, wrote:
 i don't know how much what i'm going to say would be of help, but if you 
 added
 a new check in configure.in in order to let your source know what kind of 
 db.h
 you have? you could be pretty sure that your sources are getting compiled the
 right way.
 
 Well, I'd need to know how to detect it.  I'm assuming that this isn't a
 bundled module with configure.  I can't just detect for db2.4 since that
 just happens to be the version included in glibc2.[01].  The user might
 just have that version installed.
 
of course you cannot test version numbers only. yes, version could help to
choose whether or not the test is needed. you know that below a certain
version you are speaking of db2 in glibc2 and above you are speaking of db2
out of glibc2. between these versions you have ambiguity and test is needed.
what to do in this test i'm not able to tell you.

 I suppose that I could have configure write a C program that included
 db.h and linked with -ldb.  If it failed, try including db2/db.h and
 if that worked, then I've isolated the problem in configure.
 
i suppose you should care what the linker is linking your test code at too, but
you already know this.

i have a printed manual of autoconf i've never read too much. it seems not to be
a great pain write new tests, but for sure it is neither *that* easy. i never 
did
such a thing before.

IMHO, your problem your problem is best solved by autoconf.

btw, if i'm not wrong, these changes in glibc2 affects many other developers.
maybe in autoconf's upstream level they will write this test. maybe.

i'm sorry i cannot help you more :((

cheers

ps: and if you check for something like __DB_H__ after the header that in older
glibc2 would have included it? if this symbol is not defined, it means that you
are talking about a glibc2 without db2. so you know where to look for it.
db2/db.h! since i don't know which relation exists between glibc2 headers and
db2 ones, i could be completely wrong. :(

just an idea to make simpler the test for autoconf. something like:

#include whatever_glibc2_header_should_include_db_H.h

int main()
{
#ifdef __DB_H__
  return 0;
#elif
  return 1;
#endif
}

checking the return of this test you should know what kind of db.h you have and
you don't even care about which library to link it at! this code should work
without any db2 library linked, since it doesn't reference any external symbol.
hmm, i'm not so sure of this last words... i'm not a great developer.

but once you know who db.h is, you know which db2 shared library you need.

... more 2 cents... :)

-[ Domenico Andreoli, aka cavok
  --[ get my public gpg key at http://www.freeweb.org/free/cavok/gpgkey.asc
 -[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50


pgp6wl1OMhNtk.pgp
Description: PGP signature


Re: RFC: fix for daemon start (2)

2000-09-14 Thread Henrique M Holschuh
On Wed, 13 Sep 2000, Miquel van Smoorenburg wrote:
 I like it, but why not fold this functionality in update-rc.d itself?
 update-rc.d --query ? And why not define update-rc.d --list as well..

Well, for starters I don't grok perl, and I wasn't about to let that little
detail stop me from writing the sample code :-)

Also, update-rc.d and initscriptquery don't share much in the way of common
code, I think. I don't see any major advantages in merging the two, not to 
mention that it would generate a new interface for update-rc.d...

By keeping the two scripts separate, we avoid increasing the complexity of
update-rc.d and we also keep the two interfaces independent of each other.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


pgpkHs9pOdebR.pgp
Description: PGP signature


Re: apt-get and proxy

2000-09-14 Thread Jason Gunthorpe

On Wed, 13 Sep 2000, Andreas Tille wrote:

 From /var/lib/dpkg/available:
 Package: makedev:
 ...
 MD5sum: 7f6b97b984c246ead2c7be45ce4f1678
 
 /var/cache/apt/archives/partial md5sum makedev_2.3.1-46_all.deb
 7f6b97b984c246ead2c7be45ce4f1678  makedev_2.3.1-46_all.deb

Please use apt-cache show makedev rather than the available file, and
verify the version numbers too. 

Are you certain there is not a problem with your CPU/Memory that could
cause this?

See, the only time bytes are added to the hash is when they are written to
the file, so.. Well, what you are describing is impossible : I'd like to
see strace -o /tmp/foo -f -ff's -s200 and script logs of an apt-get doing
this. 

I did lots of testing of apt-get and most squids and never once
encountered an MD5 error.
 
 Well but some of my boxes don't use NFS and those using NFS have trouble
 with tke lock file.  At least I had when I tried.  Any example for 
 /etc/exports and /etc/fstab which handle this right?

You need kernel NFS server for locking.

Jason


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



Re: apt-get and proxy

2000-09-14 Thread Jason Gunthorpe

On Wed, 13 Sep 2000, Andreas Tille wrote:

 When I wrote, that the proxy variables were ignored just my description
 was wrong.  May be they are used but they are used in an other way
 than if I use settings in /etc/apt/apt.conf.  While trying several different
 proxy-settings (sorry, don't remember) there, I got explicitely the
 message that the proxy is contacted.  Using just the environment

Nope, they are 100% identical. The only way it could not work is if you
were not actually exporting the variable, or were typing something wrong.

 the time is always the same when updating package list (also doing this
 several times on the same box - at least this could be cached even
 without using a proxy - is this worth a wishlist-bug?) or when obtaining

It is cached - only environmental problems can defeat the cache - these
invariably boil down to defective servers, transparent proxies, or
*something* like that.

Jason



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



Re: KDE2 - nice demolition job ...

2000-09-14 Thread Joey Hess
John Galt wrote:
 The big package breakups have historically been related to licensing
 issues

Not as far as I can remember. The X breakup and the netbase breakup, for
instance, had nothing to do with licenses that I know of.

-- 
see shy jo


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



Re: KDE2 - nice demolition job ...

2000-09-14 Thread Nicolás Lichtmaier
  Purpose of Rant: Stir up the coals ...

 Have you already put some meat?


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



Re: kernel BUG [Was: Re: rm and ls don't work for large files]

2000-09-14 Thread Jason Hansen
On Tue, Aug 29, 2000 at 08:39:33AM +0200, Paul Slootman wrote:
 On Mon 28 Aug 2000, Nils Rennebarth wrote:
  On Mon, Aug 28, 2000 at 02:52:01PM +0200, Paul Slootman wrote:
 
   The problem here, as I mentioned in an earlier reply before this got
   crossposted to l-k, is that our version of libc is the one released
   with debian 2.2 potato, i.e. one that's intended for use with 2.2
   kernels. AFAIK 2.2 kernels don't have any lstat64.
 
  Ok, but someone will want to use larger files, be it with a patch to 2.2 or
  with a 2.4 kernel. Do we need to release a special libc version for those?
 
 Good question :-)  I have no idea. I would hope that the latest
 glibc checks whether lstat64  friends are available, and if not,
 falls back to the 32-bit versions. Maybe someone who's intimate
 with the glibc details can enlighten us?
 
 [ more good questions snipped ]
 

I've been trying to get LFS to work with 2.2.16. And so far, I've had no
luck. I've used the patches against 2.2.16, found at
ftp://ftp.scyld.com/pub/lfs/lfs-1.2.0.tar.gz which applied cleanly.

After building the kernel, and a reboot. I recompiled the libc6 (2.1.3-13)
deb with LINUX_SOURCE set to the location of the patched kernel tree. After
installing the fresh .deb's and another reboot, I attempted to recompile
fileutils (4.0l-8)... However, fileutils configure script does not detect
'large file support.' The relevant lines from the configure script output
follow:

checking for _FILE_OFFSET_BITS... 64
checking for _LARGEFILE_SOURCE... no
checking for _LARGE_FILES... no

Does anyone have LFS working on a potato installation?

-- 
--
Jason Hansen  [EMAIL PROTECTED]


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



Re: KDE2 - nice demolition job ...

2000-09-14 Thread John Galt

I thought the netbase breakup was because of a old-BSD/GPL license
incompatibility...

On Wed, 13 Sep 2000, Joey Hess wrote:

 John Galt wrote:
  The big package breakups have historically been related to licensing
  issues
 
 Not as far as I can remember. The X breakup and the netbase breakup, for
 instance, had nothing to do with licenses that I know of.
 
 

-- 
Pardon me, but you have obviously mistaken me for someone who gives a
damn.
email [EMAIL PROTECTED]


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



Re: nice demolition job ... epilog

2000-09-14 Thread Debian Linux User
On Wed, Sep 13, 2000 at 10:54:32PM -0300, Nicolás Lichtmaier wrote:
   Purpose of Rant: Stir up the coals ...
 
  Have you already put some meat?
 
Yes, but unfortunately it was all devoured immediately by ravenous wolves. 
Barely raw as well... and apparently there was some indigestion thereafter.
Pity.


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