Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/show_bug.cgi?id=433225
Summary: Review Request: dvipdfmx - A DVI to PDF translator Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: Package Review AssignedTo: nobody@fedoraproject.org ReportedBy: jonathan.underwood@gmail.com QAContact: extras-qa@fedoraproject.org CC: fedora-package-review@redhat.com,notting@redhat.com
Spec URL: http://jgu.fedorapeople.org/dvipdfmx.spec SRPM URL: http://jgu.fedorapeople.org/dvipdfmx-20071115-1.fc9.src.rpm Description: The dvipdfmx (formerly dvipdfm-cjk) project provides an eXtended version of the dvipdfm, a DVI to PDF translator developed by Mark A. Wicks.
Commentary: Another package currently part of texlive, for which texlive is not upstream, hence the desire to split it out as a separate package.
dvipdfm seems to be unmaintained, and so dvipdfmx should probably be considered to be upstream for dvipdfm. I note that texlive currently ships both dvipdfm and dvipdfmx. Can we just ship dvipddfxm - does it have all the functionality of dvipdfm?
I have included the cdi-x.map stuff from texlive spec file, but I'm not 100 percent sure this is still needed.
Currently this package obsoletes and provides dvipdfm.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: dvipdfmx - A DVI to PDF translator
https://bugzilla.redhat.com/show_bug.cgi?id=433225
------- Additional Comments From pertusus@free.fr 2008-02-17 16:31 EST ------- dvipdfm is not obsoleted by dvipdfmx in my opinion, and still maintained, last version is from 05.03.2007 which is pretty recent. Both packages can cohabit.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: dvipdfmx - A DVI to PDF translator
https://bugzilla.redhat.com/show_bug.cgi?id=433225
------- Additional Comments From jonathan.underwood@gmail.com 2008-02-17 16:43 EST ------- Yeah, there was a minor release in 2007 which incorporated two patches, but no major development. Before that, last release was 2001.
I agree that both can co-exist, but what functionality is provided by dvipdfm that's not in dvipdfmx? If there's good reason, I'll knock up a dvipdfm package, but if there's no technical reason, I'd rather not bother.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: dvipdfmx - A DVI to PDF translator
https://bugzilla.redhat.com/show_bug.cgi?id=433225
------- Additional Comments From jonathan.underwood@gmail.com 2008-02-17 16:45 EST ------- But yes, given that both can co-exist, I'll remove the Obsoletes.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: dvipdfmx - A DVI to PDF translator
https://bugzilla.redhat.com/show_bug.cgi?id=433225
------- Additional Comments From pertusus@free.fr 2008-02-17 17:06 EST ------- (In reply to comment #2)
Yeah, there was a minor release in 2007 which incorporated two patches, but no major development. Before that, last release was 2001.
That's not necessarily bad, it may also be that dvipdfm is mature.
I agree that both can co-exist, but what functionality is provided by dvipdfm that's not in dvipdfmx? If there's good reason, I'll knock up a dvipdfm package, but if there's no technical reason, I'd rather not bother.
I don't know exactly what you mean by technical reason. In any case dvipdfm is already in texlive, so maybe it is not worth bothering packaging it separately if it is not updated more often than texlive. However I think that a dvipdfm package should stay, especially if it works well and isn't updated often.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: dvipdfmx - A DVI to PDF translator
https://bugzilla.redhat.com/show_bug.cgi?id=433225
------- Additional Comments From pertusus@free.fr 2008-02-17 17:22 EST ------- rpmlint says:
dvipdfmx.src: W: mixed-use-of-spaces-and-tabs (spaces: line 1, tab: line 9) dvipdfmx.i386: E: zero-length /usr/share/doc/dvipdfmx-20071115/NEWS
It seems to me that version should be 0 and release should be 0.x.20071115. However, dvipdfmx in texlive is already at release 16, so it seems to me that it can be 17.x.20071115. Or even x.20071115 with x beginning at 17.
Why the texlive-texmf BuildRequires?
The files %{_texmf_main}/fonts/cmap/EUC-UCS2 %{_texmf_main}/fonts/cmap/UniKSCms-UCS2-H %{_texmf_main}/fonts/cmap/UniKSCms-UCS2-V are already owned by texlive-texmf-fonts, which package should own them?
In the texlive spec, there is, for the dvipdfmx subpackage: # for cmap files Requires: texlive-texmf-fonts = %{texlive_ver}
I think that it would be better to list explicitly the files in %_bindir, to avoid surprises.
I suggest adding INSTALL='install -p' to make install.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: dvipdfmx - A DVI to PDF translator
https://bugzilla.redhat.com/show_bug.cgi?id=433225
------- Additional Comments From jonathan.underwood@gmail.com 2008-02-17 18:09 EST ------- (In reply to comment #5)
rpmlint says:
dvipdfmx.src: W: mixed-use-of-spaces-and-tabs (spaces: line 1, tab: line 9) dvipdfmx.i386: E: zero-length /usr/share/doc/dvipdfmx-20071115/NEWS
OK, will fix.
It seems to me that version should be 0 and release should be 0.x.20071115. However, dvipdfmx in texlive is already at release 16, so it seems to me that it can be 17.x.20071115. Or even x.20071115 with x beginning at 17.
Well, here I'd agree we should have something like x.20071115 as the version number, but I don't like the 17 - what happens when upstream get to 1.0 for example. This seems like a legitimate use of epoch to me. What do you think?
Why the texlive-texmf BuildRequires?
For the macro definitions eg. _texmf_main etc.
The files %{_texmf_main}/fonts/cmap/EUC-UCS2 %{_texmf_main}/fonts/cmap/UniKSCms-UCS2-H %{_texmf_main}/fonts/cmap/UniKSCms-UCS2-V are already owned by texlive-texmf-fonts, which package should own them?
I think these should be in the dvipdfmx package, as they originate from that tarball - will wait for Jindrich to comment on this also.
In the texlive spec, there is, for the dvipdfmx subpackage: # for cmap files Requires: texlive-texmf-fonts = %{texlive_ver}
Yes, I can do that in this package also.
I think that it would be better to list explicitly the files in %_bindir, to avoid surprises.
OK.
I suggest adding INSTALL='install -p' to make install.
OK. Can't help wondering why this isn't a guideline.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: dvipdfmx - A DVI to PDF translator
https://bugzilla.redhat.com/show_bug.cgi?id=433225
------- Additional Comments From pertusus@free.fr 2008-02-17 18:18 EST ------- (In reply to comment #6)
It seems to me that version should be 0 and release should be 0.x.20071115. However, dvipdfmx in texlive is already at release 16, so it seems to me that it can be 17.x.20071115. Or even x.20071115 with x beginning at 17.
Well, here I'd agree we should have something like x.20071115 as the version number, but I don't like the 17 - what happens when upstream get to 1.0 for example. This seems like a legitimate use of epoch to me. What do you think?
I am not saying the same. I am saying 0 for the version, and x.20071115 for the release.
Why the texlive-texmf BuildRequires?
For the macro definitions eg. _texmf_main etc.
I think it would be better to define them in case they are not defined, and this deserves a comment.
The files %{_texmf_main}/fonts/cmap/EUC-UCS2 %{_texmf_main}/fonts/cmap/UniKSCms-UCS2-H %{_texmf_main}/fonts/cmap/UniKSCms-UCS2-V are already owned by texlive-texmf-fonts, which package should own them?
I think these should be in the dvipdfmx package, as they originate from that tarball - will wait for Jindrich to comment on this also.
Indeed.
In the texlive spec, there is, for the dvipdfmx subpackage: # for cmap files Requires: texlive-texmf-fonts = %{texlive_ver}
Yes, I can do that in this package also.
No, this is only needed if the files come from texlive-texmf-fonts. Though maybe dvipdfmx needs texlive-texmf-fonts for other reasons.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: dvipdfmx - A DVI to PDF translator
https://bugzilla.redhat.com/show_bug.cgi?id=433225
------- Additional Comments From jonathan.underwood@gmail.com 2008-02-17 20:24 EST ------- Spec URL: http://jgu.fedorapeople.org/dvipdfmx.spec SRPM URL: http://jgu.fedorapeople.org/dvipdfmx-0-0.20.20071115cvs.fc9.src.rpm
* Sun Feb 17 2008 Jonathan G. Underwood jonathan.underwood@gmail.com - 0-0.20.20071115cvs - Remove obsolete and Provides for dvipdfm - Explicitly list contents of bindir in file list - Fix version and release tags to be guideline conforming - Add INSTALL='install -p' to make install - Add macro definitions from texlive-texmf spec file in case not defined - Remove NEWS and TODO from doc file list
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: dvipdfmx - A DVI to PDF translator
https://bugzilla.redhat.com/show_bug.cgi?id=433225
pertusus@free.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Flag| |needinfo?(jnovy@redhat.com)
------- Additional Comments From pertusus@free.fr 2008-03-03 11:39 EST ------- 2 issues remaining:
The %{_texmf_main}/fonts/cmap/EUC-UCS2 %{_texmf_main}/fonts/cmap/UniKSCms-UCS2-H %{_texmf_main}/fonts/cmap/UniKSCms-UCS2-V files ownership. Jindriiiiiich?
The release is 0.20.... while dvipdfmx coming from current texlive is 19. It is bad. I suggest using directly 20, even if it is against the guideline, and use something like 20.1.20071115cvs to avoid going higher than 20, since dvipdfmx in texlive is already wrong. Another possibility would be to use epochs, but I think we should avoid as much as possible.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: dvipdfmx - A DVI to PDF translator
https://bugzilla.redhat.com/show_bug.cgi?id=433225
jnovy@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED Flag|needinfo?(jnovy@redhat.com) |
------- Additional Comments From jnovy@redhat.com 2008-03-03 12:24 EST ------- Oops, sorry for a bit delayed reply. I agree to put the latest dvipdfmx in. I couldn't test the package yet because of broken elfutils in buildroots. I'll report back later.
For now I can only tell that it is be better to have cmap files shipped in dvipdfmx than in texlive.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: dvipdfmx - A DVI to PDF translator
https://bugzilla.redhat.com/show_bug.cgi?id=433225
------- Additional Comments From pertusus@free.fr 2008-03-03 15:13 EST ------- (In reply to comment #10)
For now I can only tell that it is be better to have cmap files shipped in dvipdfmx than in texlive.
That's the only thing I was waiting for ;-). If you can wait for the end of the week I will do the change to texlive needed to remove dvipdfmx, but if you can do it before, do it.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: dvipdfmx - A DVI to PDF translator
https://bugzilla.redhat.com/show_bug.cgi?id=433225
------- Additional Comments From jonathan.underwood@gmail.com 2008-03-04 06:49 EST ------- (In reply to comment #9)
The release is 0.20.... while dvipdfmx coming from current texlive is 19. It is bad. I suggest using directly 20, even if it is against the guideline, and use something like 20.1.20071115cvs to avoid going higher than 20, since dvipdfmx in texlive is already wrong. Another possibility would be to use epochs, but I think we should avoid as much as possible.
I would much much much rather use an epoch to get around this problem - I think it's really important to try to stick to the guidelines for version/release tags since things like automated package rebuild scripts can/will fail for packages which don't follow the guidelines.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: dvipdfmx - A DVI to PDF translator
https://bugzilla.redhat.com/show_bug.cgi?id=433225
------- Additional Comments From pertusus@free.fr 2008-03-04 07:37 EST ------- I really dislike epochs because it is easy to forget about them. Another possibility would be leave the version as is and not add an epoch, and break upgrade paths and tell people on the devel mailing list to remove the texlive dvipdfmx.
In any case do whatever you prefer between those possibilities.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: dvipdfmx - A DVI to PDF translator
https://bugzilla.redhat.com/show_bug.cgi?id=433225
------- Additional Comments From jnovy@redhat.com 2008-03-04 10:47 EST ------- (In reply to comment #11)
(In reply to comment #10)
For now I can only tell that it is be better to have cmap files shipped in dvipdfmx than in texlive.
That's the only thing I was waiting for ;-). If you can wait for the end of the week I will do the change to texlive needed to remove dvipdfmx, but if you can do it before, do it.
Ok, dvipdfmx is now remove from texlive-2007-23.fc9 and on. Feel free to import/build after approval.
FYI: http://koji.fedoraproject.org/koji/taskinfo?taskID=490825
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: dvipdfmx - A DVI to PDF translator
https://bugzilla.redhat.com/show_bug.cgi?id=433225
pertusus@free.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|nobody@fedoraproject.org |pertusus@free.fr Flag| |fedora-review+
------- Additional Comments From pertusus@free.fr 2008-03-06 17:17 EST ------- Since the only remaining issue is up to you, this is APPROVED
The source match upstream: 55b30f37da7be24e6a065e286d1f1b2b dvipdfmx-20071115.tar.gz
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: dvipdfmx - A DVI to PDF translator
https://bugzilla.redhat.com/show_bug.cgi?id=433225
------- Additional Comments From jonathan.underwood@gmail.com 2008-03-06 19:04 EST ------- (In reply to comment #13)
I really dislike epochs because it is easy to forget about them.
me too.
Another possibility would be leave the version as is and not add an epoch, and break upgrade paths and tell people on the devel mailing list to remove the texlive dvipdfmx.
OK, on balance, I like this option best, so will go with that.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: dvipdfmx - A DVI to PDF translator
https://bugzilla.redhat.com/show_bug.cgi?id=433225
jonathan.underwood@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag| |fedora-cvs?
------- Additional Comments From jonathan.underwood@gmail.com 2008-03-06 19:07 EST ------- New Package CVS Request ======================= Package Name: dvipdfmx Short Description: A DVI to PDF translator Owners: jgu jnovy pertusus Branches: InitialCC: Cvsextras Commits: Yes
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: dvipdfmx - A DVI to PDF translator
https://bugzilla.redhat.com/show_bug.cgi?id=433225
kevin@tummy.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|fedora-cvs? |fedora-cvs+
------- Additional Comments From kevin@tummy.com 2008-03-06 19:22 EST ------- cvs done.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: dvipdfmx - A DVI to PDF translator
https://bugzilla.redhat.com/show_bug.cgi?id=433225
jonathan.underwood@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE
------- Additional Comments From jonathan.underwood@gmail.com 2008-03-07 19:02 EST ------- Thanks Kevin.
Package built and pushed for rawhide. Closing NEXTRELEASE.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: dvipdfmx - A DVI to PDF translator
https://bugzilla.redhat.com/show_bug.cgi?id=433225
------- Additional Comments From pauljohn@ku.edu 2008-04-02 21:21 EST ------- On Fedora 8, I found texlive-xetex would not install without dvipdfmx, but there was no such package available. I downloaded the version from koji and installed everything OK. But I think you should put dvipdfmx in the Fedora 8 repository if you have texlive-xetex require it.
package-review@lists.fedoraproject.org