Bug 66246 - new ports: textproc/docbook-utils, textproc/p5-SGMLSpm
Summary: new ports: textproc/docbook-utils, textproc/p5-SGMLSpm
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Sam Lawrance
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-05-04 11:20 UTC by Brian Candler
Modified: 2005-11-10 02:59 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brian Candler 2004-05-04 11:20:24 UTC
I have written ports for "docbook-utils" and the Perl module it depends on,
"p5-SGMLSpl". You can find them at
http://www.linnet.org/ports/docbook-utils.tgz
http://www.linnet.org/ports/p5-SGMLSpm.tgz

This is my first attempt at contributing to FreeBSD ports; I'd be grateful
if someone would check through what I've done before committing.

"docbook-utils" is the package bundled with most Linux distributions for
processing docbook sources. It includes scripts such as docbook2html and
docbook2man.

There is a particular reason why I want to see it in the ports collection:
I've been in contact with the author of sgmltools-lite and he says that he
is not maintaining this package, and therefore he will not be releasing any
new version after 3.0.3 (this was when I sent in a patch to try and fix a
problem with it not using /usr/local/share/sgml/catalog properly). In that
case, it really seems to make sense to use what most other people are using.

Fix: 

See URLs above.
How-To-Repeat: 
Here's the patch I tried to get incorporated into sgmltools-lite:

--- utils.py.orig	Mon Apr 26 13:15:15 2004
+++ utils.py	Mon Apr 26 13:22:29 2004
@@ -247,7 +247,11 @@
 	#
 	mo = re.compile(r'CATALOG\s*"([^"]+)"').match(line)
 	if mo != None:
-	    retval = _searchInCat(mo.group(1), id, section)
+	    subfile = mo.group(1)
+	    if subfile[0] != '/' and curcat[0] == '/':
+		curdir = re.compile(r'/[^/]+$').sub('/',curcat)
+		subfile = curdir+subfile
+	    retval = _searchInCat(subfile, id, section)
 	    if retval != None:
 		return retval;
 
and here's the response I got:

Hi Brian,

SGMLtools is not being maintained anymore, at least not by me. So I
cannot use your patch to create a new release.

Regards,

Cees
Comment 1 Volker Stolz freebsd_committer freebsd_triage 2004-06-25 12:34:27 UTC
Should we consider incorparting your patch into sgmltools-lite as a  
contribution?
Can you please elaborate what it fixes?

Volker
Comment 2 Brian Candler 2004-06-26 19:08:22 UTC
On Fri, Jun 25, 2004 at 01:34:27PM +0200, Volker Stolz wrote:
> Should we consider incorparting your patch into sgmltools-lite as a  
> contribution?
> Can you please elaborate what it fixes?

The problem was that I couldn't make it work with FreeBSD's catalog
collection. I thought that I should be able to do

SGML_CATALOG_FILES=/usr/local/share/sgml/catalog sgmltools ...

but it didn't work because the catalog files contain relative filenames:
e.g. /usr/local/share/sgml/catalog contains
  CATALOG "catalog.ports"
/usr/local/share/sgml/catalog.ports contains
  CATALOG "iso8879/catalog"
  CATALOG "docbook/4.1/catalog"
  ... etc

and this is what the patch fixes. (I don't know how anyone managed to get
sgmltools-lite to work without it, unless they are expected to make their
own set of catalog files or symlinks to catalog files, which seems poor
design as it duplicates what FreeBSD's master catalog file should do)

I've just tried installing sgmltools-lite-3.0.3_1 again (with my patch
applied), and with a bit of fiddling I came up with this command line:

SGML_CATALOG_FILES=/usr/local/share/sgml/stylesheets/sgmltools/sgmltools.cat:/usr/local/share/sgml/catalog sgmltools -b html test.sgml

and hey presto it works. If this simple command line could be put in the
documentation somewhere (in the pkg-descr, perhaps) then it would make
sgmltools-lite much easier to get started with. Even better would be if the
package could set this up as the default set of catalog files. Perhaps
sgmltools.cat ought to find its way into catalog.ports as well.

However, I have also come across Makefiles in other packages which reference
tools docbook2html and friends from docbook-utils (e.g. if you build
courier-imap from CVS you need these tools) so I still think they may be
worth packaging in their own right.

Regards,

Brian.
Comment 3 Sam Lawrance freebsd_committer freebsd_triage 2005-09-01 08:52:35 UTC
State Changed
From-To: open->feedback

Hi, 

Are you still interested in adding these ports to the ports collection?  If so, could you please: 
- make sure that the shar you originally sent is up to date 
- set the port MAINTAINER is set to your email address (if not already done) 
- test the port to see that it still works correctly 

Thanks! 


Comment 4 Sam Lawrance freebsd_committer freebsd_triage 2005-09-01 08:52:35 UTC
Responsible Changed
From-To: freebsd-ports-bugs->lawrance

Take
Comment 5 Brian Candler 2005-09-11 16:24:56 UTC
On Thu, Sep 01, 2005 at 07:53:36AM +0000, Sam Lawrance wrote:
> Are you still interested in adding these ports to the ports collection?  If so, could you please:
> - make sure that the shar you originally sent is up to date
> - set the port MAINTAINER is set to your email address (if not already done)
> - test the port to see that it still works correctly

Yes, I'm still interested (building the courier suite from CVS still needs
docbook2html and docbook2man). Thanks for picking up this PR!

I have re-tested the port, made a minor tweak and re-uploaded to
http://www.linnet.org/ports/docbook-utils.tgz
The p5-SGMLS port didn't need any updating (feel free to set the MAINTAINER)

However, perhaps someone who understands the SGML/XML catalog system better
than me can help me. There is a conflict when building the docbook-utils port
if "docbook-sk" is installed (e.g. required by scrollkeeper which in turn is
required by libgnome). I had to pkg_delete -f docbook-sk\* for the port to
build. (This is just a build-time problem, and the package seems to work
correctly if used subsequently even if docbook-sk is reinstalled, so I
don't think this warrants a CONFLICTS entry)

If docbook-sk remains installed, the error you get is:

gmake[2]: Entering directory `/v/ports/textproc/docbook-utils/work/docbook-utils-0.6.14/doc/HTML'
SGML_CATALOG_FILES=/usr/local/share/sgml/catalog \
SGML_SEARCH_PATH=../..:../../doc:.. \
        jade -t sgml -i html -d ../../docbook-utils.dsl\#html \
                -V '%use-id-as-filename%' ../../doc/docbook-utils.sgml
jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:8:19:E: "X21B6" is not a function name
jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:9:19:E: "X21B7" is not a function name
... lots more of these

but I can't see why these (XML) entity definitions are being included when
building an SGML document.

The file causing the problem *does* exist in the catalog:

$ cd /usr/local/share/sgml
$ cat catalog
-- Created by XML Catalog Manager 2.2 --
CATALOG "catalog.ports"

[brian@billdog sgml]$ cat catalog.ports
-- Created by xmlcatmgr-2.1 --
CATALOG "/usr/local/share/xml/docbook/4.1.2/docbook.cat"    # <<<<< HERE

CATALOG "/usr/local/share/xml/docbook/4.2/docbook.cat"

CATALOG "/usr/local/share/xml/sdocbook/4.1.2.5/catalog"

CATALOG "/usr/local/share/xml/dtd/xhtml/xhtml-dcl.soc"

CATALOG "iso8879/catalog"

CATALOG "html/catalog"

CATALOG "docbook/4.1/catalog"

CATALOG "docbook/dsssl/modular/catalog"

CATALOG "jade/catalog"

CATALOG "docbook/3.1/catalog"

$ grep iso-amsa /usr/local/share/xml/docbook/4.1.2/docbook.cat
PUBLIC "ISO 8879:1986//ENTITIES Added Math Symbols: Arrow Relations//EN" "ent/iso-amsa.ent"

but I'm at a loss to see why it's being used, especially since the
particular document being built uses the V3.1 DocBook definition:

# grep DOCTYPE work/docbook-utils-0.6.14/doc/docbook-utils.sgml 
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V3.1//EN" [

Any clues gratefully received.

Thanks,

Brian Candler.
Comment 6 Brian Candler 2005-09-11 16:24:56 UTC
On Thu, Sep 01, 2005 at 07:53:36AM +0000, Sam Lawrance wrote:
> Are you still interested in adding these ports to the ports collection?  If so, could you please:
> - make sure that the shar you originally sent is up to date
> - set the port MAINTAINER is set to your email address (if not already done)
> - test the port to see that it still works correctly

Yes, I'm still interested (building the courier suite from CVS still needs
docbook2html and docbook2man). Thanks for picking up this PR!

I have re-tested the port, made a minor tweak and re-uploaded to
http://www.linnet.org/ports/docbook-utils.tgz
The p5-SGMLS port didn't need any updating (feel free to set the MAINTAINER)

However, perhaps someone who understands the SGML/XML catalog system better
than me can help me. There is a conflict when building the docbook-utils port
if "docbook-sk" is installed (e.g. required by scrollkeeper which in turn is
required by libgnome). I had to pkg_delete -f docbook-sk\* for the port to
build. (This is just a build-time problem, and the package seems to work
correctly if used subsequently even if docbook-sk is reinstalled, so I
don't think this warrants a CONFLICTS entry)

If docbook-sk remains installed, the error you get is:

gmake[2]: Entering directory `/v/ports/textproc/docbook-utils/work/docbook-utils-0.6.14/doc/HTML'
SGML_CATALOG_FILES=/usr/local/share/sgml/catalog \
SGML_SEARCH_PATH=../..:../../doc:.. \
        jade -t sgml -i html -d ../../docbook-utils.dsl\#html \
                -V '%use-id-as-filename%' ../../doc/docbook-utils.sgml
jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:8:19:E: "X21B6" is not a function name
jade:/usr/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:9:19:E: "X21B7" is not a function name
... lots more of these

but I can't see why these (XML) entity definitions are being included when
building an SGML document.

The file causing the problem *does* exist in the catalog:

$ cd /usr/local/share/sgml
$ cat catalog
-- Created by XML Catalog Manager 2.2 --
CATALOG "catalog.ports"

[brian@billdog sgml]$ cat catalog.ports
-- Created by xmlcatmgr-2.1 --
CATALOG "/usr/local/share/xml/docbook/4.1.2/docbook.cat"    # <<<<< HERE

CATALOG "/usr/local/share/xml/docbook/4.2/docbook.cat"

CATALOG "/usr/local/share/xml/sdocbook/4.1.2.5/catalog"

CATALOG "/usr/local/share/xml/dtd/xhtml/xhtml-dcl.soc"

CATALOG "iso8879/catalog"

CATALOG "html/catalog"

CATALOG "docbook/4.1/catalog"

CATALOG "docbook/dsssl/modular/catalog"

CATALOG "jade/catalog"

CATALOG "docbook/3.1/catalog"

$ grep iso-amsa /usr/local/share/xml/docbook/4.1.2/docbook.cat
PUBLIC "ISO 8879:1986//ENTITIES Added Math Symbols: Arrow Relations//EN" "ent/iso-amsa.ent"

but I'm at a loss to see why it's being used, especially since the
particular document being built uses the V3.1 DocBook definition:

# grep DOCTYPE work/docbook-utils-0.6.14/doc/docbook-utils.sgml 
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V3.1//EN" [

Any clues gratefully received.

Thanks,

Brian Candler.
Comment 7 Sam Lawrance freebsd_committer freebsd_triage 2005-11-10 02:58:23 UTC
State Changed
From-To: feedback->closed

Committed with some minor tweaks, thanks! 

I set you as MAINTAINER, as agreed.