Re: WANTED: someone to create a livefilesystem

[joost]

On Thu, 11 Jun 1998, Andreas Jellinghaus wrote:

> the "contrib" cdrom of the official cdset 
> should contain a livefilesystem, only to repair an installed linux.
> 
> i want that filesystem to have all text editors (see the current discussion),
> and every programm that might be usefull to repair a broken system
> (fs utils, ftape utils, smb client, amanda, whatever you think is good).

I'm really interested in this, plus I have a cdwriter.  Count me in on
this one!  

Cheers,


Joost


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

Re: Official CDROM

[Barak Pearlmutter]

[EMAIL PROTECTED]:
> Instead of the two-cd's-without-source, I'd rather see a special
> lightweight _single_ Debian cd for i386 that carries:
> ...
> A cd like this, with approximately 250 meg binaries, 250 meg sources, 40
> meg documentation, 10 meg kernels and a 100 meg live filesystem would
> make an excellent "cover cd" for computer magazines.

That's a great idea.  One minor suggestion: cut down the numbers a
touch, so there's about 100 meg free.  This would allow people to add
stuff in customizing the CD.

Last semester I needed to cut a dozen CDs for a course I was teaching.
I wanted to include a version of Scheme for a couple architectures
(Windows, MacOS, etc) and Emacs for the same set of architectures,
some manuals (R4RS and the like) plus some software of my own.  It all
added up to under 100 meg, so to fill out the CD I included the Debian
1.3 i386 binary bootable CD stuff, plus non-US and much of non-free.
I know that a number of people used it to install Debian on their home
machines.

The setup you describe would be even more suited to applications like
that.  And I'm sure magazines wouldn't mind a bit of free space on the
disk for some custom stuff either.


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

Re: Bootint big kernels

[Wichert Akkerman]

Previously Steve Dunham wrote:
> The only isapnp devices I know of are audio.  Are there any SCSI or
> enet devices?  (If so a table would be necessary as they are discovered.)

Yes, my adaptec 152x card is PnP. hint: don't use isapnp after booting
from a PnP scsi-card! 

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/


pgpryDbdHi8gC.pgp
Description: PGP signature

Re: Bootint big kernels

[Hamish Moffatt]

On Thu, Jun 11, 1998 at 06:10:16PM -0500, Martin Alonso Soto Jacome wrote:
> Steve Dunham <[EMAIL PROTECTED]> wrote:
> > The only isapnp devices I know of are audio.  Are there any SCSI or
> > enet devices?  (If so a table would be necessary as they are discovered.)
> 
> Yes, a lot of modern soundcards include an IDE controller, that is usually 
> configured with PnP.  Also, my current network card (a 3Com 3c509) is also 
> ISA 
> PnP.  I had to move it by hand to the non-PnP mode in order to use it with 
> Linux.

And internal modems. I have three PnP modems in my dialin server, although 
two have PnP disabled because they are badly behaved (they both have
the same board ID, exactly).


Hamish
-- 
Hamish Moffatt, [EMAIL PROTECTED], [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


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

Re: RFC: packaging kernel modules

[Jason Gunthorpe]

On Thu, 11 Jun 1998, Hamish Moffatt wrote:
> 
> Well, this sounds find, but I've never observed this to actually work.
> 
> [5:30pm] [EMAIL PROTECTED]:~# dpkg -s ntfs2.0.33
> Package: ntfs2.0.33
> Status: install ok installed
> 
> [5:30pm] [EMAIL PROTECTED]:~# modprobe ntfs
> /lib/modules/2.0/fs/ntfs.o: unresolved symbol generic_file_mmap_R57ec6036
> /lib/modules/2.0/fs/ntfs.o: unresolved symbol __wait_on_buffer_Rc98cf5d5
[clip]

The thing you must realize is if those symbols are no present in your
kernel then there is nothing you can do to make that module work.
recompiling that module will not help - you must rebuild the kernel to
have those symbols included.

For instance, in this case you may not have mod versions enabled, it might
be possible to convice ntfs to build without them and it might work, but
it is equally good for you to compile your kernel with mod versions
enabled to make the stock debian module work. 

Jason


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

Re: RFC: packaging kernel modules

[Jason Gunthorpe]

On Thu, 11 Jun 1998, Yann Dirson wrote:

> Jason Gunthorpe writes:
>  > Hm, we should really talk to the kernel people.. but here is my thoughts,
>  >   #1 - If person X compiles a module for kernel x.x.x and it doesn't work
>  >on your compile of x.x.x then you need to recompile your kernel.
>  >[General rule, most modules don't try to deduce what symbols are
>  > available]
> 
> Er, why ?  Does this mean I cannot choose the exact kernel config I
> will use, and what patches I apply ?

That's exactly what it means. As Wichert pointed out, you need PCI for
ALSA to work - period. If you don't want PCI then you must hack alsa.
 
>  > In the case of alsa I think it should compile for 2.0 and go into the 2.0/
>  > modules directory that appears to be on my machine.
> 
> Hm, I quite skeptic.  We'll have to have eg. a try at loading the
> 2.0.33-compiled ones in a 2.0.34 kernel...

I think alsa is using a fairly stable portion of the kernel interface. My
suggestion is to compile alsa against headers with modversions enabled and
require that anyone using the prebuild alsa driver also have that flag
(and pci and what ever else) enabled.

Jason


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

Re: RFC: packaging kernel modules

[Hamish Moffatt]

On Thu, Jun 11, 1998 at 07:17:19PM -0600, Jason Gunthorpe wrote:
> For instance, in this case you may not have mod versions enabled, it might
> be possible to convice ntfs to build without them and it might work, but
> it is equally good for you to compile your kernel with mod versions
> enabled to make the stock debian module work. 

I am 95% sure I compiled it with modversions enabled -- I always do.
I would have to check the .config file for the other 5%.

Easier to recompile the package, or run Linux 2.1.

Hamish
-- 
Hamish Moffatt, [EMAIL PROTECTED], [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


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

Re: mirroring policy

[Jason Gunthorpe]

On Thu, 11 Jun 1998, James A.Treacy wrote:

> I've discussed this with Jason and he's against it. He feels that it will be 
> too
> much administrative overhead to keep a list of acceptable mirrors. The reason
> we would want to set up restrictions is to prevent just anyone from mirroring 
> from
> the primary Debian sites (va and master. It would be a good idea to minimize 
> the
> net load from mirroring so they can be used for other tasks).

Lets ask Andrew to add CHAP like authentication - that will clear my
complaints. I don't like the idea of IP based authentication, it is weak
and it is a pain to admin.
 
> Given the large number of mirrors (ftp and www) it would be a good idea if we 
> set up
> a more formal mirroring policy. My proposal would be to switch to anon rsync 
> on
> master which is restricted to 3 primary ftp and web mirrors (2 in the US and 1
> in Europe for both ftp and web). All other mirrors would have to use one of
> the primary mirrors.

Also, those primary mirrors will be 'push' mirrors. Lets not do this
until Guy adds the runparts we talked about earlier.

I propose a two level scheme, master does a push to the top level mirrors
(va, .de, .uk, .au) then each of those does a push to a few others. I
think we should require that mirrors in the .debian.org domain be push
mirrors - I see too many complaints that a mirror is perpetually broken
because it mirrors a mirror during it's mirror cycle.

We can set va to push mirror from master as soon as guy adds the runparts
script and see how things work.

Jason


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

Re: RFC: packaging kernel modules

[Herbert Xu]

In article <[EMAIL PROTECTED]> you wrote:
> On Thu, 11 Jun 1998, Hamish Moffatt wrote:
>> 
>> Well, this sounds find, but I've never observed this to actually work.
>> 
>> [5:30pm] [EMAIL PROTECTED]:~# dpkg -s ntfs2.0.33
>> Package: ntfs2.0.33
>> Status: install ok installed
>> 
>> [5:30pm] [EMAIL PROTECTED]:~# modprobe ntfs
>> /lib/modules/2.0/fs/ntfs.o: unresolved symbol generic_file_mmap_R57ec6036
>> /lib/modules/2.0/fs/ntfs.o: unresolved symbol __wait_on_buffer_Rc98cf5d5
> [clip]

> The thing you must realize is if those symbols are no present in your
> kernel then there is nothing you can do to make that module work.

Not strictly true.  The symbols refered to above are always in the kernel, but
the checksum is very much version and config-sensitive.  What you could do if
you're brave is to remap those symbols in the .o file.

-- 
Debian GNU/Linux 1.3 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


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

Re: RFC: packaging kernel modules

[Jason Gunthorpe]

On Fri, 12 Jun 1998, Herbert Xu wrote:

> > The thing you must realize is if those symbols are no present in your
> > kernel then there is nothing you can do to make that module work.
> 
> Not strictly true.  The symbols refered to above are always in the kernel, but
> the checksum is very much version and config-sensitive.  What you could do if
> you're brave is to remap those symbols in the .o file.

What exactly is that checksum a checksum of? I would hope that it is a
hash of the function signature which should be constant for any kernel
version. If it is a hash of the contents then there is no point in having
binary modules..

Jason


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

Re: RFC: packaging kernel modules

[Herbert Xu]

Jason Gunthorpe wrote:
> 
> What exactly is that checksum a checksum of? I would hope that it is a
> hash of the function signature which should be constant for any kernel
> version. If it is a hash of the contents then there is no point in having
> binary modules..

It is computed from the signature.  But it is overzealous in that it follows
to many pointers, i.e. if your signature were

void foo(struct bar p);

and bar is

struct bar {
struct baz *q;
};

then if baz is changed, foo's checksum will also change.

-- 
Debian GNU/Linux 1.3 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


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

Propersel for standerd configuration system.

[Kevin Atkinson]

Although this is really a broader issue than just linux or debian
I thought I would present it to you guys and girls first.

One of the major problems with unix is that, for new users, 
it is a bear to configure.

I was thinking about this this afternoon an an idea struck me
on a great way to solve this problem: A standard confutation system.
Part of the problem with this is that every program has their own
format for the configuration files.  This idea would solve that
problem for ever.

It would consist of these parts:

- A server back end which would manage the master and users
  registry of configuration
- A server/watchdog that will manage the translation of the
  registry to the old fashion configuration files.  It will
  also watch the configuration files for changes and update the
  registry appropriately
- An easy to use API in C, C++, Perl, Java, Sh, and just about 
  another other language that a unix program or script can be
  written in.
- A command line based front end to manage the registry
- A ncurses based front end to manage the registry
- A X based front end to manage the registry

The actual data will be store in a binary format that is specific
to the server.  However the server will be able to export and import
configurations in a standard text based format.

The layout of the registry will be similar to Microsoft's windows
registry however it will be far more powerful.

Configurations will be stored with key/value pairs which will then
be stored under a sub category which will be stored under another
sub category etc

There will also be a template data file which will contain information
about how the configuration should look like such as: what keys are
valid 
under a subcategory,  what subcategories are under a certain
subcategory, 
and what format the key's value should look like.

The template data will also contain a detailed description of what
exactly a 
certain subcatagory is and what each of the key/value pairs under it do.
It will also contain information that will warn the user if he/she is 
modifying something which should really be modified by some other
utility.

Also, the template data file will contain event information.  These
events 
will tell the server what else it has to doing the event that data was
modified. Events can include information such as:
  - restarted a demean
  - updating the old fashion configuration file
  - running a program to modify system resources based on the new
configuration (such as mounted drives, etc.)

So what do you think of this idea?

If people think it is worthwhile of pursing I will work on a formal
draft
standard which will lay things out in more detail than this.


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

Re: joilet fs for official cdrom

[Ben Gertzfield]

(Cc:'ed to [EMAIL PROTECTED])

> "Ronald" == Ronald Lembcke <[EMAIL PROTECTED]> writes:

Ronald> I had the same problem with my selfburned hamm cd's... the
Ronald> debian-hamm kernel seems to prefere joliet over
Ronald> rockridge with mount -o nojoliet the symlinks
Ronald> worked...

Ronald> another problem with joliet... a bug in mkisofs and
Ronald> mkhybrid (at least in the newest available versioin
Ronald> arround april 6th)

Ronald> when you make a bootable cd with joliet _and_ rockridge
Ronald> the information for the bios that it is a bootable cd is
Ronald> written one sector too late... the cd won't be recognized
Ronald> as bootable.

Even though this is a "me too", I had *all* the exact same problems.

So:

 * We need a way to make the kernel prefer iso9660 with rock-ridge over
   Joliet. The kernel currently prefers Joliet over iso9660 with
   rock-ridge, so symlinks are invisible on CD-ROMs that are both
   iso9660 and Joliet.

 * El Torito needs to get along with mkhybrid.

Does anyone know any solutions for these?

Ronald> If someone can tell me the author's email address i could
Ronald> report this bug...

[EMAIL PROTECTED] is the right place for this.

-- 
Brought to you by the letters X and M and the number 10.
"Make a little birdhouse in your soul." -- They Might Be Giants
Debian GNU/Linux -- where do you want to go tomorrow? http://www.debian.org/
I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox.


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

Re: Propersel for standerd configuration system.

[Kevin Atkinson]

After writing this I realized that I did not give any good reason for
while it is needed so here it is.

The Standard Configuration System solves the problem of the difficulty
in managing unix (and especially linux) machines forever.

Although there are many front end for configuring various parts of the
linux system they rarely control all of the little features of a
program.  And in some cases they make it even more difficult to use
features not support by the front end.

The Standard Configuration System (SCS) doesn't have this problem
because it will control every aspect of the configuration.  Unlike front
ends which are often time consuming to write all the SCS requires is the
a template file describe what is valid and for older programs a
translation utility that will convert it to and from the old fashion
configuration file.  In most cases this utility can very easily be
written with a simple perl script. (Some more tricky configurations like
bind will take a little more doing, However.)

However the SCS will (eventually) also support a basic language for
describing a front-end for configuring a particular subcatagory (see
below) there for also having the ease of use of a graphical front end. 
(However I hope to design the SCS in a such a way that a front end will
rarely be needed).

Kevin Atkinson wrote:
> 
> Although this is really a broader issue than just linux or debian
> I thought I would present it to you guys and girls first.
> 
> One of the major problems with unix is that, for new users,
> it is a bear to configure.
> 
> I was thinking about this this afternoon an an idea struck me
> on a great way to solve this problem: A standard confutation system.
> Part of the problem with this is that every program has their own
> format for the configuration files.  This idea would solve that
> problem for ever.
> 
> It would consist of these parts:
> 
> - A server back end which would manage the master and users
>   registry of configuration
> - A server/watchdog that will manage the translation of the
>   registry to the old fashion configuration files.  It will
>   also watch the configuration files for changes and update the
>   registry appropriately
> - An easy to use API in C, C++, Perl, Java, Sh, and just about
>   another other language that a unix program or script can be
>   written in.
> - A command line based front end to manage the registry
> - A ncurses based front end to manage the registry
> - A X based front end to manage the registry
> 
> The actual data will be store in a binary format that is specific
> to the server.  However the server will be able to export and import
> configurations in a standard text based format.
> 
> The layout of the registry will be similar to Microsoft's windows
> registry however it will be far more powerful.
> 
> Configurations will be stored with key/value pairs which will then
> be stored under a sub category which will be stored under another
> sub category etc
> 
> There will also be a template data file which will contain information
> about how the configuration should look like such as: what keys are
> valid
> under a subcategory,  what subcategories are under a certain
> subcategory,
> and what format the key's value should look like.
> 
> The template data will also contain a detailed description of what
> exactly a
> certain subcatagory is and what each of the key/value pairs under it do.
> It will also contain information that will warn the user if he/she is
> modifying something which should really be modified by some other
> utility.
> 
> Also, the template data file will contain event information.  These
> events
> will tell the server what else it has to doing the event that data was
> modified. Events can include information such as:
>   - restarted a demean
>   - updating the old fashion configuration file
>   - running a program to modify system resources based on the new
> configuration (such as mounted drives, etc.)
> 
> So what do you think of this idea?
> 
> If people think it is worthwhile of pursing I will work on a formal
> draft
> standard which will lay things out in more detail than this.


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

Re: mirroring policy

[Philip Hands]

> Lets ask Andrew to add CHAP like authentication - that will clear my
> complaints. I don't like the idea of IP based authentication, it is weak
> and it is a pain to admin.

Too late --- he's already added it :-)

In the /etc/rsyncd.conf file on the target, you need something like this:

  [debian-push]
 path = /mirror/debian
 comment = Debian Push Mirror Access (requires authentication)
 auth users = debiansama
 gid = debmirror
 read only = false
 secrets file = /etc/rsyncd.debian.secrets

with a /etc/rsyncd.debian.secrets something like:

   debiansama:masterpassword

Then on master, you would run something like:

RSYNC_PASSWORD=masterpassword \
 rsync -av --delete /debian2/debian/ [EMAIL PROTECTED]::debian-push/

Obviously, having the passwords in the script is a security problem, but 
anyone with root access to master is probably going to be able to get round 
any other approach.

Cheers, Phil.



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

Intent to package: ud

[Fredrik Hallenberg]

I intend to package ud, the uptime daemon. This package should be ready in
a few days.

--
Fredrik Hallenberg [EMAIL PROTECTED]
http://www.lysator.liu.se/~hallon  [EMAIL PROTECTED]


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

Re: Rescue and Installation (was Re: VI reasons)

[Michael Shields]

In article <[EMAIL PROTECTED]>,
Steve Shorter <[EMAIL PROTECTED]> wrote:
>   Exactly! System "rescue" is fundamentally different from
> "installation". It is logical and expedient to seperate the two functions.  

Take a look at the rescue disks on ftp.varesearch.com.  They're very good.
-- 
Shields, CrossLink.


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

Re: mirroring policy

[Michael Shields]

I don't mind having people mirror off debian.crosslink.net; it has
lots of capacity.  The past problems with debian.crosslink.net not
mirroring correctly, and the underlying problem of my having no time
to fix it, have been resolved.  Currently I'm mirroring it over
rsync/ssh to master; but by hand, because I lost the password on the
`shields' account and have not been able to get it reset, so I cannot
get a .shosts file up.  Therefore I have to manually enter the
`shieldsM' password.  If someone can reset the `shields' password on
master then I can have it mirror several times daily.

I've put in a 9 GB drive just for Debian so I'll be carrying the CD
images too.
-- 
Shields, CrossLink.


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

Re: Propersel for standerd configuration system.

[Philip Hands]

> The layout of the registry will be similar to Microsoft's windows
> registry however it will be far more powerful.
...
> So what do you think of this idea?

IMHO The registry is the main reason that on Windows the solution to every
problem is ``re-install from scratch''.

What happens when you get a bad block in the registry ?  It doesn't just screw 
one program, it wreaks havoc across the entire system.

A bug in the server/wachdog, and you get a similar result.

A security bug in just about any of the software involved, and you can expect 
every program on the system to be compromised.

When you need to do disaster recovery, having the real configuration hidden in 
a binary database is a nightmare.

Sorry, but as you can probably tell, (to quote Groucho Marx):

  Before you've even started or commenced it, I'm against it.

Now, linuxconf is another matter, because that automates the editing of 
the files that were there already.

Wasn't someone supposed to be packaging linuxconf ?  If that someone happens 
to be me, could someone remind me of the fact ;-)

Cheers, Phil.




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

Re: joilet fs for official cdrom

[Philip Hands]

> [EMAIL PROTECTED] is the right place for this.
  

Don't you mean:

  [EMAIL PROTECTED]


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

Re: joilet fs for official cdrom

[James Pearson]

>Ronald> another problem with joliet... a bug in mkisofs and
>Ronald> mkhybrid (at least in the newest available versioin
>Ronald> arround april 6th)
>
>Ronald> when you make a bootable cd with joliet _and_ rockridge
>Ronald> the information for the bios that it is a bootable cd is
>Ronald> written one sector too late... the cd won't be recognized
>Ronald> as bootable.
>
> * El Torito needs to get along with mkhybrid.

I believe this is fixed in the latest release of mkisofs (and mkhybrid,
as it's based on mkisofs) - I haven't tried it, but comments in the
mkisofs code say:

SVD for El Torito. MUST be immediately after the PVD!

and the El Torito SVD is now written out immediately after the PVD and
before any Joliet SVD.

mkisofs-1.12b4 is available from ftp://andante.jic.com/pub/mkisofs
and mkhybrid-1.12a4.0 is available from ftp://ftp.ge.ucl.ac.uk/pub/mkhfs

James Pearson


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

Re: joilet fs for official cdrom

[Thomas Hohenberger]

On 11 Jun 1998, Ben Gertzfield wrote:

[]
> So:
> 
>  * We need a way to make the kernel prefer iso9660 with rock-ridge over
>Joliet. The kernel currently prefers Joliet over iso9660 with
>rock-ridge, so symlinks are invisible on CD-ROMs that are both
>iso9660 and Joliet.
[]

I followed the discussion above. I have two SuSE Linux 2.0.33/2.0.34 systems.
The first system has my cdrecorder attached. I patched this one with the 
Joliet patch and a 2k blocksize patch for my MO drive. This system prefers 
Joliet over Rockridge. 
The second system was not Joliet aware. I applied the 2.0.34 patch, which 
seems to install Joliet support. This system does Rockridge before Joliet 
and therefore knows about symbolic links.

Maybe this is the same for You people owning a cdrecorder.
Using a pure 2.0.34 kernel might help.

Ciao,
Thomas "Tom" Hohenberger

And remember: "The solution to a problem tends to change the problem".
  /--\
  |  Thomas Hohenberger, Lehrstuhl Experimentalphysik V  |
  |  Universitaet Bayreuth, 95440 Bayreuth   |
  |  Phone: +49-921/55-3317   FAX: +49-921/55-3647   |
  |  e-mail: [EMAIL PROTECTED]|
  |  or: [EMAIL PROTECTED] :-)  |
  \--/


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

Re: joilet fs for official cdrom

[Luis Francisco Gonzalez]

Philip Hands wrote:
> > >I thought debian's 2.0.33 had the FAT32 patch. This is the same as the 
> > >joilet
> > >stuff AFAIK. Does this mean that you are using a non-standard kernel or am 
> > >I
> > >just totally wrong here?
> > 
> > i don't know what [EMAIL PROTECTED] is useing (no symlinks at his machine),
> > but my own system is running 2.0.34pre15 (will upgrade to 2.1 soon).
> 
> 2.0.33 built from (IIRC) a straight kernel-source_2.0.33 source tree.
> 
> This presumably means that the kernel on the boot floppies is going to choke 
> on Joilet CD's too, which is probaly enough reason not to use Joilet at the 
> moment, isn't it ?
No, the kernel in the floppies has it (the patch). I don't have any CDW to
test this but the patch is there.

Luis.
-- 
Luis Francisco Gonzalez <[EMAIL PROTECTED]>
PGP Fingerprint = F8 B1 13 DE 22 22 94 A1  14 BE 95 8E 49 39 78 76


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

Re: another look at release-critical bugs: lpr

[Paul Slootman]

On Wed 03 Jun 1998, Craig Sanders wrote:
> On Sat, 30 May 1998, Jay Wardle wrote:
> 
> > [...Raul wrote...]
> > > If this can't be fixed easily, perhaps we ought to promote lprng to
> > > standard and demote lpr to optional. Yes, I know that bug-for-bug
> > > compatability is a nice thing, but in my experience lprng is superior to
> > > lpr.

If you take a look at the bug report, you'll see that there's a
workaround already in place for this bug, but the maintainer left the
bug report intact because he wants to find a cleaner solution.

Hence this discussion of lpr <-> lprng is pretty much off-topic, and
distracting to the point in question.

He probably should have changed the priority to wishlist, however.

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


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

Re: joilet fs for official cdrom

[Joerg Schilling]

>From [EMAIL PROTECTED] Fri Jun 12 10:34:48 1998

>>Ronald> another problem with joliet... a bug in mkisofs and
>>Ronald> mkhybrid (at least in the newest available versioin
>>Ronald> arround april 6th)
>>
>>Ronald> when you make a bootable cd with joliet _and_ rockridge
>>Ronald> the information for the bios that it is a bootable cd is
>>Ronald> written one sector too late... the cd won't be recognized
>>Ronald> as bootable.
>>
>> * El Torito needs to get along with mkhybrid.

>I believe this is fixed in the latest release of mkisofs (and mkhybrid,
>as it's based on mkisofs) - I haven't tried it, but comments in the
>mkisofs code say:

>   SVD for El Torito. MUST be immediately after the PVD!

>and the El Torito SVD is now written out immediately after the PVD and
>before any Joliet SVD.

>mkisofs-1.12b4 is available from ftp://andante.jic.com/pub/mkisofs
>and mkhybrid-1.12a4.0 is available from ftp://ftp.ge.ucl.ac.uk/pub/mkhfs

The Joliet/Eltorito problem was fixed on 29th of march in cdrecord-1.6a13
Eric was very busy and therefore not able to incorporate the fix in his
official release.

 Jörg

 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  If you don't have iso-8859-1
   [EMAIL PROTECTED](work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix


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

Re: Propersel for standerd configuration system.

[Jules Bean]

--On Fri, Jun 12, 1998 7:53 am +0100 "Philip Hands" <[EMAIL PROTECTED]> wrote: 

>> The layout of the registry will be similar to Microsoft's windows
>> registry however it will be far more powerful.
> ...
>> So what do you think of this idea?
> 
> IMHO The registry is the main reason that on Windows the solution to every
> problem is ``re-install from scratch''.

Search the mailing list archives.

We have discussed this, in detail, quite recently.

COAS is a system which has something in common with your suggestions.

We opted for linuxconf, which also has something in common with our
suggestions :-)

Jules


/+---+-\
|  Jelibean aka  | [EMAIL PROTECTED] |  6 Evelyn Rd|
|  Jules aka |   |  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.  |
\--/



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

Swedish maintainers?

[Thimo Neubauer]

-BEGIN PGP SIGNED MESSAGE-

Hi,
I am a german physics-student right now studying in Uppsala, Sweden.
Really soon I want to register as a new Debian-maintainer and take over
some orphaned packages (bibindex, xbattle, p2c?) to help to reach the goal
of a completely maintained distribution.
Now I wonder if there is any maintainer somewhere in the Uppsala/Stockholm
region who can authenticate me?

 Thimo Neubauer

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

iQCVAwUBNYEP1Mo2QMNDSTUFAQEMGQP/UCWgJtJKWScZcQSvam8Toe4dgVKok7jo
wS5LwDVn2h18LfJmLgCNAKP7uVpbzNrWxfHbVMxRLEvleGjb74J+f4Z0T7qS0V0J
D87z8YRLnf45XDzcHxzRXKIp4WmoKa71XNAC06NphAqcCfih92N2UVT2OcpI0V7+
r/KWWc/7P/I=
=ug6E
-END PGP SIGNATURE-


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

Re: mkdosfs

[Paul Slootman]

On Wed 10 Jun 1998, Michael Alan Dorman wrote:
> On Wed, Jun 10, 1998 at 09:10:37AM +0200, [EMAIL PROTECTED] wrote:
> > On Tue, Jun 09, 1998 at 02:26:50PM +0200, Michael Dietrich wrote:
> > > who maintains the mkdosfs package 
> > There's no separate mkdosfs package anymore; it has been merged into
> > 'dosfstools' which is maintained by [EMAIL PROTECTED] .
> 
> And which I'm fairly certain I ported, since I used it to create the boot
> partition on my alpha...

dosfsck however does not work on Alpha, it always complains about bad
fat type (0)  or something like that. I tried to track it down, but
dosfsck is a mess of data types where assumptions are made about
endianness and word size :-(


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


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

Compiling stuff for frozen with g++272 ?

[Gregor Hoffleit]

I don't know how to handle this:

My swig package in frozen has a small, but `important' bug dealing with  
version numbers (#20068, swig: dpkg thinks 1.1p5-1 < 1.1.b5.p2-1).

I thought about simply rebuilding the package with a changed revision  
number "1.1.p5-1" which would fix the bug in a very transparent way.

But when I compared the resulting packages, I found that the old package  
had been built with a g++/libstdc++ based on 2.7.2, while nowadays g++  
2.90 is the official C++ compiler, going with libstdc++2.8.

Now I don't know: When I recompile the package using the official g++  
2.90 / libstdc++ 2.80 combo, this may introduce new bugs, therefore I'm  
sure Brian won't allow this to go into frozen.

The alternative is faking an build environment that installs g++272 as  
c++ and uses libstdc++272. Is this the accepted way to go ?

Gregor


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

Re: Compiling stuff for frozen with g++272 ?

[jdassen]

On Fri, Jun 12, 1998 at 03:54:57PM +0200, Gregor Hoffleit wrote:
> Now I don't know: When I recompile the package using the official g++ 2.90
> / libstdc++ 2.80 combo, this may introduce new bugs, therefore I'm sure
> Brian won't allow this to go into frozen.

IIRC, at least one package has been fixed this way and accepted into frozen.
Personally, I'd prefer maintainers to use the up to date g++ package with
matching lib.

> The alternative is faking an build environment that installs g++272 as c++

Not necessary. g++272 installs it's driver binary as `g++272'; just make
sure you pass that to the build process (e.g. via CXX).

> and uses libstdc++272.

This is a possibility too. It's not one that has my preference.

HTH,
Ray
-- 
UNFAIR  Term applied to advantages enjoyed by other people which we tried 
to cheat them out of and didn't manage. See also DISHONESTY, SNEAKY, 
UNDERHAND and JUST LUCKY I GUESS. 
- The Hipcrime Vocab by Chad C. Mulligan  


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

Re: Compiling stuff for frozen with g++272 ?

[Hamish Moffatt]

On Fri, Jun 12, 1998 at 03:54:57PM +0200, Gregor Hoffleit wrote:
> But when I compared the resulting packages, I found that the old package  
> had been built with a g++/libstdc++ based on 2.7.2, while nowadays g++  
> 2.90 is the official C++ compiler, going with libstdc++2.8.
> 
> Now I don't know: When I recompile the package using the official g++  
> 2.90 / libstdc++ 2.80 combo, this may introduce new bugs, therefore I'm  
> sure Brian won't allow this to go into frozen.
> 
> The alternative is faking an build environment that installs g++272 as  
> c++ and uses libstdc++272. Is this the accepted way to go ?

I think I'm going to have to do the same if I'm to fix 22325 against
guavac. It won't build with libstdc++2.8, and the error seems to be
in the STL header files, ie not in guavac's source. Very strange.


Hamish
-- 
Hamish Moffatt, [EMAIL PROTECTED], [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


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

Re: another look at release-critical bugs: lpr

[Raul Miller]

Paul Slootman <[EMAIL PROTECTED]> wrote:
> If you take a look at the bug report, you'll see that there's a
> workaround already in place for this bug, but the maintainer left the
> bug report intact because he wants to find a cleaner solution.
>
> Hence this discussion of lpr <-> lprng is pretty much off-topic, and
> distracting to the point in question.

If you look a bit closer, you'll see that the first message about
a workaround was a followup to my suggestion of using lprng as an
alternative.

-- 
Raul


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

Re: guavac bug #22325

[Hamish Moffatt]

On Wed, Jun 10, 1998 at 10:05:05AM -0400, Brian White wrote:
> > Bug #22325, marked important, says that my package guavac has an
> > unsatisfied suggestion on java-virtual-machine. I need your
> > advice on what to do about it.

> I'd do either:
> 
> 1) ignore the "suggests" problem

I think this will have to be the plan of action. It doesn't
build in g++ 2.8 with libstdc++2.8/libg++2.8, it almost builds on
g++272 with libg++272-dev but not quite, presumably because
the autoconf stuff tests some things using `g++' (2.8) but
then the code gets compiled with g++272, and I'm not too sure
how to work around this.

Unfortunately we don't really seem to support concurrent
2.7.2 and 2.8 development, since the -dev packages conflict.

> 2) repack the existing package to remove the "suggests" line.

How do you mean `repack'?

Since it's a valid virtual package name I'm not even convinced
it's a bug in any package at all. May I change it to wishlist?

thanks,
Hamish
-- 
Hamish Moffatt, [EMAIL PROTECTED], [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


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

Re: Swedish maintainers?

[Rafael Laboissiere]

> "TN" == Thimo Neubauer <[EMAIL PROTECTED]> writes:


TN> Really soon I want to register as a new Debian-maintainer and
TN> take over some orphaned packages (bibindex, xbattle, p2c?) 
  

Too late, I already took over bibindex (the package is ready for
uploading).

See my announce some days ago at 
http://www.debian.org/Lists-Archives/debian-devel-9806/msg00642.html
 

Welcome to Debian, anyway,

--
Rafael Laboissiere
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


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

Re: Propersel for standerd configuration system.

[sjc]

On Fri, Jun 12, 1998 at 12:23:28AM -0400, Kevin Atkinson wrote:

> One of the major problems with unix is that, for new users, 
> it is a bear to configure.

I definitly agree (and am glad im not one of those "new users"). In fact
most "new things" that one has never configured before take a while
to figure out and do...the upshot however is that you can learn allot
from it.
 
> It would consist of these parts:

ok
 
> - A server back end which would manage the master and users
>   registry of configuration

ewwwyuk...gee I wish I hadn't read this right before lunch time
lost my appitite now...
(Read: This "feature" is one of the "Top 10" reasons I switched to linux)

> - An easy to use API in C, C++, Perl, Java, Sh, and just about 
>   another other language that a unix program or script can be
>   written in.

APIs, when well written are always nice to have :)

> The actual data will be store in a binary format that is specific
> to the server.  However the server will be able to export and import
> configurations in a standard text based format.

sounds like a nightmare. Ok lets see...something happnes to the registry..
(maybe it gets deleted or becomes somehow unreadable)...I loose the
configs for EVERYTHING.

Should the registry editor stop working (maybe part of the reg is corrupted,
any reason) I have no recource but to wipe it all out and re-install
(okill just pull out the tape backup...but not everyone has a tape backup 
and I don't enjoy NEEDing to restore)

It would HAVE to be able to fit on a rescue disk (along with all of the 
other tools which already HAVE to be on it) 
 
> So what do you think of this idea?

As you can see I don't like it. 

I could however see writing a library or some sort of "interface" that programs
can use. This would take the burden of writting a parser and working out the 
more "exact details" of the configuration file off of the designer of the
application, and place it on the library.

This would allow the library to basically do whatyou say (make a database of
configurations and provide and interface for changin gthem) but...it would
also allow the library to do it right (well... RIGHT as in what _I_ think
is right..which is of course right). It could take care of the details of
parsing and writting a config file.

This would put all conifg files ofprograms which use it into a standard format.
The advantages:

1) It would be easier to write programs that configure programs. All they
would have to do is know what variables exist, and what legal values are.
The actual format of the file would eb un-important (I would imaging that 
that is a stu,bling block for writting programs that configure
a wide range of applications as each on emay have a subtly differnt format)

2) It would allow an administrator to repair the system the same as they 
always have.

3) The files all using a standard format would make editing files by hand
easier as one doesn't have to think "Ok...in this file can I use tabs?" (etc)

4) For those who want better performance and don't care about editing by hand 
it would not be a problem to use a binary database instead of
text files.

of course you have to convince everyone that your system is good and worth 
them using in their programs (unless you intend to edit them yourself :) )
but...thats the same for any system.

When trying to decide between two vastly differnt systems of doing things
always pick niether and steal the best of both ways :)
 
As for this library...I might even be willing to work on such a thing...
I do wish to experient with config files and parsing etc...

-Steve


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

Re: The Hamm Bugs Stamp-Out List

[Adam P. Harris]

"Marcelo E. Magallon" <[EMAIL PROTECTED]> writes:

> On Sun, Jun 07, 1998 at 11:40:30PM +0200, Richard Braakman wrote:
> 
> > Package: bootdisk (pseudo)
> > Maintainer: Maintainer Group <[EMAIL PROTECTED]> 
> >   20779  Debian 2.0 won't boot of a hard disk after install
> > [STRATEGY] Enrique: "This is a hardware-specific bug too. I have asked
> >   the submitter to try to install after disabling the 128KB cache
> >   as stated in the docs (he has a Cyrix CPU). He is going to try it
> >   and will report back."
> 
> I can confirm that on Cyrixes having the cache disabled solves problems. I
> ran into a similar problem, I got as far as the second installation screen,
> and then dinstall starts to segfault. For the record, I had to disable BOTH
> caches, internal and external. Surprisingly, the machine didn't run *much*
> slower...

I know there were a few cyrix-specific fixes introduced in 2.0.34.
Maybe some of the people experiencing this problem might test it out
with that kernel?  That might push out to definately try to get 2.0.34
in for hamm release.  (Although AFAIK, it's ok to have new version of
boot floppies for hamm even after release date?)

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


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

Re: p3nfs (was Bug #21488: p3nfs linked against libc5)

[Adam P. Harris]

David Frey <[EMAIL PROTECTED]> writes:
> On Tue, Jun 09, 1998 at 08:35:47PM +0100, Chris Reed wrote:
> >As listed in The Hamm Bugs Stamp-Out List for 1998-06-08, p3nfs is still 
> >linked against libc5, and the maintainer,  [EMAIL PROTECTED] (Billy 
> >C.-M. Chow) cannot be contacted.
> >
> >I have looked on ftp.uni-elargen.de:/pub/psion3/local/utilities and found a 
> >glibc diff for version 5.3 (current version in hamm is 5.1).  I've 
> >downloaded this and with a one line patch it compiles, and I've had it 
> >working.
> 
> I did this several weeks ago and tried a upload into frozen/unstable.
> It got rejected, since new versions aren't accepted...

So, in summary, we either need to back patch 2.1, or just pull the
package from hamm, and put patched 5.3 in slink, and leave it at that.

I would think the latter option would be better.

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


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

Re: Propersel for standerd configuration system.

[Kevin Atkinson]

[EMAIL PROTECTED] wrote:
> 
> On Fri, Jun 12, 1998 at 12:23:28AM -0400, Kevin Atkinson wrote:
> 
> > One of the major problems with unix is that, for new users,
> > it is a bear to configure.
> 
> I definitly agree (and am glad im not one of those "new users"). In fact
> most "new things" that one has never configured before take a while
> to figure out and do...the upshot however is that you can learn allot
> from it.
> 
> > It would consist of these parts:
> 
> ok
> 
> > - A server back end which would manage the master and users
> >   registry of configuration
> 
> ewwwyuk...gee I wish I hadn't read this right before lunch time
> lost my appitite now...
> (Read: This "feature" is one of the "Top 10" reasons I switched to linux)
> 
> > - An easy to use API in C, C++, Perl, Java, Sh, and just about
> >   another other language that a unix program or script can be
> >   written in.
> 
> APIs, when well written are always nice to have :)
> 
> > The actual data will be store in a binary format that is specific
> > to the server.  However the server will be able to export and import
> > configurations in a standard text based format.
> 
> sounds like a nightmare. Ok lets see...something happnes to the registry..
> (maybe it gets deleted or becomes somehow unreadable)...I loose the
> configs for EVERYTHING.
> 
> Should the registry editor stop working (maybe part of the reg is corrupted,
> any reason) I have no recource but to wipe it all out and re-install
> (okill just pull out the tape backup...but not everyone has a tape backup
> and I don't enjoy NEEDing to restore)
> 
> It would HAVE to be able to fit on a rescue disk (along with all of the
> other tools which already HAVE to be on it)

Very good point.  However first off the registry should consist of lots
of little files with one file for each major subcatogry, therefore if
one gets corrupted it won't bring the entire system down.  Second off
data will be regually exported to text based backup files (say like
every hour) so if something goes wrong it can easilly read the text
based file to fix the corrupted parts.  
> 
> > So what do you think of this idea?
> 
> As you can see I don't like it.
> 
> I could however see writing a library or some sort of "interface" that 
> programs
> can use. This would take the burden of writting a parser and working out the
> more "exact details" of the configuration file off of the designer of the
> application, and place it on the library.
> 
> This would allow the library to basically do whatyou say (make a database of
> configurations and provide and interface for changin gthem) but...it would
> also allow the library to do it right (well... RIGHT as in what _I_ think
> is right..which is of course right). It could take care of the details of
> parsing and writting a config file.
> 
> This would put all conifg files ofprograms which use it into a standard 
> format.
> The advantages:
> 
> 1) It would be easier to write programs that configure programs. All they
> would have to do is know what variables exist, and what legal values are.
> The actual format of the file would eb un-important (I would imaging that
> that is a stu,bling block for writting programs that configure
> a wide range of applications as each on emay have a subtly differnt format)
> 
> 2) It would allow an administrator to repair the system the same as they
> always have.
> 
> 3) The files all using a standard format would make editing files by hand
> easier as one doesn't have to think "Ok...in this file can I use tabs?" (etc)
> 
> 4) For those who want better performance and don't care about editing by hand
> it would not be a problem to use a binary database instead of
> text files.
> 
> of course you have to convince everyone that your system is good and worth
> them using in their programs (unless you intend to edit them yourself :) )
> but...thats the same for any system.
> 
> When trying to decide between two vastly differnt systems of doing things
> always pick niether and steal the best of both ways :)
> 
> As for this library...I might even be willing to work on such a thing...
> I do wish to experient with config files and parsing etc...
> 

I really just should not have mentioned the windows registry as most
people hate it. However what I was thinking off would is exactly what
you are thinking off.  There will just be a server running where
programs can talk to to change their configuration.  However it can also
translate things to in from the old fashion configuration files so that
applications don't have to use the library if they don't wants to.

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


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

Re: another look at release-critical bugs: lpr

[Adam Klein]

On Fri, Jun 12, 1998 at 12:56:42PM +0200, Paul Slootman wrote:
> On Wed 03 Jun 1998, Craig Sanders wrote:
> > On Sat, 30 May 1998, Jay Wardle wrote:
> > 
> > > [...Raul wrote...]
> > > > If this can't be fixed easily, perhaps we ought to promote lprng to
> > > > standard and demote lpr to optional. Yes, I know that bug-for-bug
> > > > compatability is a nice thing, but in my experience lprng is superior to
> > > > lpr.
> 
> If you take a look at the bug report, you'll see that there's a
> workaround already in place for this bug, but the maintainer left the
> bug report intact because he wants to find a cleaner solution.
> 
> Hence this discussion of lpr <-> lprng is pretty much off-topic, and
> distracting to the point in question.
> 
> He probably should have changed the priority to wishlist, however.

I did change the severity to wishlist.

Adam Klein


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

Re: ssl browsers

[Tommi Virtanen]

On Thu, Jun 11, 1998 at 03:37:11PM +0100, Luis Francisco Gonzalez wrote:
> I wanted to know what ssl-enabled browsers we have in debian now. Also
> does anybody know if ftps:// is a valid URL for ssl-enabled ftp?

fortify (in non-US) can patch Netscapes to support
reasonable crypto. It does weak crypto even without
that. HTH.
-- 
[EMAIL PROTECTED] - it's a valid address w/o spam


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

Re: ssl browsers

[Tim Sailer]

On Fri, Jun 12, 1998 at 08:47:37PM +0300, Tommi Virtanen wrote:
> On Thu, Jun 11, 1998 at 03:37:11PM +0100, Luis Francisco Gonzalez wrote:
> > I wanted to know what ssl-enabled browsers we have in debian now. Also
> > does anybody know if ftps:// is a valid URL for ssl-enabled ftp?
> 
>   fortify (in non-US) can patch Netscapes to support
>   reasonable crypto. It does weak crypto even without
>   that. HTH.

Does anyone know of a SSL-enabled pop3 server?

Tim

-- 
 (work) [EMAIL PROTECTED] / (home) [EMAIL PROTECTED] - http://www.buoy.com/~tps
  "Today is the tomorrow that yesterday you spent money like there was no"
   Ivern Ball
** Disclaimer: My views/comments/beliefs, as strange as they are, are my own.**


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

Re: joilet fs for official cdrom

[Ben Gertzfield]

> "Thomas" == Thomas Hohenberger <[EMAIL PROTECTED]> writes:

Thomas> I followed the discussion above. I have two SuSE Linux
Thomas> 2.0.33/2.0.34 systems.  The first system has my cdrecorder
Thomas> attached. I patched this one with the Joliet patch and a
Thomas> 2k blocksize patch for my MO drive. This system prefers
Thomas> Joliet over Rockridge. The second system was not Joliet
Thomas> aware. I applied the 2.0.34 patch, which seems to install
Thomas> Joliet support. This system does Rockridge before Joliet
Thomas> and therefore knows about symbolic links.

Hm, that's odd. Perhaps the order somehow matters..

Thomas> Maybe this is the same for You people owning a cdrecorder.
Thomas> Using a pure 2.0.34 kernel might help.

Unfortunately, this is the same with a pure 2.0.34 kernel.

-- 
Brought to you by the letters P and N and the number 4.
"What's your order? I can SuperSize that." -- TMBG
Debian GNU/Linux -- where do you want to go tomorrow? http://www.debian.org/
I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox.


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

Re: joilet fs for official cdrom

[Ben Gertzfield]

> "Philip" == Philip Hands <[EMAIL PROTECTED]> writes:

>> [EMAIL PROTECTED] is the right place for this.
Philip>   

Philip> Don't you mean:

Philip>   [EMAIL PROTECTED]

No, [EMAIL PROTECTED] is a separate mailing list just for CD
burning software under unix.

-- 
Brought to you by the letters E and Y and the number 4.
"Nerd. Loser. Jerk. Moron. Worm. Scum. Idiot. Fool." -- Pkunk, SCII
Debian GNU/Linux -- where do you want to go tomorrow? http://www.debian.org/
I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox.


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

Re: Propersel for standerd configuration system.

[Dan Jacobowitz]

Now, don't get me wrong...I hate windows registries just as badly as
anyone else, and I've been using linuxconf on and off for ages.  But
this has one darn good idea to it: many programs using the same data
source.  For instance, I just installed this machine with one hostname
before realizing that alas, I could not get that hostname!  It was a
royal pain to find all occurances of that hostname and change them all.

Dan


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

Re: The Hamm Bugs Stamp-Out List

[Michael Stone]

Quoting Adam P. Harris ([EMAIL PROTECTED]):
> I know there were a few cyrix-specific fixes introduced in 2.0.34.
> Maybe some of the people experiencing this problem might test it out
> with that kernel?  That might push out to definately try to get 2.0.34
> in for hamm release.  (Although AFAIK, it's ok to have new version of
> boot floppies for hamm even after release date?)

If you changed the kernel on the boot floppies, you'd also need a new
kernel-source package, etc., in the dist.

-- 
Michael Stone, Sysadmin, ITRI PGP: key 1024/76556F95 from mit keyserver,
[EMAIL PROTECTED]finger, or email with "Subject: get pgp key" 


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

RE: ISDN driver support

[Jaakko Niemi]

>> > Hi,
>> > 
>> > My name is Peter Hum and I am a program manager at Eicon Technology.  We
>> > are currently in the process of porting our driver for our ISDN PRI/BRI
>> > adapter into Linux.  I would like to know we can have this driver
>> > integrated into your next release of the kernel.

 Hi!

 There is info about Linux and ISDN in : 
http://www.muc.de/~hm/linux/linux-isdn.html .
 Through there you can find the people developing ISDN drivers. There is some 
 support for some of your cards in the newer developement kernels (2.1.101 and
 later.).

 Personally I think this is a great move from you. It will definately have a 
positive
 effect also in your sales. I have to every now and then find a card that works
 with Linux, and it can sometimes be a bit of work. Your cards are very well
 available in here. 

--j




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

Re: Propersel for standerd configuration system.

[Raul Miller]

Dan Jacobowitz <[EMAIL PROTECTED]> wrote:
> Now, don't get me wrong...I hate windows registries just as badly as
> anyone else, and I've been using linuxconf on and off for ages.  But
> this has one darn good idea to it: many programs using the same data
> source.  For instance, I just installed this machine with one hostname
> before realizing that alas, I could not get that hostname!  It was a
> royal pain to find all occurances of that hostname and change them all.

So?  There's already a system call to give you the hostname.

Which is to say: a good idea is only a good idea unless you're 
willing to do the hard work of actually making it work properly.

-- 
Raul


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

Re: Propersel for standerd configuration system.

[sjc]

On Fri, Jun 12, 1998 at 12:29:41PM -0400, Kevin Atkinson wrote:
> [EMAIL PROTECTED] wrote:
> > 
> > On Fri, Jun 12, 1998 at 12:23:28AM -0400, Kevin Atkinson wrote:
> > 
>  Second off
> data will be regually exported to text based backup files (say like
> every hour) so if something goes wrong it can easilly read the text
> based file to fix the corrupted parts.  

hmm this sounds good at first...but has some problems.
First: What if the configuration error or orruption takes more than an hour (or 
even
more than a day) before it is noticed? it could start dumping off corrupt data
(depending on whether or not it notices the corruption)

second: seems execcive

> > > So what do you think of this idea?
> > 
> > As you can see I don't like it.
> > 
> > I could however see writing a library or some sort of "interface" that 
> > programs
> > can use. This would take the burden of writting a parser and working out the
> > more "exact details" of the configuration file off of the designer of the
> > application, and place it on the library.
> > 
> > This would allow the library to basically do whatyou say (make a database of
> 
> I really just should not have mentioned the windows registry as most
> people hate it.

not most peoplejust those people who know of it and have had to
deal with it :)

> However what I was thinking off would is exactly what
> you are thinking off.  There will just be a server running where
> programs can talk to to change their configuration.  

Thats not exactly what I was thinking of...I was thinking litterally of a 
library. just the code to do it in a nice dynamically linkable library.

I don't see the need for a server running...those chores would best be handled 
by some other utility which uses the API. SUing an actual server for this 
seems like major overkill to me.

> However it can also
> translate things to in from the old fashion configuration files so that
> applications don't have to use the library if they don't wants to.

well thats the nice thing about the library...all you have to do is update
the library, and use a utility to dump the old configs back through it...
and presto...your using a new file format.. ALL programs which
use the library would automatically use the new one.

Ya know...while I think that the registry, database, and server are all
overkill in their own way...I am almost surprized that such a library has never
been written. I mean, think how many programs need to parse a config file?

(btw HAS someone written such a library? if so I have never heard of it)
-Steve


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

Re: VI reasons (was Re: Base Set: Suggested additions & removals.)

[Marcus Brinkmann]

On Wed, Jun 10, 1998 at 03:38:59PM -0400, Dale Scheetz wrote:

> If vi would fit on the rescue disk, do you think we would be discussing
> ae?
> 
> To be able to do an install with the rescue disk the space priorities
> don't allow anything but ae in that environment. When you can get vi's
> binary size down to the footprint of ae, I will be glad to replace it.
> Until then all talk of superior usability are nothing but talk. It will
> not fit.

Dale, I hope you only spoke about the link from vi to ae, but I read it that
you would not object against using vi alone on the rescue disk.

Oh, cool.

"DEBIAN: Sorry, you need a ph.d. in computer science, 10-year-experience
in unix system administration or a good handbook on the obscure "vi" program
before you can edit a file during installation process.
Don't even think of installing it."

Nice.

Marcus

-- 
"Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ 
Marcus Brinkmann   http://www.debian.orgmaster.debian.org
[EMAIL PROTECTED]for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/   PGP Key ID 36E7CD09


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

Re: VI reasons (was Re: Base Set: Suggested additions & removals.)

[Raul Miller]

Marcus Brinkmann <[EMAIL PROTECTED]> wrote:
> "DEBIAN: Sorry, you need a ph.d. in computer science, 10-year-experience
> in unix system administration or a good handbook on the obscure "vi" program
> before you can edit a file during installation process.
> Don't even think of installing it."

Er.. a command summary for vi, with enough detail to make it
as easy to use as ae, can be made to fit on one screen.

No matter what the editor is, I think that the rescue disk 
needs to announce its existence and provide a short description
(just before dropping into the shell prompt).

-- 
Raul


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

Re: VI reasons (was Re: Base Set: Suggested additions & removals.)

[Marcus Brinkmann]

On Fri, Jun 12, 1998 at 02:41:56PM -0400, Raul Miller wrote:
> Marcus Brinkmann <[EMAIL PROTECTED]> wrote:
> > "DEBIAN: Sorry, you need a ph.d. in computer science, 10-year-experience
> > in unix system administration or a good handbook on the obscure "vi" program
> > before you can edit a file during installation process.
> > Don't even think of installing it."
> 
> Er.. a command summary for vi, with enough detail to make it
> as easy to use as ae, can be made to fit on one screen.

Problem is, you'll never be able to convince a DOS user of a text editor
with different modes. Sorry, I don't think a dumb newbie should be able to
install a workstation, but he should be able to install the base system and
play with Gnome apps.

It is only wise to use the simplest editor that is available, not the one
with the most features (well, *best* solution would be to have *both*,
agreed).

> No matter what the editor is, I think that the rescue disk 
> needs to announce its existence and provide a short description
> (just before dropping into the shell prompt).

Yes.

Marcus

-- 
"Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ 
Marcus Brinkmann   http://www.debian.orgmaster.debian.org
[EMAIL PROTECTED]for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/   PGP Key ID 36E7CD09


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

About 2.0.34 not being perfect

[Yann Dirson]

"There's always one more bug"
I got it.  At least, I got one...

Adam P. Harris writes:
 > I know there were a few cyrix-specific fixes introduced in 2.0.34.
 > Maybe some of the people experiencing this problem might test it out
 > with that kernel?  That might push out to definately try to get 2.0.34
 > in for hamm release.  (Although AFAIK, it's ok to have new version of
 > boot floppies for hamm even after release date?)

Hm, be careful with 2.0.34...  I reported a nasty bug against it to
linux-kernel, which makes it MUCH MUCH more unstable for me than
2.0.33 (console crashes within a few hours).  As I did not receive any
answer to it yes, I include it so it is know on Debian (I only sent a
copy to Brandon as it's somewhat triggered under X)

-- 
Yann Dirson<[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer,
isp-email:   <[EMAIL PROTECTED]> | support Debian GNU/Linux:
debian-email:   <[EMAIL PROTECTED]> | more powerful, more stable !
http://www.mygale.org/~ydirson/ | Check 

=== Message to Kernel list
>From: Yann Dirson <[EMAIL PROTECTED]>
>To: Kernel list <[EMAIL PROTECTED]>
>CC: [EMAIL PROTECTED]
>Subject: 2.0.34 quite reproducible OOPS in con_init()
>Date: Wed, 10 Jun 1998 01:24:49 +0200 (CEST)

This OOPS occured to me twice, when under X (xdm on tty2), while ppp0
is up.  The visual symptoms are: color-palette changing, cursor
freezes, kbd unresponsive, but the system's still running behind
(packets get sent and received according to the modem's lights).

The X freeze also occurs sometimes when ppp0 is down, but then I get
no OOPS, only the "release_dev" lines (I have 3 or 4 occurences of
them, in addition to those with OOPSes).

Note it never occured during all the time I was running 2.0.33.

There is maybe an X server problem as well, but the fact that I got
2 similar OOPSes makes me think that's not all of it.

Now the OOPSes:
===
Jun  9 18:19:31 bylbo kernel: Linux version 2.0.34 ([EMAIL PROTECTED]) (gcc 
version 2.7.2.3) #1 Fri Jun 5 23:39:29 CEST 1998
[...]

Jun  9 12:24:08 bylbo kernel: registered device ppp0
Jun  9 12:32:49 bylbo kernel: Unable to handle kernel NULL pointer dereference 
at virtual address c082
Jun  9 12:32:49 bylbo kernel: current->tss.cr3 = 00db3000, %cr3 = 00db3000
Jun  9 12:32:49 bylbo kernel: *pde = 00102067
Jun  9 12:32:49 bylbo kernel: *pte = 
Jun  9 12:32:49 bylbo kernel: Oops: 
Jun  9 12:32:49 bylbo kernel: CPU:0
Jun  9 12:32:49 bylbo kernel: EIP:0010:[con_init+516/1040]
Jun  9 12:32:49 bylbo kernel: EFLAGS: 00013206
Jun  9 12:32:49 bylbo kernel: eax:    ebx:    ecx: 0010   
edx: 0301
Jun  9 12:32:49 bylbo kernel: esi:    edi: 001aabe8   ebp: 203c   
esp: 01140e24
Jun  9 12:32:49 bylbo kernel: ds: 0018   es: 0018   fs: 002b   gs: 002b   ss: 
0018
Jun  9 12:32:49 bylbo kernel: Process XF86_SVGA (pid: 215, process nr: 6, 
stackpage=0114)
Jun  9 12:32:49 bylbo kernel: Stack: 00167ad5 0124e000 010c5e00 0110ea5c 
0001  00167a30 0110ea5c
Jun  9 12:32:49 bylbo kernel:0001 010c5e00 0012f5c2 010c5e00 
00184af2 0001  0004
Jun  9 12:32:49 bylbo kernel:0110ea5c    
0012f77d 0001  0110ea5c
Jun  9 12:32:49 bylbo kernel: Call Trace: [tty_select+165/192] 
[tty_select+0/192] [check+50/144] [do_select+349/656] [sys_select+398/608] 
[read_chan+800/1888] [tty_read+177/224]
Jun  9 12:32:49 bylbo kernel:[system_call+85/124]
Jun  9 12:32:49 bylbo kernel: Code: 80 a0 82 00 00 00 7f 8b 93 b0 aa 1a 00 a1 
50 ac 1a 00 89 02
Jun  9 12:32:49 bylbo kernel: release_dev: tty2: read/write wait queue active!
Jun  9 12:32:49 bylbo kernel: ad/write wait queue active!
Jun  9 12:32:49 bylbo kernel: release_dev: tty2: read/write wait queue active!
Jun  9 12:32:49 bylbo last message repeated 156 times
Jun  9 12:32:49 bylbo kernel: ad/write wait queue active!
Jun  9 12:32:49 bylbo kernel: release_dev: tty2: read/write wait queue active!
Jun  9 12:32:50 bylbo last message repeated 234 times
[...]

Jun  9 19:08:14 bylbo kernel: registered device ppp0
Jun  9 19:10:44 bylbo kernel: Unable to handle kernel NULL pointer dereference 
at virtual address c082
Jun  9 19:10:44 bylbo kernel: current->tss.cr3 = 00a29000, %cr3 = 00a29000
Jun  9 19:10:44 bylbo kernel: *pde = 00102067
Jun  9 19:10:44 bylbo kernel: *pte = 
Jun  9 19:10:44 bylbo kernel: Oops: 
Jun  9 19:10:44 bylbo kernel: CPU:0
Jun  9 19:10:45 bylbo kernel: EIP:0010:[con_init+516/1040]
Jun  9 19:10:45 bylbo kernel: EFLAGS: 00013206
Jun  9 19:10:45 bylbo kernel: eax:    ebx:    ecx: 0010   
edx: 0301
Jun  9 19:10:45 bylbo kernel: esi:    edi: 001aabe8   ebp: 203c   
esp: 01349e24
Jun  9 19:10:45 bylbo kernel: ds: 0018   es: 0018   fs: 002b   gs: 002b   ss: 
0018
Jun  9 19:10:45 bylbo kernel: Process XF86_SVGA (pid: 239, process nr: 6, 
stackpage=01349000)
Jun  9 19:10:45 bylbo kernel: Stack: 0016

Re: RFC: packaging kernel modules

[Wichert Akkerman]

Previously Jason Gunthorpe wrote:
> That's exactly what it means. As Wichert pointed out, you need PCI for
> ALSA to work - period. If you don't want PCI then you must hack alsa.

I'll add some checking to the postinst of ALSA to check for PCI support
in the kernel and warn if it isn't there.

> I think alsa is using a fairly stable portion of the kernel interface. My
> suggestion is to compile alsa against headers with modversions enabled

Which is exactly what I'm doing. The only different thing about my kernel
is some hack in the arp-code.

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/


pgpmQMuF1N778.pgp
Description: PGP signature

Re: About 2.0.34 not being perfect

[Raul Miller]

Yann Dirson <[EMAIL PROTECTED]> wrote:
> Hm, be careful with 2.0.34...  

Sounds like it should go in extra, for now.

-- 
Raul


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

Problems with javalex

[Martin Schulze]

Hi folks,

I was trying to fix that javalex package lately but failed
constantly.  I don't speak any Java at all, this could be a reason.

I'd like to receive some help.  The program gets called with the
following command

  /usr/bin/java JavaLex.Main $*

The main problem is that there is no JavaLex.Main file.  It is not
included in the .tar.gz nor in the .diff.gz file and it isn't
generated when the program gets compiled.

As interim bugfix I have already requested javalex to be removed from
hamm.  The question now is: Do we want to keep the package in slink?

If we can't get it to work we should completely remove it.

TIA,

Joey

-- 
 / Martin Schulze  http://home.pages.de/~joey/
/ Linux - the choice of a GNU generation  [EMAIL PROTECTED] /


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

Re: About 2.0.34 not being perfect

[Miquel van Smoorenburg]

In article <[EMAIL PROTECTED]>,
Raul Miller <[EMAIL PROTECTED]> wrote:
>Yann Dirson <[EMAIL PROTECTED]> wrote:
>> Hm, be careful with 2.0.34...  
>
>Sounds like it should go in extra, for now.

OTOH our news server didn't survive longer then a day with 2.0.[0-3] and
runs rockstable with 2.0.34 ...

Mike.
-- 
 Miquel van Smoorenburg | Our vision is to speed up time,
[EMAIL PROTECTED]  |   eventually eliminating it.


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

Re: Security problem - inetd.conf has rsh/rlogin/rexec "ON" as a default

[Joel Klecker]

At 06:34 -0700 1998-06-11, Amos Shapira wrote:
>I do a lot of remote administration too (actually, almost exclusively)
>using ssh.  I know that ssh is not freely distributable with debian
>(due to the crypto limitations)

It isn't just the crypto, ssh isn't DFSG free either.
--
Joel "Espy" Klecker
Debian GNU/Linux Developer




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

Re: Intent to package: webalizer

[Joel Klecker]

At 13:39 -0700 1998-06-10, Remco van de Meent wrote:
>Hey,
>
>I'm currently applying for being a Debian maintainer (using the Debian
>Developer's Reference).
>
>I created a package of the Webalizer software:
>
>Package: webalizer
>Status: install ok installed
>Installed-Size: 108
>Maintainer: Remco van de Meent <[EMAIL PROTECTED]>
>Version: 1.12-1
>Depends: libc6, libgd1g
>Conffiles:
> /etc/webalizer.conf 0e93aac1c4ed0190911c5565630a9657
>Description: webalizer - a web server log analysis program
> The Webalizer is a web server log analysis program. It is designed to scan
> web server log files in various formats and produce usage statistics in
> HTML format for viewing through a browser.
> The Webalizer produces yearly, monthly, daily and hourly statistics. In the
> monthly reports, various statistics may be produced to show overall usage,
> usage by day and hour, usage by visiting sites, URL's, user agents
> (browsers), referrers and country. The Webalizer is highly configurable by
> use of either command line options or a configuration file, allowing the
> program to be tailored to individual needs easily.
>
>
>The homepage of this thingie is located at http://www.mrunix.net/webalizer/.
>This utility uses the GD-library, so I think the webalizer-package should go
>into non-free.

gd 1.3 is now DFSG free, and works around the patent issues too. I have
uploaded a non-maintainer release of gd to main, thus, webalizer can go in
main.

BTW, its dependence on a non-free package would have put it in contrib, not
non-free.

>If noone else is working on this one, and they're no objections, I'd like to
>"officialy" package webalizer. If you need more information, please let me
>know.

I had planned to package it, but since you have already done so, you can
have it.

Can you make the package available somewhere?
--
Joel "Espy" Klecker
Debian GNU/Linux Developer




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