Bug 437667
Summary: | Review Request: dvipdfm - A DVI to PDF converter | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jonathan Underwood <jonathan.underwood> |
Component: | Package Review | Assignee: | Patrice Dumas <pertusus> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | fedora-package-review, jnovy, notting, pertusus |
Target Milestone: | --- | Flags: | pertusus:
fedora-review+
kevin: fedora-cvs+ |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-05-11 00:48:32 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jonathan Underwood
2008-03-16 00:38:42 UTC
The base page is http://gaspra.kettering.edu/dvipdfm/ you used the dvipdfmx one... There is a security issue in dvipdft since it generates files in tmp with predictible names. In texlive dvipdfm the script comes from another place and is furthermore patched. A dot is missing at the end of %description. the doc shipped should be the dvi version or even better the pdf version. To have the dvi, you should have a BuildRequires: tex(tex) and during build do something along pushd doc tex dvipdfm popd and add %docs doc/dvipdfm.dvi To have a pdf it is less obvious since the preferred way seems to be using dvipdfm itself, but since it is not installed it is not obvious that it will succeed. You can try anyway pushd doc tex dvipdfm ../dvipdfm dvipdfm popd and verify that it builds in mock, with an updated texlive that doesn't contain the dvipdfm files that should be in dvipdfm. Last issue regards the differences between config files and corresponding map files. Differences are: D "zcat -f %i | gs -q -sPAPERSIZE=a0 -sDEVICE=pdfwrite -dCompatibilityLevel=1.2 -dUseFlateCompression=true -sOutputFile=%o - -c quit" versus (-dSAFER added in texlive): D "zcat -f %i | gs -q -sPAPERSIZE=a0 -sDEVICE=pdfwrite -dCompatibilityLevel=1.2 -dUseFlateCompression=true -dSAFER -sOutputFile=%o - -c quit" a4 in texlive -p letter +p a4 The maps are, in dvipdfm the shipped maps: f cmr.map f psbase14.map f lw35urw.map In texlive, the font map created by updmap (and another map) are used: f cm-dvipdfm-fix.map f dvipdfm.map It seems to me that the dvipdfm config file in texlive is better, but I am far from being an expert in this matter. It seems to me that the config file in texlive-texmf can be kept instead of using the one in dvipdfm. The map and enc files of dvipdfm should still be shipped, though unused in the default fedora config. A Requires: tex(tex) is also certainly missing, I don't think that dvipdfm will be ok without fonts. These fonts should be brought in by kpathsea, but I think that it is better not to count on it. Spec URL: http://jgu.fedorapeople.org/dvipdfm.spec SRPM URL: http://jgu.fedorapeople.org/dvipdfm-0.13.2d-36.fc9.src.rpm * Sun Apr 14 2008 Jonathan G. Underwood <jonathan.underwood> - 0.13.2d-36 - Fix URL - Cherry pick changes made by TeXLive 2007 - Build dvi and pdf docs - Add Requires for tex(tex) - Add security fix patches for temp file creation As well as dealing with all of the comments you (Patrice) raised, I carefully audited the changes between texlive 2007's version of dvipdfm (which is derived from dvipdfm 0.13.2c) and upstream 0.13.2c and 0.13.2d, and applied what I think are the few necessary changes to the packaged version (0.13.2d). I also reviewed all related patches from Jindrich's texlive package (I hope i didn't miss any). (In reply to comment #1) > The base page is > http://gaspra.kettering.edu/dvipdfm/ > you used the dvipdfmx one... > Fixed. > There is a security issue in dvipdft since it generates files in tmp > with predictible names. In texlive dvipdfm the script comes from another > place and is furthermore patched. > Fixed. > A dot is missing at the end of %description. > Fixed. > the doc shipped should be the dvi version or even better the pdf > version. > > To have the dvi, you should have a > > BuildRequires: tex(tex) > > and during build do something along > pushd doc > tex dvipdfm > popd > Fixed. > and add > %docs doc/dvipdfm.dvi > > To have a pdf it is less obvious since the preferred way seems to > be using dvipdfm itself, but since it is not installed it is not obvious > that it will succeed. You can try anyway > > pushd doc > tex dvipdfm > ../dvipdfm dvipdfm > popd > and verify that it builds in mock, with an updated texlive that doesn't > contain the dvipdfm files that should be in dvipdfm. Fixed and works. > Last issue regards the differences between config files and corresponding > map files. > > Differences are: > D "zcat -f %i | gs -q -sPAPERSIZE=a0 -sDEVICE=pdfwrite -dCompatibilityLevel=1.2 > -dUseFlateCompression=true -sOutputFile=%o - -c quit" > > versus (-dSAFER added in texlive): > > D "zcat -f %i | gs -q -sPAPERSIZE=a0 -sDEVICE=pdfwrite -dCompatibilityLevel=1.2 > -dUseFlateCompression=true -dSAFER -sOutputFile=%o - -c quit" > > > a4 in texlive > -p letter > +p a4 > Fixed - now packaging the texlive config (with the original config shipped as a doc as it contains helpful commentary). > The maps are, in dvipdfm the shipped maps: > f cmr.map > f psbase14.map > f lw35urw.map > I still include these, but they're not used. > In texlive, the font map created by updmap (and another map) are used: > f cm-dvipdfm-fix.map > f dvipdfm.map > yes - the texlive config file will ensure these are used, I believe. > > It seems to me that the dvipdfm config file in texlive is better, but I am > far from being an expert in this matter. > Yes, I think so too. > > > It seems to me that the config file in texlive-texmf can be kept > instead of using the one in dvipdfm. The map and enc files of dvipdfm > should still be shipped, though unused in the default fedora config. > Agreed. > A Requires: tex(tex) is also certainly missing, I don't think that > dvipdfm will be ok without fonts. These fonts should be brought in > by kpathsea, but I think that it is better not to count on it. Fixed. Looks good. Still some little issues: * the comment explaining the tex(tex) BR is a bit wrong now, since it is also used to build the documentation. * I think it would be better to have another name for the config file, it is not very specific (especially for those who have a shared SOURCES directory), like dvipdfm-config. * I suggest using %makeinstall INSTALL='install -p' to keep timestamps. * There are Requires(post): /usr/bin/mktexlsr but it is not used. Since there are files in texmf_main, I guess that the calls should be done. * I think it is better to have rm dvipdft instead of rm -f dvipdft to be warned when upstream changes. Spec URL: http://jgu.fedorapeople.org/dvipdfm.spec SRPM URL: http://jgu.fedorapeople.org/dvipdfm-0.13.2d-37.fc9.src.rpm * Sat Apr 26 2008 Jonathan G. Underwood <jonathan.underwood> - 0.13.2d-37 - Fix comment about texlive-texmf [tex(tex)] BuildRequires - Rename config file tp dvipdfm-config in SRPM - Add INSTALL='install -p' to makeinstall - Run mktexlsr on install * rpmlint is still unhappy: dvipdfm.src: W: mixed-use-of-spaces-and-tabs (spaces: line 5, tab: line 16) dvipdfm.src: W: strange-permission dvipdft 0775 dvipdfm.i386: W: file-not-utf8 /usr/share/man/man1/dvipdft.1.gz dvipdfm.i386: W: file-not-utf8 /usr/share/man/man1/ebb.1.gz These should be fixed. The comment about the BR tex(tex) wasn't changed (as far as I can tell). Spec URL: http://jgu.fedorapeople.org/dvipdfm.spec SRPM URL: http://jgu.fedorapeople.org/dvipdfm-0.13.2d-38.fc9.src.rpm * Sun Apr 27 2008 Jonathan G. Underwood <jonathan.underwood> - 0.13.2d-38 - Untabify spec file - Ensure dvipdft is not executeable in SRPM - Ensure man pages are UTF-8 - Fix comment about tex(tex) rpmlint is now silent. (In reply to comment #5) > The comment about the BR tex(tex) wasn't changed (as far as I can tell). Sorry - I had changed one of the two comments about tex(tex), but not the other. Fixed now. * rpmlint is silent * follow guidelines * match upstream 9d450a964511e4bd68051e793037d8d9 dvipdfm-0.13.2d.tar.gz * %files section right APPROVED I am ok to be in initialCC and commit messages. Jindrich? (In reply to comment #7) > * rpmlint is silent > * follow guidelines > * match upstream > 9d450a964511e4bd68051e793037d8d9 dvipdfm-0.13.2d.tar.gz > * %files section right > > APPROVED > > I am ok to be in initialCC and commit messages. > > Jindrich? Thanks. Jindrich - we'll need to coordinate removal of the relevant parts ot he texlive packaging of dvipdfm as well. New Package CVS Request ======================= Package Name: dvipdfm Short Description: A DVI to PDF converter Owners: jgu pertusus jnovy Branches: F-9 InitialCC: Cvsextras Commits: Yes Patrice - I've put you as a co-maintainer, but I just realized that you wrote "I am ok to be in initialCC and commit messages." - does that mean you don't want to be a co-maintainer for this package? I hope I can convince you to remain as a co-maintainer. jindrich - I added you as a co-maintainer - shout if you don't want to be. (In reply to comment #10) > Patrice - I've put you as a co-maintainer, but I just realized that you wrote "I > am ok to be in initialCC and commit messages." - does that mean you don't want > to be a co-maintainer for this package? It indeed means that I agree to be co-maintainer. But to me when cvsextra people can commit and I am in intialCC and commit messages I consider to have the needed rights for a co-maintainer, since I think it is the primary maintainer duty to use his approveacls power. But I don't mind having full powers either... > I hope I can convince you to remain as a > co-maintainer. I am convinced ;-) > jindrich - I added you as a co-maintainer - shout if you don't want to be. Ok, just writing a comment to let you know I have this on the radar :) Feel free to propose what needs to be done on the texlive side/mostly when is the right time to remove dvipdfm from texlive. cvs done. Imported and built for F-9: http://koji.fedoraproject.org/koji/taskinfo?taskID=603597 Imported and built for devel: http://koji.fedoraproject.org/koji/taskinfo?taskID=603591 Opened a new bug for removing dvipdfm from the texlive packages: https://bugzilla.redhat.com/show_bug.cgi?id=445983 Closing this review bug. |