Re: Looking for debcheck

[Hamish Moffatt]

On Tue, Jan 06, 1998 at 08:05:30PM +0100, Andreas Jellinghaus wrote:
> 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.

Does this mean that deb-check has all of debstd's bugs? :-)


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

[Hamish Moffatt]

On Tue, Jan 06, 1998 at 10:38:15PM +0100, David Frey wrote:
> 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.

It could support it, but it would need to support free alternatives
(ie gs) as well.


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: Bug#16718: kon2: should be Architecture: i386

[yochi]

I Fixed at kon2_0.3.7-4.

From: James Troup <[EMAIL PROTECTED]>
Date: 06 Jan 1998 23:48:18 +

J.J.Troup> Package: kon2
J.J.Troup> Version: 0.3.7-3
J.J.Troup> 
J.J.Troup> The source for this package has hard coded i386 assembler in it and
J.J.Troup> should probably have Architecture: i386 in debian/control and not
J.J.Troup> Architecture: any.

+---+
 Yoshiaki Yanagihara   Debian JP Project
 E-mail: [EMAIL PROTECTED][Japanese] http://www.debian.or.jp/
 [EMAIL PROTECTED]  [English ] Sorry, now under construction.


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

[EMAIL PROTECTED] (Kai Henningsen) writes:

> [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.

It solves the problem with incorrect fields, but not the problem that
prompted my complaint in the first place, namely that the fields are
absent in some (many) packages. 

The Debian distribution is - in my opinion - far too dependent on the
existence of a correct and uptodate Packages file.  E.g. in a
situation with a partial mirror (or partial uptodate mirror) the
Packages file cannot be expected to be fully synchronized with the
mirror.  I like the feature of dpkg/dselect where I can scan a bunch
of packages for this information, but it is not of much use if half of 
the packages come out as unclassified.  This gives me the impression
of a low quality distribution (even Redhat can do this right). 

- Sten Anderson


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

Re: Bug#16663: lyx: depends on xforms0

[Stuart Lamble]

In a private email to me, Gergely Madarasz wrote:
> Btw, I just see the note in the changelog that you dont have time to
> maintain lyx... i could take it over.

Well, that note was accurate at the time I wrote it. :-) I'm about to
start full-time work, so I should have more time to maintain Debian
packages than I did whilst at university.


The key problem is Internet access. I have several accounts, all at
Monash University:

  * Computer center systems ([EMAIL PROTECTED],
[EMAIL PROTECTED]). These will be deleted any time
soon (they're staff accounts, I no longer work as a casual at Monash.)
  * Yoyo account ([EMAIL PROTECTED]). Should last until at
least March, possibly April or May depending on the sysadmin.
  * Novell account ([EMAIL PROTECTED]). Will be disabled at
the end of February.
  * Accounts on Linux systems in the library ([EMAIL PROTECTED]).
Should last indefinitely (I know the sysadmin ;-)


I'm intending to get myself a permanent connection to my home (yes, I'm
addicted to email, amongst other things :-) When that happens, I'll be
picking up again with the project:

  * LyX (if nobody else has taken it over. I'm _sure_ somebody said that
he'd do it..)
  * fsp (it seems to be unwanted, unloved, ... ;-)
  * Modula-3 (compiles into packages just fine with libc5; there are
issues to deal with under libc6.)
  * cvsup (once Modula-3 is working properly.)

I should be back in action within a month or two. As for LyX -- the best
way to proceed would probably be to package 0.11.46 or something of the
sort. (0.12.0pre6, perhaps?)


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

Hamish Moffatt wrote:
> On Tue, Jan 06, 1998 at 10:38:15PM +0100, David Frey wrote:
> > 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.
> 
> It could support it, but it would need to support free alternatives
> (ie gs) as well.
> 
gs-aladin provides gs, conflicts with the package gs and its executables
use the same names as in gs. Thus, since magicfilter supports gs it
also supports gs-aladin.

Magicfilter does not currently support the uniprint driver though.
I edited one of the other files from magicfilter to work with it.
Here is what my setup looks like.

- Jay


I'm not sure if it is proper to have them all use the same
spool directory, but it works. The only problem I've had is
sometimes when I cancel a job, junk gets sent to the printer
(pages and pages worth) and I've had to go in and manually
fix things.
-- begin /etc/printcap --
lp|epl|stc600pl|Epson Stylus 600 low-res:\
:lp=/dev/lp1:sd=/var/spool/lpd/lp:\
:sh:pw#80:pl#66:px#1440:mx#0:\
:if=/usr/sbin/stylus_color_360dpi-filter:\
:af=/var/log/lp-acct:lf=/var/log/lp-errs:
lph|eph|stc600p|Epson Stylus 600 hi-res:\
:lp=/dev/lp1:sd=/var/spool/lpd/lp:\
:sh:pw#80:pl#66:px#1440:mx#0:\
:if=/usr/sbin/stylus_color_720dpi-filter:\
:af=/var/log/lp-acct:lf=/var/log/lp-errs:
lpih|epih|stc600ih|Epson Stylus 600 very hi-res:\
:lp=/dev/lp1:sd=/var/spool/lpd/lp:\
:sh:pw#80:pl#66:px#1440:mx#0:\
:if=/usr/sbin/stylus_color_1440dpi-filter:\
:af=/var/log/lp-acct:lf=/var/log/lp-errs:
-- end /etc/printcap ---

I've included this here as I put in a few extra fixes to some filters.
For example it uses tiff2ps. Look at the bug reports against magicfilter
to see exactly what I changed and what other packages you need to install
to get everything to work.
--- begin /usr/sbin/stylus_color_360dpi-filter -
#! /usr/sbin/magicfilter
#
# Magic filter setup file for EPSON ESC/P2 (i.e. Stylus Color) series color
# printers in 360 dpi
#
# Based on epsonlqc. Modified and partially tested together with the original
# Stylus Color, Ghostscript versions 3.33 and 4.03 by [EMAIL PROTECTED]
# but please no Mail >64 kB to this address.
#
# No warranty for anything whatsoever!
#
# This file is in the public domain.
#
# This file has been automatically adapted to your system.
#
# wild guess: native control codes start with 
0   \033cat

# You really should change Ghostscripts options if you have a version >=3.51
# since the options changed. See devices.doc (or *.txt) for what they do.
# These esoteric options are needed and aren't documented in Ghostscripts
# Manual page since they are specific to the device driver 'stcolor':
#
# -sDEVICE=stcolor -r360 -q -dSAFER -dNOPAUSE -sOutputFile=- stcolor.ps -
#
# The options currently used should work with Ghostscript up to version 3.33.
#
# PostScript
0   %!  filter  /usr/bin/gs  @stc600pl.upp -q -dSAFER -dNOPAUSE 
-sOutputFile=- - -c quit
0   \004%!  filter  /usr/bin/gs  @stc600pl.upp -q -dSAFER -dNOPAUSE 
-sOutputFile=- - -c quit

# PDF
0   %PDFfpipe   /usr/bin/gs  @stc600pl.upp -q -dSAFER -dNOPAUSE 
-sOutputFile=- $FILE -c quit


# TeX DVI
0   \367\002fpipe   /usr/bin/dvips  -D 360  -R -q -f 

# compress'd data
0   \037\235pipe/bin/gzip  -cdq 

# packed, gzipped, frozen and SCO LZH data
0   \037\036pipe/bin/gzip  -cdq 
0   \037\213pipe/bin/gzip  -cdq 
0   \037\236pipe/bin/gzip  -cdq 
0   \037\240pipe/bin/gzip  -cdq 

# troff documents
0   .\?\?\040   fpipe   `/usr/bin/grog  -Tps $FILE` 
0   .\\\"   fpipe   `/usr/bin/grog  -Tps $FILE` 
0   '\\\"   fpipe   `/usr/bin/grog  -Tps $FILE` 
0   '.\\\"  fpipe   `/usr/bin/grog  -Tps $FILE` 
0   \\\"fpipe   `/usr/bin/grog  -Tps $FILE` 

# ditroff
0   "x T ps"pipe/usr/bin/grops 
0   "x T dvi"   pipe/usr/bin/grodvi 
0   "x T ascii" pipe/usr/bin/grotty 
0   "x T latin1"pipe/usr/bin/grotty 
0   "x T lj4"   reject  Cannot print LaserJet 4 ditroff files.

# Portable bit-, grey- and pixmaps
0   P1\npipe/usr/bin/pnmtops  -scale 1000 -dpi 360  
2>/dev/null 
0   P2\npipe/usr/bin/pnmtops  -scale 1000 -dpi 360  
2>/dev/null 
0   P3\npipe/usr/bin/pnmtops  -scale 1000 -dpi 360  
2>/dev/null 
0   P4\npipe/usr/bin/pnmtops  -scale 1000 -dpi 360  
2>/dev/null 
0   P5\npipe/usr/bin/pnmtops  -scale 1000 -dpi 360  
2>/dev/null 
0   P6\npipe/usr/bin/pnmtops  -scale 1000 -dp

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

[Martin Mitchell]

Stephen Zander <[EMAIL PROTECTED]> writes:

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

Yes, that's the point. A Recommends heading would work just fine to allow
this flexibility. Unfortunately the kernel-headers-2.0.32 package is in the
Depends line. I don't like using --force except in exceptional circumstances,
so the current situation is not a proper solution.

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

[Martin Mitchell]

[EMAIL PROTECTED] (Kai Henningsen) writes:

> [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.

Please refrain from such language, it adds nothing to the discussion.

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

That's true, but since other architectures aren't integrated with the kernel
source (yet), the kernel-headers package is not complete for those archs.

> 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):

I know this too. It's the way to go, but sometimes more recent kernel headers
are necessary for some programs, and some architectures.

Martin.


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

Re: boot-floppies progress

[Stephen Zander]

Given the .sig on that message, the packages were suprisingly appropriate :)

-- 
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] .

Request for BO status files

[Jason Gunthorpe]

Hi,

If a few of you could send me your status files from a clean bo system
that is not running any hamm stuff that also has X windows I would be most
appreciative.

The file I am interested in is /var/lib/dpkg/status, it contains your
package selections. I am going to be using them to test out some Deity
functions and all I have access to are hamm machines.

I also have an interest in partial bo/hamm machines, especially more on
the bo side of things.

MIME or UUEncode to [EMAIL PROTECTED], PLEASE do not send these to
the mailing lists.

Thanks,
Jason
Team Deity


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

Perl LWP method for dselect

[Drake Diedrich]

   I'm working on an LWP method for dselect.  Current code is available at
http://biocomp.anu.edu.au/~dld/debian/dpkg-http_0.1_all.deb The method can
use any URL supported by LWP.  Proxies can be set using
ftp_proxy=http://wwwcache and http_proxy=...  Multiple sites can be
specified during Access setup (main archive, non-US archive, local
archives, bo-updates, ...).  The Packages files are downloaded using
mirror(), so if the remote site hasn't changed, the Update function should
return quickly. 

   For the moment, I'm using the standard MIME-Base64 and libwww-perl perl
modules (/usr/local/site_perl/...).  I'm expecting the Debian modules to
be functional soon (libwww-perl is a bit behind, and mime-base64 is m68k
only).

  Yes, I know deity will be out soon, but we're paying $0.19/megabyte
here, and caching helps.

--
Dr. Drake Diedrich, Research Officer - Computing, (02)6279-8302
John Curtin School of Medical Research, Australian National University 0200
Replies to other than [EMAIL PROTECTED] will be routed off-planet


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

Bug#16727: project: xload is no longer available.

[Alexander Stavitsky]

Package: project
Version: N/A

Xload was removed from xproc 1.2.2-1
However it is not available as a part of any other package.
It used to be xcontrib for some time but is no longer there either.


-- System Information
Debian Release: 1.3
Kernel Version: Linux norwood 2.0.32 #1 Thu Dec 18 13:07:55 EST 1997 i586 
unknown


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

Re: Perl LWP method for dselect

[Jason Gunthorpe]

On Wed, 7 Jan 1998, Drake Diedrich wrote:

>   Yes, I know deity will be out soon, but we're paying $0.19/megabyte
> here, and caching helps.

I would be very interested in hearing your experiances with using HTTP for
downloading .debs and the Packages file. I was hoping to use it as the
prefered method with deity.

Jason
Deity Team.


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

Self Referencing depends

[Jason Gunthorpe]

Hi,

In my continuing testing of deity I have discovered a number of packages
that had/have a self referencing depends, ie:

Package: mh
Depends: libc5 (>= 5.4.0-0), mh (>= 6.8.4-11), ncurses3.0 

>From a bo system it seems libpaper, xpm4.7 and mh (at least) have this
problem. I don't know how dpkg allowed this to happen, deity's depends
code prevents a package from satisfying its own dependancies. 

This means packages formed like this will be considered broken by deity
and it will also complain quite abit if someone trys to install them.

I just want to be sure that this IS a packaging bug and not something done
deliberately. It looks like the packages I mentioned above are fixed in
hamm so this only effects bo users and upgrading..

Thanks,
Jason


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

Re: Perl LWP method for dselect

[Drake Diedrich]

On Tue, 6 Jan 1998, Jason Gunthorpe wrote:

> I would be very interested in hearing your experiances with using HTTP for
> downloading .debs and the Packages file. I was hoping to use it as the
> prefered method with deity.
> 

   Not much experience yet, as the code is less than a day old and there
are no HTTP accessible mirrors yet (prod prod).  I just downloaded some
files from nonus.debian.org through the cache at high speed, so they do
cache locally, even when the source is ftp.  HTTP should cache more
reliably (using If-Modified-Since GETs) rather than the heuristics of an
ftp cache.  HTTP/1.0 doesn't support partial retrieves (unlike ftp which
can continue an interrupted download), but HTTP/1.1 does.
   I suspect we'll get better cache hit rates if everyone in Australia
[the world?] uses the same sites (ftp.debian.org.au and nonus.debian.org),
rather than everyone picking a nearby site.  This way the caches will be
more likely to hold a local copy.  Most universities here are in the same
cache heirachy - so using common remote URL's will be cheaper than using
dispersed interstate URLs.  I don't think the smaller ISP's are as
organized (judging by their volume limits), but the larger ones may be.
More sophisticated hashing (HTTP/1.1?) in the caches might make this all
irrelevant.

-Drake



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

Re: Perl LWP method for dselect

[Sten Anderson]

Drake Diedrich <[EMAIL PROTECTED]> writes:

> On Tue, 6 Jan 1998, Jason Gunthorpe wrote:
> 
> > I would be very interested in hearing your experiances with using HTTP for
> > downloading .debs and the Packages file. I was hoping to use it as the
> > prefered method with deity.
> > 
> 
>Not much experience yet, as the code is less than a day old and there
> are no HTTP accessible mirrors yet (prod prod).  

There is a http mirror in Denmark at:

http://sunsite.auc.dk/ftp/pub/os/linux/debian/

(accessing this from Australia may require a little patience :)

- Sten Anderson


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

Re: Custom library for emacs 19.34 ?

[Hannu Koivisto]

Gregor Hoffleit <[EMAIL PROTECTED]> writes:

| I have tried to package custom (look at  
| http://www.mathi.uni-heidelberg.de/~flight/debian-private/custom/) so that  
| it can be dropped in for emacs-19.34 and that works for python-mode.el  
| 3.28. Still I've heard rumours that custom-1.9961 breaks GNUS. Perhaps  
| interested parties could try this package.

I don't know about your package but at least when I tried new
custom package (because of new python-mode) with emacs-19.34 it
indeed broke Gnus. That is, the Gnus that comes with
emacs-19.34. 

I don't really see the point of installing newest versions of
elisp stuff to old versions of emacs, especially when only few
elisp packages are available as Debian packages.

Actually your custom package should now depend on Emacs 20* and
that would be pointless. If Gnus were provided as a package,
Gnus version 5.5 (which is the one that comes with Emacs 20*
AFAIK) could simply depend on this new custom package and Gnus
5.3 would depend on older custom and conflict with the new
one. Gnus 5.5 again could be installed with emacs-19.34 (unless,
of course, it again breaks something that I'm not aware of).

Summa summarum: stick to packages with similar age to emacs
distribution's age, use Gnus 5.3, old custom and old python-mode
with emacs-19.34 _or_ start modularizing emacs so that its elisp
packages can be updated independently as Debian packages with
reasonable dependency/conflict control.

| If it does no big damage, I'd like to suggest to include this in hamm  
| somehow (either as separate package, or as addition to emacs).

Sorry, but you don't get my vote with this plan. Unless you
provide at least Gnus as a separate package, users can
easily break emacs by installing a package (custom in this
case) that conflicts with something (Gnus 5.3 in this case) in a
way that dpkg can't see (because custom conflicts with Gnus 5.3,
which is contained in emacs-19.34, which custom doesn't conflict
with (according to your idea)).

just my 2c,

-- 
Hannu Koivisto | What you see is all you get.
NOYB   |- Brian Kernighan
-


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

Re: Self Referencing depends

[jdassen]

On Tue, Jan 06, 1998 at 11:34:01PM -0700, Jason Gunthorpe wrote:
> In my continuing testing of deity I have discovered a number of packages
> that had/have a self referencing depends, ie:

> I just want to be sure that this IS a packaging bug and not something done
> deliberately. It looks like the packages I mentioned above are fixed in
> hamm so this only effects bo users and upgrading..

I suspect a self-referenced "Depends:" is always a bug. However, you also
reported a bug in the "ddd" package that "Provides:" itself. This type of
self-reference need not be a bug.

For instance, take "unzip". The "unzip" and "unzip-crypt" (on non-US)
packages both provide the virtual package "unzip", so that other packages
can have a "Depends: unzip" (the virtual one), without having to know which
packages actually provide that functionality.

Ray
-- 
LEADERSHIP  A form of self-preservation exhibited by people with auto-
destructive imaginations in order to ensure that when it comes to the crunch 
it'll be someone else's bones which go crack and not their own.   
- The Hipcrime Vocab by Chad C. Mulligan


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

RE: Bug#16727: project: xload is no longer available.

[Meskes, Michael]

I think we have to report this against the appropriate X package now
since procps source does no longer contain xload. Quite some time ago we
decided to go with procps' xload simply because it was better than the X
one. Now it seems we have to revert that decision.

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: Alexander Stavitsky [SMTP:[EMAIL PROTECTED]
> Sent: Wednesday, January 07, 1998 6:30 AM
> To:   debian-bugs-dist@lists.debian.org
> Cc:   debian-devel@lists.debian.org
> Subject:  Bug#16727: project: xload is no longer available.
> 
> Package: project
> Version: N/A
> 
> Xload was removed from xproc 1.2.2-1
> However it is not available as a part of any other package.
> It used to be xcontrib for some time but is no longer there either.
> 
> 
> -- System Information
> Debian Release: 1.3
> Kernel Version: Linux norwood 2.0.32 #1 Thu Dec 18 13:07:55 EST 1997
> i586 unknown
> 
> 
> --
> 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: file descriptors??

[Meskes, Michael]

Isn't there a bug in the 2.0 series that makes the kernel bomb when too
many file-descriptors are used?

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: Craig Sanders [SMTP:[EMAIL PROTECTED]
> Sent: Tuesday, January 06, 1998 11:08 PM
> To:   Elie Rosenblum
> Subject:  Re: file descriptors??
> 
> 
> 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] .


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

As long as it still uses gnu gs too, there shouldn't be a problem.

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: David Frey [SMTP:[EMAIL PROTECTED]
> Sent: Tuesday, January 06, 1998 10:38 PM
> To:   debian-devel@lists.debian.org
> Subject:  Re: driver for Epson Stylus 300 
> 
> 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] .


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

Apparently the 300 is not compatible to the 600. When I use the stcolor
driver with 720x720 dpi I just get white paper, but lots of that. In
fact the printing doesn't finish before I switch of the printer. When
using 360x360 I get correct output but always using color ink to print
black (hmm, even a colored image is printed that way). After some tips
(600 related) I tried using stcolor.ps but that gives me the white pages
again.

Finally I gave up last night and tried installing the Windows NT driver
just to see some nice output, but it didn't install either. After some
looking around in the docu I found that they do not have one for NT. The
NT driver only works with the 400 and 600 series. Since I have NT on my
machine for work reasons, I could try that. But I refuse to install that
bastard 95 just to print!

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: Tuesday, January 06, 1998 5:48 PM
> To:   [EMAIL PROTECTED]
> Cc:   [EMAIL PROTECTED]; [EMAIL PROTECTED];
> debian-devel@lists.debian.org
> Subject:  Re: driver for Epson Stylus 300
> 
> > 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] .

Isaac Asimov and the millenium bug [offtopic]

[Juan Cespedes]

On Tue, 6 Jan 1998, Fabrizio Polacco wrote:

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

I have it in a book called "Change! 71 Glimpses of the
Future".  This book is a list of articles written by Isaac from 1974
to 1980.

I only have it in spanish; ISBN: 84-206-9978-0.

Isaac Asimov suggests that we should always use the decimal
system, with one day as the base, and forget about hours, minutes,
seconds, weeks, months, years and so on.  For example, the actual date
would be "10227.4042" (10227 days since Jan 1 1970, 0.4042 days since
12 AM (UTC)).  Using 4 decimals will give us a precision of 8.6
seconds.

-- 
Juan Cespedes


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

Re: Ian Jackson back

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Mon, 5 Jan 1998, Ian Jackson wrote:
> I'm now properly back.  I'll try to catch up on the mailing lists in
> the next few days.

Great! Will you be so kind to:

a) Put bug web pages in normal order.

and

b) divert all those 300K reports from debian-bugs-dist to debian-bugs-reports.


as you said you were going to do?

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

iQCVAgUBNLNgiCqK7IlOjMLFAQHpVQQApu+ZQ1XVJItGgWhUocfiQ95P7LFEQcYQ
+aJzYS33wQNv21ZUNAd1/loFAOgdryMotDPqx3/e86fNLD/gTaDXGHdlVp5jmSfg
BbQdzpUQE8knr5LFMzZMRRt1qyzTcuMc+hm44M/qH5kEF0C7EAaxkPRiE4yMopnA
jdQsf27MV4g=
=VFEk
-END PGP SIGNATURE-


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

Re: Perl LWP method for dselect

[Hamish Moffatt]

On Wed, Jan 07, 1998 at 06:35:30PM +1100, Drake Diedrich wrote:
>I suspect we'll get better cache hit rates if everyone in Australia
> [the world?] uses the same sites (ftp.debian.org.au and nonus.debian.org),

ftp.debian.org.au == ftp.debian.org; ftp.au.debian.org is different
though. It has non-us too.

> dispersed interstate URLs.  I don't think the smaller ISP's are as
> organized (judging by their volume limits), but the larger ones may be.
> More sophisticated hashing (HTTP/1.1?) in the caches might make this all
> irrelevant.

A whole bunch of medium sized ones here in Melbourne have the peering
through working quite nicely. My ISP is connected to an ISP who's
on the backbone, so performance is quite nice. From there we hit
the connect.com.au proxy and so on.

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] .

Is xforms0.86 save to install?

[Alan Eugene Davis]

BY the way, I don't feel comfortable about posting to the developers's
list, although I do lurk there.  

I had some trouble installing some packages that needed xforms0.86.
xforms0.86, in turn, needed elf-x11r6lib, which apparently is
obsolete.  

Is it safe to install xforms0.86, not including the dev package?  

Thank you for any possible reply, as well as to the several thoughtful
people who have responded to other concerns of mine recently.

Alan 

-- 
"Our loyalties are to the species and the   Alan E. Davis
planet.  We speak for Earth. Our[EMAIL PROTECTED]
obligation to survive is owed not just to   Marianas High School  
ourselves but also to that Cosmos, ancient  AAA196, Box 10001 
and vast, from which we spring."Saipan, MP  96950 
Northern Mariana Islands  
   ---Carl SaganGMT+10


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

On 6 Jan 1998, Kai Henningsen wrote:

> [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.

I like this option, too.

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

It's a small "disadvantage", after all.

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

Yes, that's very important to point out: Anacron will only run scripts in
the /etc/cron.period directories. Therefore, only jobs which can safely be
ignored if the system is powered down can be placed into /etc/cron.often. 
(What about "/etc/cron.generic" ?)


Other opinions?


Thanks,

Chris

--  Christian Schwarz
   [EMAIL PROTECTED], [EMAIL PROTECTED]
  [EMAIL PROTECTED], [EMAIL PROTECTED]
   
PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
  
 CS Software goes online! Visit our new home page at
 http://www.schwarz-online.com


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

Re: Self Referencing depends

[Christian Schwarz]

On Wed, 7 Jan 1998 [EMAIL PROTECTED] wrote:

> On Tue, Jan 06, 1998 at 11:34:01PM -0700, Jason Gunthorpe wrote:
> > In my continuing testing of deity I have discovered a number of packages
> > that had/have a self referencing depends, ie:
> 
> > I just want to be sure that this IS a packaging bug and not something done
> > deliberately. It looks like the packages I mentioned above are fixed in
> > hamm so this only effects bo users and upgrading..

How does this affect upgrading from bo? I think, deity should support
these upgrades in a user friendly manner. Otherwise, people will hate
deity as they hate dselect from the first minute.

> I suspect a self-referenced "Depends:" is always a bug. However, you also
> reported a bug in the "ddd" package that "Provides:" itself. This type of
> self-reference need not be a bug.
> 
> For instance, take "unzip". The "unzip" and "unzip-crypt" (on non-US)
> packages both provide the virtual package "unzip", so that other packages
> can have a "Depends: unzip" (the virtual one), without having to know which
> packages actually provide that functionality.

Why has "unzip" to "Provide" itself? As "unzip" is a _real_ package, there
should be no need for a "virtual" package. (Of course, "unzip-crypt" would
have to Provide: unzip.)

But note, that a package may "Conflict:" with something it provides:

   Package: sendmail
   Version: 8.8.5-1
   Provides: mail-transport-agent
   Conflicts: mail-transport-agent, smail


Thanks,

Chris

-- Christian Schwarz
[EMAIL PROTECTED], [EMAIL PROTECTED],
Don't know Perl? [EMAIL PROTECTED], [EMAIL PROTECTED]
  
Visit  PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
http://www.perl.com http://fatman.mathematik.tu-muenchen.de/~schwarz/


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

Re: Perl LWP method for dselect

[Michael Alan Dorman]

Drake Diedrich <[EMAIL PROTECTED]> writes:
>For the moment, I'm using the standard MIME-Base64 and libwww-perl perl
> modules (/usr/local/site_perl/...).  I'm expecting the Debian modules to
> be functional soon (libwww-perl is a bit behind, and mime-base64 is m68k
> only).

The latest libwww-perl should be out there, although there are
apparently some problems getting libmime-base64 out of incoming.

I'll try and expedite this.

Mike.
-- 
Michael Alan Dorman   | E-Mail: [EMAIL PROTECTED]
Network Administrator | Phone: (305) 284-2463
University of Miami School of Law |   Fax: (305) 284-3753


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

Dale Scheetz wrote:
> 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.

But it doesn't put them in, even if the information is in the control
file, unless you give it the -isp flag.

>From "man dpkg-gencontrol":
   -is, -ip, -isp
  Include the Section and Priority  fields  for  this
  package  from  the  main source control file in the
  binary package control file being generated.   Usu?
  ally  this  information  is  not included here, but
  only in the  .changes  file.   -isp  includes  both
  fields,  -is only the Section and -ip only the Pri?
  ority.

All my packages have section and priority information in the control
file, but only three packages call dpkg-gecontrol -isp, because I
never saw a reason to care one way or another.  Only those three have
the information in their deb files.

If we all agree that putting this information in the binary packages
is a good thing, then I'd say it is much better to change the default
in dpkg, than to have every maintainer check every rules file.

The packaging manual also has a paragraph about this:

   These fields may appear in binary package control files, in which case
   they provide a default value in case the Packages files are missing
   the information. dpkg and dselect will only use the value from a .deb
   file if they have no other information; a value listed in a Packages
   file will always take precedence. By default dpkg-genchanges does not
   include the section and priority in the control file of a binary
   package - use the -isp, -is or -ip options to achieve this effect.

By now I'm really curious about the reason :-)

Richard Braakman


--
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:
>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.

What I do is something different. I put this in /etc/initscript:

# Set # of fd's to 256 for all processes.
ulimit -S -n 256

That sets the soft limit for all processes to 256 fds. It can be raised
by an individual process if needed. My /etc/init.d/squid script contains:

MAXFD=`ulimit -H -n`
if [ "$MAXFD" -gt 1024 ]
then
MAXFD=1024
fi
ulimit -n $MAXFD

So this way, the number of file descriptors for squid is 1024 max, but
for all other proceses it's limited to 256.

>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).

That's a nice box. But don't expect any extra performance because it's
a SMP machine - squid is one monolithic process and will not benefit from
a second processor.

32 GB cache and 512MB of mem sounds about right for squid, you could do
with 256 or 384 MB if you'd run squid-novm (but squid-novm uses a lot
more file descriptors).

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

Don't worry - we have exactly the same setup (only 9GB of cache tho')
and it hasn't crashed ever. Except for the libc6 problems, but these
are now solved. I sacrificed myself as guinea pig when the box was
still installed here locally, and I think all bugs are gone now.

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

[Miquel van Smoorenburg]

In article <[EMAIL PROTECTED]>,
Meskes, Michael <[EMAIL PROTECTED]> wrote:
>Isn't there a bug in the 2.0 series that makes the kernel bomb when too
>many file-descriptors are used?

Not if you use the right patch to raise the number of file descriptors
(search for filehandle.patch.linux, or look in the squid FAQ)

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: Self Referencing depends

[Santiago Vila]

-BEGIN PGP SIGNED MESSAGE-

On Wed, 7 Jan 1998 [EMAIL PROTECTED] wrote:

> For instance, take "unzip". The "unzip" and "unzip-crypt" (on non-US)
> packages both provide the virtual package "unzip", so that other packages
> can have a "Depends: unzip" (the virtual one), without having to know which
> packages actually provide that functionality.

BTW: Now that I think of it... Does the fact that unzip-crypt provides
unzip make unzip to be a virtual package? If so, should I ask unzip and
zip to be added to the authoritative list of virtual packages?

Thanks.

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

iQCVAgUBNLOHGyqK7IlOjMLFAQEHlAP/Xd677zFh8LOYxaNTEyVgNDlqaYJ7s3vX
ZHeFfFJJs4J3ZUvaBhBTrsYc7kUu/sYh+CTWPF0oLVY/LD1YW3uxEWIOKHG4Y9hX
JOf7LwGR1xjQ3H9o33HlbSepnHA2m+9w4UGhsMFBy+d+F5vkZmWuPtRnVN9PcsuK
ES1iJ/JDxWQ=
=IP9y
-END PGP SIGNATURE-


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

Re: file descriptors??

[Kai Henningsen]

[EMAIL PROTECTED] (Craig Sanders)  wrote on 07.01.98 in <[EMAIL PROTECTED]>:

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

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

Well, with libc6, they don't have to, unles they need more than 1024 files  
per process. Kernel and maybe libc, but not the rest.

See this excerpt from /usr/include/gnu/types.h:



/* One element in the file descriptor mask array.  */
typedef unsigned long int __fd_mask;

/* Number of descriptors that can fit in an `fd_set'.  */
#define __FD_SETSIZE1024

/* It's easier to assume 8-bit bytes than to get CHAR_BIT.  */
#define __NFDBITS   (8 * sizeof (__fd_mask))
#define __FDELT(d)  ((d) / __NFDBITS)
#define __FDMASK(d) (1 << ((d) % __NFDBITS))

/* fd_set for select and pselect.  */
typedef struct
  {
/* XPG4.2 requires this member name.  */
__fd_mask fds_bits[__FD_SETSIZE / __NFDBITS];
  } __fd_set;


typedef int __key_t;



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

That depends on how far you want to increase it.


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

[Dale Scheetz]

On Wed, 7 Jan 1998, Richard Braakman wrote:

> Dale Scheetz wrote:
> > 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.
> 
> But it doesn't put them in, even if the information is in the control
> file, unless you give it the -isp flag.

You are correct. I was confused...the gmp2 package includes these fields
in the "package" paragraph of the master control file, and they are also
in the packages control file. Other packages of mine, like diff only have
these fields in the "source" paragraph, and they don't appear in the
package. I mistakenly assumed that this was the only difference, but the
gmp2 package, on closer inspection, does use the -isp flag with
gencontrol, so that was the "real" reason.

I believe that if these fields are provided in the "package" paragraph,
that dpkg should automatically include them in the control fields for the
package.

On the other hand, what's 4 characters in the rules file cost?

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] .

perl5.004 for bo

[David Morton]

Greetings from Kansas,

I am quite upset with the fact that no update for perl has
been included in the "stable" release, currently named bo, I think.

A security bug in suid-perl has been known to exist in 5.003, as you
have noticed on your security page.  However, the IRC people
told me that 5.004 only existed in hamm.  This is *NOT* acceptable.
I am not able to move to a glibc base at this time, and I use
Linux in a commercial environment.  I need STABLE, and I need
secure.  (As well as some features of 5.004 to compile MySQL)
A production machine has just been rendered useless due to this.
(No not a breach of security, but lack of functionality)

I wasted 5 hours yesterday trying to get 5.004 installed, but to no
avail.  If Debian is interested in keeping commercial use
of Linux, this kind of issue needs to be fixed ASAP.

In the meantime, I'm switching back to RedHat4.2 as I can't
waste any more time on this.  I have deadlines, after all.
MySQL compiled out of the box on RedHat; As it should.

-
David Morton
System Administrator
Computer Advantage


--
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:
> >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.
> 
> What I do is something different. I put this in /etc/initscript:
> 
> # Set # of fd's to 256 for all processes.
> ulimit -S -n 256
> 
> That sets the soft limit for all processes to 256 fds. It can be raised
> by an individual process if needed. My /etc/init.d/squid script contains:
> 
> MAXFD=`ulimit -H -n`
> if [ "$MAXFD" -gt 1024 ]
> then
> MAXFD=1024
> fi
> ulimit -n $MAXFD
> 
> So this way, the number of file descriptors for squid is 1024 max, but
> for all other proceses it's limited to 256.

i'll have to think about this.  Does this mean that you don't have to
actually patch the kernel any more?  all you have to do is set the
appropriate values in /proc/sys/kernel and then increase the ulimit?

i just ran 'ulimit -H -n' on my linux 2.0.32 machines and got 256.  Did
you have to recompile the kernel to get more than that? what kernel
version are you running?

i think there's something quite basic that i must be missing...something
must have changed. it used to be that you hacked limits.h and fs.h
in /usr/src/linux/include/linux and recompiled the kernel and then
recompiled whatever apps needed more fd's. sounds like that's not true
any more.


> >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).
>
> That's a nice box. But don't expect any extra performance because it's
> a SMP machine - squid is one monolithic process and will not benefit
> from a second processor.

yes.  very nice.  wish i had one here at home.

the extra cpu is for the redirectors. this machine will also have to do
a lot of filtering (using a redirector program rather than squid's acls
so we can offload the processing load to the 2nd cpu). it's going into a
school network and has to to provide the teachers with "access control".

> 32 GB cache and 512MB of mem sounds about right for squid, you could
> do with 256 or 384 MB if you'd run squid-novm (but squid-novm uses a
> lot more file descriptors).

i don't believe in squid-novm :-). file descriptors are a scarcer
resource than memory.


> >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.
>
> Don't worry - we have exactly the same setup (only 9GB of cache tho')
> and it hasn't crashed ever. Except for the libc6 problems, but these
> are now solved. I sacrificed myself as guinea pig when the box was
> still installed here locally, and I think all bugs are gone now.

yep, i've built several debian-based squid proxies of around the
256MB RAM and 9GB disk size - they work wonderfully.  These machines
have worked so well that a few people who started out with anti-linux
attitudes have admitted that they were wrong :-)

(you may remember that i was the one who made the first debian package
for squid back in june '96, and then ran out of time to maintain it)

craig

--
craig sanders


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

Re: perl5.004 for bo

[Martin Schulze]

On Wed, Jan 07, 1998 at 08:18:22AM -0600, David Morton wrote:

> I am quite upset with the fact that no update for perl has
> been included in the "stable" release, currently named bo, I think.
> 
> A security bug in suid-perl has been known to exist in 5.003, as you
> have noticed on your security page.  However, the IRC people
> told me that 5.004 only existed in hamm.  This is *NOT* acceptable.

Please file a bug report against the perl package.

I the meantime you can try the packages I have compiled for
a much simplier reason:
ftp://ftp.infodrom.north.de/pub/people/joey/debian/hamm-files-for-bo-systems/perl*

> secure.  (As well as some features of 5.004 to compile MySQL)
> A production machine has just been rendered useless due to this.
> (No not a breach of security, but lack of functionality)

Why not just grab the perl 5.004 source and just compile it?
That's what I've done iirc.

> I wasted 5 hours yesterday trying to get 5.004 installed, but to no
> avail.  If Debian is interested in keeping commercial use
> of Linux, this kind of issue needs to be fixed ASAP.

This sounds quite unfriendly for me.  Who pays us that we
*have to* update the packages?  I'd appreciate any hint for
security fixes or things that we had forgotton (we're only
humans, you know?) but I get offended if people are telling
me what I _have to_ do in my spare time.

Again: Please file a bugreport against perl so that a new
perl will be installed in bo alias stable.

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 /


pgpbGGPKCMXvT.pgp
Description: PGP signature

Libc6 progress: 1998-01-07

[Richard Braakman]

This is a list of packages in the main distribution that need work to
be fully libc6-based.  I base it on the Packages file at my local mirror,
so it may be a day or two out of date.  If you have questions about why
a particular package is on the list, or if you think there is an error,
don't hesitate to contact me.

Since the last time I mailed this list, Packages bulkmail, chord,
dbview, grmonitor, mdutils, modemu, netatalk, omirr, pacman, povray,
pstoedit, radiusd-livingston, sliphangup, super, tkdesk, tkdiff, tkps,
wu-ftpd, and xspread were converted to libc6.

Packages aout-binutils, aout-gcc, blt, dld, f2c, guile-lib, libfcgi1,
libpam-util, mesa2-widgets, ratfor77, and xega were removed or moved
to project/orphaned for various reasons.

Package htdig popped up in the list after the new rx1 library was
installed, and a new version has already been uploaded.

This leaves 76 packages in the list, with 2 conversions on the way and
4 obsolete.

Heiko Schlittermann <[EMAIL PROTECTED]>:
  wu-ftpd-academ-2.4.2.13-0 (Adam Heath has a new version ready)

Martin Soto <[EMAIL PROTECTED]>:
  wxwin-ol-dev-1.66B-1
  wxwin-ol-runtime-1.66B-1
  wxwin-dev-1.66B-1
  wxwin-ol1-1.66B-1

Soenke Lange <[EMAIL PROTECTED]>:
  smail-3.2.0.92-2(important) (New versions are still libc5)

Johnie Ingram <[EMAIL PROTECTED]>:
  php-2.0b10-5(extra)

joost witteveen <[EMAIL PROTECTED]>:
  nfsroot-0.5
  axe-6.1.2-6  (Listed as "Needing a new maintainer")
  wm2-3-2  (Listed as "Needing a new maintainer")

Yoshiaki Yanagihara <[EMAIL PROTECTED]>:
  kterm-6.2.0-5(Upgrade in Incoming)

Stephan Alexander Suerken <[EMAIL PROTECTED]>:
  gom-x-0.29.10-1  (Mixed dependencies)

Lawrence Chim <[EMAIL PROTECTED]>:
  cqcam-0.40b-2(extra) (Being worked on)
  vic-cqcam-2.8-2(extra) (Being worked on)

David H. Munro <[EMAIL PROTECTED]>:
  yorick-gist-1.4-5(New version is still libc5)
  yorick-1.4-5 (New version is still libc5)

Neil A. Rubin <[EMAIL PROTECTED]>:
  wmaker-0.6.3-1   (Mixed dependencies)
  afterstep-1.0-5  (Mixed dependencies)

Christian Meder <[EMAIL PROTECTED]>:
  amanda-client-2.3.0.4-2
  amanda-2.3.0.4-2

Dale Scheetz <[EMAIL PROTECTED]>:
  imap-4-4-4

Paul Seelig <[EMAIL PROTECTED]>:
  psutils-1.17-1   (Will be taken by Rob Browning)

Peter Tobias <[EMAIL PROTECTED]>:
  enscript-1.5.0-3 (Upgrade in Incoming)

Karl Sackett <[EMAIL PROTECTED]>:
  libtclobjc1-1.1b6-1
  blt2-2.1-6

Sue Campbell <[EMAIL PROTECTED]>:
  lapack-2.0.1-1

Christian Schwarz <[EMAIL PROTECTED]>:
  htdig-3.0.8b2-1  (Upgrade in Incoming)

Wichert Akkerman <[EMAIL PROTECTED]>:
  xcdroast-0.96-1  (Waiting for upstream version)

Christian Hudon <[EMAIL PROTECTED]>:
  icont-9.1-1
  iconx-9.1-1
  iconc-9.1-1

Craig Small <[EMAIL PROTECTED]>:
  ax25-utils-2.1.37a-1(extra) (Obsolete, will be removed)

Billy C.-M. Chow <[EMAIL PROTECTED]>:
  p3nfs-5.1-2(extra)

Patrick J. Edwards <[EMAIL PROTECTED]>:
  bitchx-bin-0.70-2

Brian White <[EMAIL PROTECTED]>:
  gnats-tk-3.104-1

Tom Lees <[EMAIL PROTECTED]>:
  e2compr-1.06-2(extra) (Difficult; awaiting consensus)
  iproute-961225-2(extra) (Difficult; being worked on)

Hakan Ardo <[EMAIL PROTECTED]>:
  compface-1989.11.11-12 (Mixed dependencies)
  xfaces-3.3-9 (Depends on both xlib6 and xlib6g)

Radu Duta <[EMAIL PROTECTED]>:
  xosview-1.5.0-1

Sven Rudolph <[EMAIL PROTECTED]>:
  cti-ifhp-2.1.8-1

Fabien Ninoles <[EMAIL PROTECTED]>:
  vrweb-1.3-1

"Boris D. Beletsky" <[EMAIL PROTECTED]>:
  xinetd-2.1.7-3(extra) (Adam Heath has a new version ready)

John Goerzen <[EMAIL PROTECTED]>:
  perl-curses-1.01-1   (Superseded by libcurses-perl)

James LewisMoss <[EMAIL PROTECTED]>:
  xemacs20-20.2-4  (Mixed dependencies)
  xemacs19-19.16-1 (Mixed dependencies)

Philippe Troin <[EMAIL PROTECTED]>:
  perlmagick-1.15-2
  imagemagick-3.9.0-1
  libhdf4g-dev-4.0.2-4 (Depends on libhdf4)

(orphan):
  objpak-dev-1.1.1-1
  objpak1-1.1.1-1
  xmailtool-3.1.2b-1
  ftnchek-2.9.4-1
  vgrind-5.7-10
  groupkit-3.2-1
  saoimage-1.19-4  (Mixed dependencies)
  gettyps-2.0.7i-1(extra)

Klee Dienes <[EMAIL PROTECTED]>:
  ilu-base-2.0.0.8-2
  python-misc-1.4.0-4  (Being worked on by Gregor Hoffleit)
  python-tk-1.4.0-4
  python-net-1.4.0-4   (Being worked on by Gregor Hoffleit)
  win32gcc-17.1-1
  python-curses-1.4.0-4 (Being worked on by Gregor Hoffleit)
  win32binutils-17.1-1
  python-mpz-1.4.0-4   (Being worked on by Gregor Hoffleit)
  python-base-1.4.0-4  (Being worked on by Gregor Hoffleit)
  python-gdbm-1.4.0-4  (Being worked on by Gregor Hoffleit)
  python-bsddb-1.4.0-4 (Being worked on by Gregor Hoffleit)
  ksmbfs-2.0.1-2(extra) (Superseded by smbfs)

Joe Reinhardt <[EMAIL PROTECTED]>:
  dxpc-3.7.0-1

Federico Di Gregorio <[EMAIL PROTECTED]>:
  tkstep42-4.2-1   (Superseded by tkstep4.2)

Rob Browning <[EMAIL PROTECTED]>:
  rscheme-0.7.1-2

Gordon Russell <[EMAIL PROTECTED]>:
  doc++-3.01-1

Hanno Wagner <[EMAIL PROTECTED]>:
  qps-1.1-1

Volker Ossenkopf <[EMAI

Re: Self Referencing depends

[jdassen]

On Wed, Jan 07, 1998 at 02:46:25PM +0100, Santiago Vila wrote:
> BTW: Now that I think of it... Does the fact that unzip-crypt provides
> unzip make unzip to be a virtual package?

Yes. Though other packages can still have "Depends:", "Conflicts:" etc. with
the concrete pkunzip package if there is a version number mentioned, I
think.

> If so, should I ask unzip and zip to be added to the authoritative list of
> virtual packages?

Perhaps. It would be very useful if someone could go over the actual virtual
packages (grep '^Provides:' /var/lib/dpkg/available) and see what other
virtual packages ought to be registered with the authorative list.

Ray
-- 
Obsig: developing a new sig


--
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 6 Jan 1998, Rob Browning wrote:

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

I have been looking al over for this trick... Tried this one to, which did
not work...

---
 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: perl5.004 for bo

[Scott Hanson]

At 8:18 Uhr -0600 07.01.1998, David Morton wrote:
>Greetings from Kansas,
>
>I am quite upset with the fact that no update for perl has
>been included in the "stable" release, currently named bo, I think.
>
>A security bug in suid-perl has been known to exist in 5.003, as you
>have noticed on your security page.  However, the IRC people
>told me that 5.004 only existed in hamm.  This is *NOT* acceptable.
>I am not able to move to a glibc base at this time, and I use
>Linux in a commercial environment.  I need STABLE, and I need
>secure.  (As well as some features of 5.004 to compile MySQL)

For mysql, try running the configure script with the flag '--without-perl'.
It should then skip the perl packages when compiling... you can then
compile the perl stuff separately, if you need it.

Scott

Johmsweg 9, D-21266 Jesteburg, Germany
[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

[Turbo Fredriksson]

On Tue, 6 Jan 1998, Dale Scheetz wrote:

> I will also never feel comfortable with an automatic process editing my
> lilo.config file.

I do agree on that... :)

> 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 ;-)

A loop-root?

---
 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: Self Referencing depends

[Jason Gunthorpe]

On Wed, 7 Jan 1998 [EMAIL PROTECTED] wrote:

> On Tue, Jan 06, 1998 at 11:34:01PM -0700, Jason Gunthorpe wrote:
> > In my continuing testing of deity I have discovered a number of packages
> > that had/have a self referencing depends, ie:
> 
> > I just want to be sure that this IS a packaging bug and not something done
> > deliberately. It looks like the packages I mentioned above are fixed in
> > hamm so this only effects bo users and upgrading..
> 
> I suspect a self-referenced "Depends:" is always a bug. However, you also
> reported a bug in the "ddd" package that "Provides:" itself. This type of
> self-reference need not be a bug.

Check the archives, I brought this up for discussion a few months ago and
some ppl fixed their packages but others haven't and 2 more ppl used this
broken system so I filed bugs against them all.

It was generally agreed that it is wrong for a package to provide itself,
this is implicit.
 
> For instance, take "unzip". The "unzip" and "unzip-crypt" (on non-US)
> packages both provide the virtual package "unzip", so that other packages

Unzip does not need to provide unzip, it IS unzip and will match any
depends for unzip. Only unzip-crypt needs to provide unzip because it
isn't called unzip!

The same is true for the 4 packages I filed bugs against.

Jason


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

Dale Scheetz wrote:

> I believe that if these fields are provided in the "package" paragraph,
> that dpkg should automatically include them in the control fields for the
> package.

So do I.  I don't see any reason why it should not.

> On the other hand, what's 4 characters in the rules file cost?

Well... I can think of a couple of costs :-)

  - All maintainers have to go check their rules files and add this flag.
  - Inevitably, many will forget or won't notice, so someone will have
to spend time filing bug reports and chasing after maintainers.
(Consider how long it's taking to get the changelog and copyright
 files named right in all packages)
  - It will be one more thing that new maintainers can get wrong about
a package.

Richard Braakman


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

Re: Self Referencing depends

[Jason Gunthorpe]

On Wed, 7 Jan 1998, Christian Schwarz wrote:

> On Wed, 7 Jan 1998 [EMAIL PROTECTED] wrote:
> 
> > On Tue, Jan 06, 1998 at 11:34:01PM -0700, Jason Gunthorpe wrote:
> > > In my continuing testing of deity I have discovered a number of packages
> > > that had/have a self referencing depends, ie:
> > 
> > > I just want to be sure that this IS a packaging bug and not something done
> > > deliberately. It looks like the packages I mentioned above are fixed in
> > > hamm so this only effects bo users and upgrading..
> 
> How does this affect upgrading from bo? I think, deity should support
> these upgrades in a user friendly manner. Otherwise, people will hate
> deity as they hate dselect from the first minute.

When you run deity on a bo system it will consider all installed packages
with this screwy depends setup to be broken and will complain bitterly.
There is very little I can do about that without weakening the depends
checking. I hope this will not be a problem, upgrading from bo with Deity
will be okay, only running deity on an all bo system will have issues.
 
> But note, that a package may "Conflict:" with something it provides:
> 
>Package: sendmail
>Version: 8.8.5-1
>Provides: mail-transport-agent
>Conflicts: mail-transport-agent, smail

This is exactly why Deity will never match a depends against the owning
package. We handle all depends in the same way so if you say that 'A
package may not conflict with itself' then you are also saying 'A package
may not depend on itself'. Since conflicts is just a form of depends. 
 
Jason


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

Re: Self Referencing depends

[Christian Schwarz]

On Wed, 7 Jan 1998 [EMAIL PROTECTED] wrote:

> On Wed, Jan 07, 1998 at 02:46:25PM +0100, Santiago Vila wrote:
> > BTW: Now that I think of it... Does the fact that unzip-crypt provides
> > unzip make unzip to be a virtual package?
> 
> Yes. Though other packages can still have "Depends:", "Conflicts:" etc. with
> the concrete pkunzip package if there is a version number mentioned, I
> think.
> 
> > If so, should I ask unzip and zip to be added to the authoritative list of
> > virtual packages?

The policy for virtual packages allow use of "unregistered" virtual
packages (i.e., those that are not on the list) for "local use":

  ``Packages MUST NOT use virtual package names (except privately, amongst
  a cooperating group of packages) unless they have been agreed upon and
  appear in this list.''

In my interpretation, your case (unzip) is covered by the exception. Any
objections?

> Perhaps. It would be very useful if someone could go over the actual
> virtual packages (grep '^Provides:' /var/lib/dpkg/available) and see
> what other virtual packages ought to be registered with the authorative
> list. 

Yes, this would be good. But remember, that not every "Provide:" has to be
registered (see above). 

I think you can exclude virtual packages which have a corresponding "real"
package (like in the case of unzip), and also virtual packages which come
from the same source/maintainer (i.e., the lg-* packages all provide
lg-issue).


thanks,

Chris

-- Christian Schwarz
[EMAIL PROTECTED], [EMAIL PROTECTED],
Don't know Perl? [EMAIL PROTECTED], [EMAIL PROTECTED]
  
Visit  PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
http://www.perl.com http://fatman.mathematik.tu-muenchen.de/~schwarz/


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

According to Craig Sanders:
> > What I do is something different. I put this in /etc/initscript:
> > 
> > # Set # of fd's to 256 for all processes.
> > ulimit -S -n 256
> > 
> > That sets the soft limit for all processes to 256 fds. It can be raised
> > by an individual process if needed. My /etc/init.d/squid script contains:
> > 
> > MAXFD=`ulimit -H -n`
> > if [ "$MAXFD" -gt 1024 ]
> > then
> > MAXFD=1024
> > fi
> > ulimit -n $MAXFD
> > 
> > So this way, the number of file descriptors for squid is 1024 max, but
> > for all other proceses it's limited to 256.
> 
> i'll have to think about this.  Does this mean that you don't have to
> actually patch the kernel any more?  all you have to do is set the
> appropriate values in /proc/sys/kernel and then increase the ulimit?

No, you will still have to patch the kernel with the filehandle.patch.linux
patch. I forgot the original location, but it's also available at

ftp://ftp.cistron.nl/pub/linux/kernel/unoff-patches/v2.0/filehandle.patch.linux

> i just ran 'ulimit -H -n' on my linux 2.0.32 machines and got 256.  Did
> you have to recompile the kernel to get more than that? what kernel
> version are you running?

2.0.33 + the above mentioned patch.

> (you may remember that i was the one who made the first debian package
> for squid back in june '96, and then ran out of time to maintain it)

Oh yes, ofcourse!

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] .

intent to package quake2, qwcl, qwsv and unixded

[Roderick Schertler]

I'm going to start working on packages for quake2, qwcl (the Quakeworld
client), qwsv (the Quakeworld server) and unixded (the Quake dedicated
server).  I spoke to Joey Hess, he said he doesn't intend to package any
of them.

All of these packages will have to go in non-free.

What should the package for unixded be called?  I'm thinking quake-server.

I've got an expect script I use for my Quake servers which reboots them
if they become stuck.  Would it be appropriate to ship that and use it
by default with the server packages?

-- 
Roderick Schertler
[EMAIL PROTECTED]


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

Re: Libc6 progress: 1998-01-07

[Dale Scheetz]

On Wed, 7 Jan 1998, Richard Braakman wrote:

> This is a list of packages in the main distribution that need work to
> be fully libc6-based.  I base it on the Packages file at my local mirror,
> so it may be a day or two out of date.  If you have questions about why
> a particular package is on the list, or if you think there is an error,
> don't hesitate to contact me.
> 
> Dale Scheetz <[EMAIL PROTECTED]>:
>   imap-4-4-4
> 
Memory says that someone else took over this package...but I can't
remember who. I'll look over my archives and see if I can figure it out.

If you remember who you are ;-) let me know how it's going, or something.

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] .

Re: Isaac Asimov and the millenium bug [offtopic]

[Fabrizio Polacco]

On  7 Jan, Juan Cespedes wrote:
> On Tue, 6 Jan 1998, Fabrizio Polacco wrote:
> 
>> 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.
> 
>   Isaac Asimov suggests that we should always use the decimal
> system, with one day as the base, and forget about hours, minutes,
> seconds, weeks, months, years and so on.  For example, the actual date
> would be "10227.4042" (10227 days since Jan 1 1970, 0.4042 days since
> 12 AM (UTC)).  Using 4 decimals will give us a precision of 8.6
> seconds.
> 

Humm, the one that I recall was to divide the year in 4 seasons and
count days per season instead than month (91), plus one spare day to be
used as a "foolish-day". The peculiarity was that in that proposal the
sequence of days, weeks, seasons was the same on every year, that is to
say that (I guess) the 3rd of spring was thursday on every year ...

He calculated the savings of all the economic activities because of a
highly prevedible calendar.
 


Fabrizio, flying highly offtopic :-)
-- 
| [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: AucTeX

[Adam P. Harris]

[Removed CC to ]

[You ("Davide G. M. Salvetti")]
>1) AucTeX has many .el's which should be shipped byte-compiled: should I
>compile them with some specific Emacs flavor or doesn't it matter which
>Emacs I'll use?  (Please consider that, AFAIK, XEmacs comes with its own
>AucTeX, so AucTeX should probably care only about GNU/Emacs; I'm not sure,
>about that, though, mainly 'cause I don't use XEmacs :-).)

Yes sir that is correct at this point.  Word is that eventually XEmacs 
will unbundle a lot of the lisp packages it comes with but for now that 
is the case.  With xemacs19-19.16-1 I have AucTeX v 9.7l.

>3) Current AucTeX package puts its data (.elc's) in /usr/lib/emacs/common;
>should I put them in /usr/share/emacs/whatever_is_more_appropriate or
>something else instead?  (Please, consider FHS and FSSTND, and the fact
>many packages already put stuff in /usr/share.)

I'd leave it where it is.  Or else put it in share and symlink from /usr/
lib/emacs/common.  We'll embrace FHS in 2.1 or so; right now it's FSSTD 
which is stipulated by policy.

>4) AucTeX needs to periodically scan (La)TeX style files to keep itself in
>touch with what one has installed on his machine;  it does this by
>cron.weekly.  Current AucTeX package puts resulting files under /usr
>(precisely just where it puts its data: /usr/lib/emacs/common);  I believe
>I should put things under /var, instead: any comments, please?

Yes, /var/lib/emacs/auctex perhaps?

>5) Current AucTeX package puts its configuration files directly under
>/etc/elisp: is this still good behavior?

Yes, I think so, although Robert Browning was doing some Emacs 20 (?) 
work which would imping upon all this and the byte-compilation issues.

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


--
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 Wed, 7 Jan 1998, Turbo Fredriksson wrote:

> On Tue, 6 Jan 1998, Dale Scheetz wrote:
> 
> > 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 ;-)
> 
> A loop-root?
> 
With a small patch to the kernel and some modification of the loop device
code, you can create a file-system-in-a-file. Using the loop device
the internal file system can be mounted as the root file system for the
kernel. These patches were never adopted by the kernel, and it is getting
harder and harder to apply them, so I currently use a patched 2.0.27
kernel to boot that system. 

I provide this monstrosity as "Drop in Debian", configured to provide a
platform on a DOS machine sufficient to building a custom kernel. The
concept is easily expandable to take over whatever disk space you have
available ;-)

The one I boot with lilo is on an ext2 partition (another beauty of the
imbeded file system, it can be coppied to almost any other file system).
Interesting point: on an ext2 file system, no care need be taken. On a DOS
file system the file system must be un-fragmented (using dfrag) before the
DiD installation will work properly. The funny part of this is that it
doesn't matter whether you do the dfrag before you copy the file system,
or afterwards, it still works. Without it you get file system errors.

This was an interesting concept when I first ran into it, but the need for
it is slowly going away. I keep the one file system around for testing
purposes, as it's easy to make a back up copy of the system, do
testing...destroy the file system completely, and recover to the initial
state by simply copying the backup file over the broken one.

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] .

xtar, xtar-smotif, xtar-dmotif orphaned

[Steve Dunham]

The source package "xtar" and resultant binary packages "xtar-smotif"
and "xtar-dmotif" are now orphaned.


Steve
[EMAIL PROTECTED]


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

Re: Emacs20 and mail file locking.

[Rob Browning]

[EMAIL PROTECTED] (Karl M. Hegbloom) writes:

> > "Rob" == Rob Browning <[EMAIL PROTECTED]> writes:
> 
> Rob> Assuming you're right, and movemail is used for all mail
> Rob> locking, then if we patch movemail to use liblockfile, we
> Rob> should be fine.
> 
>  I volunteer to try rolling those patches into XEmacs 20.5.  I think
>  that configure ought to detect `liblockfile' and compile `movemail'
>  accordingly.  Sound right?

Maybe you already knew this, but I just got around to looking at the
movemail source for emacs 20, and it really looks like movemail
already knows how to handle liblockfile.  Check out MAIL_USE_MAILLOCK
and HAVE_TOUCHLOCK.

If someone who knows liblockfile better than I do gets motivated
before I do, please check movemail to make sure it really is doing the
right thing when those vars are defined, and let me know.

Thanks

-- 
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: please upgrade your packages to current standards

[Dale Scheetz]

On Wed, 7 Jan 1998, Richard Braakman wrote:

> Dale Scheetz wrote:
> 
> > I believe that if these fields are provided in the "package" paragraph,
> > that dpkg should automatically include them in the control fields for the
> > package.
> 
> So do I.  I don't see any reason why it should not.
> 
> > On the other hand, what's 4 characters in the rules file cost?
> 
> Well... I can think of a couple of costs :-)
> 
>   - All maintainers have to go check their rules files and add this flag.

This is a good thing. I encourage everyone to periodically look at the
rules file for each of your packages. I keep a check list of these sorts
of issues that I go over when I make a pass at my packages.

Admittedly just because I do it this way doesn't mean it's the best way
for everyone. (or even for me ;-)

>   - Inevitably, many will forget or won't notice, so someone will have
> to spend time filing bug reports and chasing after maintainers.

Sounds like a lot of exercise (with all that chasing) which is something
I could use more of ;-)

> (Consider how long it's taking to get the changelog and copyright
>  files named right in all packages)

It is interesting that you choose this example. I saw that as one of the
most positive uses of the bug tracking system for the year 1997!

All funnies aside, the bug tracking system is *the* method for resolving
such issues, whether the bug report is against dpkg or the packages that
fail to provide fields is another matter. I would say that if you submit a
bug against dpkg *and* all packages that don't provide it, it is even
money as to which solution will be implemented first, but closure will
eventually happen.

>   - It will be one more thing that new maintainers can get wrong about
> a package.

We should have a list ;-)

While I admit that unnecessary complication causes unecessary error. This
is all "pretty well" documented, and as changes happen (like new policy)
the documentation should be made to properly track those changes. (we are
actually doing a much better job in this arena than we have historically
and this causes a problem in itself)

As a "not so new" maintainer, the recend changes in the documentation have
made it harder for me to keep track of "what the current policy" actually
is. I read the packaging guidelines from cover to cover when they first
came out, and used that information to convert my packages to the new
source format. I found that task quite straight forward, at the time, and
still find package construction to be a very clean process (without any
helpers thankyou...). Only by watching discussions like this, on the
lists, and making an "action item list" from those discussions, can I hope
to keep my packages "up to date". The fact that I fall behind, and miss
things on the lists (dispite my best attempts) makes me more and more
reliant on the bug tracking system to keep me in line on these issues.

***

What we need first is a policy statement on the issue (policy statements
should not declare implimentation details unless absolutely necessary) so
that bugs can be filed against dpkg and packages that don't already supply
the new policy.

Looking back over the last statement, I find that I have fallen into "the
policy" trap myself. That is, it is a trap to use policy to dictate bug
reports. I heard someone say recently that all bug reports should quote
the paragraphs in the policy document that qualify/quatify the bug. The
implication here is that the only valid bug report is one based on our
policy statements, which completely ignores "brokenness" issues, as well
as other reasons for bug reports. I would clarify the statement with "only
if the bug is addressed by Debian Policy..."

Given that, I guess the quickest approach would be to file a bug against
dpkg and begin policy discussions. That should give most of us time to
impliment the new policy before it is declared ;-) and those of us who
don't get to it can recieve bug reports. If the dpkg maintainer agrees
that it should get fixed soon and has the time to work on it, we may even
see dpkg deal with the problem seamlessly.

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] .

loop-root (was What's Debian's /usr/src policy)

[Adam P. Harris]

[You (Dale Scheetz)]
>On Wed, 7 Jan 1998, Turbo Fredriksson wrote:
>> A loop-root?

>With a small patch to the kernel and some modification of the loop device
>code, you can create a file-system-in-a-file. 

You can do this already in stock debian (rex and hamm) with 
  mount -o loop -t

Why do you need to patch the kernel for this?

>Using the loop device
>the internal file system can be mounted as the root file system for the
>kernel. These patches were never adopted by the kernel, and it is getting
>harder and harder to apply them, so I currently use a patched 2.0.27
>kernel to boot that system. 

Why do you have to patch the kernel at all?  I already have this
funcationality w/ initrd. Again, this is on an upatched 2.0.30 and 2.0.32 
kernels.

BTW, I use it on my custom-rolled boot floppies for debian booting off a
floppy for a laptop which runs an initrd w/ cardmgr on it so I could get
PCMCIA subsystem up and play with NFS-mounting root.  I have a little make
file which makes a pretty complete but small initrd file system (using
mount -o loop) complete w/ shared libs etc, even ash.  It all works, at
least to the extent that NFS-root works well at all (which is not much but
I haven't gotten around to pestering Joost about it).

Alternatively you could use the ramdisk and just mount root in the same 
basic fashion (although initrd is a little different -- not much really).

>The one I boot with lilo is on an ext2 partition (another beauty of the
>imbeded file system, it can be coppied to almost any other file system).
>Interesting point: on an ext2 file system, no care need be taken. On a DOS
>file system the file system must be un-fragmented (using dfrag) before the
>DiD installation will work properly. The funny part of this is that it
>doesn't matter whether you do the dfrag before you copy the file system,
>or afterwards, it still works. Without it you get file system errors.

Never noticed this issue on my 'mount -o loop' and initrd scheme.  Using 
SYSLINUX to boot I think.

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


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

auto-pgp

[Ian Jackson]

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.

I don't know about anyone else, but I still use it.

If noone else wants it, since I'm the upstream author, I could quite
happily take the package back.  The current maintainer is Mike Deisher
<[EMAIL PROTECTED]> and I'm happy for him to keep it if he's
still there.

Ian.


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

Re: Libc6 progress: 1998-01-07

[Joel Klecker]

-BEGIN PGP SIGNED MESSAGE-

Regarding "Libc6 progress: 1998-01-07" of 6:22 AM -0800 1/7/98, Richard
Braakman wrote:
>  vgrind-5.7-10

I have uploaded a libc6 build of vgrind, and have adopted the package.

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



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

iQCVAwUBNLPMIAoYIlYX1XaBAQFCUQQAgrqO+ADfp9VJsGAKTPBnK03SWiD0B9m/
SLNUoLu8cs4M1hBn2oOE1DUMIJaAD3fNltqgdBo3U0mI+f0+iWaTy07hjsF348uW
3Ct8PLxyLo2UO8rtNsW1ERoOR2I8T0THaEPSVnn5agfV6X4fdyYzIq+ZmNlrGCat
wCKSev9ZtCg=
=6wDn
-END PGP SIGNATURE-


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

Re: Self Referencing depends

[Ian Jackson]

The meaning of self-referencing dependencies is as follows:

 A (version x) --Depends-> A (no version specified)
 A (version x) --Depends-> A (satisfied by x)
 A (version x) --Provides-> A (version x)
   Useless, but should be allowed and ignored.

 A (version x) --Depends-> A (not satisfied by x)
   Dependency cannot be satisfied; this is definitely a bug.
   Behaviour should be sane (no coredumps, etc) but may be arbitrary
   (installation program may ignore it, complain, whatever).

 A (version x) --Conflicts-> A (no version specified)
   Ignored as regards A itself, but may be affected by Provides in
   other packages.

 A (version x) --Conflicts-> A (version spec y)
   Ignored as regards A itself; currently no meaning because Provides
   are not versioned, but they will be and then it will have the
   obvious meaning.

 A (version x) --Provides-> A (not version x)
   Currently not supported (syntax error), but in future will allow
   differently-versioned dependencies to be satisfied.  When this is
   possible it should be used only with great care. 

I believe that dpkg's behaviour conforms to this specification, and
that always-broken self-referential dependencies are ignored.

Deity should conform to this specification too.  If that means
changing its dependency calculation code then it should be changed.

Ian.


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

Re: loop-root (was What's Debian's /usr/src policy)

[Michael Stone]

Quoting Adam P. Harris ([EMAIL PROTECTED]):
> [(Dale Scheetz)]
> >With a small patch to the kernel and some modification of the loop device
> >code, you can create a file-system-in-a-file. 
> 
> You can do this already in stock debian (rex and hamm) with 
>   mount -o loop -t
> 
> Why do you need to patch the kernel for this?

I think there was a kernel patch to allow booting directly off the
loopback device, without needing a floppy.
 
Mike Stone


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

Re: Self Referencing depends

[Jason Gunthorpe]

On Wed, 7 Jan 1998, Ian Jackson wrote:

> The meaning of self-referencing dependencies is as follows:
> 
>  A (version x) --Depends-> A (no version specified)
>  A (version x) --Depends-> A (satisfied by x)
>  A (version x) --Provides-> A (version x)
>Useless, but should be allowed and ignored.
> 
>  A (version x) --Depends-> A (not satisfied by x)
>Dependency cannot be satisfied; this is definitely a bug.
>Behaviour should be sane (no coredumps, etc) but may be arbitrary
>(installation program may ignore it, complain, whatever).
>
>  A (version x) --Conflicts-> A (no version specified)
>Ignored as regards A itself, but may be affected by Provides in
>other packages.
> 
>  A (version x) --Conflicts-> A (version spec y)
>Ignored as regards A itself; currently no meaning because Provides
>are not versioned, but they will be and then it will have the
>obvious meaning.
> 
>  A (version x) --Provides-> A (not version x)
>Currently not supported (syntax error), but in future will allow
>differently-versioned dependencies to be satisfied.  When this is
>possible it should be used only with great care. 
> 
> I believe that dpkg's behaviour conforms to this specification, and
> that always-broken self-referential dependencies are ignored.

AFAIK dpkg does.
 
> Deity should conform to this specification too.  If that means
> changing its dependency calculation code then it should be changed.

Okay, I will add a special case for dependancies that are not conflicts to
make it conform to what you have specified.

Could you clarify the last situation you have written? I am not sure what
you mean in that case. (A (version x) --Provides-> A (not version x))

Most people who have posted on this subject seem to agree that self
depending should be reported as a bug so the only reason I am changing
deity is for backwards compatibility with dpkg. I see no real reason to
support these sort of buggy packages.

There are some other cases in the display code where this issue comes up.
I will be leaving those as is. This will be more clear later..

Jason



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

Re: Is xforms0.86 save to install?

[Ben Gertzfield]

> "Alan" == Alan Eugene Davis <[EMAIL PROTECTED]> writes:

Alan> Is it safe to install xforms0.86, not including the dev
Alan> package?

I've recently uploaded re-done and working versions of both
libforms0.86 and libforms0.88. They're sitting in Incoming now, and
work fine. :)

-- 
Brought to you by the letters W and T and the number 7.
"Do you wish to see our *surprising toys*? No! Do not!" -- Orz, SCII
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] .

netpbm status?

[Wichert Akkerman]

Is anyone maintaining netpbm? AFAIK the current version is still
libc5 based. I've recompiled it for libc6 here and cold upload
it if noone objects.

Wichert.

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


pgpeqlj4c8jJ8.pgp
Description: PGP signature

Re: Question/request concerning master

[Amos Shapira]

In message <[EMAIL PROTECTED]> you write:
|On 6 Jan 1998, Rob Browning wrote:
|
|> Or if you use X, just put:
|>=20
|>   exec ssh-agent ~/.x-common-startup
|>=20
|> in your .xinitrc.  Then you can run ssh-add once after logging in, and
|> never type the phrase again until you log out.
|
|I have been looking al over for this trick... Tried this one to, which did
|not work...

It's very simple (assuming that a .xsession is equal in function to .xinitrc) 
here is my .xsession:

--
#!/bin/sh --
# execute the rest of the .xsession file through the ssh-agent
exec /usr/bin/ssh-agent $HOME/.xsession-ssh
--

And here is my .xsession-ssh:
--
#!/bin/sh --
export PATH="/usr/local/bin:/usr/sbin:$PATH"
xrdb $HOME/.Xresources
# run window manager first and remember its pid
fvwm & wmpid=$!
# Next line is significant:
xtoolwait /usr/bin/ssh-add < /dev/null
xtoolwait xterm -geometry +150+8
xtoolwait xterm -geometry +150+385
xtoolwait xdaliclock
xtoolwait xemacs -f mh -name emh -iconic
#xsetroot -solid RoyalBlue4 &
xsetroot -solid DeepSkyBlue4 &
#xsetbg -smooth -border DeepSkyBlue4 -center ~/etc/pictures/float.jpg
#xearth &
unclutter &
netscape -iconic &
# wait for the window manager to exit, this marks the logout
wait $wmpid
--

And here is something relevant from the .fvwmrc (artificially
line-warped):

Style "SSH Authentication Passphrase Request" NoTitle, NoHandles, \
Sticky, WindowListSkip, StaysOnTop

One "bug" I noticed which is worked on by the author is that ssh-add
seems to call ssh-askpass using a system(3) call without quoting the
user identification comment, so you should avoid characters which are
meaningfull to the shell in the user identification comment.
Otherwise you can do something like:

ssh-askpass | ssh-add

instead of the call to ssh-add above.

And while I'm on the soap-box - who should I talk to about an offer to
provide "auto-login"?  I find it very convenient that my home machine
boots and automatically "logs me in".  I have it set up and working
for a year and I think it would be very usefull to most home users.

Cheers,

--Amos

--Amos Shapira| "Of course Australia was marked for
133 Shlomo Ben-Yosef st.  |  glory, for its people had been chosen
Jerusalem 93 805  |  by the finest judges in England."
ISRAEL[EMAIL PROTECTED] | -- Anonymous


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

[Jason Gunthorpe]

On Wed, 7 Jan 1998, Amos Shapira wrote:

> In message <[EMAIL PROTECTED]> you write:
> |On 6 Jan 1998, Rob Browning wrote:
> |
> |> Or if you use X, just put:
> |>=20
> |>   exec ssh-agent ~/.x-common-startup
> |>=20
> |> in your .xinitrc.  Then you can run ssh-add once after logging in, and
> |> never type the phrase again until you log out.
> |
> |I have been looking al over for this trick... Tried this one to, which did
> |not work...
> 
> It's very simple (assuming that a .xsession is equal in function to .xinitrc) 
> here is my .xsession:

Simpler than that, just put

eval `ssh-agent`

At the top of your .xsession. Call ssh-add from a xterm when you want to
enable your key. 

Jason


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

Debian and memory

[APreusse]

Hello,
i have
only one problem. My computer has a memory amount of 128 mb, but linux(debian)
only recognizes 64 mb of memory.
I would be very pleased, if you can send me a e-mail with the solution of my
problem.
My e-mail adress is "[EMAIL PROTECTED]".
Thank you very much


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

Re: Debian and memory

[Simon's Mailing List Account]

First, you need to send mail to the correct mailing list. This is
debian-devel; questions like that should go to debian-user, or
should be answered by one of the many available FAQs.

Add append="mem=128m" to your /etc/lilo.conf and re-run lilo and reboot
(test first though by adding it to the kernel command line at bootup)

Simon

On Wed, 7 Jan 1998, APreusse wrote:

> Hello,
> i have
> only one problem. My computer has a memory amount of 128 mb, but linux(debian)
> only recognizes 64 mb of memory.
> I would be very pleased, if you can send me a e-mail with the solution of my
> problem.
> My e-mail adress is "[EMAIL PROTECTED]".
> Thank you very much

Simon Karpen[EMAIL PROTECTED]
Sysadmin, Shodor Education Foundation

"On two occasions I have been asked [by members of Parliament!], `Pray,
Mr.  Babbage, if you put into the machine wrong figures, will the right
answers come out?'  I am not able rightly to apprehend the kind of
confusion of ideas that could provoke such a question."
-- Charles Babbage



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

Re: Debian and memory

[Turbo Fredriksson]

On Wed, 7 Jan 1998, APreusse wrote:

> My computer has a memory amount of 128 mb, but linux(debian)
> only recognizes 64 mb of memory.

Add the following line to your '/etc/lilo.conf':

- s n i p p -
append="mem=128Mb"
- s n i p p -

Or, at your lilo prompt: 'mem=128Mb'...

---
 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: cron jobs more often than daily

[Joey Hess]

Christian Schwarz wrote:
> Yes, that's very important to point out: Anacron will only run scripts in
> the /etc/cron.period directories. Therefore, only jobs which can safely be
> ignored if the system is powered down can be placed into /etc/cron.often. 
> (What about "/etc/cron.generic" ?)

How about /etc/cron.frequent?

-- 
see shy jo


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

Anybody tried to compile COAS ?

[Gregor Hoffleit]

Has anybody tried the COAS 0.09 snapshot with Debian ? With a few  
small modifications it compiled and installed for me. Many of the  
tests succeed, but the `table' UI test with qt interface hangs, all UI  
tests with curses interface segfault or dump cores, and all python  
programs with UI don't work.

I tried this with two different versions of python 1.5, once with  
threading enabled (linked against libc6' libpthread) and once without  
threading support. This seemed to influence the point of crash, so  
there might be a problem with compiling threading into python  
(although python did pass all other threading tests).

I'd like to hear other experiences with COAS and Debian. Did anybody  
try it on an libc5 system ?

Gregor


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

Re: Custom library for emacs 19.34 ?

[Gregor Hoffleit]

Hannu Koivisto <[EMAIL PROTECTED]> wrote in reply to me:

>  If it does no big damage, I'd like to suggest to include this in
>  hamm somehow (either as separate package, or as addition to
>  emacs).

Sorry, but you don't get my vote with this plan. Unless you
provide at least Gnus as a separate package, users can
easily break emacs by installing a package (custom in this
case) that conflicts with something (Gnus 5.3 in this case) in a
way that dpkg can't see (because custom conflicts with Gnus 5.3,
which is contained in emacs-19.34, which custom doesn't conflict
with (according to your idea)).

Ok, I could make python-elisp 1.5 depend on  
xemacs19|xemacs20|emacs20|custom-el, make a second package  
python-oldelisp (no dependencies since it would work with all  
emacsen), and finally a third package custom-el which recommends a  
fourth package gnus (>=5.5).

That would make the users of 67% of Debian emacsens happy and provide  
the remaining with two options.

Isn't it a pity that there's no established way to package elisp for  
Debian in a way that supports all emacsens, as far as possible.


Gregor


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

Re: Self Referencing depends

[Tommi Virtanen]

On Wed, Jan 07, 1998 at 11:49:46AM +0100, Christian Schwarz wrote:
> > > In my continuing testing of deity I have discovered a number of packages
> > > that had/have a self referencing depends, ie:
> > 
> > > I just want to be sure that this IS a packaging bug and not something done
> > > deliberately. It looks like the packages I mentioned above are fixed in
> > > hamm so this only effects bo users and upgrading..
> How does this affect upgrading from bo? I think, deity should support
> these upgrades in a user friendly manner. Otherwise, people will hate
> deity as they hate dselect from the first minute.

Are we going to support upgrading from any level of previous
install to hamm? Because the deity problems could be avoided
by providing new bo-updates versions of packages that have a
self-referential Depends: -line. Ugly, but it would work (Or
so it seems). Would policy allow this? Do you think it would
be too much trouble for upgraders? Why is this text a block?

-- 
[EMAIL PROTECTED] - it's a valid address w/o spam | +358-50-5124907
f u cn rd ths, thn u cn rd perl 2 | rm -rf / && echo bye-bye. |   --tv


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

Re: Custom library for emacs 19.34 ?

[Rob Browning]

Gregor Hoffleit <[EMAIL PROTECTED]> writes:

> Isn't it a pity that there's no established way to package elisp for  
> Debian in a way that supports all emacsens, as far as possible.

It's in the works.  We've recently had an initial discussion about the
problems involved in supporting all the emacsen simultaneously which
was enough to make me back off until I get an initial emacs20 package
out.

However, I'm about to propose an interim step which if agreed to by
the other emacsen maintaners will ease the transition to the "right"
solution once we figure out what that is.

-- 
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] .

libc5 to libc6 auto-upgrade script

[Craig Sanders]

i think we're going to need some sort of auto-upgrade script to include on
the hamm release CD rom, because dselect just can't do the libc6 upgrade
safely (AFAIK).  The CD will also Need a top-level README.NOW file saying
run this script first or suffer the consequences...would be nice if we
could have a note printed on the "Oficial" :-) CD-ROMS produces by various
manufacturers too.

Anyway, I wrote a primitive one based on Scott Ellis' HOWTO.

Here it is.  This script is untested.  I've never actually run it.  It
is, however, an accurate duplicate of what I've done by hand over a
dozen times by now.  It will probably need some tweaking, in particular,
the command line options for dpkg may need some --force- options.

Also, all the "*/foo_*.deb" filenames should probably be replaced with
the correct section directories.

Anyone got a bo machine they want to test this on?  I haven't got any left,
they're all upgraded now :-)

--- cut here --- 
#! /bin/sh

# upgrade a libc5 (bo) machine to libc6 (hamm).

# based on Scott Ellis' excellent "Debian libc5 to libc6 Mini-HOWTO"
# document.

# first, build up a list of installed -dev packages so that we can
# remove them.
#
# this is necessary even on machines which aren't doing libc6
# development because libc5 can't be upgraded to latest without removal
# of libc5-dev which also necessitates removal of other -dev packages
# like libdb1-dev and libdl1-dev if they are installed.

DEVPACKAGES=`dpkg --get-selections | 
grep -- -dev | 
grep -v deinstall | 
cut -f1`

dpkg --purge $DEVPACKAGES

# now install the new versions of things.  Just the bare minimum to let
# the user safely run dselect for the rest of the upgrade.

# change this to prompt the user for the location of the debian archive.

cd /debian/dists/unstable/main/binary-i386

# libc
#
dpkg -iB */ldso_*.deb */libc5_*.deb */libc6_*.deb

# bash
#
dpkg -iB */ncurses3.0_*.deb */ncurses3.4_*.deb 
dpkg -iB */libreadline2_*.deb */libreadlineg2_*.deb
# paranoia says run ldconfig NOW. don't laugh, i've needed to do this on
# some libc5-libc6 upgrades. i know that the postinst scripts for the
# libs are supposed to do it but 
ldconfig
dpkg -iB */bash_*.deb

# new dpkg
#
dpkg -iB */libg++272_*.deb
dpkg -iB */dpkg_*.deb */dpkg-dev_*.deb */dpkg-ftp_*.deb

# perl
#
dpkg -iB */libgdbm_*.deb */libgdbm1g_*.deb
# paranoia says "run ldconfig now".
ldconfig
dpkg -iB */perl-base_*.deb */perl_*.deb

# the user can now run dselect and select any -dev packages they want
# (and other packages too, of course :-)

--- cut here---


--
craig sanders


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

[Adrian Bridgett]

On Tue, Jan 06, 1998 at 04:30:00AM +0100, Sten Anderson wrote:
> 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.

This has reminded me about something that really bugs me :-(

I'm writing a program so that I can so all my downloading at work. However I
hit a problem - I cannot tell which packages are in non-us (for which I go
to a different, slower, site).

Is there a way to handle this (and similarly for experimental etc.)? It
would be nice to be able to look at a "Distribution:" field and a
"Filename:" field to find out exactly where a package is.

And now for some optimisation. My program (and dpkg too I imagine) expects
each package in available (and status) to be in a paragraph, but it imposes
no restriction on the formatting of that paragraph. I wonder what the
speed-up would be if we imposed an ordering on the paragraphs (note that
this would *not* prevent future expansion). All those reg-exps can't be as
efficient as a search for a specific string.

Adrian

email: [EMAIL PROTECTED]   | Debian Linux - www.debian.org
http://www.poboxes.com/adrian.bridgett   | Because bloated, unstable 
PGP key available on public key servers  | operating systems are from MS


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

Debian Release Roadmap

[Christian Schwarz]

Hi folks!

We had a discussion on debian-private in the last days about the release
of Debian 2.0. I decided (with agreement of the other developers) to
continue Brian's "Upcoming Debian Releases" postings for now. The goal is
to get Debian 2.0 released in a reasonable time while keeping the high
quality of our distribution and adding new features, of course :)

Therefore, I'll maintain several lists: list of release requirements
(previously called release "goals"), list of action items, responsibles,
etc. Brian will continue to make the decision regarding functionality and
which packages are included or dropped.

I've set up new pages that contain up-to-date information about the next
Debian releases. The URL is: 

  http://fatman.mathematik.tu-muenchen.de/~schwarz/debian-roadmap/

If included a text version of the home page. It gives an explanation of
how release management will be done in the future. Any comments, critics,
suggestions, etc. are welcome!

Please tell me if you like the web pages that way. If you agree with its
contents, we should add a hyper link from www.debian.org to the page and
announce it's availability on the other lists.


Thanks,

Chris

[Note, that the web page currently contains one link to the list of
"Release Requirements for Debian 2.0". Please check out me other posting
here, for details.]

---cut-here


  Debian Release Roadmaps

   Last updated on Wed, 7 Jan 1998 17:43:58 +0100

About Debian's Release Management

These web pages have been set up to provide up-to-date information about
scheduled Debian releases for all Debian developers and users. 

To get releases of large pieces of software like Debian GNU/Linux out in
time while keeping a high quality and implementing new features, some
coordination between the developers is necessary. 

The first step towards a release is to define release requirements, that
is, a list of features which will be implemented in a release. 

The second step is to compare the current implementation against the list
of release requirements. This will result in a list of work packages, each
of which will be split into several action items. Most of the action items
will be reported to our Bug Tracking System. For other, non-package
related actions responsibles will be defined (release organization), who
will implement a feature or who will coordinate several people to
implement a feature, and a deadline until when the feature should be
implemented. This person has to report any appearing difficulties that may
delay the implementation, immediately, so we can discuss what to do with
the feature (either give more time, have more people working on a topic,
drop the release requirement, etc.). 

The development progress will be watched to determine when a release is
justified and to define dead-lines for the code freeze and the release.
All these dates are documented in the frame schedule of a release. 

The collection of release specific information will be called release
planning documentation. 

Debian GNU/Linux 2.0

Release 2.0 has the code-name hamm. It will be fully based on glibc 2.0
(libc6) and support more hardware architectures. 

Below, you'll find the different parts of the release planning
documentation for Debian 2.0: 

   * Release requirements

Coming soon: 

   * Frame schedule

   * Release organization

   * Work packages and action items

   * Development progress

Debian GNU/Linux 2.1

Release 2.1 will implement the FHS, will have a new frontend to the dpkg
package management tool, and will have several enhancements with respect
to online documentation. 

Coming soon: 

   * Release requirements

   * Frame schedule

   * Release organization

   * Work packages and action items

   * Development progress

 -
 Please send all comments, critics,
 and suggestions about this web page
 to Christian Schwarz or to the
 Debian Development mailing list. 
 
-- Christian Schwarz
[EMAIL PROTECTED], [EMAIL PROTECTED],
Don't know Perl? [EMAIL PROTECTED], [EMAIL PROTECTED]
  
Visit  PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
http://www.perl.com http://fatman.mathematik.tu-muenchen.de/~schwarz/



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

Debian 2.0 release requirements

[Christian Schwarz]

Hi folks!

[This is the 2nd mail concerning the new Release Roadmap. I suggest that
you read the mail with subject "Debian Release Roadmap" first.]

First step towards a stable Debian 2.0 release in time is to have a
consensus about the release requirements. (Note, that I changed the term
"goal" into "requirements".) We had a discussion about this on
debian-private in the last days, so the list included below has already
gone through some discussion.

After we have a consensus about the requirements, we'll start defining
"work packages" and "action items" that have to be performed to achieve
the release requirements. Depending on how quickly the tasks are done,
we'll define dead-lines for the code-freeze and release. 

(I know, everyone is intrested in having some real dates now. So I'll make
the mistake and give you one :) I expect to have the code freeze done in
Feb 98. I hope I'm not too wrong with this estimate :-)

Now back to the list of requirements: The major changes between Brian's
last posting (around Sep 97) are:

  - postponed implementation of PAM to some future release
  - deity is not expected to be ready for 2.0, so we'll leave this for 2.1
(Though I hope I'm totally wrong and we'll get it into 2.0 :-)
  - some packages in 2.0 will be released with "overdue" bugs
  - I'm not sure if the alpha and sparc ports are ready until 2.0
  - The goal of using "cfgtool" has been dropped. Instead of that, 2.1
will be based on "choas", hopefully.

The current list of release requirements is included below and also
available online at

http://fatman.mathematik.tu-muenchen.de/~schwarz/debian-roadmap/hamm/requirements.html

I've done my best to include some "rationale" for every requirement. It
looks like it turned into an advertisment for Debian 2.0--but hey, this
isn't too bad either! Perhaps we can copy this into the release
announcement later :-)

It would be good if some developers could check if I missed something or
included a goal which has been decided to be dropped. Furthermore, I would
be very thankful about a verification of the "rationales". (I hope they
are at least partially correct :-) 

_Any_ feedback is welcomed. Please tell me if you have other goals which
should be included in the list or which goals show be dropped/modified
etc. (The corresponding list for 2.1 will be set up shortly.) After we
have a consensus about the list of requirements, we can start collecting
the list of action items, etc.


Thanks,

Chris

P.S: After having worked a few hours on collecting the release goals and
rationales, I really feel that "hamm" will be the best thing we ever had!
Keep up the good work! 

cut-here


 Debian GNU/Linux 2.0 Release Requirements

   Last changed on Wed, 7 Jan 1998 18:01:58 +0100

Below you'll find a list of release requirements of Debian GNU/Linux 2.0,
SPI's popular Linux distribution.

All requirements have been discussed and ratified by the Debian developers.
Please contact our mailing list if you have questions.

Note, that this list should not be confused with a to-do list. Some items on
the list may already be implemented (for example, the logo).



All packages compiled against glibc 2.0 (libc6)

 The glibc 2.0 (libc6) is the successor of libc5. While libc5 was
 only available for Linux, libc6 is also available for other UNIX
 systems and for other architectures than i386. This will
 eventually allow binaries compiled for Linux to run on other glibc
 based systems on the same architecture (for example, GNU HURD) and
 will simplify Debian ports to other architectures a lot.

 While libc6 will be the default C library of Debian 2.0, all tools
 necessary to build and develop libc5-based software will still be
 available.

Support of more architectures

 Debian 2.0 will fully support the i386 and m68k architectures.

 Several other architectures (alpha, sparc, powerpc) will
 eventually be supported, too.

All packages comply with the Debian Free Software Guidelines

 The Debian Free Software Guidelines (DFSG) (part of Debian's
 Social Contract) is Debian's definition of free software.

 Every piece of software included in the Debian GNU/Linux
 distribution has to comply with these rules. This grants the user
 a maximum of freedom, as all packages will be provided with the
 complete source code, will be freely usable, modifiable,
 redistributable, and derived works will be allowed.

New installation utility based on package pre-selections

 Debian 2.0 will contain over 1000 packages! To simplify
 installation, a new installation program will allow to choose
 between several predefined `default installations,' for example,
 Internet server, X11 desktop, or router/firewall host.

 Since this new installation utility will be based on top of the
 existing pa

Re: libc5 to libc6 auto-upgrade script

[James Troup]

Craig Sanders <[EMAIL PROTECTED]> writes:

> cd /debian/dists/unstable/main/binary-i386

Grr.

cd /debian/dists/unstable/main/binary-$(dpkg --print-installation-architecture)

-- 
James - Hardcoded-i[345]86 detection alarm triggered


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

My Epson Stylus (color 600) config

[Yann Dirson]

I thought the small trick I've installed on my box would be of
interest.  Maybe not as such, because the few bytes spared from
printcap are replaced by an additionnal script, but as an idea of
future directions for magicfilter.

It makes use of a lprng special feature, and uses the uniprint driver;
I use aladdin-gs, and didn't test it with GNU gs.  It simply works
with a single printcap entry using many names (one per
resolution/actual filter), by making lprng pass the printer name as a
command-line arg to a script, which then calls the appropriate magic
filter.

My magicfliters are not different from the one James posted.

This could be improved.  Eg, you'll notice that the default resolution
is hardcoded in the filter script ("stclow").

What I think could be done would be to add some more powerful
parametrization to magicfilter.  What's needed here is a case-like
structure on the printer-name.  It will prevent to have many filters
differing only by the resolution used.

-- 
Yann Dirson  <[EMAIL PROTECTED]>  | Stop making M$-Bill richer & richer,
alt-email: <[EMAIL PROTECTED]>  | support Debian GNU/Linux:
debian-email:   <[EMAIL PROTECTED]>  | more powerful, more stable !
http://www.a2points.com/homepage/3475232 | Check 


printcap
Description: Binary data


stc600-filter
Description: Binary data

Re: loop-root (was What's Debian's /usr/src policy)

[Dale Scheetz]

On Wed, 7 Jan 1998, Adam P. Harris wrote:

> 
> [You (Dale Scheetz)]
> >On Wed, 7 Jan 1998, Turbo Fredriksson wrote:
> >> A loop-root?
> 
> >With a small patch to the kernel and some modification of the loop device
> >code, you can create a file-system-in-a-file. 
> 
> You can do this already in stock debian (rex and hamm) with 
>   mount -o loop -t
> 
> Why do you need to patch the kernel for this?

So that the kernel can perform this mount process for it's root file
system. It includes recognition of the kernel parameter
"loop=" and configuration entries for enabling/disabling
the feature.

> 
> >Using the loop device
> >the internal file system can be mounted as the root file system for the
> >kernel. These patches were never adopted by the kernel, and it is getting
> >harder and harder to apply them, so I currently use a patched 2.0.27
> >kernel to boot that system. 
> 
> Why do you have to patch the kernel at all?  I already have this
> funcationality w/ initrd. Again, this is on an upatched 2.0.30 and 2.0.32 
> kernels.
> 
This process moves the file system into ramdisk, limiting the size of the
root file system, although there is also the possibility of mounting such
a file on that minimal ramdisk using the mount command you referenced, it
still requires some ramdisk. The loop-root doesn't.

> BTW, I use it on my custom-rolled boot floppies for debian booting off a
> floppy for a laptop which runs an initrd w/ cardmgr on it so I could get
> PCMCIA subsystem up and play with NFS-mounting root.  I have a little make
> file which makes a pretty complete but small initrd file system (using
> mount -o loop) complete w/ shared libs etc, even ash.  It all works, at
> least to the extent that NFS-root works well at all (which is not much but
> I haven't gotten around to pestering Joost about it).
> 
This is exactly what initrd is intended to allow.

> Alternatively you could use the ramdisk and just mount root in the same 
> basic fashion (although initrd is a little different -- not much really).
> 
See above.

> >The one I boot with lilo is on an ext2 partition (another beauty of the
> >imbeded file system, it can be coppied to almost any other file system).
> >Interesting point: on an ext2 file system, no care need be taken. On a DOS
> >file system the file system must be un-fragmented (using dfrag) before the
> >DiD installation will work properly. The funny part of this is that it
> >doesn't matter whether you do the dfrag before you copy the file system,
> >or afterwards, it still works. Without it you get file system errors.
> 
> Never noticed this issue on my 'mount -o loop' and initrd scheme.  Using 
> SYSLINUX to boot I think.
> 
Only happens on a DOS file system, and, depending on the degree of
fragmentation of the partition, doesn't always happen there. You probably
aren't supporting such a system on a DOS partition.

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: Debian 2.0 release requirements

[Alex Yukhimets]

> Support of 8-bit characters by default
> 
>  Some programs need special configuration options to work 8-bit
>  clean. This is very important for a lot of non-English users who
>  need to input umlauts, accented characters, etc. All Debian
>  packages will be configured to be 8-bit clean by default.

Hi.

I would like to question the need for this requirement. 
While this can be of importance to some users, it can be quite
annoying to others. What it means is saying "good-bye" to clean
ascii e-mail, etc. What is more important, *some* utilities,
"less" most notably, *shouldn't* be 8-bit clean. 

I think we should put a little bit more thought into this decision.
Not *all* packages should be 8-bit clean in any case, and for some
others, I would still prefer to have some options.

Thanks.

Alex Y.

-- 
   _ 
 _( )_
( (o___   +---+
 |  _ 7   |Alexander Yukhimets|
  \(")|   http://pages.nyu.edu/~aqy6633/  |
  / \ \   +---+


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

Re: Debian 2.0 release requirements

[Martin Schulze]

On Wed, Jan 07, 1998 at 06:27:48PM -0500, Alex Yukhimets wrote:
> > Support of 8-bit characters by default
> > 
> >  Some programs need special configuration options to work 8-bit
> >  clean. This is very important for a lot of non-English users who
> >  need to input umlauts, accented characters, etc. All Debian
> >  packages will be configured to be 8-bit clean by default.
> 
> Hi.
> 
> I would like to question the need for this requirement. 
> While this can be of importance to some users, it can be quite
> annoying to others. What it means is saying "good-bye" to clean
> ascii e-mail, etc. What is more important, *some* utilities,
> "less" most notably, *shouldn't* be 8-bit clean. 

I don't understand that.  Could you explain that?

Regards

Joey

-- 
  / Martin Schulze  *  [EMAIL PROTECTED]  *  26129 Oldenburg /
 /  Whenever you meet yourself you're in a time loop /
/ http://home.pages.de/~joey/   or in front of a mirror /


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

Re: Is there a maintainer for the install doc?

[Igor Grobman]

> Is anyone maintaining the Debian installation manual?
> I know that Sven is no longer doing it. If not,
> we will need a volunteer.

I'd like to maintain it.  I plan to  be active on the 
testing front, so I should be aware of all the quirks with the installation 
and upgrading.  

BTW, are the .txt and .html files generated from sgml source?  If so, where is 
the sgml version located?

 
-- 
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: Debian 2.0 release requirements

[Alex Yukhimets]

> > > Support of 8-bit characters by default
> > > 
> > >  Some programs need special configuration options to work 8-bit
> > >  clean. This is very important for a lot of non-English users who
> > >  need to input umlauts, accented characters, etc. All Debian
> > >  packages will be configured to be 8-bit clean by default.
> > 
> > Hi.
> > 
> > I would like to question the need for this requirement. 
> > While this can be of importance to some users, it can be quite
> > annoying to others. What it means is saying "good-bye" to clean
> > ascii e-mail, etc. What is more important, *some* utilities,
> > "less" most notably, *shouldn't* be 8-bit clean. 
> 
> I don't understand that.  Could you explain that?

Sure.

it is nice property of "less" (as opposed to "more") that it filters
out all non-ascii charachters (changes them to some ^... printable
sequencies). As a result, it is not possible to trash the console by
doing "less " or, more important - if something
bad happened and you created a file(s) with some non-ascii charachters,
"ls" will trash the console while "ls | less" will show you everything
and let you delete it.

Thanks.

Alex Y.

-- 
   _ 
 _( )_
( (o___   +---+
 |  _ 7   |Alexander Yukhimets|
  \(")|   http://pages.nyu.edu/~aqy6633/  |
  / \ \   +---+


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

Re: Debian 2.0 release requirements

[Dale Scheetz]

On Wed, 7 Jan 1998, Christian Schwarz wrote:

> All applications registered to menus
> 
>  The menu package included in the Debian distribution stores
>  information about which applications are installed on the system
>  and provides this data for X11 window managers or text-based menu
>  programs like pdmenu. With that, the user always has up-to-date
>  application menus, no matter which packages are installed or which
>  menu program is used.
> 
This one is new to me...I have been waiting for the menu system to
stabalize. I guess this means that it has?

Is there a description in the Policy Manual? More important is there a
good example of how to impliment this and will it make it into the
Programmers Manual?

Thanks,

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] .