--- "Dr. Volker Zell" <[EMAIL PROTECTED]> wrote: > Hi > > Your patch doesn't apply cleanly. Try the below patches.
Ok, I realized that a couple hours after I posted the links, and corrected the problem, but I guess you downloaded before I got that done. Just before I posted the initial source package, I found that the index.htm file in the documentation contained commercial advertising, so I edited it, to remove the ads. But all the docs were using dos cr-lf formatting, rather than unix lf, which for some reason makes patch barf, even though diff computes fine. I'm sure there is an elegant way to solve that problem using diff, but I couldn't find it. I fixed it by putting a d2u command in the unpack function in the packaging script. Is there any problem with that solution? > Some comments: > > o Development packages have devel in their names and not dev OK. I accept your first patch, then. > o Your README states that libswf could be used for SWF support. > But configure checks for libming from > o ming - http://ming.sourceforge.net/ - Good catch. I was going by the docs at the web site, and was led astray. I'll ask Dr. Glunz to update his docs. I guess your second patch takes care of this. > o I would also copy the java subdirectory (without the Makefile* files > of course) to the pstoedit doc dir in the install phase. (This is not > yet in my patch below) OK. > > If you fix these, I think your package is GTG. > > I'm thinking now that packaging plotutils/libplot and then configuring/linking pstoedit against that would greatly expand the range of output formats available from pstoedit. What would you think about deferring a pstoedit package until I make a plotutils package available? I've done a trial build of plotutils, and only issue I see is that it won't build a shared library (libplot) on cygwin, even if it is told to do so during configuration. It builds a static library fine, as far as I can tell. Assuming I go with that instead of trying to fix the issue, that means libplot will be a development library only, required at build time, but not at run time.
