How to upload to nonus.debian.org?

[Juan Cespedes]

I want to upload some packages to nonus, but I don't know how.
What's the correct way to do it?

I've tried anonymous FTP to nonus.debian.org, but I cannot
upload files to any dir...

Thanks.

-- 
Juan Cespedes


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

Re: Debian and the millenium bug

[bruce]

Remember Emerson: "A foolish consistency is the hobgoblin of small minds."

Bruce


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

Re: Debian and the millenium bug

[bruce]

> Why does glibc2 not use long long (64 bits) for dates, insead of long int
> (32 bits)?  Surely we ought to change this now along with all the other
> libc6 changes?

We have to get POSIX to bless it first. We have 40 years to do it, relax.

Bruce


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

Re: What warrants a non-maintainer release number?

[Jason Gunthorpe]

On Tue, 6 Jan 1998, Christian Schwarz wrote:

> However, the `non-maintainer' part of this discussion is totally
> unimportant. What matters is the question `in which cases has the version
> number to be incremented and in which cases can it be left'?
> 
> I think we all agree now that the version number has to be incremented
> whenever the binary package is changed on master (even in Incoming/).

There are more complex aspects to this. I was talking to Christoph today
and he mentioned that there were some cases with two different sources for
packages. A simple example is his debs.fuller.edu where a number of
experimental versions of packages are present. We also speculated that the
KDE people might have custom releases of the KDE debs on the KDE CD and so
on. We need to have some policy to prevent different .debs from having the
same version number that covers this.

For Deity at least is it VERY important that the version number of
packages be exactly associated with the .deb file, there must never be two
.debs with the same version that are not exactly the same. As soon as that
happens it is no longer possible to tell which of the .debs are installed.

Here is a possible example, for a time libc6 2.0.6 in main was was -0.1.
What is someone had put an early release on debs.fuller also using -0.1,
how is the person releasing into main to know that -0.1 is taken by the
debs.fuller ppl?
 
Jason


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

Re: Screen-refresh in vi

[bruce]

VI? You mean "elvis", "vim", or "nvi"?

Elvis seems to be somewhat flakey on hamm.

Bruce


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

Re: What warrants a non-maintainer release number?

[Remco Blaakmeer]

On Mon, 5 Jan 1998, Jason Gunthorpe wrote:

> For Deity at least is it VERY important that the version number of
> packages be exactly associated with the .deb file, there must never be two
> .debs with the same version that are not exactly the same. As soon as that
> happens it is no longer possible to tell which of the .debs are installed.

Indeed.

> Here is a possible example, for a time libc6 2.0.6 in main was was -0.1.
> What is someone had put an early release on debs.fuller also using -0.1,
> how is the person releasing into main to know that -0.1 is taken by the
> debs.fuller ppl?

There has been some discussion about other people supplying .deb's on this
list before. I think the general opinion was "let the others take care of
not conflicting with us". So, the people on debs.fuller should make sure
that the version numbers they use will not be taken by 'official' .deb
packages. I suggest using numbers like -0.0.1, depending on what kind of
version numbers are used by the package.

Remco


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

Re: What's Debian's /usr/src policy

[Fabrizio Polacco]

On  5 Jan, Christian Schwarz wrote:
> On Mon, 5 Jan 1998, Ian Jackson wrote:
> 
>> I think that /usr/src should the be domain of the local admin.
> 

I disagree.
/usr/local/src is for local admin.


>> This may be the case if you look at all packages, but I have never
>> installed any packages that did this, and if I had I would have
>> reported it as a bug.
> 
> A few packages currently install into /usr/src: awe-drv, debian-cd, etc. 

add liblockdev0g-dbg and libdb2-dbg to that list.
I recently managed to add some sources in my -dbg shared lib packages,
to make them easily debuggable. (See bug#16038 on 30 Dec)


Fabrizio
-- 
| [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
| Pluto Leader - Debian Developer & Happy Debian 1.3.1 User - vi-holic
| 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E
> Just because Red Hat do it doesn't mean it's a good idea. [Ian J.]


pgpJd15FBTjm3.pgp
Description: PGP signature

Re: What's Debian's /usr/src policy

[Remco Blaakmeer]

On Tue, 6 Jan 1998, Fabrizio Polacco wrote:

> On  5 Jan, Christian Schwarz wrote:
> > On Mon, 5 Jan 1998, Ian Jackson wrote:
> > 
> >> I think that /usr/src should the be domain of the local admin.
> > 
> 
> I disagree.
> /usr/local/src is for local admin.

Indeed. In general:

- /usr/local is for the local admin
- the rest of /usr is for the OS vendor

Remco
-- 
If you can't beat your computer at chess, try kick-boxing


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

Re: What's Debian's /usr/src policy

[Vincent Renardias]

On Tue, 6 Jan 1998, Remco Blaakmeer wrote:

> On Tue, 6 Jan 1998, Fabrizio Polacco wrote:
> 
> > On  5 Jan, Christian Schwarz wrote:
> > > On Mon, 5 Jan 1998, Ian Jackson wrote:
> > > 
> > >> I think that /usr/src should the be domain of the local admin.
> > > 
> > 
> > I disagree.
> > /usr/local/src is for local admin.
> 
> Indeed. In general:
> 
> - /usr/local is for the local admin
> - the rest of /usr is for the OS vendor



Seconded.



--
- Vincent RENARDIAS [EMAIL PROTECTED],pipo.com,debian.org} -
- Debian/GNU Linux:   Pipo:WAW:   -
- http://www.fr.debian.orghttp://www.pipo.com  http://www.waw.com -
---
- "La fonctionnalite Son Visuel vous delivre des avertissements visuels." -
-  [Message durant l'installation de Windows95] :wq


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

Re: What warrants a non-maintainer release number?

[Fabrizio Polacco]

On  6 Jan, Remco Blaakmeer wrote:
> 
> I think the general opinion was "let the others take care of
> not conflicting with us". So, the people on debs.fuller should make sure
> that the version numbers they use will not be taken by 'official' .deb
> packages.

This sounds nonsense.

People at deb.somewhere will not care at all of our policies and package
as they like (as KDE is doing); Debian's maintainer will get the
complaints.

You cannot expect that the _others_ will do in the right way.
Ask Murphy.


Fabrizio
-- 
| [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
| Pluto Leader - Debian Developer & Happy Debian 1.3.1 User - vi-holic
| 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E
> Just because Red Hat do it doesn't mean it's a good idea. [Ian J.]


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

Re: Debian and the millenium bug

[Mark W. Eichin]

> Where did you get this 4000 years figure anyway?  33 bits would just

Oh, having become hopelessly confused by the original posting, I came
up with some additional errors (the 16x10^18 is just as wrong, too;
584,942,417,355 is more like it...)  Comes of posting to debian lists
in my sleep :-)


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

Re: libc6 based gpc

[Christoph Lameter]

No. Someone else will probably do so. I am not using pascal at all right
now.

On Mon, 5 Jan 1998, Paolo M. Pumilia wrote:

> Hi Christoph Lameter,
> I am switching my linux system to hamm. 
> Since gcc upgraded to 2.7.2.3, it seems i cannot use
> my old gpc compiler any more. Do you plan to package a new gpc
> release based on libc6 and compatible with gcc  2.7.2.3-3 ?
> Thank you
> Paolo Pumilia
> 
> --- CSTC -
> 
> 


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

Re: How to upload to nonus.debian.org?

[Martin Schulze]

On Tue, Jan 06, 1998 at 01:23:34AM +0100, Juan Cespedes wrote:
>   I want to upload some packages to nonus, but I don't know how.
> What's the correct way to do it?
> 
>   I've tried anonymous FTP to nonus.debian.org, but I cannot
> upload files to any dir...

Why not try debian-incoming?  At least it looks like the incoming
directory for Debian for my.

Regards

Joey

-- 
  / Martin Schulze  *  [EMAIL PROTECTED]  *  26129 Oldenburg /
 /Erfahrung ist eine nützliche Sache /
/ Leider macht man sie immer erst kurz nachdem man sie brauchte /


pgpMuMCFulhlN.pgp
Description: PGP signature

Re: Debian and the millenium bug

[James A . Treacy]

> > Where did you get this 4000 years figure anyway?  33 bits would just
> 
> Oh, having become hopelessly confused by the original posting, I came
> up with some additional errors (the 16x10^18 is just as wrong, too;
> 584,942,417,355 is more like it...)  Comes of posting to debian lists
> in my sleep :-)
> 
I got

292,271,023,017 years ~=
 ( 2^62 / (60sec/min) / (60min/hr) / (24hr/day) / (365.25day/yr) -
 (28 year since 1970)

It only has 5 digits of accuracy at best, but that's what I put on the
web page (news.html). :)

- Jay


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

Re: cron jobs more often than daily

[Steve Greenland]

Kai is absolutely correct in his justification of the policy:

> Umm. There's a good reason for not automatically modifying conffiles,  
> ever: "... was modified by you or by a script ..."
> 
> The general rule, AFAIR, is for a file to _either_ be a conffile, or  
> _completely_ handled by scripts, and never the twain shall meet.

To reiterate: if a file is listed as a conffile by dpkg, then *any*
modification is going to cause dpkg to notify you when the distributed
version of the file changes. It doesn't matter if the mod was done by a
script provided by the package.

I agree that there seems to be a need for general solution. There are
two general approaches:

1. Extend the current model of providing directories and using
run-parts. This is the most straightforward, but leads to
questions about how fine a granularity to provide (I'm thinking
5m,10m,15m,20m,30m,1h,2h,6h,12h) and is kind of ugly in terms having
a pile of directories around. I could easily convince myself to put
them all under cron.scripts/, although it leaves cron.{daily,
weekly, monthly} hanging out in the breeze. I'd probably softlink
cron.scripts/daily -> cron.daily, and so on.

Advantages: Easy to do, consistent with current policy and practice.
Only packages that have to be modified are cron and packages that are
currently in violation of policy.

Disadvantages: Limited control by packages over granularity, offset, and
user. (I'm not convinced that this is a real showstopper: if the package
*really* requires that fine of control, it probably needs a custom user
anyway.)

2. /etc/crontab is no longer a dpkg conffile, but is built by calls to
a script (for debian packages) or editing (for sysadmins). Probably
it's marked into two sections: one for sysadmin customization, one for
update-crontab's playground. I have a lot misgivings about what could go
wrong if the sysadmin messes with the playground.

Advantages: packages have complete control over cron scheduling.
Everything is actually in /etc/crontab, which is probably what most
(debian) newcomers expect. Packages could add comments, arguments to
scripts.

Disadvantages: Every package that currently uses cron.{daily,...} has to
be modified (not immediately, perhaps, but eventually: you don't want
both schemes). What about packages that don't rely on cron, but can
use it: if cron is installed after that package, it's too late, they
won't be in the crontab. Upgrade from the current situation is tricky,
although not so bad if we say that packages that currently violate
policy by modifying /etc/crontab are screwed.

Also, how does all of this affect anacron? (now that they're finally
playing well together, it would be a shame to screw them up...)

As cron maintainer, right now I'm leaning towards 1), mostly because
it's the least disturbance to a working system. If we were starting from
scratch, I'd probably prefer 2), but I also believe the update-crontab
script is going to require more thought than most people think

steve

-- 
Steve Greenland


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

Re: cron jobs more often than daily

[Lindsay Allen]

On Mon, 5 Jan 1998, Christian Schwarz wrote:

> Fact is, that the "cron" package, the local sysadmin, and possibly other
> packages modify the /etc/crontab file. However, dpkg only controls
> modification between the sysadmin and _one_ package ("cron" here). I
> really think the cron package should provide a script where other packages
> can register cron jobs.
> 
> I'll file a bug report.

Could the crontab file be made to source another file which could contain
all the changes?

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lindsay Allen   <[EMAIL PROTECTED]>  Perth, Western Australia
voice +61 8 9316 248632.0125S 115.8445Evk6lj  Debian Unix
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=



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

Re: please upgrade your packages to current standards

[Sten Anderson]

Christian Schwarz <[EMAIL PROTECTED]> writes:

> Yesterday, I wrote a script that scans our whole archive for .dsc files
> (Debian source package description files) and outputs some statistics
> regarding the `Standards-Version' fields, that is, which policy version
> the packages "claim" to comply with (according to the maintainer).

Now you are at it, I suggest that you also scan the archive for packages 
that fails to include a "Section" and/or "Priority" field. It is far
too many, and it is quite annoying.

- Sten Anderson 







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

Re: cron jobs more often than daily

[Hamish Moffatt]

On Mon, Jan 05, 1998 at 09:12:23AM -0600, Nathan E Norman wrote:
> On Mon, 5 Jan 1998, Hamish Moffatt wrote:
> :  Packages may not touch the configuration file `/etc/crontab', nor may
> :  they modify the files in `/var/spool/cron/crontabs'.
> : 
> : Doesn't this rule this out?
> 
> The mrtg package in hamm adds an entry to /etc/crontab; it also places
> comments around the entry to aid future removal, I suppose.  This may
> violate policy (I don't know), but it does show that other packages are
> doing this.

Actually, you're not allowed to modify other configuration
files at all, Christian points out. So mrtg can't edit /etc/crontab,
mgetty-fax shouldn't edit it either, mgetty shouldn't edit
/etc/inittab, etc.


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 FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: cron jobs more often than daily

[Hamish Moffatt]

On Mon, Jan 05, 1998 at 09:45:39PM +0100, Torsten Landschoff wrote:
> What about a kind of tag-oriented style of appending to /etc/crontab after
> asking the admin:
> 
> ipac-install suggest to append an entry to /etc/crontab, which starts ipac
> every 15 minutes:
> 
> [line to be inserted]
> 
> The lines will be enclosed by # -*- install: ipac -*-.
> 
> This way a remove script will be able to remove the lines which were
> inserted by install. 

That is the best way to do it (and the way debstd does it
automatically), but the problem is that it is illegal under policy
however you do it.


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 FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: What's Debian's /usr/src policy

[Hamish Moffatt]

On Mon, Jan 05, 1998 at 05:48:27PM -0500, Dale Scheetz wrote:
> I never understood why the kernel source was made into a .deb package. It

Because it's something we expect people will want to recompile,
so we should make it readily available to them.

> doesn't make sense to me. I also don't see any point in "managing" a
> binary package of the kernel either. The system doesn't gain anything by
> having dpkg know which kernel binaries are installed either. The binary
> thus installed still needs to be configured for lilo or loadlin or grub,
> so what's the point?

I think it does gain something; it is much easier to have multiple
versions around. If I compile a new 2.1 kernel and find that
it is not too good (like 2.1.76 seems to have broken sound
for me so I went back to 2.1.72), I can just reinstall the old
one with dpkg. I don't need to edit my lilo config, play with
symlinks in / etc.


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 FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: What's Debian's /usr/src policy

[Hamish Moffatt]

On Mon, Jan 05, 1998 at 11:54:14AM -0800, Stephen Zander wrote:
> Martin Mitchell <[EMAIL PROTECTED]> writes:
> > Ian Jackson <[EMAIL PROTECTED]> writes:
> > > Why does libc6 depend on kernel-header ?
> > 
> > It's libc6-dev that has that dependency.
> > Perhaps weakening the dependency to Suggests might be the best solution.
> 
> No, you can't.  Their are multiple header files that will be flat *broken*
> without a /usr/include/{linux,asm}.

So the required kernel-headers package installs the headers
into /usr/include/{linux,asm}? I thought that they always installed
the headers in /usr/src/kernel-headers-x.x.x. Unless the dreaded
symlinks from /usr/include are back?


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 FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: What's Debian's /usr/src policy

[Martin Mitchell]

Stephen Zander <[EMAIL PROTECTED]> writes:

> Martin Mitchell <[EMAIL PROTECTED]> writes:
> > Ian Jackson <[EMAIL PROTECTED]> writes:
> > > Why does libc6 depend on kernel-header ?
> > 
> > It's libc6-dev that has that dependency.
> > Perhaps weakening the dependency to Suggests might be the best solution.
> 
> No, you can't.  Their are multiple header files that will be flat *broken*
> without a /usr/include/{linux,asm}.

I know, however it would allow people to much more easily install and
maintain their own kernel sources for these includes.

Martin.


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

Re: cron jobs more often than daily

[Rob Browning]

Steve Greenland <[EMAIL PROTECTED]> writes:

> I agree that there seems to be a need for general solution. There are
> two general approaches:

This might be completely off base, but what about a (hopefully small)
hack to cron for debian systems that makes it concatenate
/etc/cron.debian/* with /etc/crontab everytime it would have just
loaded /etc/crontab.  Then packages would just have to put crontab
snippets into /etc/crontab.debian/.  If stat-ing all these files is
too much work for cron every minute, then just have update-crontab
concatenate them into one file, say /etc/crontab.debian/cron.  Then
there are only two files to stat.

Something like

  if [ -x /usr/bin/update-crontab ] ; then update-crontab ; fi

would be used in each package's postinst to make sure things are OK if
cron's not installed.

An alternate idea, which I thought of first, but probably won't work,
was to create a user called debcron or something, then have files like
menu's /usr/lib/menu files which are used to build debcron's crontab.
The problem with that would be that I can't see any easy way to make
the tasks run as the appropriate user.

This latter approach is just another case of the more general
mechanism that Guy outlined eariler.

-- 
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94  53 2B 97 F5 D6 4E 39 30


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

boot-floppies progress

[Bruce Perens]

I just finished patching "newt" so that "whiptail" works as a complete
replacement for "dialog", using s-lang instead of ncurses. I had to hack
"modconf" slightly (because it used leading "-" in menus, and that won't
parse), but it now works with "whiptail". We now have all of the boot-floppy
components working with s-lang, but we have not yet assembled the floppy.

Bruce
--
Balance the U.S. budget! - NO tax cuts until the deficit's gone.


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

Re: boot-floppies progress

[Ben Gertzfield]

> "Bruce" == Bruce Perens <[EMAIL PROTECTED]> writes:

Bruce> I just finished patching "newt" so that "whiptail" works as
Bruce> a complete replacement for "dialog", using s-lang instead
Bruce> of ncurses. I had to hack "modconf" slightly (because it
Bruce> used leading "-" in menus, and that won't parse), but it
Bruce> now works with "whiptail". We now have all of the
Bruce> boot-floppy components working with s-lang, but we have not
Bruce> yet assembled the floppy.

I'm extremely interested in this; does "whiptail" use a more decent
way of returning the data selected by the user than dialog did? I did
some work on re-writing the network config tool, but got lost in a
twisty maze of return values and stderr output.

-- 
Brought to you by the letters B and A and the number 8.
"XTC versus Adam Ant -- which one will survive?" -- They Might Be Giants
Ben Gertzfield  Finger me for my public
PGP key. I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox.


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

Re: cron jobs more often than daily

[Joey Hess]

Steve Greenland wrote:
> Disadvantages: Limited control by packages over granularity, offset, and
> user. (I'm not convinced that this is a real showstopper: if the package
> *really* requires that fine of control, it probably needs a custom user
> anyway.)

Another disadvantage is that this would lead to run-parts running evey
5 minutes and wasting some cpu time, even if there were no 5 minute 
granularity cron jobs installed on the system.

-- 
see shy jo


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

Re[2]: cron jobs more often than daily

[Adam Heath]

| On Tuesday, 6 January 98, at 2:28:26 AM
| Joey wrote about "cron jobs more often than daily"
> Steve Greenland wrote:
>> Disadvantages: Limited control by packages over granularity, offset, and
>> user. (I'm not convinced that this is a real showstopper: if the package
>> *really* requires that fine of control, it probably needs a custom user
>> anyway.)

> Another disadvantage is that this would lead to run-parts running evey
> 5 minutes and wasting some cpu time, even if there were no 5 minute 
> granularity cron jobs installed on the system.

Or:

Have a directory, /etc/debian.crontab/, that holds a file for every package that
wants to be run by cron.  Modify /etc/cron.tab(in the master version), to have a
line that runs /etc/init.d/debian.cron.  Have a script, update-debian-crontab,
that when called to add a new /etc/debian.crontab/package, updates
/etc/init.d/debian.cron to run the package that would next need to be.
Everytime that /etc/init.d/debian.cron is run, it checks to see when the next
package is to be run, and updates itself, and /etc/cron.tab.

Does anyone understand what I am trying to accomplish here?  Each time
/etc/init.d/debian.cron runs, it modifies /etc/cron.tab, changing the time that
it will next be run at.  This might be better handled with some type of alarm
program, that will exec another program at a specific time, instead of every so
often.


Why do keyboards get replaced?  Because people run Windows, and they can't hit 
Bill!

Adam Heath of Borg-Linux [EMAIL PROTECTED] Join the H.323 effort.  Email
http://www.debian.org - Get Your Own Linux! [EMAIL PROTECTED] with
http://wwp.mirabilis.com/3375265 - Page Me  the word subscribe in the body.


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

Webmin .. ?

[pb]

Hello,
I ran across something very cool the other day -- Webmin
(http://www.webmin.com/webmin/).  It's a web-based system management
tool, which is capable of doing things like cron jobs and DNS administration.
The developer has a version for Debian, and I think it would make a great
addition to make Debian more "user friendly" .. optional, of course. ;)

I   I'm not sure if it's GPL'd, but if it is, I'd be interested in taking
a shot at maintaining a package for it.  The only problem is my rather unstable
living situtation right now .. but that will be over with in a few months.

Cheers,
Peat


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

Re: Re[2]: cron jobs more often than daily

[Hamish Moffatt]

On Tue, Jan 06, 1998 at 02:51:52AM -0500, Adam Heath wrote:
> /etc/init.d/debian.cron to run the package that would next need to be.
> Everytime that /etc/init.d/debian.cron is run, it checks to see when the next
> package is to be run, and updates itself, and /etc/cron.tab.
> 
> Does anyone understand what I am trying to accomplish here?  Each time
> /etc/init.d/debian.cron runs, it modifies /etc/cron.tab, changing the time 
> that
> it will next be run at.  This might be better handled with some type of alarm
> program, that will exec another program at a specific time, instead of every 
> so
> often.

Sounds like `at' to me. So I could schedule my thing to run every
15 minutes with at, but I think that the sysadmin probably assumes
that standard system tasks will not be run through at, but by cron.
at has an atd, probably because it wasn't allowed to add atrun to
crontab :-)


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 FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: What's Debian's /usr/src policy

[Joel Klecker]

-BEGIN PGP SIGNED MESSAGE-

Regarding "Re: What's Debian's /usr/src policy" of 8:09 PM -0800 1/5/98,
Hamish Moffatt wrote:
>On Mon, Jan 05, 1998 at 11:54:14AM -0800, Stephen Zander wrote:
>> Martin Mitchell <[EMAIL PROTECTED]> writes:
>> > Ian Jackson <[EMAIL PROTECTED]> writes:
>> > > Why does libc6 depend on kernel-header ?
>> >
>> > It's libc6-dev that has that dependency.
>> > Perhaps weakening the dependency to Suggests might be the best solution.
>>
>> No, you can't.  Their are multiple header files that will be flat *broken*
>> without a /usr/include/{linux,asm}.
>
>So the required kernel-headers package installs the headers
>into /usr/include/{linux,asm}?

No, the kernel-{headers,source}-x.x.x packages install into
/usr/src/kernel-{headers,source}-x.x.x, with linux-x.x.x symlinked to it,
libc6-dev has /usr/include/{linux,asm} symlinked to
/usr/src/linux-2.0.32/include/{linux,asm}.

- --
Joel "Espy" Klecker Debian GNU/Linux Developer



-BEGIN PGP SIGNATURE-
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQCVAwUBNLH0UQoYIlYX1XaBAQHZYgP+LX5yFstGOa3ewpzEPkZMdMy7X82LV2Yv
JZrymaocQ6CIjdrWPqFuP09ikzkEwqi5IMA2/6sXxknzfpalxSrYF3pWL3GPJvXo
rHe1E3IZemRpgsmNaetjF+89h/mJPEWRbI9ZV/DzxghNraraopncWOhc5Ydp51YO
XFuD05yEPho=
=EaEy
-END PGP SIGNATURE-


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

Re: Re[2]: cron jobs more often than daily

[Paul Slootman]

On Tue 06 Jan 1998, Adam Heath wrote:
> 
> Have a directory, /etc/debian.crontab/, that holds a file for every package 
> that
> wants to be run by cron.  Modify /etc/cron.tab(in the master version), to 
> have a
> line that runs /etc/init.d/debian.cron.  Have a script, update-debian-crontab,
> that when called to add a new /etc/debian.crontab/package, updates
> /etc/init.d/debian.cron to run the package that would next need to be.
> Everytime that /etc/init.d/debian.cron is run, it checks to see when the next
> package is to be run, and updates itself, and /etc/cron.tab.

Why not require packages that need this level of control over cron jobs
to register a user, so that a user-specific crontab (in
/var/spool/cron/crontabs) can be installed, e.g. with "crontab -u
package file" ?



Paul Slootman
-- 
Can you get your operating system fixed when you need it?
Linux - the supportable operating system. http://www.debian.org/support.html
home: [EMAIL PROTECTED] | work: [EMAIL PROTECTED]
http://www.wurtel.demon.nl | Murphy Software, Enschede, the Netherlands


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

[Fwd: Bug#16660: metro-motif-aout: depends on xcompat which is in project/orphaned]

[ychim]

[EMAIL PROTECTED] wrote:
> 
> Package: metro-motif-aout
> 
> Depends on xcompat which does not exist?

metro-motif-aout is an installer only and it does requires the x11 aout
libs from xcompat.

I think I can't do anything.

-- 
Lawrence--- Begin Message ---
Package: metro-motif-aout

Depends on xcompat which does not exist?


--- End Message ---

Re: Question/request concerning master

[jdassen]

On Mon, Jan 05, 1998 at 11:33:25PM +0200, Amos Shapira wrote:
> I might be missing something here, but after being beaten by crackers who
> simply put a password sniffer on one of my Debian machines, I'd strongly
> recommand the Debian leaders to reconsider the policy of plain ftp and
> telnet.  In the least you should consider using SSLtelnet and SSLftp, if
> you insist on an alternative for ssh.

Maybe you should ask for SSLftp (and SSLftpd) to be added to the list of
needed packages? (or maybe even SSL patches for the comfortable FTP clients
like ncftp).

> I'd also like to recommand that all passwords on master shall be replaced
> if and when you disable plain ftp and telnet.

As a purely practical point: I dislike having to type my passphrase or
password for every file I'm uploading. Heiko, can dupload be changed to
upload all files with one "scp" when using SSH to upload?

Ray
-- 
Cyberspace, a final frontier. These are the voyages of my messages, 
on a lightspeed mission to explore strange new systems and to boldly go
where no data has gone before. 


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

Re: Re[2]: cron jobs more often than daily

[Hamish Moffatt]

On Tue, Jan 06, 1998 at 10:57:48AM +0100, Paul Slootman wrote:
> Why not require packages that need this level of control over cron jobs
> to register a user, so that a user-specific crontab (in
> /var/spool/cron/crontabs) can be installed, e.g. with "crontab -u
> package file" ?

Because sometimes the jobs need to run as root. Quite often I suspect.
My package ipac (which started this) needs to run ipfwadm to configure
and reset the IP accounting rules, which requires root.

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 FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: How to upload to nonus.debian.org?

[Sven Rudolph]

Juan Cespedes <[EMAIL PROTECTED]> writes:

>   I want to upload some packages to nonus, but I don't know how.
> What's the correct way to do it?
>
>   I've tried anonymous FTP to nonus.debian.org, but I cannot
> upload files to any dir...

/pub/debian-non-US/Incoming

Sven
-- 
Sven Rudolph <[EMAIL PROTECTED]>
http://www.sax.de/~sr1/


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

Re: [Fwd: Bug#16660: metro-motif-aout: depends on xcompat which is in project/orphaned]

[Hamish Moffatt]

On Tue, Jan 06, 1998 at 09:11:12PM +1100, [EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
> > Package: metro-motif-aout
> > Depends on xcompat which does not exist?
> 
> metro-motif-aout is an installer only and it does requires the x11 aout
> libs from xcompat.
> 
> I think I can't do anything.

I think Guy intended to move all packages that don't have source
to project/orphaned. So libc4 and xcompat, among others, moved.
If libc4 and xcompat are to remain in project/orphaned,
perhaps you could upload metro-motif-aout with section
project/orphaned, or file/reassign a bug to ftp.debian.org
to get the package moved.

However libc4 & xcompat might move back, there has been
some discussion on debian-devel in support of that.


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 FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

RE: driver for Epson Stylus 300

[Meskes, Michael]

Yes, I could try that. Can the 600 use color and black ink at the same
time?

Also would you mind sending me your gs setup? I'm not sure about
uniprint but the stcolor driver usage in magicfilter is outdated, i.e.
it uses options no longer avalaible in gs-aladin. Or is that no problem
with uniprint?

Michael

--
Dr. Michael Meskes, Project-Manager| topsystem Systemhaus GmbH
[EMAIL PROTECTED]| Europark A2, Adenauerstr. 20
[EMAIL PROTECTED]  | 52146 Wuerselen
Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux!  | Fax: (+49) 2405/4670-10

> -Original Message-
> From: James A. Treacy [SMTP:[EMAIL PROTECTED]
> Sent: Monday, January 05, 1998 5:48 PM
> To:   [EMAIL PROTECTED]
> Cc:   debian-devel@lists.debian.org
> Subject:  Re: driver for Epson Stylus 300
> 
> > Does anyone know if there is a ghostscript driver for this new
> printer
> > available? Yes, I can use the other Stylus drivers, but that means
> the
> > printer tries to print black by mixing the other three colors, not
> by using
> > the black ink.
> >
> There may be another way, but you can by installing gs-aladin. In
> 5.0.3
> there is a new driver (called uniprint) which works great. I'm using
> it
> with my Stylus Color 600.
> 
> - Jay


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

Re: What warrants a non-maintainer release number?

[Christian Schwarz]

On Mon, 5 Jan 1998, Jason Gunthorpe wrote:

> On Tue, 6 Jan 1998, Christian Schwarz wrote:
> 
> > However, the `non-maintainer' part of this discussion is totally
> > unimportant. What matters is the question `in which cases has the version
> > number to be incremented and in which cases can it be left'?
> > 
> > I think we all agree now that the version number has to be incremented
> > whenever the binary package is changed on master (even in Incoming/).
> 
> There are more complex aspects to this. I was talking to Christoph today
> and he mentioned that there were some cases with two different sources for
> packages. A simple example is his debs.fuller.edu where a number of
> experimental versions of packages are present. We also speculated that the
> KDE people might have custom releases of the KDE debs on the KDE CD and so
> on. We need to have some policy to prevent different .debs from having the
> same version number that covers this.

Yes, this is another important issue. A possible solution to this has been
presented in the recent KDE-virtual-package discussion on debian-policy:
Each .deb should carry a new control field called "Origin:" or
"Distributor:" or something like that. For example, all Debian packages
would have "Origin: SPI". 

This has to be combined with digital signatures on the packages so
that noone else can put out an "Origin: SPI" package. 

With that, our package tools (dpkg, deity, etc.) could check for possible
problems when packages from different sources are mixed.

(Telling non-Debian people how which version numbers to use will
definitely not work.)


Thanks,

Chris

--  Christian Schwarz
 [EMAIL PROTECTED], [EMAIL PROTECTED],
Debian has a logo![EMAIL PROTECTED], [EMAIL PROTECTED]

Check out the logo PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
pages at  http://fatman.mathematik.tu-muenchen.de/~schwarz/debian-logo/


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

Re: cron jobs more often than daily

[Christian Schwarz]

I currently see three practical solutions out of the dilemma (that
/etc/crontab is edited by the sysadmin and scripts): 

  (a) We set up another crontab (say /etc/crontab.deb) which is maintained
  by install-cronjob only. The current /etc/crontab will stay a
  conffile and only be touched by the sysadmin.

  Disadvantage: The sysadmin might want to remove (or change) an entry 
  of /etc/crontab.deb too, so we didn't solve any problems.

  (b) We set up a certain directory (say /usr/lib/cronjobs) where each
  package can install its own crontab file (/usr/lib/cronjobs/foo).

  Disadvantage: See above.

  (c) We split /etc/crontab into two "areas". The install-cronjob script
  will only touch one area, while the sysadmin can touch both. For
  example:

  # /etc/crontab
  # Sysadmin's private area: Do whatever you like to do here.
  # Nothing will be changed automatically...
  * * * * *  root  rm -rf /
  # (I hope noone installs this crontab :)
  # --
  # automatic area: You can do changes to this area, but packages
  # might add or remove new entries via install-cronjob
  # ---entry from package foo1---
  * * * * *  root  something
  # ---entry from package foo2---
  

  This keep all cronjobs in a single file which makes life easier for
  the sysadmin, I think.

  Note, that the install-cronjob script should be smart enough to
  handle commented-out cron entries correctly (they should stay
  commented-out during package upgrades).


Comments?


Thanks,

Chris

--  Christian Schwarz
 [EMAIL PROTECTED], [EMAIL PROTECTED],
Debian has a logo![EMAIL PROTECTED], [EMAIL PROTECTED]

Check out the logo PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
pages at  http://fatman.mathematik.tu-muenchen.de/~schwarz/debian-logo/


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

auto-pgp

[Michael Meskes]

Is auto-pgp still an active package? Or is it as outdated as it seems to be.
That means it is the only package on my machine that still has an AOUT
binary.

Michael
-- 
Dr. Michael Meskes, Project-Manager| topsystem Systemhaus GmbH
[EMAIL PROTECTED]| Europark A2, Adenauerstr. 20
[EMAIL PROTECTED]  | 52146 Wuerselen
Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux!  | Fax: (+49) 2405/4670-10


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

Re: What's Debian's /usr/src policy

[Kai Henningsen]

[EMAIL PROTECTED] (Martin Mitchell)  wrote on 06.01.98 in <[EMAIL PROTECTED]>:

> Stephen Zander <[EMAIL PROTECTED]> writes:
>
> > Martin Mitchell <[EMAIL PROTECTED]> writes:
> > > Ian Jackson <[EMAIL PROTECTED]> writes:
> > > > Why does libc6 depend on kernel-header ?
> > >
> > > It's libc6-dev that has that dependency.
> > > Perhaps weakening the dependency to Suggests might be the best solution.
> >
> > No, you can't.  Their are multiple header files that will be flat *broken*
> > without a /usr/include/{linux,asm}.
>
> I know, however it would allow people to much more easily install and
> maintain their own kernel sources for these includes.

Which is why we shouldn't do that. Remember, we *DO NOT* want them to  
include their own kernel sources for these includes, because it is a *VERY  
BAD IDEA*.


MfG Kai


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

Re: What's Debian's /usr/src policy

[Kai Henningsen]

[EMAIL PROTECTED] (Dale Scheetz)  wrote on 05.01.98 in <[EMAIL PROTECTED]>:

> On Mon, 5 Jan 1998, Ian Jackson wrote:
>
> > I think that /usr/src should the be domain of the local admin.
> >
> > I don't think kernel-{header,source}-x.xx.deb should exist, really,
> > because I don't think source code should be distributed as .deb files
> > anyway.  So I'm not unhappy about making a policy decision that leaves
> > kernel-{header,source} with nowhere good to go.
>
> I never understood why the kernel source was made into a .deb package. It
> doesn't make sense to me. I also don't see any point in "managing" a
> binary package of the kernel either. The system doesn't gain anything by
> having dpkg know which kernel binaries are installed either. The binary
> thus installed still needs to be configured for lilo or loadlin or grub,
> so what's the point?

Well, handling kernels with kernel-package is _a_lot_ easier than doing it  
by hand. I've done both, and I don't want to go back, ever.

> > Why does libc6 depend on kernel-header ?
>
> I don't know either, but it is on the top of my list of things I need to
> understand as the new maintainer. It was my understanding that the way we
> deal with kernel headers was supposed to free the c library from the
> headers. I don't know that anything has changed in that reguard. I'll let
> you know what I find asap.

I think our main problem here is that people (including both you and Ian)  
don't keep on top of debian-private and debian-devel. I can't count the  
times this has been explained already, and I get very, very tired of it.

libc6 depends on a specific version of kernel-headers to avoid including  
what is in that package as a diff. Nothing more, nothing less.


MfG Kai


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

Re: Debian and the millenium bug

[Kai Henningsen]

[EMAIL PROTECTED]  wrote on 05.01.98 in <[EMAIL PROTECTED]>:

> Well, there is a problem with the Gregorian calendar that has to be dealt
> with in 2000 years or so (having to do with leap-millenia), but I figure
> if it's more than 100 years it's no problem.

That depends on what you call a problem.

The Gregorian year amounts to 365.2425 days on average, whereas the  
astronomical one is 365.2422 days. That's a difference of 0.0003 days per  
year, or approximately one day every 3000 years. (Incidentally, did you  
know that this works out so weekdays are exactly the same every 400  
years?)

Remember that the last calendar reform was made at an actual difference of  
about 10 days (and some countries took a long time after that to implement  
it, thus increasing the difference even more), so I'd expect people won't  
touch that until the difference is again in that ballpark - around AD  
31000-32000, that is. And even that will only happen if enough people will  
still be interested in the relation of this calendar to the Christian  
faith at that time - which I personally doubt, frankly.


MfG Kai


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

Re: What warrants a non-maintainer release number?

[Kai Henningsen]

[EMAIL PROTECTED] (Fabrizio Polacco)  wrote on 06.01.98 in <[EMAIL PROTECTED]>:

> On  6 Jan, Remco Blaakmeer wrote:
> >
> > I think the general opinion was "let the others take care of
> > not conflicting with us". So, the people on debs.fuller should make sure
> > that the version numbers they use will not be taken by 'official' .deb
> > packages.
>
> This sounds nonsense.

It's the only option we have.

> People at deb.somewhere will not care at all of our policies and package
> as they like (as KDE is doing); Debian's maintainer will get the
> complaints.
>
> You cannot expect that the _others_ will do in the right way.
> Ask Murphy.

And no policy of ours can possibly change that, so we might as well just  
give up on that idea.

We manage our version numbers, and as far as the project is concerned, non- 
project .debs are in no way a responsibility of the project.

We might suggest ways to keep those numbers distinct to other people, but  
as we can't enforce that, we shouldn't even try. Simple example: someone  
grabs a source package and rebuilds it without any changes. He will now  
have a different .deb (and it _will_ be different - different time stamps,  
maybe he used a different gcc, different debmake version ...) with the  
exact same version number as the original.

Just close bug reports referring to non-project .debs with "not our  
package, not our problem". And maybe work on an official bug report tool  
with some chance of announcing who built that package (might need some  
support in dpkg-dev).


MfG Kai


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

Re: Question/request concerning master

[James Troup]

[EMAIL PROTECTED] writes:

> Heiko, can dupload be changed to upload all files with one "scp"
> when using SSH to upload?

See #13383.

-- 
James


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

Re: Re[2]: cron jobs more often than daily

[Paul Slootman]

On Tue 06 Jan 1998, Hamish Moffatt wrote:
> On Tue, Jan 06, 1998 at 10:57:48AM +0100, Paul Slootman wrote:

> > Why not require packages that need this level of control over cron jobs
> > to register a user, so that a user-specific crontab (in
> > /var/spool/cron/crontabs) can be installed, e.g. with "crontab -u
> > package file" ?
> 
> Because sometimes the jobs need to run as root. Quite often I suspect.
> My package ipac (which started this) needs to run ipfwadm to configure
> and reset the IP accounting rules, which requires root.

Ah, that's quite a good reason.

The mechanism involved in scanning for users' crontabs could be
used to implement what Christian has proposed: using something like
/usr/lib/cronjobs which would contain package-specific crontabs.

In that scheme, is the user id under which the jobs are to be run
configurable in any way? I'd says that not all such jobs would need to
be run as root, and minimizing the number of root jobs helps to prevent
security trouble.


Paul Slootman
-- 
Can you get your operating system fixed when you need it?
Linux - the supportable operating system. http://www.debian.org/support.html
home: [EMAIL PROTECTED] | work: [EMAIL PROTECTED]
http://www.wurtel.demon.nl | Murphy Software, Enschede, the Netherlands


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

Re: cron jobs more often than daily

[Hamish Moffatt]

On Tue, Jan 06, 1998 at 11:49:30AM +0100, Christian Schwarz wrote:
> I currently see three practical solutions out of the dilemma (that
> /etc/crontab is edited by the sysadmin and scripts): 
> 
>   (b) We set up a certain directory (say /usr/lib/cronjobs) where each
>   package can install its own crontab file (/usr/lib/cronjobs/foo).
> 
>   Disadvantage: See above.

I like this solution the best. Isn't it acceptable that
the admin may modify these files just as they may
modify the files in /etc/init.d and /etc/cron.daily?
Then package-supplied crontab files would be conffiles too.

So it would be much like /etc/cron.daily etc, but
each package can specify its own interval. We should
still encourage /etc/cron.daily perhaps because it
allows a central point for changing the system
maintenance time (in /etc/crontab), makes it easy
to use anacron instead, etc.

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 FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Anyone working on new lyx version?

[Michael Meskes]

Did anyone take over lyx? It seems as if we're close the release of a new
stable version.

Michael
-- 
Dr. Michael Meskes, Project-Manager| topsystem Systemhaus GmbH
[EMAIL PROTECTED]| Europark A2, Adenauerstr. 20
[EMAIL PROTECTED]  | 52146 Wuerselen
Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux!  | Fax: (+49) 2405/4670-10


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

Re: What warrants a non-maintainer release number?

[James Troup]

Christian Schwarz <[EMAIL PROTECTED]> writes:

>``Whenever the source package is changed WRT to the last uploaded
>version, its version number has to be incremented. In addition,
>if the source package is not changed but the binary package
>changed (because it has been recompiled in another environment),
>the version number has to be incremented too (this is, the source
   ^^^
>package has to be changed and uploaded again) to make sure
 
>dpkg/dselect recognizes the changed package.''

I completely disagree with the last sentence.  If I compile xfree for
m68k and because of a broken ldd, it has hosed dependencies (this is
not so fictional an example, it actually happened with ncurses), I
should be able to recompile X with a different version number and
*only upload binaries*.  What would redoing and uploading the source
get me or anyone else?

o it takes 5 days to compile X on my machine, I don't even want to
  think how long it would take dpkg-source to work on a 42 Mb source
  tree.

o it would spark off 100% pointless recompiles on other architectures.  

o it serves no purpose.  The only source change is to the changelog,
  and that is included in the deb.  And it doesn't help the rational
  of this policy (that is: source, or no source, dpkg/dselect will
  still recognise foo_1.2-1.0.1 to be newer than fo_1.2-1).

-- 
James


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

Re: What's Debian's /usr/src policy

[Martin Mitchell]

[EMAIL PROTECTED] (Kai Henningsen) writes:

> [EMAIL PROTECTED] (Martin Mitchell)  wrote on 06.01.98 in <[EMAIL PROTECTED]>:
> 
> > Stephen Zander <[EMAIL PROTECTED]> writes:
> >
> > > Martin Mitchell <[EMAIL PROTECTED]> writes:
> > > > Ian Jackson <[EMAIL PROTECTED]> writes:
> > > > > Why does libc6 depend on kernel-header ?
> > > >
> > > > It's libc6-dev that has that dependency.
> > > > Perhaps weakening the dependency to Suggests might be the best solution.
> > >
> > > No, you can't.  Their are multiple header files that will be flat *broken*
> > > without a /usr/include/{linux,asm}.
> >
> > I know, however it would allow people to much more easily install and
> > maintain their own kernel sources for these includes.
> 
> Which is why we shouldn't do that. Remember, we *DO NOT* want them to  
> include their own kernel sources for these includes, because it is a *VERY  
> BAD IDEA*.

Rubbish, it's essential for almost all architectures except i386 and alpha,
that are not yet integrated with the main kernel source.

Martin.


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

Anyone working on new rxvt version?

[Paul Slootman]

rxvt 2.4.5 was announced on New Year's Day.  As the current hamm package of
rxvt is still 2.20, it would be great if the new version is available.
There have been many improvements; I notice the difference immediately
when I happen to use 2.20 instead of the 2.4.x versions.


Paul Slootman
-- 
Can you get your operating system fixed when you need it?
Linux - the supportable operating system. http://www.debian.org/support.html
home: [EMAIL PROTECTED] | work: [EMAIL PROTECTED]
http://www.wurtel.demon.nl | Murphy Software, Enschede, the Netherlands


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

Re: Debian and the millenium bug

[Kai Henningsen]

[EMAIL PROTECTED] (Michael Stone)  wrote on 05.01.98 in <[EMAIL PROTECTED]>:

> Quoting Oliver Elphick (olly@lfix.co.uk):
> > Why does glibc2 not use long long (64 bits) for dates, insead of long int
> > (32 bits)?  Surely we ought to change this now along with all the other
> > libc6 changes?
>
> IIRC, POSIX stipulates that time_t has to be a standard arithmetic type

C89 (ANSI (1989) / ISO (1990, same text)) assert that. Many, many programs  
would break if you change it.

> whereas long long is a non-standard extension. (Although I also seem to
> recall some talk of ANSI standardizing long long, so that might not be
> true anymore.)

It's going to be in C9X, which has just published a draft for comment.  
Search comp.std.c in DejaNews for the last one or two weeks for the  
announcement. There's also an unofficial version available on the web  
somewhere, announced one or two weeks earlier.

Don't expect the standard to be ratified before 1999-31-12, though ;-)

In the meantime, Unix98 is also available on the web somewhere (can't  
remember that URL).

MfG Kai


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

RE: Anyone working on new lyx version?

[Meskes, Michael]

Paul, could you send me your diff file?

Since I am the original maintainer I might do a new upload.

Michael
--
Dr. Michael Meskes, Project-Manager| topsystem Systemhaus GmbH
[EMAIL PROTECTED]| Europark A2, Adenauerstr. 20
[EMAIL PROTECTED]  | 52146 Wuerselen
Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux!  | Fax: (+49) 2405/4670-10

> -Original Message-
> From: Paul Seelig [SMTP:[EMAIL PROTECTED]
> Sent: Tuesday, January 06, 1998 2:23 PM
> To:   debian-devel@lists.debian.org
> Subject:  Re: Anyone working on new lyx version?
> 
> [EMAIL PROTECTED] (Michael Meskes) writes:
> 
> > Did anyone take over lyx? It seems as if we're close the release of
> > a new stable version.
> >
> I've been making quick'n'dirty packages of the recent lyx-0.12.0preX
> releases, but don't plan in any case to take over the maintenance of
> the official beast.  Just wanted to say that the new LyX version is
> finally becoming a really fine wordprocessing application worth to
> upgrade to.  I hope it will become part of Debian-2.0.
> 
>   Cheers, P. *8^)
> -- 
>Paul Seelig [EMAIL PROTECTED]
>African Music Archive - Institute for Ethnology and Africa Studies
>Johannes Gutenberg-University   -  Forum 6  -  55099 Mainz/Germany
>My Homepage in the WWW at the URL http://www.uni-mainz.de/~pseelig 
> 
> 
> --
> TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe"
> to
> [EMAIL PROTECTED] . 
> Trouble?  e-mail to [EMAIL PROTECTED] .


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

Re: Webmin .. ?

[Tim Sailer]

[EMAIL PROTECTED] wrote:
> 
> Hello,
>   I ran across something very cool the other day -- Webmin
> (http://www.webmin.com/webmin/).  It's a web-based system management
> tool, which is capable of doing things like cron jobs and DNS administration.
> The developer has a version for Debian, and I think it would make a great
> addition to make Debian more "user friendly" .. optional, of course. ;)
> 
> I I'm not sure if it's GPL'd, but if it is, I'd be interested in taking
> a shot at maintaining a package for it.  The only problem is my rather 
> unstable
> living situtation right now .. but that will be over with in a few months.

I took a look at it a month or so back, and it looked neat, but 
the DNS part would *not* work without major mods, if at all. It has
no concept of includes, expecting all lines to be included in
1 file.

Tim

-- 
 (work) [EMAIL PROTECTED] / (home) [EMAIL PROTECTED] - http://www.buoy.com/~tps
"Very Pete Townshendish." "Who?" "Exactly."
 -- Anon
** Disclaimer: My views/comments/beliefs, as strange as they are, are my own.**


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

Re: What warrants a non-maintainer release number?

[Mark W. Eichin]

> should be able to recompile X with a different version number and
> *only upload binaries*.  What would redoing and uploading the source

Yeah, my recent experience with the sparc port confirms this.  At this
stage, it seems that all of the non-x86 ports have "system changes
that aren't usefully reflected in dependencies" so simple recompiles
often fix real bugs.  

Of course, what I'd *really* like is a way to do an upload of diffs
that are architecture specific; sure, we don't want that *in the end*,
but while we're still getting there, lots of stuff is getting uploaded
*without* matching sources, just to actually make it available...


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

Re: Question/request concerning master

[Mark W. Eichin]

> upload all files with one "scp" when using SSH to upload?

Isn't that what ssh-agent is for?  You run it, give it the pass
phrase, and then dupload forever :-)


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

file descriptors??

[Craig Sanders]

is there any debian policy on number of file descriptors compiled into the
kernel?  (and also in limits.h in libc6-dev - AFAIK pretty much everything
that uses select() will need to be recompiled if the limit is increased).

some time ago the debian kernels came patched with 1024 fd's.  this meant
that squid and apache and other servers could run out of the box without
running out of file descriptors (linux crashes badly when it runs out of
fd's - not a pretty sight). 

recent kernels seem to have reverted back to 256 fd's. 

imo, 256 just isn't enough...especially when nearly the entire
distribution has to be recompiled if a user wants to recompile a kernel
with the >256 fd's patch.

the latest ">256 fd's patch" mallocs an arbitrary number of file
descriptors.

should something be done about this for 2.0?  or wait until 2.1?  

btw, we'll face have to face this problem when the 2.1 kernel is released
as 2.2. 

craig

--
craig sanders


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

Re: What's Debian's /usr/src policy

[Turbo Fredriksson]

On Tue, 6 Jan 1998, Hamish Moffatt wrote:

> I think it does gain something; it is much easier to have multiple
> versions around. If I compile a new 2.1 kernel and find that
> it is not too good (like 2.1.76 seems to have broken sound
> for me so I went back to 2.1.72), I can just reinstall the old
> one with dpkg. I don't need to edit my lilo config, play with
> symlinks in / etc.

If you wrote your lilo config propperly, you did not have to reinstall at all..
Just have multiple bootable configs and one 'default=xxx' (or whatever it
was called), which you change depending on your working kernel... I for one
have ten or fifteen different kernels that I can boot, depending on if the
new one worked or not...

---
 Turbo_ /// If there are no Amigas in heaven, send me to HELL!
 ^\\\/
 Unix _IS_ user friendly - it's just selective about who its friends are !
 Turbo Fredriksson Tel: +46-704-697645
 S-415 10 Göteborg[EMAIL PROTECTED]
 SWEDEN www5.tripnet.se/~turbo
   My PGP key can be found at: 'www5.tripnet.se/~turbo/pgp.html'
 Key fingerprint = B7 92 93 0E 06 94 D6 22  98 1F 0B 5B FE 33 A1 0B
---


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

Re: please upgrade your packages to current standards

[Richard Braakman]

Sten Anderson wrote:
> Now you are at it, I suggest that you also scan the archive for packages 
> that fails to include a "Section" and/or "Priority" field. It is far
> too many, and it is quite annoying.

Do we want all packages to include the Section and Priority fields?

If so, then I think it is far more effective to change dpkg's default
behaviour so that it does include these fields, rather than requiring
an explicit flag -isp.
 
However, I don't know the history behind this.  What is the reason for
not including Section and Priority by default?

Richard Braakman


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

Re: What's Debian's /usr/src policy

[Dale Scheetz]

On 6 Jan 1998, Kai Henningsen wrote:

> [EMAIL PROTECTED] (Dale Scheetz)  wrote on 05.01.98 in <[EMAIL PROTECTED]>:
> 
> > On Mon, 5 Jan 1998, Ian Jackson wrote:
> >
> > > I think that /usr/src should the be domain of the local admin.
> > >
> > > I don't think kernel-{header,source}-x.xx.deb should exist, really,
> > > because I don't think source code should be distributed as .deb files
> > > anyway.  So I'm not unhappy about making a policy decision that leaves
> > > kernel-{header,source} with nowhere good to go.
> >
> > I never understood why the kernel source was made into a .deb package. It
> > doesn't make sense to me. I also don't see any point in "managing" a
> > binary package of the kernel either. The system doesn't gain anything by
> > having dpkg know which kernel binaries are installed either. The binary
> > thus installed still needs to be configured for lilo or loadlin or grub,
> > so what's the point?
> 
> Well, handling kernels with kernel-package is _a_lot_ easier than doing it  
> by hand. I've done both, and I don't want to go back, ever.

I'm sorry, but my experience has been very different. I too have tried
both. Maybe my timing has been poor, but both times I tried there was a
mismatch between the kernel-package package and the kernel-source package
and after much futsing around resulted in failure. 

Kernel source should be provided the way we provide source for all other
packages. You should be able to unpack it with dpkg-source -x and run
dpkg-buildpackage and build a kernel to your spec and construct a .deb
package from that result. (Note, I have no real problem with a
kernel-binary package, although personally I would have no use for it, I
can understand others point of view in wishing to "manage" their kernels
with dpkg)

> 
> > > Why does libc6 depend on kernel-header ?
> >
> > I don't know either, but it is on the top of my list of things I need to
> > understand as the new maintainer. It was my understanding that the way we
> > deal with kernel headers was supposed to free the c library from the
> > headers. I don't know that anything has changed in that reguard. I'll let
> > you know what I find asap.
> 
> I think our main problem here is that people (including both you and Ian)  
> don't keep on top of debian-private and debian-devel. 

I can't speak for Ian here, but I am a constant reader and participant on
both these lists. Your implication is both unfair and has nothing to do
with the technical discussion.

>I can't count the  
> times this has been explained already, and I get very, very tired of it.
> 
I am sorry for your exaustion. I am capable of counting, but what is the
point. The reason this keeps coming up is that, so far, all explanations
have been inadequate.

> libc6 depends on a specific version of kernel-headers to avoid including  
> what is in that package as a diff. Nothing more, nothing less.
> 
This exaplanation is inadequate as well. While shrinking the size of a
diff file helps the developer who pays by the byte/minute for access, it
creates a problem for the user which is not necessary. Forcing the
coupling of two packages via depends when the two packages are only used
together makes installation and upgrades one step more complex than is
necessary in a way that adds to package bloat when it isn't necessary.
(BTW it's libc6-dev that is coupled to kenrel-headers)

Still unconvinced,

Dwarf
-- 
_-_-_-_-_-_-   Author of "The Debian User's Guide"_-_-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (904) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


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

Re: What's Debian's /usr/src policy

[Dale Scheetz]

On Tue, 6 Jan 1998, Hamish Moffatt wrote:

> On Mon, Jan 05, 1998 at 05:48:27PM -0500, Dale Scheetz wrote:
> > I never understood why the kernel source was made into a .deb package. It
> 
> Because it's something we expect people will want to recompile,
> so we should make it readily available to them.

A proper source package (.diff, .dsc, and orig.tar.gz) is smaller, and the
user can get the orig.tar.gz from other sources, making the download from
Debian trivial. How is this less "readily available"?

> 
> > doesn't make sense to me. I also don't see any point in "managing" a
> > binary package of the kernel either. The system doesn't gain anything by
> > having dpkg know which kernel binaries are installed either. The binary
> > thus installed still needs to be configured for lilo or loadlin or grub,
> > so what's the point?
> 
> I think it does gain something; it is much easier to have multiple
> versions around. If I compile a new 2.1 kernel and find that
> it is not too good (like 2.1.76 seems to have broken sound
> for me so I went back to 2.1.72), I can just reinstall the old
> one with dpkg. I don't need to edit my lilo config, play with
> symlinks in / etc.
> 
When I try a new kernel and it doesn't work, I only have to edit
lilo.config an run lilo to get back to the old one (actually I always
leave hooks in lilo to get back to the "old" kernel). No package
installation is required.

I will also never feel comfortable with an automatic process editing my
lilo.config file. I am set up to boot several linux partitions as well as
a dos partition and a loop-root system. I am much happier editing that
beast myself thankyou ;-)

Luck,

Dwarf
-- 
_-_-_-_-_-_-   Author of "The Debian User's Guide"_-_-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (904) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


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

Re: Question/request concerning master

[Turbo Fredriksson]

On Tue, 6 Jan 1998 [EMAIL PROTECTED] wrote:

> As a purely practical point: I dislike having to type my passphrase or
> password for every file I'm uploading. Heiko, can dupload be changed to
> upload all files with one "scp" when using SSH to upload?

It seem you haven't read ssh's man page propperly... Use 'ssh-agent bash' (
or whatever shell you are using, tcsh, yuck.. :) then use 'ssh-add' which
will then tell each ssh/scp client your passphrase...

'man ssh' will tell it all... :)

---
 Turbo_ /// If there are no Amigas in heaven, send me to HELL!
 ^\\\/
 Unix _IS_ user friendly - it's just selective about who its friends are !
 Turbo Fredriksson Tel: +46-704-697645
 S-415 10 Göteborg[EMAIL PROTECTED]
 SWEDEN www5.tripnet.se/~turbo
   My PGP key can be found at: 'www5.tripnet.se/~turbo/pgp.html'
 Key fingerprint = B7 92 93 0E 06 94 D6 22  98 1F 0B 5B FE 33 A1 0B
---


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

Re: Re[2]: cron jobs more often than daily

[Turbo Fredriksson]

On Tue, 6 Jan 1998, Hamish Moffatt wrote:

> Because sometimes the jobs need to run as root. Quite often I suspect.
> My package ipac (which started this) needs to run ipfwadm to configure
> and reset the IP accounting rules, which requires root.

Why not use a daemon? In peal, that would be a ten-liner...

---
 Turbo_ /// If there are no Amigas in heaven, send me to HELL!
 ^\\\/
 Unix _IS_ user friendly - it's just selective about who its friends are !
 Turbo Fredriksson Tel: +46-704-697645
 S-415 10 Göteborg[EMAIL PROTECTED]
 SWEDEN www5.tripnet.se/~turbo
   My PGP key can be found at: 'www5.tripnet.se/~turbo/pgp.html'
 Key fingerprint = B7 92 93 0E 06 94 D6 22  98 1F 0B 5B FE 33 A1 0B
---


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

Looking for debcheck

[Richard Braakman]

There are a number of bug reports in the archive that were automatically
generated by a program named "deb-check".  Is this program still around?
I would like to look at it.

Thanks,

Richard Braakman


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

Re: What's Debian's /usr/src policy

[Rob Browning]

Dale Scheetz <[EMAIL PROTECTED]> writes:

> I will also never feel comfortable with an automatic process editing my
> lilo.config file. I am set up to boot several linux partitions as well as
> a dos partition and a loop-root system. I am much happier editing that
> beast myself thankyou ;-)

Dale, I think you must misunderstand how kernel-package works.  It
never touches your lilo.conf file.  You just have to have entries
pointing to /vmlinuz and /vmlinux.old, and then it just runs lilo in
the postinst.  All of kernel-package's work wrt lilo is confined to
updating the /vmlinuz and /vmlinuz-old pointers.

Actually, I'm not completely sure I got the kernel locations right
because I use a couple of little known kernel-package features:

  image_in_boot := True
  DEB_DEST := ../kernel-images

so that I have no "/" level kernel symlinks, and so that when
make-kpkg builds a kernel image package, it puts it in
../kernel-images rather than ../ .  I got tired of looking at those
humongous file names in /usr/src.

I think other people have sufficiently covered the other advantages of
kernel-package, but I'll add that your suggested solution of just
using kernel-source doesn't work if you want to use *today's* kernel
today.

Also, I've witnessed someone else, who doesn't want to use
kernel-package (which is fine) leave their system unbootable by
forgetting to run lilo after a manual install.  That's impossible if
you use the .debs.

-- 
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94  53 2B 97 F5 D6 4E 39 30


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

Re: Question/request concerning master

[Rob Browning]

Turbo Fredriksson <[EMAIL PROTECTED]> writes:

> It seem you haven't read ssh's man page propperly... Use 'ssh-agent bash' (
> or whatever shell you are using, tcsh, yuck.. :) then use 'ssh-add' which
> will then tell each ssh/scp client your passphrase...

Or if you use X, just put:

  exec ssh-agent ~/.x-common-startup

in your .xinitrc.  Then you can run ssh-add once after logging in, and
never type the phrase again until you log out.

-- 
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94  53 2B 97 F5 D6 4E 39 30


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

Re: Anyone working on new rxvt version?

[Brian Mays]

Paul Slootman <[EMAIL PROTECTED]> writes:

> rxvt 2.4.5 was announced on New Year's Day.  As the current hamm package of
> rxvt is still 2.20, it would be great if the new version is available.
> There have been many improvements; I notice the difference immediately
> when I happen to use 2.20 instead of the 2.4.x versions.

Of course.  I, the Debian maintainer of rxvt, am packaging the new
version.  Actually, I've already assembled the package.  I am currently
testing it, so it should be uploaded sometime this week when I'm satisfied
that I have worked out most of the quirks.

Brian

-- 
Deadwood, n.:
Anyone in your company who is more senior than you are.


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

Re: please upgrade your packages to current standards

[Dale Scheetz]

On Tue, 6 Jan 1998, Richard Braakman wrote:

> Do we want all packages to include the Section and Priority fields?

Probably.
> 
> If so, then I think it is far more effective to change dpkg's default
> behaviour so that it does include these fields, rather than requiring
> an explicit flag -isp.
>  
Dpkg can't put them in if the information is not available in the control
file.

> However, I don't know the history behind this.  What is the reason for
> not including Section and Priority by default?
> 
I believe that if you put section and priority fields in the "package"
section of the control file, dpkg puts them into the control file for the
package. How would dpkg be able to do this by default without knowing all
the section and priority values for all packages?

These were thought to be unnecessary (from the developers point of view)
because the installer on master (from the overrides file) inserts the
correct values into the packages and contents file dispite what the
control file might say.

With my "user" hat on, I like having the package contain these fields, as
I typically use mc to dive into a new .deb file to see what it contains.
The INFO file thus provided is more informative if it contains section and
priority information.

As a developer, I have already begun to put these fields into my packages.
The feedback I get from the installer is useful if we disagree on location
because I can then discuss it. This allows packages to be "relocated" if
there is a place where users are more likely to look.

Luck,

Dwarf
-- 
_-_-_-_-_-_-   Author of "The Debian User's Guide"_-_-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (904) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


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

gnuchess & gnuchess-book

[Ulf Jaenicke-Roessler]

Hi,

 just recently I installed gnuchess-book and gnuchess.
 I used something like 'dpkg -i gnuchess-book_* gnuchess_*'.

 When the packages were configured I got the message: 'note the
 disappearence of gnuchess-book, which has been completely
 replaced'. In fact, there's no sign of gnuchess-book anymore.
 All maintainer scripts and data files from /var/lib/dpkg/info are
 gone. Only the chess opening library file of the package (>1MB) is
 left, but doesn't belong to any package (and therefore it's not
 removed by purging a certain package).
 When I use 'dpkg -i gnuchess_* gnuchess-book_*' (ie. in an alternate
 sequence) this doesn't happen.

 I found, that this is caused by a divertion in gnuchess-book.

 1) Should there really be a diversion here?
 2) Why are there two packages at all? Yes, you can install gnuchess
without the large library, but then the two packages should
remain two packages.
 3) If I remember correctly, gnuchess-book doesn't contain any docs
(or copyrights). Should this be reported as a bug? I guess, this is
related to the above problem, but is it covered by the policy?
 4) A more general question: How are diversions introduced: must there
be an aggreement of the involved package maintainers or an
agreement of "all" developers?

 Thanks,

  Ulf


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

Re: driver for Epson Stylus 300

[James A . Treacy]

> Yes, I could try that. Can the 600 use color and black ink at the same
> time?
> 
yes. It has 2 cartridges: one black and another which has 3 bays.
When I print latex documents containing color images the black is black
and the colors come out just fine.

> Also would you mind sending me your gs setup? I'm not sure about
> uniprint but the stcolor driver usage in magicfilter is outdated, i.e.
> it uses options no longer avalaible in gs-aladin. Or is that no problem
> with uniprint?
> 
I only skimmed through the docs, but it looks like the author of uniprint
put a lot of thought into it and has plans for further improvements.
You can customize it without having to recompile.

I use magicfilter and /usr/sbin/stylus_color_360dpi-filter has the following 
line in it:

0   %!  filter  /usr/bin/gs  @stc600pl.upp -q -dSAFER -dNOPAUSE 
-sOutputFile=- - -c quit

The @stc600pl.upp specifies the stc600pl.upp config file for the uniprint 
driver.

To give you an idea of what it does, here it is:

- begin /usr/lib/ghostscript/5.03/stc600pl.upp ---
-supModel="Epson Stylus Color 600, 360x360DpI, Plain Paper"
-sDEVICE=uniprint
-dNOPAUSE
-dSAFER
-dupColorModel=/DeviceCMYKgenerate
-dupRendering=/FSCMYK32
-dupOutputFormat=/EscP2
-r360x360
-d.HWMargins="{ 9.0 39.96 9.0 9.0}"
-dMargins="{-45   -45}"
-dupBlackTransfer="{   0. 0.0553 0.1158 0.1998 0.4321 1. }"
-dupCyanTransfer="{0. 0.0851 0.1512 0.2111 0.2606 0.2818 }"
-dupMagentaTransfer="{ 0. 0.1188 0.2272 0.3745 0.5396 0.6145 }"
-dupYellowTransfer="{  0. 0.0679 0.1742 0.3129 0.4587 0.5389 }"
-dupOutputComponentOrder="{ 1 2 3 0 }"
-dupWeaveYPasses=4
-dupOutputPins=32
-dupWeaveYFeeds="{33 30 35 30}"
-dupWeaveInitialYFeeds="{1  1  1 29}"
-dupWeaveInitialPins="{  8 16 32 23}"
-dupBeginPageCommand="<
   1b40   1b40
   1b2847 0100 01
   1b2855 0100 0A
   1b5501
   1b2865 0200 0002
   1b2843 0200 
   1b2863 0400  
>"
-dupAdjustPageLengthCommand
-dupAdjustTopMarginCommand
-dupAdjustBottomMarginCommand
-dupEndPageCommand="([EMAIL PROTECTED])"
-dupAbortCommand="([EMAIL PROTECTED]Printout-Aborted\15\014)"

- end /usr/lib/ghostscript/5.03/stc600pl.upp ---


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

Re: Debian and the millenium bug

[Raul Miller]

[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Well, there is a problem with the Gregorian calendar that has to be
> dealt with in 2000 years or so (having to do with leap-millenia), but
> I figure if it's more than 100 years it's no problem.

I believe that can be handled by making the year 4000 not be a leap
year.

-- 
Raul


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

Re: What's Debian's /usr/src policy

[Dale Scheetz]

On 6 Jan 1998, Rob Browning wrote:

> Dale Scheetz <[EMAIL PROTECTED]> writes:
> 
> > I will also never feel comfortable with an automatic process editing my
> > lilo.config file. I am set up to boot several linux partitions as well as
> > a dos partition and a loop-root system. I am much happier editing that
> > beast myself thankyou ;-)
> 
> Dale, I think you must misunderstand how kernel-package works.  It
> never touches your lilo.conf file.  You just have to have entries
> pointing to /vmlinuz and /vmlinux.old, and then it just runs lilo in
> the postinst.  All of kernel-package's work wrt lilo is confined to
> updating the /vmlinuz and /vmlinuz-old pointers.

Which means that it will not work at all with my configuration.
My lilo.conf calls out kernels explicitly from /boot where I can keep as
many, or as few kernel images as I please, file system size permitting.

> 
> I think other people have sufficiently covered the other advantages of
> kernel-package, but I'll add that your suggested solution of just
> using kernel-source doesn't work if you want to use *today's* kernel
> today.

I don't see why not? Simply take the debian diffs and apply them against
*today's* kernel and you are off and running. The kernel file organization
hasn't changed in ages. (I hope that doesn't mean that someone will change
it simply because it is old and stable ;-)

> 
> Also, I've witnessed someone else, who doesn't want to use
> kernel-package (which is fine) leave their system unbootable by
> forgetting to run lilo after a manual install.  That's impossible if
> you use the .debs.
> 
Nothing is impossible ;-)

This is clearly a "different strokes" issue. I'm sure there will be two
sides to this discussion for the indefinite future.

Waiting is,

Dwarf
-- 
_-_-_-_-_-_-   Author of "The Debian User's Guide"_-_-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (904) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


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

dwww Missing-in-action

[Jim Pick]

Sorry,

For those holding their breath...

I had system problems this weekend.  I'll have dwww ready
next weekend.

Cheers,

 - Jim



pgpFTRhdIqcvr.pgp
Description: PGP signature

Re: Anyone working on new rxvt version?

[Andreas Jellinghaus]

In article <[EMAIL PROTECTED]> you write:
>rxvt 2.4.5 was announced on New Year's Day.  As the current hamm package of
>rxvt is still 2.20, it would be great if the new version is available.
>There have been many improvements; I notice the difference immediately
>when I happen to use 2.20 instead of the 2.4.x versions.

if these copyright issues are still relevant - you will find the email
of the xvt author about changeing the copyright to gpl in the kdebase
copyright file (because kdebase include kvt, and this way xvt code).

andreas


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

Re: file descriptors??

[Elie Rosenblum]

And thus spake Craig Sanders, on Wed, Jan 07, 1998 at 01:52:06AM +1100:
> is there any debian policy on number of file descriptors compiled into the
> kernel?  (and also in limits.h in libc6-dev - AFAIK pretty much everything
> that uses select() will need to be recompiled if the limit is increased).
> 
> some time ago the debian kernels came patched with 1024 fd's.  this meant
> that squid and apache and other servers could run out of the box without
> running out of file descriptors (linux crashes badly when it runs out of
> fd's - not a pretty sight). 
> 
> recent kernels seem to have reverted back to 256 fd's. 
> 
> imo, 256 just isn't enough...especially when nearly the entire
> distribution has to be recompiled if a user wants to recompile a kernel
> with the >256 fd's patch.
> 
> the latest ">256 fd's patch" mallocs an arbitrary number of file
> descriptors.
> 
> should something be done about this for 2.0?  or wait until 2.1?  
> 
> btw, we'll face have to face this problem when the 2.1 kernel is released
> as 2.2. 

This has been sysctl configurable in the runtime kernel since at most 2.0,
probably 1.3.

deliverator:[~]-#cd /proc/sys/kernel/
deliverator:[/proc/sys/kernel]-#ls -l *-max *-nr
-rw-r--r--   1 root root0 Jan  6 13:40 file-max
-r--r--r--   1 root root0 Jan  6 13:40 file-nr
-rw-r--r--   1 root root0 Jan  6 13:40 inode-max
-r--r--r--   1 root root0 Jan  6 13:40 inode-nr
deliverator:[/proc/sys/kernel]-#cat file-max inode-max
1024
4096
deliverator:[/proc/sys/kernel]-#echo 2048>file-max; echo 8192>inode-max
deliverator:[/proc/sys/kernel]-#cat file-max inode-max
2048
8192
deliverator:[/proc/sys/kernel]-#

-- 
Elie Rosenblum <[EMAIL PROTECTED]>   That is not dead which can eternal lie,
 <[EMAIL PROTECTED]>  And with strange aeons even death may die.
Developer / Mercenary / System Administrator - _The Necromicon_


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

Re: Anyone working on new rxvt version?

[Brian Mays]

Andreas Jellinghaus <[EMAIL PROTECTED]> writes:

> If these copyright issues are still relevant - you will find the email
> of the xvt author about changing the copyright to gpl in the kdebase
> copyright file (because kdebase include kvt, and this way xvt code).

The new upstream maintainers must be aware of this copyright change
because the latest stable rxvt release is under the GPL.

Brian


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

Re: gnuchess & gnuchess-book

[Martin Mitchell]

[EMAIL PROTECTED] (Ulf Jaenicke-Roessler) writes:

>  When I use 'dpkg -i gnuchess_* gnuchess-book_*' (ie. in an alternate
>  sequence) this doesn't happen.
> 
>  I found, that this is caused by a divertion in gnuchess-book.
> 
>  1) Should there really be a diversion here?

Probably not. I'll take a look at this and the other issues you've raised.

Martin.


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

Re: What's Debian's /usr/src policy

[Stephen Zander]

Martin Mitchell <[EMAIL PROTECTED]> writes:
> I know, however it would allow people to much more easily install and
> maintain their own kernel sources for these includes.

Surely if they're clever enough for that, they're clever enough to
override a Recommends (not a Suggests) heading. Maybe that would work,
though I still don't like it.

-- 
Stephen
---
"Normality is a statistical illusion." -- me


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

Re^2: uploaded dhelp (i386 source)

[Marco Budde]

Am 05.01.98 schrieb leutloff # sundancer.oche.de ...

Moin Christian!

CL> >* cgiparse binary (from CERN httpd)
CL> isn't it better to use the correct Recommends/Depends flag instead of
CL> doubling the binaries.

Because most people use the Apache server and I'm not sure if you can  
install several http Servers at one machine. I'll replace cgiparse in one  
of the next releases with a Perl script.

CL> >* dbugreport (report Debian bugs)
CL> where's the difference to the bug program (located in the package
CL> bug)?

I don't know. Is this a CGI Interface?

CL> Btw.: Shouldn't we switch the priority for bug to a higher one,
CL> i.e. standard or essential!? It's a small but very useful program that
CL> should be found on *every* Debian system.

Done :). This package uses standard.

cu, Marco

--
Uni: [EMAIL PROTECTED]  Fido: 2:240/5202.15
Mailbox: [EMAIL PROTECTED]http://www.tu-harburg.de/~semb2204/


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

Re^4: dhelp 0.2 - a online help system

[Marco Budde]

Am 05.01.98 schrieb schwarz # monet.m.isar.de ...

Moin Christian!

CS> > think, we should use this help system in Debian 2.0. Some other
CS> > distributions already use such systems (for example SuSE).
CS> You should probably not refer to SUSE here. They are know for their quick
CS> and _dirty_ solutions ;-)

That's right, but a dirty solution is better than no solution. And dhelp  
is no dirty solution :).

CS> Please don't get me wrong. I have nothing against packages supporting
CS> dhelp. However, dhelp is not our "official" system by now (nor is dwww) so
CS> we can't force everyone to use it by policy.

Right, but we could suggest the use of dhelp (and maybe dwww) in the  
policy for Debian 2.0. And remember, you can register *not* only HTML  
document at dhelp.

CS> I promise that we'll start discussing and implement the new doc-policy
CS> and all this when "hamm" is out of the door.

Fine, but please add dhelp support to your packages containing HTML/PS/PDF  
documents. It takes you less than 5 minutes :).

cu, Marco

--
Uni: [EMAIL PROTECTED]  Fido: 2:240/5202.15
Mailbox: [EMAIL PROTECTED]http://www.tu-harburg.de/~semb2204/


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

Re: Anyone using dhelp with netscape?

[Marco Budde]

Am 05.01.98 schrieb meskes # topsystem.de ...

Moin Michael!

MM> It seems communicator 4.0 doesn't like it at all. As soon as I click on
MM> the debian link netscape gets a bus error.

The index.html files are all in HTML 3.2 that's no problem :). But there's  
one know bug in dhelp :(. The last created index.html doesn't include the  
tail .
I'm trying to fix this, maybe someone finds the bug :)?

cu, Marco

P.S.: I'm using netscape 3.x and lynx without problems.

--
Uni: [EMAIL PROTECTED]  Fido: 2:240/5202.15
Mailbox: [EMAIL PROTECTED]http://www.tu-harburg.de/~semb2204/


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

Re: Re^2: uploaded dhelp (i386 source)

[James Troup]

[EMAIL PROTECTED] (Marco Budde) writes:

> Am 05.01.98 schrieb leutloff # sundancer.oche.de ...
> 
> > Btw.: Shouldn't we switch the priority for bug to a higher one,
> > i.e. standard or essential!? It's a small but very useful program
> > that

Definitely not essential.  It by no means matches the definition of
it.  It probably could be raised to a higher priority though.

> CL> should be found on *every* Debian system.
> 
> Done :).

Christian was talking about the bug package not yours.

> This package uses standard.

Uh, why?  How is it ``standard''?

-- 
James


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

Re: Webmin .. ?

[Igor Grobman]

> Hello,
>   I ran across something very cool the other day -- Webmin
> (http://www.webmin.com/webmin/).  It's a web-based system management
> tool, which is capable of doing things like cron jobs and DNS administration.
> The developer has a version for Debian, and I think it would make a great
> addition to make Debian more "user friendly" .. optional, of course. ;)
> 
> I I'm not sure if it's GPL'd, but if it is, I'd be interested in taking
> a shot at maintaining a package for it.  The only problem is my rather 
> unstable
> living situtation right now .. but that will be over with in a few months.

I was thinking of packaging it too about a month ago.  I contacted the author 
about webmin's license (which is not to be found anywhere), and still haven't 
heard back.

-- 
Proudly running Debian Linux! Linux vs. Windows is a no-Win situation
Igor Grobman   [EMAIL PROTECTED] [EMAIL PROTECTED] 



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

Re: What's Debian's /usr/src policy

[Rob Browning]

Dale Scheetz <[EMAIL PROTECTED]> writes:

> I don't see why not? Simply take the debian diffs and apply them against
> *today's* kernel and you are off and running. The kernel file organization
> hasn't changed in ages. (I hope that doesn't mean that someone will change
> it simply because it is old and stable ;-)

I was under the impression that Debian had a bunch of kernel patches
in the Debian diffs as well as the Debianization info.  Given an
arbitrary new kernel, some of these patches may fail.  Whereas
kernel-package via make-kpkg just includes the debian/* stuff which is
all I care about.

> This is clearly a "different strokes" issue. I'm sure there will be two
> sides to this discussion for the indefinite future.

Without doubt.

-- 
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94  53 2B 97 F5 D6 4E 39 30


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

Re: Anyone using dhelp with netscape?

[Marco Budde]

Am 05.01.98 schrieb meskes # topsystem.de ...

Moin Michael!

MM> It seems communicator 4.0 doesn't like it at all. As soon as I click on
MM> the debian link netscape gets a bus error.

I've found the bug (missing fclose). I'll upload 0.2.2 tomorrow.

--
Uni: [EMAIL PROTECTED]  Fido: 2:240/5202.15
Mailbox: [EMAIL PROTECTED]http://www.tu-harburg.de/~semb2204/


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

Re: Looking for debcheck

[Andreas Jellinghaus]

In article <[EMAIL PROTECTED]> you write:
>There are a number of bug reports in the archive that were automatically
>generated by a program named "deb-check".  Is this program still around?
>I would like to look at it.

its a tcl script i wrote once.
all functionality is also in deblint and debmake.
indeed, if a programm were using debmake, it will not have any bugs,
that deb-check can find.

if you still want it, contact me directly.

andreas


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

Re: What warrants a non-maintainer release number?

[Fabrizio Polacco]

On  6 Jan, Kai Henningsen wrote:
> [EMAIL PROTECTED] (Fabrizio Polacco)  wrote:
> 
>> On  6 Jan, Remco Blaakmeer wrote:
>> > So, the people on debs.fuller should make sure
>> > that the version numbers they use will not be taken by 'official' .deb
>> > packages.
>>
>> This sounds nonsense.
> 
> It's the only option we have.

The only option we have is to find a way to say if a package is
official or not (and it cannot be its presence in the ftp site).


> Simple example: someone  
> grabs a source package and rebuilds it without any changes. He will now  
> have a different .deb (and it _will_ be different - different time stamps,  
> maybe he used a different gcc, different debmake version ...) with the  
> exact same version number as the original.
> 

Yes, and therefore, as Christian has just recalled, we need to add an
"origin" field somewhere _inside_ the binary package.
It cannot be included by the maintainer, because not all the packages
that a maintainer build will become "official", and also a maintainer
can step out from the project (and still use his own pgp key).

My suggestion was that dinstall will unpack the .deb , insert some
signature in it (for example a md5sum list of the files in the
control.tar.gz, pgp-signed with an official key), and repack it just
before installation in the ftp hierarchy.
(If the control.tar.gz contains the md5sums of the files installed by
the package, then installing also this signed list into dpkg/info would
add a way to check if a single file is the one distributed by us.)

pgp-signing the Packages file could be another way to achieve this (the
origin field), but will be too easily broken on rearranged distributions
(e.g: your own mirror, or a custom CD), and the signature will be lost
when updating the available list (that is to say: _before_
installation).


> Just close bug reports referring to non-project .debs with "not our  
> package, not our problem".

The problem is "knowing" when a bug refers to a non-project package.
When the user is sending us such bugs, probably he didn't notice or
remember that the package wasn't build by us.
Without a trusted origin field you will be prosecuted by the suspicion
if the package is original or not.
If the signature (that certifies that a package is debian-original), is
installed in the dpkg database then we could have the "bug" command (or
else) add automatically this information to the report.


Fabrizio
-- 
| [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
| Pluto Leader - Debian Developer & Happy Debian 1.3.1 User - vi-holic
| 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E
> Just because Red Hat do it doesn't mean it's a good idea. [Ian J.]


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

Re: Debian and the millenium bug

[Fabrizio Polacco]

On  6 Jan, Kai Henningsen wrote:
> 
> Remember that the last calendar reform was made at an actual difference of  
> about 10 days (and some countries took a long time after that to implement  
> it, thus increasing the difference even more), so I'd expect people won't  
> touch that until the difference is again in that ballpark - around AD  
> 31000-32000, that is.

Continuing off-topic, I remember that when I was young (very young) I
read a nice proposal for a reform of the calendar, made by Isaac Asimov.
I cannot find it anymore and, for some strange but human reason, I'm no
more in the possibility to ask Isaac himself.

Did anybody read it and can tell me where I could find it?

Thanks,
Fabrizio
-- 
| [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
| Pluto Leader - Debian Developer & Happy Debian 1.3.1 User - vi-holic
| 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E
> more than 35 months are needed to get rid of the millennium. [me]


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

Re: Webmin .. ?

[bruce]

It's OK to package it if you can get the license straight, but I think it
makes sense for us to base our system-management strategy on COAS (see
http://www.coas.org/) .

Bruce


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

Re: file descriptors??

[Craig Sanders]

On Tue, 6 Jan 1998, Elie Rosenblum wrote:

> And thus spake Craig Sanders, on Wed, Jan 07, 1998 at 01:52:06AM +1100:
> > is there any debian policy on number of file descriptors compiled into the
> > kernel?  (and also in limits.h in libc6-dev - AFAIK pretty much everything
> > that uses select() will need to be recompiled if the limit is increased).
> 
> This has been sysctl configurable in the runtime kernel since at most 2.0,
> probably 1.3.
> 
> deliverator:[~]-#cd /proc/sys/kernel/
> deliverator:[/proc/sys/kernel]-#ls -l *-max *-nr
> -rw-r--r--   1 root root0 Jan  6 13:40 file-max
> -r--r--r--   1 root root0 Jan  6 13:40 file-nr
> -rw-r--r--   1 root root0 Jan  6 13:40 inode-max
> -r--r--r--   1 root root0 Jan  6 13:40 inode-nr
> deliverator:[/proc/sys/kernel]-#cat file-max inode-max
> 1024
> 4096
> deliverator:[/proc/sys/kernel]-#echo 2048>file-max; echo 8192>inode-max
> deliverator:[/proc/sys/kernel]-#cat file-max inode-max
> 2048
> 8192
> deliverator:[/proc/sys/kernel]-#

so why have there been patches to increase the number of available fd's
right up until recent kernel versions (e.g. 2.0.30)?  here's what happens on
my 2.0.32 system:

[EMAIL PROTECTED] [08:41:43] kernel# cd /proc/sys/kernel/
[EMAIL PROTECTED] [08:41:58] kernel# ls -l *-max *-nr
-rw-r--r--   1 root root0 Jan  7 08:40 file-max
-r--r--r--   1 root root0 Jan  7 08:40 file-nr
-rw-r--r--   1 root root0 Jan  7 08:40 inode-max
-r--r--r--   1 root root0 Jan  7 08:40 inode-nr
[EMAIL PROTECTED] [08:42:34] kernel# cat file-max inode-max
1024
3072
[EMAIL PROTECTED] [08:42:41] kernel# echo 2048>file-max; echo 
8192>inode-max
bash: file-max: Bad file descriptor
bash: inode-max: Bad file descriptor
[EMAIL PROTECTED] [08:42:48] kernel# cat file-max inode-max
1024
3072

strange. your system reports 1024 and 4096 for file-max and inode-max. 
mine reports 1024 and 3072. yours allows it to be changed. mine doesn't.
what kernel version are you running? any patches? standard
linux-x.x.x.tar.gz or a debian patched kernel-source-x.x.x.deb (many of
the debian kernels were patched with various fixes and enhancements -
maybe debian's kernel should come with the linux "big-mama" or "big-mama's
best child" patch sets)? 

anyway, here's what i'm running:

[EMAIL PROTECTED] [08:42:52] kernel# uname -a
Linux siva.taz.net.au 2.0.32 #1 Wed Dec 3 10:31:25 EST 1997 i486 unknown


bash seems to know that 256 fd's are available per process.

[EMAIL PROTECTED] [08:47:36] kernel# ulimit -a | grep files
open files  256

squid too (from the cachemgr.cgi):

File descriptor usage for squid:
Maximum number of file descriptors:256
Largest file desc currently in use: 25
Number of file desc currently in use:   25
Available number of file descriptors:  231
Reserved number of file descriptors:64

craig


--
craig sanders


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

Re: cron jobs more often than daily

[Kai Henningsen]

[EMAIL PROTECTED] (Christian Schwarz)  wrote on 06.01.98 in <[EMAIL PROTECTED]>:

>   (b) We set up a certain directory (say /usr/lib/cronjobs) where each
>   package can install its own crontab file (/usr/lib/cronjobs/foo).

Use /etc/cron.often (or similar name). It will contain crontabs, not  
executable scripts. All of them will be conffiles, so the sysadmin can  
change them without fear of updates.

Disadvantage: needs a patch for cron, to scan this directory as well as  
the usual user crontab directory, and to execute those cronjobs as root,  
not as a user.

Policy would be to only use this for cron jobs that absolutely cannot be  
handled by any of the other /etc/cron.period directories.

MfG Kai


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

Re: What's Debian's /usr/src policy

[Kai Henningsen]

[EMAIL PROTECTED] (Martin Mitchell)  wrote on 06.01.98 in <[EMAIL PROTECTED]>:

> [EMAIL PROTECTED] (Kai Henningsen) writes:
>
> > [EMAIL PROTECTED] (Martin Mitchell)  wrote on 06.01.98 in
> > <[EMAIL PROTECTED]>:
> >
> > > Stephen Zander <[EMAIL PROTECTED]> writes:
> > >
> > > > Martin Mitchell <[EMAIL PROTECTED]> writes:
> > > > > Ian Jackson <[EMAIL PROTECTED]> writes:
> > > > > > Why does libc6 depend on kernel-header ?
> > > > >
> > > > > It's libc6-dev that has that dependency.
> > > > > Perhaps weakening the dependency to Suggests might be the best
> > > > > solution.
> > > >
> > > > No, you can't.  Their are multiple header files that will be flat
> > > > *broken* without a /usr/include/{linux,asm}.
> > >
> > > I know, however it would allow people to much more easily install and
> > > maintain their own kernel sources for these includes.
> >
> > Which is why we shouldn't do that. Remember, we *DO NOT* want them to
> > include their own kernel sources for these includes, because it is a *VERY
> > BAD IDEA*.
>
> Rubbish, it's essential for almost all architectures except i386 and alpha,
> that are not yet integrated with the main kernel source.

Complete and utter bullshit.

The "we really need specific headers" thing is true for _all_  
architectures; the reasons are completely independant of architecture.

Where to get those specific headers - that is, which patches to apply -  
might differ between architectures, but the principle is the same:

/usr/doc/libc6-dev/FAQ.Debian.gz (this one is from the previous version):

-
Q1: Why does Debian provide kernel headers with the libc6-dev package
instead of using the standard Linux convention of having symlinks to
the currently installed kernel?

A1: Manoj Srivastava explains why (this was originally for libc5, but
is still valid for libc6):

> From: Manoj Srivastava <[EMAIL PROTECTED]>
>
>   The headers were included in libc5-dev after a rash of very
>  buggy alpha kernel releases (1.3.7* or something like that) that
>  proceeded to break compilations, etc.  Kernel versions are changed
>  far more rapidly than libc is, and there are higer chances that
>  people install a custom kernel than they install custom libc.
>
>   Add to that the fact that few programs really need the more
>  volatile elements of the header files (that is, things that really
>  change from kernel version to kernel version), [before you reject
>  this, consider: programs compiled on one kernel version usually work
>  on other kernels].
>
>   So, it makes sense that a set of headers be provided from a
>  known good kernel version, and that is sufficient for compiling most
>  programs, (it also makes the compile time environments for programs
>  on debian machines a well known one, easing the process of dealing
>  with problem reports), the few programs that really depend on cutting
>  edge kernel data structures may just use -I/usr/src/linux/include
>  (provided that kernel-headers or kernel-source exists on the system).
>
>   libc5-deb is uploaded frequently enough that it never lags too
>  far behind the latest released kernel.
>
>   I hope I was clear enough to answer your question.
>
>   manoj
-

There's also a message from Linus somewhere which explicitely agrees with  
that point of view.

MfG Kai


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

Re: please upgrade your packages to current standards

[Kai Henningsen]

[EMAIL PROTECTED] (Dale Scheetz)  wrote on 06.01.98 in <[EMAIL PROTECTED]>:

> On Tue, 6 Jan 1998, Richard Braakman wrote:
>
> > Do we want all packages to include the Section and Priority fields?
>
> Probably.

I tend to do it like this:

* don't include them in the first version of the package

* see where Guy installs it (best look into the override file)

* put those values into the next version

This ought to solve most problems.

MfG Kai


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

Re: What's Debian's /usr/src policy

[Kai Henningsen]

[EMAIL PROTECTED] (Dale Scheetz)  wrote on 06.01.98 in <[EMAIL PROTECTED]>:

> On 6 Jan 1998, Kai Henningsen wrote:
>
> > [EMAIL PROTECTED] (Dale Scheetz)  wrote on 05.01.98 in
> > <[EMAIL PROTECTED]>:
> >
> > > On Mon, 5 Jan 1998, Ian Jackson wrote:
> > >
> > > > I think that /usr/src should the be domain of the local admin.
> > > >
> > > > I don't think kernel-{header,source}-x.xx.deb should exist, really,
> > > > because I don't think source code should be distributed as .deb files
> > > > anyway.  So I'm not unhappy about making a policy decision that leaves
> > > > kernel-{header,source} with nowhere good to go.
> > >
> > > I never understood why the kernel source was made into a .deb package.
> > > It doesn't make sense to me. I also don't see any point in "managing" a
> > > binary package of the kernel either. The system doesn't gain anything by
> > > having dpkg know which kernel binaries are installed either. The binary
> > > thus installed still needs to be configured for lilo or loadlin or grub,
> > > so what's the point?
> >
> > Well, handling kernels with kernel-package is _a_lot_ easier than doing it
> > by hand. I've done both, and I don't want to go back, ever.
>
> I'm sorry, but my experience has been very different. I too have tried
> both. Maybe my timing has been poor, but both times I tried there was a
> mismatch between the kernel-package package and the kernel-source package
> and after much futsing around resulted in failure.

Don't use the kernel-source package, then. I usually don't.

Raw kernel source plus kernel-package is what I use most.

> Kernel source should be provided the way we provide source for all other
> packages. You should be able to unpack it with dpkg-source -x and run
> dpkg-buildpackage and build a kernel to your spec and construct a .deb
> package from that result. (Note, I have no real problem with a
> kernel-binary package, although personally I would have no use for it, I
> can understand others point of view in wishing to "manage" their kernels
> with dpkg)

Well, that's more or less what I do, except I use raw kernels usually.

Ftp the kernel from ftp.kernel.org, unpack somewhere, and then

   make menuconfig
   make-kpkg --revision kai.17 kernel-image # from kernel-package
   dpkg -i ../kernel-image_2.0.33-kai.17_i386.deb

That's *all* there is to it.

And it works. Reliably.

Note that I mentioned kernel-package above, not some kernel-source  
package. If you've never used make-kpkg, then you've definitely missed out  
on something as important as the menu package!

> > > > Why does libc6 depend on kernel-header ?
> > >
> > > I don't know either, but it is on the top of my list of things I need to
> > > understand as the new maintainer. It was my understanding that the way
> > > we deal with kernel headers was supposed to free the c library from the
> > > headers. I don't know that anything has changed in that reguard. I'll
> > > let you know what I find asap.
> >
> > I think our main problem here is that people (including both you and Ian)
> > don't keep on top of debian-private and debian-devel.
>
> I can't speak for Ian here, but I am a constant reader and participant on
> both these lists. Your implication is both unfair and has nothing to do
> with the technical discussion.

Oh yes? I don't think so.

> >I can't count the
> > times this has been explained already, and I get very, very tired of it.
> >
> I am sorry for your exaustion. I am capable of counting, but what is the
> point. The reason this keeps coming up is that, so far, all explanations
> have been inadequate.

Obviously, I think the _explanation_ _is_ adequate. That doesn't mean you  
have to agree it's the right solution, though I do wonder why you haven't  
said so when this was originally discussed.

> > libc6 depends on a specific version of kernel-headers to avoid including
> > what is in that package as a diff. Nothing more, nothing less.
> >
> This exaplanation is inadequate as well. While shrinking the size of a
> diff file helps the developer who pays by the byte/minute for access, it
> creates a problem for the user which is not necessary. Forcing the
> coupling of two packages via depends when the two packages are only used
> together makes installation and upgrades one step more complex than is
> necessary in a way that adds to package bloat when it isn't necessary.
> (BTW it's libc6-dev that is coupled to kenrel-headers)

Well, I do agree that the user side of this seems to be suboptimal right  
now. On the other hand, there's also the problem with packages made from  
multiple sources.

Personally, I don't like either the old or the new solution. And I don't  
have a third one up my sleeve, either.

The only thing that seems clear is that the end effect - specific kernel  
headers - is what we need.


MfG Kai


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

Re: driver for Epson Stylus 300

[David Frey]

On Tue, Jan 6 1998 12:18 +0100 "Meskes, Michael" writes: 
> I'm not sure about uniprint but the stcolor driver usage in magicfilter 
> is outdated, i.e. it uses options no longer avalaible in gs-aladin.

Sigh. gs-alladin is in non-free, so magicfilter can't use it.

David
-- 
David Frey (51F35923114FC864 7D05FF173C61EFDE)
Those who do not understand Unix are condemned to reinvent it, poorly.
  -- Henry Spencer



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

Re: What's Debian's /usr/src policy

[Hamish Moffatt]

On Tue, Jan 06, 1998 at 04:11:57PM +0100, Turbo Fredriksson wrote:
> On Tue, 6 Jan 1998, Hamish Moffatt wrote:
> 
> > I think it does gain something; it is much easier to have multiple
> > versions around. If I compile a new 2.1 kernel and find that
> > it is not too good (like 2.1.76 seems to have broken sound
> > for me so I went back to 2.1.72), I can just reinstall the old
> > one with dpkg. I don't need to edit my lilo config, play with
> > symlinks in / etc.
> 
> If you wrote your lilo config propperly, you did not have to reinstall at 
> all..
> Just have multiple bootable configs and one 'default=xxx' (or whatever it
> was called), which you change depending on your working kernel... I for one
> have ten or fifteen different kernels that I can boot, depending on if the
> new one worked or not...

No, I said I don't want to edit my lilo.conf. The only way to get more
than two kernels (current and previous) is to edit your lilo config
each time. And if one of them is broken, I don't want it to be the default,
so I have to edit lilo.conf again. Easier just to use dpkg I think.


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 FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: What's Debian's /usr/src policy

[Hamish Moffatt]

On Tue, Jan 06, 1998 at 11:42:52AM -0500, Dale Scheetz wrote:
> When I try a new kernel and it doesn't work, I only have to edit
> lilo.config an run lilo to get back to the old one (actually I always
> leave hooks in lilo to get back to the "old" kernel). No package
> installation is required.
> 
> I will also never feel comfortable with an automatic process editing my
> lilo.config file. I am set up to boot several linux partitions as well as
> a dos partition and a loop-root system. I am much happier editing that
> beast myself thankyou ;-)

kernel-package's scripts don't edit lilo.conf. You have two symlinks,
/vmlinuz and /vmlinuz.old, which point to the current and previous kernels.
The scripts just change the symlinks. By default, lilo.conf boots 
/vmlinuz; it's handy to add an entry to boot /vmlinuz.old too.


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 FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Re[2]: cron jobs more often than daily

[Hamish Moffatt]

On Tue, Jan 06, 1998 at 04:27:53PM +0100, Turbo Fredriksson wrote:
> On Tue, 6 Jan 1998, Hamish Moffatt wrote:
> 
> > Because sometimes the jobs need to run as root. Quite often I suspect.
> > My package ipac (which started this) needs to run ipfwadm to configure
> > and reset the IP accounting rules, which requires root.
> 
> Why not use a daemon? In peal, that would be a ten-liner...

That's certainly possible, but it's a bit of a shame to
be implementing custom versions of cron, when cron can do exactly
this already but we don't have any way to configure it so.


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 FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: file descriptors??

[Miquel van Smoorenburg]

In article <[EMAIL PROTECTED]>,
Craig Sanders <[EMAIL PROTECTED]> wrote:
>
>On Tue, 6 Jan 1998, Elie Rosenblum wrote:
>
>> And thus spake Craig Sanders, on Wed, Jan 07, 1998 at 01:52:06AM +1100:
>> > is there any debian policy on number of file descriptors compiled into the
>> > kernel?  (and also in limits.h in libc6-dev - AFAIK pretty much everything
>> > that uses select() will need to be recompiled if the limit is increased).
>> 
>> This has been sysctl configurable in the runtime kernel since at most 2.0,
>> probably 1.3.

Not true. That's the global limit. The per-process limit is hardcoded at
256 fds per process in the 2.0.x kernel

>   [EMAIL PROTECTED] [08:41:43] kernel# cd /proc/sys/kernel/
>   [EMAIL PROTECTED] [08:41:58] kernel# ls -l *-max *-nr
>   -rw-r--r--   1 root root0 Jan  7 08:40 file-max
>   -r--r--r--   1 root root0 Jan  7 08:40 file-nr
>   -rw-r--r--   1 root root0 Jan  7 08:40 inode-max
>   -r--r--r--   1 root root0 Jan  7 08:40 inode-nr
>   [EMAIL PROTECTED] [08:42:41] kernel# echo 2048>file-max; echo 
> 8192>inode-max
>   bash: file-max: Bad file descriptor
>   bash: inode-max: Bad file descriptor

You forgot a space. Try echo 2048 > file-max. 2048>file-max means something
entirely different in shell-syntax..

Mike.
-- 
 Miquel van Smoorenburg |  The dyslexic, agnostic, insomniac lay in his bed
[EMAIL PROTECTED]  |  awake all night wondering if there is a doG


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

Re: file descriptors??

[Craig Sanders]

On 7 Jan 1998, Miquel van Smoorenburg wrote:

> In article <[EMAIL PROTECTED]>,
> Craig Sanders <[EMAIL PROTECTED]> wrote:
> >
> >On Tue, 6 Jan 1998, Elie Rosenblum wrote:
> >
> >> And thus spake Craig Sanders, on Wed, Jan 07, 1998 at 01:52:06AM +1100:
> >> > is there any debian policy on number of file descriptors compiled
> >> > into the kernel? (and also in limits.h in libc6-dev - AFAIK
> >> > pretty much everything that uses select() will need to be
> >> > recompiled if the limit is increased).
> >>
> >> This has been sysctl configurable in the runtime kernel since at
> >> most 2.0, probably 1.3.
>
> Not true. That's the global limit. The per-process limit is hardcoded
> at 256 fds per process in the 2.0.x kernel

yep.  i realised after i sent this last message that i should have specified
that i was talking about the per process fd limit, not the global limit.

> > [EMAIL PROTECTED] [08:41:43] kernel# cd /proc/sys/kernel/
> > [EMAIL PROTECTED] [08:41:58] kernel# ls -l *-max *-nr
> > -rw-r--r--   1 root root0 Jan  7 08:40 file-max
> > -r--r--r--   1 root root0 Jan  7 08:40 file-nr
> > -rw-r--r--   1 root root0 Jan  7 08:40 inode-max
> > -r--r--r--   1 root root0 Jan  7 08:40 inode-nr
> > [EMAIL PROTECTED] [08:42:41] kernel# echo 2048>file-max; echo 
> > 8192>inode-max
> > bash: file-max: Bad file descriptor
> > bash: inode-max: Bad file descriptor
> 
> You forgot a space. Try echo 2048 > file-max. 2048>file-max means something
> entirely different in shell-syntax..

that works now.  which is odd because i cut and pasted Elie's example.

anyway, as you point out, that only sets the global limit, not the
per-process limit.


i've tried applying the "gt256 fd patch" but that causes some NFS
problems (i use nfs to mount my debian mirror for upgrades) which would
probably go away if netstd and netbase were recompiled with the new fd
limit.  I feel that it's a bit unreasonable to expect debian users to
recompile the entire system if they happen to be building a server (e.g.
squid proxy or apache web server) that needs more than 256 fds.  Given
that debian makes an excellent web server or proxy or internet gateway
machine out of the box it's not an uncommon thing to want to do...

btw, as background info for this, i'm building a squid box with dual
ppro 200 cpus, 512mb memory, 40GB disk (32gb cache, 8gb system, logging,
etc and hot-swap root fs). this machine is expected to be able to
handle at least 150 simultaneous users (with netscape's default of 4
connections at once) at any given moment. this is expected _average_
usage. peak usage could be double that. squid could quite easily
require several thousand file descriptors under peak load. to add more
temptation for murphy, this box is to be installed remotely - several
thousand kilometres away. it's being built with the latest unstable now
because i don't want to have to do a libc5 to libc6 upgrade remotely
when hamm gets released...and debian's upgradability (for bug fixes and
security fixes) is absolutely vital for a remote server like this, imo.

you got any good ideas on what to do about the fd limits? is my
assumption that increasing the per process limit will require
re-compiling just about every package (e.g. squid, apache, netstd,
netbase, libc6, . etc) correct or have i misunderstood something
fundamental?

how do you handle this issue on your squid box(es)?

craig

--
craig sanders


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