Bug#4271: emacs has no "debian-rundir"

[Dirk . Eddelbuettel]

Package: emacs
Version: 19.34-1 

/etc/emacs/site-start.el, after upgrading from 19.31 to 19.34, contains

(load "debian-rundir")
(debian-run-directory)

which fails as there is no debian-rundir.el in the package.

-- 
Dirk Eddelb"uttel http://qed.econ.queensu.ca/~edd

Bug#4269: xosview has only XOSView as application resource file

[David Frey]

Package: xosview
Version: 1.3.2-6

Xosview only reads the file XOSView (and ~/.Xdefaults) when evaluating 
its X resources. It does this by doing all the reading by foot (calling
XrmGetFileDatabase() etc.). 
This is IMO the wrong way to do it; the application should use 
XtGetApplicationResources() (as xsysinfo does it).  Using 
XtGetApplicationResources() makes it possible to have a set of
Application-Default-files which can conditionally be used; the classic
use of this is to have a 'Foo' and a 'Foo-color' resource file, where
'Foo' contains only black & white stuff and 'Foo-color' contains the color
definition and #includes 'Foo'. By doing it this way you can put 

#ifdef COLOR
*customization: -color
#endif

...

into your /etc/X11/XDefaults line and all (correctly configured) 
applications look their color configuration up in *-color application 
definitions.

David

PS:  This bug should probably forwarded to the upstream maintainer.
PPS: If I knew enough C++ and if I understood the code dependencies,
 I had fixed this myself.

Bug#4270: xosview should be able to monitor /dev/ttyS? too

[David Frey]

Package: xosview
Version: 1.3.2-6

Xosview should be able to monitor the /dev/ttyS* lines too; since nowadays
(with the advent of mgetty) a lot of people use /dev/ttyS* for dialout.

David

Re: dpkg 1.3.8: dpkg-buildpackage -sa works and is recommended

[Peter Tobias]

Ian Jackson wrote:
> > BTW: I didn't have much time the last weeks (and I won't have much
> > time the next weeks) so I wasn't able to check if this new source
> > format will also work for packages like netstd (packages which contain
> > lots of "sub packages" each with its own original source. Do you
> > see any problems with it?
> 
> I'm afraid I totally fail to understand the netbase and netstd source
> packages.

Ian Murdock wanted to have them that way to make it easier to download
the sources for a single program. The size of the sources of the first
net package were ~2MB ...

> The new source packaging scheme will require you to put all of these
> sub-packages together, and turn the whole thing into a normal package.

No problem. The archive with the original sources would be my own
collection of original sources then ...


Thanks,

Peter

-- 
 Peter TobiasEMail:
 Fachhochschule Ostfriesland [EMAIL PROTECTED]
 Fachbereich Elektrotechnik und Informatik   [EMAIL PROTECTED]
 Constantiaplatz 4, 26723 Emden, Germany [EMAIL PROTECTED]

I dropped off the list

[Giuseppe Vacanti]

pgp1cnNxvhntB.pgp
Description: PGP message

Bug#4268: Figure displayed incorrectly

[Carlos Fonseca]

Package: gs
Version: 4.01-2

The eps file attached is not displayed properly by gs 4.01.
gs 2.62 displays it correctly.

Carlos


diffusion.eps.gz
Description: GNU Zip compressed data

Re: Bruce - fiat required to end discussion on lyx/copyright ?

[Michael Meskes]

Dale Scheetz writes:
> Pine is in non-free because it's copyright places restrictions on the
> distribution of source. Xforms has more severe restrictions on the
> distribution of source than pine does. It is my understanding that this

That's why there is no source available. :-)

> source distribution restriction is what makes Xforms' proper location to
> be non-free.

It was once decided that binary-only packages belong into contrib.

Michael

-- 
Michael Meskes   |_  __  
[EMAIL PROTECTED] |   / ___// / // / / __ \___  __
[EMAIL PROTECTED]  |   \__ \/ /_  / // /_/ /_/ / _ \/ ___/ ___/
[EMAIL PROTECTED]|  ___/ / __/ /__  __/\__, /  __/ /  (__  )
Use Debian Linux!| //_/  /_/  //\___/_/  //

Bug#4267: xosview doesn't understand -geometry very well

[joost witteveen]

> 
> Package: xosview
> Version: 1.3.2-1
> 
> I ran xosview with this command:
> 
> xosview -geometry 48x48+388+0 &

xosview does not confirm to most X standards.

It really isn't a very nice programme.

The upstream maintainer says he will some time start using the
standard Xt interface, but he didn't say when.

Xosview-1.4.1 AFAIK doesn't use it.

I'm closing this bug, as I cannot do anything about it, and
the upstream maintainer doesn't care.

Thanks anyway,

-- 
joost witteveen
[EMAIL PROTECTED]
  [EMAIL PROTECTED]
--
Use Debian/GNU Linux!

Buglist philosophy, (was bug 4164: ferret extended description...)

[Steve Greenland]

Susan G. Kleinmann wrote:
> So, except where the ratio of 
>   triviality-of-bug / responsiveness-of-maintainer 
> is near 0, or (better) where the reporter realizes the maintainer
> has his own motivations for fixing the bug right away, I agree with Ian that 
> the right thing to do is to log the bug.  I believe the bug tracking system 
> may be the single most important aspect of the Debian system.

As a maintainer whose responsiveness is probably less than ideal[1],
I must say I rather like having the bug tracking system, and I
would just as soon have people report stuff there. It saves me from
having to keep a separate list of "private" bugs, and while it may
not be a "pole of shame", if the list gets long, it tends to inspire
some effort to reduce it to something a little less personally
embarrasing :-).

One enhancement I would like to see is the ability to access the
buglist by package. No, not sorted by package, but a single page
of the outstanding bugs for a given package, so that I can have a
link to "http://www.debian.org/bugs/bypackage/nvi.html"; or some
such. Or maybe a form, so that somebody can enter a package name
and get the appropriate list. I think this would make it much more
likely that people would look to see if a bug has been reported
before submitting a new one, and would make it easier for maintainers.
(I have no idea how hard this would be; I'm just throwing the idea
out there...)

Steve

[1] I enjoy contributing in a small way to a community (both Debian
and the free software community in general) that has provided a
lot of benefit for me over the years, but the reality is that Debian
is a spare time thing for me, and I haven't had much spare time
this year.

-- 
The Mole - I think, therefore I scream 

"Calling all units!  Leading monster
 stampede through the bottomlands to lower
 forty!... Set up ambush on flanks!... Also,
 do not shoot me!... Repeat!... Do not shoot
 me!!!"
[FLAMING CARROT vs the Giant Japanese Monsters!]

Bug#4267: xosview doesn't understand -geometry very well

[Richard Kettlewell]

Package: xosview
Version: 1.3.2-1

I ran xosview with this command:

xosview -geometry 48x48+388+0 &

and indeed from xlsclients -l:

Window 0x282:
  Machine:  sfere
  Name:  [EMAIL PROTECTED]
  Icon Name:  [EMAIL PROTECTED]
  Command:  xosview -geometry 48x48+388+0
  Instance/Class:  xosview/xosview

...but (as you can see below) the window is not in the correct
position:

xwininfo: Window id: 0x282 "[EMAIL PROTECTED]"

  Absolute upper-left X:  392
  Absolute upper-left Y:  3
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 48
  Height: 48
  Depth: 8
  Visual Class: PseudoColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x26 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +392+3  -160+3  -160-399  +392-399
  -geometry 48x48+390+1

Sometimes xosview positions itself near, but not exactly in, the right
place; sometimes it positions itself in the upper left corner of the
screen; and occasionally it even ends up in the right place.

-- 
Richard Kettlewell   [EMAIL PROTECTED]   [EMAIL PROTECTED]
 http://www.elmail.co.uk/staff/richard/

Bug#4235: cpp, gcc, dpkg

[Ian Jackson]

[EMAIL PROTECTED] writes ("Bug#4235: cpp, gcc, dpkg "):
^ was this intentional ?
> 
...
> Somehow installation with dpkg-ftp and the new cpp uninstalled my gcc
> package and look how dpkg selects on a dselect update.  This shouldn't
> happen.  Somehow gcc is too easily uninstalled because the conflict with
> the cpp package.  Another reason to remove the cpp thing from gcc and
> let it come in its own package and let gcc depend on it.

The problem with gcc and cpp is being discussed atm.

> # dselect update
> 
> dpkg (subprocess): failed to exec C compiler `gcc': No such file or directory
> dpkg: subprocess gcc --print-libgcc-file-name returned error exit status 2

This is due to dpkg-ftp calling `dpkg --print-architecture' rather
than `dpkg --print-installation-architecture'.  I'm reassigning this
bug report.

Ian.

Re: dpkg 1.3.8: dpkg-buildpackage -sa works and is recommended

[Ian Jackson]

Peter Tobias asks me in private email:
...
> BTW: I didn't have much time the last weeks (and I won't have much
> time the next weeks) so I wasn't able to check if this new source
> format will also work for packages like netstd (packages which contain
> lots of "sub packages" each with its own original source. Do you
> see any problems with it?

I'm afraid I totally fail to understand the netbase and netstd source
packages.

The new source packaging scheme will require you to put all of these
sub-packages together, and turn the whole thing into a normal package.

Ian.

Re: Bruce - fiat required to end discussion on lyx/copyright ?

[Ian Jackson]

Dale Scheetz writes ("Re: Bruce - fiat required to end discussion on 
lyx/copyright ?"):
> [...] xforms is improperly
> located in contrib instead of non-free where it belongs (because source is
> not distributed). [...]

Sourceless packages are fine to distribute in contrib, so long as the
binaries may be redistributed for profit &c.

Please see the policy manual, chapter 2.

Ian.

Re: Bruce - fiat required to end discussion on lyx/copyright ?

[Ian Jackson]

Michael Meskes writes ("Re: Bruce - fiat required to end discussion on 
lyx/copyright ?"):
...
> Ahem, this isn't exact enough IMO. With a standard Debian system I am able
> to rebuild LyX. 

You can't rebuild LyX entirely from source using only packages in the
main Debian distribution.

> > [...]
> >  All packages in the Debian distribution proper must be freely useable,
> >  modifiable and redistributable in both source and binary form. It must
> >  be possible for anyone to distribute and use modified source code and
> >  their own own compiled binaries, at least when they do so as part of a
>  ^^^

Fixed the typo.

Ian.

Re: Bug#4051: access permissions for /usr/bin/fdmount

[Ian Jackson]

Michael Meskes writes ("Re: Bug#4051: access permissions for /usr/bin/fdmount"):
> Ian Jackson writes:
...
> > Compiling names of groups or even worse group ids into binaries is a
> > bad idea.
> 
> Why? Because it's not easy to change? 

It's hard to change and obscure.  Policy is best implemented where it
can be seen.

>  I talked to Alain (upstream
> maintainer) about my changes and he's going to included them into 4.4. I
> don't see the problem right now, since you're able to put everyone in group
> floppy who shall be able to use fdmount. On the other hand this group coding
> (which is ifdef'ed btw so it's not much work to create a new version) adds
> security. How many systems have wrong permissions on some files? In
> particular a file with s.bit should be as secure as possible IMHO.

Obviously if you've done it right having the binary check itself
whether rgid or getgroups includes `floppy' and having it only
executable by group floppy have the same security effect.

However, there are other differences: having the permissions on the
binary do the enforcement means that a programming error of any kind
in the binary is at most an exposure to group floppy (which may well
be only the sysadmin anyway).  It also makes it much more obvious to
people how to get access.

...
> No problem Ian. But then I'm not so sure if it's a bug now.

We should either change fdmount to match the policy and the other
similar programs (dip, for example), or we should change the policy
and the other programs to match fdmount.

I think that using the file permissions is technically superior, so I
think we should stick with it.

Ian.

Re: New virtual package names.

[Ian Jackson]

Dale Scheetz writes ("Re: New virtual package names. "):
> On Wed, 21 Aug 1996, Ian Jackson wrote:
...
> > I can't prove that it's needless.  You're shifting the burden of
> > proof.  It's up to you to show that it's needed.
> 
> The burden I am trying to shift onto your shoulders is for you to have
> read the complete thread of this discussion. It is not clear that you have
> done so. You declared the needlessness but gave no explanation of why this
> was so.

Suppose that I were to declare that it is necessary for dpkg to be
able to read mail.  How would you refute my declaration of this
necessity ?  You can't.  Instead, you would ask me to justify this
assertion.

When the question is being discussed as to whether something is
necessary or not the burden of proof must fall on those who claim that
it is.  By default - in the absence of any reason not to think so -
a thing should be assumed not to be necessary.

> The rest of us, as a group, have discussed this, at some length, and come
> to the conclusion that the editor virtual package name was a viable
> solution. As a late arrival to this discussion it is your responsibility
> to have, at least, read the complete discussion, and speak to the points
> raised and settled there. Blanket assertions without supporting arguments
> are neither constructive, nor informative.

I have read all of the discussion.  Just because I'm a week behind on
my email doesn't mean I'm not reading it.

However, since you seemed so insistent, I went back and had a look at
what arguments people might have presented.

I found a rather limited amount of discussion.  It did not appear to
me to have reached a definite conclusion.  The virtual package got
added by the maintainer of the list because noone objected in time.

The only one I could find was based on the idea that in order for it
to be safe to remove the `Essential' flag from `ae' it would be
necessary to use the dependency mechanism to stop people from
deinstalling it before they install another editor.

This didn't seem to be stated explicitly in this form, but it was
clear that people were seeing the idea of an `editor' virtual package
as an alternative to marking `ae' essential.

I don't see that this is a true case of alternative solutions to a
problem: I don't think there is a problem, and I think that it would
be just fine for `ae' not to be essential and for nothing to depend
on it.

Ian.

Re: Bruce - fiat required to end discussion on lyx/copyright ?

[Ian Jackson]

[EMAIL PROTECTED] writes ("Re: Bruce - fiat required to end discussion on 
lyx/copyright ?"):
> >  All packages in the Debian distribution proper must be freely useable,
> >  modifiable and redistributable in both source and binary form. It must
> >  be possible for anyone to distribute and use modified source code and
> >  their own own compiled binaries, at least when they do so as part of a
> >  Debian distribution.
> 
> This can't be done with nearly all (la)tex related style files.  When one
> wants to change a (la)tex style an other named copy can be used but the
> original may not be touched.  Do we really want to ditch (la)tex?

I've added the following footnote:
It is OK for there to be a requirement that modified
versions carry a warning, or that they be released with a different
name or version number, or something similar, because we can comply
with this requirement if necessary.

Ian.

Re: Bruce - fiat required to end discussion on lyx/copyright ?

[Ian Jackson]

[EMAIL PROTECTED] writes ("Re: Bruce - fiat required to end discussion on 
lyx/copyright ?"):
> >  All packages in the Debian distribution proper must be freely useable,
> >  modifiable and redistributable in both source and binary form. It must
> >  be possible for anyone to distribute and use modified source code and
> >  their own own compiled binaries, at least when they do so as part of a
> >  Debian distribution.
> 
> This can't be done with nearly all (la)tex related style files.  When one
> wants to change a (la)tex style an other named copy can be used but the
> original may not be touched.  Do we really want to ditch (la)tex?

Being required to change names is fine, as we can do that if
necessary.

Ian.

Re: Bug#4261: Ghostview and virtual package postscript_viewer

[Brian C. White]

> No, that isn't what should be done, or at least not the only thing.
> I'm on my way to produce a second posctscript-viewer (front-end to gs)
> called gv, that is in some ways much better than ghostview, though there
> are too many differences in the user interface to drop ghostview instead.

Yes, it _is_ what should be done.  "install-mime" handles multiple entries
for the same mime-type.  Thus, if both "ghostview" and "gv" get installed,
the user is given the choice of which is to have priority in the mailcap file.
Trust me, this will work.  It was designed to handle just this case.

Please see the "install-mime" man page for more information.

Brian
   ( [EMAIL PROTECTED] )

---
In theory, theory and practice are the same.  In practice, they're not.

Bug#4266: gs prints debugging info when invoked from xdvi

[Carlos Fonseca]

Package: gs
Version: 4.01-2

When called from xdvi, gs works as expected, but prints the
following (debugging?) messages:

gs: Error: /undefinedfilename in --file--
gs: Operand stack:
gs:(./Fontmap)   (r)
gs: Execution stack:
gs:%interp_exit   --nostringval--   --nostringval--   --nostringval--
--nostrin
gs: gval--   0   --nostringval--   %array_continue   --nostringval--
--nostringval-
gs: -   false   --nostringval--   --nostringval--
gs: Dictionary stack:
gs:--dict:678/701--   --dict:0/20--   --dict:47/200--
--dict:678/701--
gs: Current allocation mode is global
gs: Current file position is 29607

This does not happen when invoking gs from the command line. 

Carlos

Re: Bug#4164: Ferret extended description has blank lines

[Susan G. Kleinmann]

I agree with Brian that micro-bugs should probably be reported to the 
maintainer, just because it takes more work to contact the reporter and 
close the bug than to fix it.  However, in this case the reporter has to
keep his _own_ bug tracking system, if he wants to make sure that the
maintainer actually fixed the bug.  This may or may not be a big deal,
depending on the responsiveness (read, speed and verbal skills) of
the maintainer.  Also, the reporter then takes the moral responsibility
of (a) having wasted a third person's time who may chance across the bug
(it takes time to identify a bug), and (b) having wasted someone else's 
time reporting a bug.

I agree with Lars that the bug tracking system is not a shame pole.

I agree with Dale that trivial (or incorrect) bugs give a bad and unbalanced
impression of the distribution.  

I agree with Ian that we can't afford to let bugs go unreported because
they might be publicly visible (that's actually a lot of help!).
And I also agree with Ian that debian-user is a bad, bad place to report
bugs because of its traffic.

Having to do with psychology, it seems to me there is another advantage
of using the bug tracking system, and that has to do with the 
less-than-perfect side of humans:  all of Debian's developers are
busy folks who need to save time.  If someone mails a developer a message 
regarding a trivial (or maybe not so trivial) bug fix, and he deems it 
unimportant, he might be tempted to tell the reporter to forget it.
This leaves these possibilities:
A. the reporter agrees it was silly and defers to the maintainer, and no
   one else is ever bothered by this.  
B. the reporter agrees it was silly and defers to the maintainer, and someone
   else does find the same bug, thereby wasting his time and _really_
   giving the Debian distribution a bad name because of real bugs.
C. the reporter doesn't agree with the maintainer, takes the bug to the
   bug tracking system, thereby deliberately turning up the heat on the
   maintainer, and potentially causing a mini-war.

So, except where the ratio of 
  triviality-of-bug / responsiveness-of-maintainer 
is near 0, or (better) where the reporter realizes the maintainer
has his own motivations for fixing the bug right away, I agree with Ian that 
the right thing to do is to log the bug.  I believe the bug tracking system 
may be the single most important aspect of the Debian system.

Even when a reporter isn't sure that an event is a bug, he should report
it, since this eventually leads to FAQ's which can then be aired and 
resolved :-).

(I now feel guilty for not having always used the BTS myself in the past.)

Best regards,
Susan Kleinmann

Bug#4265: util-linux_2.5-5.deb: /sbin/clock Seg. faults

[Erik B Andersen]

Package: util-linux
Version: 2.5-5

/sbin/clock seg. faults.  The following illustrates this problem:


   Dillweed# dpkg -i util-linux_2.5-5.deb
   (Reading database ... 15590 files and directories currently
   installed.)
   Preparing to replace util-linux (using util-linux_2.5-5.deb) ...
   Unpacking replacement util-linux ...
   Setting up util-linux (2.5-5) ...

   Dillweed# clock 
-> Segmentation fault
   Dillweed# dpkg -i util-linux_2.5-4.deb 
   dpkg - warning: downgrading util-linux from 2.5-5 to 2.5-4.
   (Reading database ... 15590 files and directories currently
   installed.)
   Preparing to replace util-linux (using util-linux_2.5-4.deb) ...
   Unpacking replacement util-linux ...
   Setting up util-linux (2.5-4) ...

   Dillweed# clock
-> Fri Aug 23 01:21:12 1996
   Dillweed# 

I solved this by copying the binary from util-linux_2.5-4.deb over the
binary
from util-linux_2.5-5.deb, and everything was fine...

I am using Debian 1.1, patched up to everything in the experimental
distribution as of August 24, 1996, with kernel version 2.0.14 and
libc.so.5.2.18 from libc5.5.2.18-10.deb.

-- 
Erik B. Andersen Web:   
http://www.et.byu.edu/~andersee/ 
2485 South State St. email:  [EMAIL PROTECTED]
Springville, Ut 84663phone:  (801) 489-1231
--This message was written using 73% post-consumer electrons--

Re: Documentation formats

[Lars Wirzenius]

Ian Jackson:
> > I'm not certain that distributing HTML with the packages and other formats
> > separately is a good idea. I think it might be a better idea to continue
> > as now and use on-line conversions from man and Info to HTML. Pre-converted
> > HTML should be distributed as separate packages.
> 
> So you'd rather I put the SGML source for the manuals in the dpkg
> binary package, rather than the HTML pre-converted form ?

No, I was talking about man and Info, in my usual unclear fashion, sorry.
The conversions of man and Info to HTML are fairly fast.

-- 
Please read  before mailing me.
Please don't Cc: me when replying to my message on a mailing list.




pgpXJhJp2w2Ky.pgp
Description: PGP signature

Re: Bug#4261: Ghostview and virtual package postscript_viewer

[Helmut Geyer]

> 
> Package: ghostview
> Version: 1.5-8
> 
> Ghostview should install itself into the /etc/mailcap entry so mime
> compatible programs can use it to view postscript documents.
> 
> I suggest making ghostview "Recommends: mime-support" and adding the
> following to the install scripts:
> 
> debian.postinst
> ~~~
> if [ -x /usr/sbin/install-mime ]
> then
>   install-mime--install --package=ghostview 
> --content=application/postscript \
>   --description="Postscript Formatted Output" 
> --nametemplate="%s.ps" \
>   --test='test "$DISPLAY" != ""' \
>   --view='/usr/bin/X11/ghostview %s' \
>   --comment="Ghostview is a fairly good front-end for viewing 
> postscript \
>  and should probably be given a reasonably high 
> priority."
> fi
> 
> debian.prerm
> 
> if [ -x /usr/sbin/install-mime ]
> then
>   install-mime --remove --package=ghostview
> fi
> 
> 
No, that isn't what should be done, or at least not the only thing.
I'm on my way to produce a second posctscript-viewer (front-end to gs)
called gv, that is in some ways much better than ghostview, though there
are too many differences in the user interface to drop ghostview instead.

I propose to have a virtual package postscript_viewer installing a 
/etc/alternatives - managed binary /usr/bin/X11/ps_view and handling the stuff 
via update-alternatives. 
mime-support should either put/usr/bin/X11/ps_view into mailcap by default
(which is what I propose), or we install it from ghostview and gv using
install-mime.

Helmut

Bug#4264: DIP/PPP support incorrect.

[Karl Ferguson]

Package: netstd
Version: 2.06-1

Hi...

In the README file for ppp in /usr/doc/pppd it says:

   2.  Make sure pppd is where dip thinks it is: /usr/lib/ppp/pppd, or
   make a link from there to where pppd really is.  (Or re-compile dip
   to tell it where pppd is on your system - see pathnames.h).

Now, if I were to fire up a connection with DIP using ppp.dip in the examples
for dip (of course, modifying it to my purposes) then it can't find a pppd
to execute because there is no /usr/lib/ppp directory for dip to execute a
pppd in.  Making the directory and symlinking it seems to make it work.

...Karl

--
Karl Ferguson,
Tower Networking Pty Ltd (ACN: 072 322 760)[EMAIL PROTECTED]
t/a STAR Online Services   [EMAIL PROTECTED]
Tel: +61-9-455-3446  Fax: +61-9-455-2776   http://www.star.net.au/

Bug#4263: dpkg-source requires patch

[Susan G. Kleinmann]

Package: dpkg
Version: 1.3.8

In unpacking the sgmlspm dsc file on a fairly fresh system, I found:

# dpkg-source -x sgmlspm_1.03ii-2.dsc 
dpkg-source: extracting sgmlspm in sgmlspm-1.03ii
dpkg-source: failure: exec patch: No such file or directory
dpkg-source: failure: patch gave error exit status 2

Once patch was installed, dpkg-source completed successfully.

Since patch isn't in base, I assume this means that the dpkg Depends
field has to be amended to add 'patch'.

Susan Kleinmann

Bug#4262: dpkg-source requires cpio

[Susan G. Kleinmann]

Package: dpkg
Version: 1.3.8

In unpacking the sgmlspm dsc file on a fairly fresh system, I found:

# dpkg-source -x sgmlspm_1.03ii-2.dsc 
dpkg-source: failure: exec cpio: No such file or directory
dpkg-source: failure: cpio gave error exit status 2
# type -a cpio
type: cpio: not found

Installing cpio cured the problem, but suggests that the newest
versions of dpkg need to depend on cpio, which (I think) means that
cpio would have to be added to base.

Susan Kleinmann

Re: Bug#4164: Ferret extended description has blank lines

[Dale Scheetz]

On Sat, 24 Aug 1996, Ian Jackson wrote:

> This is a different matter.  Encouraging people to discuss things that
> might or might not be bugs is fine.
> 
> Discouraging people from reporting things that definitely are bugs is
> not fine.
> 
I agree completely, but I will still contend that the appropriate step to
take before submitting a bug is to contact the maintainer. When that can't
be done, or the maintainer is resistant, or the maintainer agrees, then is
the right time to submit the bug report.

Later,

Dwarf

  --

aka   Dale Scheetz   Phone:   1 (904) 877-0257
  Flexible Software  Fax: NONE 
  Black Creek Critters   e-mail:  [EMAIL PROTECTED]

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

fsp_2.71-3 and libelf_0.5.2-1 uploaded

[Mr Stuart Lamble]

I've finally got around to doing these. I'm not entirely sure that
libelf belongs in devel, but since nobody has responded to my queries
on this matter... shrug. Bug me if I'm wrong.

-BEGIN PGP SIGNED MESSAGE-

Date: 23 Aug 96 11:07 UT
Format: 1.6
Distribution: unstable
Urgency: Low
Maintainer: Stuart Lamble <[EMAIL PROTECTED]>
Source: fsp
Version: 2.71-3
Binary:  fsp
Architecture:  i386 source
Description: 
 fsp: An alternative to anonymous FTP
Changes:
 - Fixed a typo in fhostcmd.1 (c/o Michael Meskes)
 - all man pages are now compressed with gzip -9
 - added postinst script to automatically add fspd to /etc/inetd.conf
 - added corresponding prerm to disable fspd. :-) (thanks to Michael Meskes
   for his help with these)
 - moved fspd.conf from the examples directory to /etc
 - added /etc/fspd.conf to the (new :-) conffiles listing
 - moved /usr/doc/examples/fsp to /usr/doc/fsp/examples
 - added a changelog (probably not in the right format, though),
 - removed the changes list from the copyright information file.
Files:
 3b5519778f783eaffaa6a00c0e3565c5  158691  net  -  fsp_2.71-3.tar.gz
 1348cbec478132d88556d9ab7acc0bea  17400  net  -  fsp_2.71-3.diff.gz
 8ee57ea4d9b6337a934ee6f8df8ae14a  81032  net  optional  fsp_2.71-3_i386.deb

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

iQCVAwUBMh+t6tancbR/eGtJAQECigQAucXxtLYLm5uofQxsgpHb5M+Yw5kg8YVS
57+rdQLTwjGvVpHHAlGfe6JEkQYkCi+ItqIuajPPpKqaoK9SIhfd8Ym773s+eXb6
2QJeIrIVyMT+Z9YccUlYf+4VfPPiwCqJm/sTb7lpyIjmeBP6k/WjrJ8uwgMjHY3q
TBbX4xp8H00=
=mre4
-END PGP SIGNATURE-
-BEGIN PGP SIGNED MESSAGE-

Date: 24 Aug 96 09:01 UT
Format: 1.6
Distribution: unstable
Urgency: Low
Maintainer: Stuart Lamble <[EMAIL PROTECTED]>
Source: libelf
Version: 0.5.2-1
Binary:  libelf-dev libelf
Architecture:  i386 source
Description: 
 libelf-dev: an ELF object file access library (development files)
 libelf: an ELF object file access library
Changes:
 New packages - added the Debian control files.
Files:
 8db6879839857d86c9b92188b2f8a2dd  56314  devel  -  libelf_0.5.2-1.tar.gz
 c1b1205b7dc23a4bc3a8a9c597726498  2376  devel  -  libelf_0.5.2-1.diff.gz
 23bb5fa903aec29b20f881e60a101f98  67034  devel  Optional  
libelf-dev_0.5.2-1_i386.deb
 80d5d2fea886ebbd69d6b47de2d1d61f  51204  devel  Optional  
libelf_0.5.2-1_i386.deb

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

iQCVAwUBMh+t+9ancbR/eGtJAQFphQP/XTkDNGWGeK1/cG0FyVNlBokTMBRDfbVh
uPfum1aHmxmOGuD8c1Y+z8PJGPp24Dm969mQJps8d1GGlc4FUx2cmFW9Hw1sEyCr
ksYx3Z4OUX62JNTkMXQ+NPGzDfhj8rCxdx6cHJPAhulnjk+BeZ9hrAIMg7MfX2Gw
rts2wEk7uOw=
=SJU2
-END PGP SIGNATURE-

Bug#4261: Ghostview -- needs MIME entry

[Brian C. White]

Package: ghostview
Version: 1.5-8

Ghostview should install itself into the /etc/mailcap entry so mime
compatible programs can use it to view postscript documents.

I suggest making ghostview "Recommends: mime-support" and adding the
following to the install scripts:

debian.postinst
~~~
if [ -x /usr/sbin/install-mime ]
then
  install-mime  --install --package=ghostview --content=application/postscript \
--description="Postscript Formatted Output" 
--nametemplate="%s.ps" \
--test='test "$DISPLAY" != ""' \
--view='/usr/bin/X11/ghostview %s' \
--comment="Ghostview is a fairly good front-end for viewing 
postscript \
   and should probably be given a reasonably high 
priority."
fi

debian.prerm

if [ -x /usr/sbin/install-mime ]
then
  install-mime --remove --package=ghostview
fi


For more information, please see the "install-mime" man page.

Brian
   ( [EMAIL PROTECTED] )

---
In theory, theory and practice are the same.  In practice, they're not.

Re: Bruce - fiat required to end discussion on lyx/copyright ?

[Dale Scheetz]

On Sat, 24 Aug 1996, Michael Meskes wrote:

> I think our consensus is that the non-free tree is for programs not freed by
> teh copyright, while binary-only packages belong into contrib. Thus contrib
> is the correct location.

Pine is in non-free because it's copyright places restrictions on the
distribution of source. Xforms has more severe restrictions on the
distribution of source than pine does. It is my understanding that this
source distribution restriction is what makes Xforms' proper location to
be non-free.

Luck,

Dwarf

  --

aka   Dale Scheetz   Phone:   1 (904) 877-0257
  Flexible Software  Fax: NONE 
  Black Creek Critters   e-mail:  [EMAIL PROTECTED]

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