On Fri, 2006-01-06, at 15:55:15 +0530, Kapil Hari Paranjape wrote: > Dear Anders, > > On Wed, 28 Dec 2005, Anders Lennartsson wrote: > > I'm looking for a sponsor for a set of deb-packages of bmeps and the > > libraries. > > I am not a DD so I cannot sponsor your upload but here are some > comments on your package. > > > This application is a tool to convert various bitmaps to > > eps-format. It is released by the upstream author Dirk Krause under > > LGPL. The upstream web-site is at http://bmeps.sourceforge.net. > > > > >From the control file: > > The bmeps packages contain tools for converting bitmap images to > > eps-files. Currently bmeps can handle .pnm, .ppm, .pgm, .pbm, .jpeg, > > and .png images. The conversion functions are also available in > > library form. > > Since PNG and JPG files can be included in PS level 3 essentially > without conversion you could perhaps give some reasons why such > conversion could be useful.
Bmeps is a project to add bitmap graphics support to dvips. This makes it useful for including bitmaps in LaTeX documents. This is particularly useful when producing dvi-documents, but less useful for pdfLaTeX since then some bitmaps can be included already. >From the manual page: The EPS images are intended for use with text processing and DTP systems (i.e. LaTeX), not for direct printing. No attempts are made to fit pages of any paper size, scaling and rotating is left up to the text processing software using the EPS images. You can produce EPS level 1, 2 or 3. Different compression and encoding mechanisms are avail- able: run-length-compression (requires EPS level 2), flate compression (requires EPS level 3) and ASCII-85-encoding (requires EPS level 3). Alpha channels in PNG files can be used to mix against a user specified background colour and/or to create an image mask for EPS level 3 output files. There is also the option of of extending dvips with the capability to include (compressed) bitmaps, which I assume depends on the possibility of including bitmaps in PS level 3(?). In fact, there is a patched dvipsk included in the source tar-file, although not the latest version, that does this. > > The packaging specific parts and files are viewable on > > http://www.lennartsson.se/svn/debian/bmeps > > (at least will be, after syncing tonight) > > I couldn't access the packages from there but from the sources lines > given below I could. With a browser you can look in there, in trunk or tags, to see the files in the debian directory, rules, changelog etc, which are under version control by subversion. > > debs are available from > > deb http://www.lennartsson.se/ debian/ > > deb-src http://www.lennartsson.se/ debian/ > > 1. Lintian points out the following errors: How did you instruct lintian to do this? (ok, I'll read the man again...) > a. The debian/compat file and the DH_COMPAT variable in > debian/rules are two ways of doing the same thing. You should > pick one. Thanks for pointing this out. > b. While your debian/changelog says you bumped the standards version > your debian/control file does not indicate the same. Oops. > 2. The orig.tar.gz contains the original tar.gz as a file. Is there a > reason for packaging this way rather than the more conventional > way of keeping the original tar.gz as Debian's orig.tar.gz? Packaging with dbs normally involves this method. I suppose it is a matter of taste or philosophy, but building the package by first unpacking the original tar-file, applying any pathces, and so on, seems nice to me. It clearly separates the upstream files from the debian-specific parts, including patches. For my bmeps package you can look at the changes to the upstream at http://www.lennartsson.se/svn/debian/bmeps/trunk/patches Other similiary packging methods are cdbs or dpatch. Of course they may seem to be overkill for simple packages but I started out by using dbs on simple packages to learn the method. > 3. The debian/changelog refers to earlier versions of bmeps but there > were no earlier versions in the archive! Hmm, must earlier versions be archived? The necessary (debian) files are available in svn and the upstream tar-files are available from sourceforge. So it is in principle possible to build them. But they were originally built on various states of sid, which I don't keep track of when i upgrade, so I don't see the value of keeping the binary packages. > All the best with getting your package accepted by a "real" sponsor. > > Regards, > > Kapil. > -- Thank you, Anders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
