Bugzilla Bug 32648

No installation ebuild exists for the log reporting system Lire. 
www.logreport.org

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Created an attachment (id=20219) [edit]
lire 1.3 ebuild

How does this look? Testing would be much appreciated.

Created an attachment (id=20260) [edit]
Modified ebuild with added xsl stylesheet dependency

I added a dependency for xsl stylesheets.  I'm not sure if ploticus or lynx
could be considered possible use variables, but those are things that might
be
wanted by people.  However, the ebuild seems good now :)

Here's the installation manual page for lire:
http://download.logreport.org/pub/current/doc/user-manual/ch02s02.html

I think everything that gentoo has in the portage system is now supported,
but
I mentioned above that ploticus and lynx might be addable in some manner.

Thanks for the prompt work on this.


Include excerpt from configuration (determine if ploticus or lynx are
interesting):
checking for ploticus... no
checking for pl... no
checking for gs... /usr/bin/gs
checking for XML::Parser... yes
checking for GD::Graph... no (you can install it later)
checking for SpreadSheet::WriteExcel... no (you can install it later)
checking for MIME::Entity... yes
checking for Time::Timezone... no (will install included version)
checking for jade... jade
checking for jade... /usr/bin/jade
checking for pdfjadetex... no
checking for pdfxmltex... no
checking for xsltproc... /usr/bin/xsltproc
checking xsltproc version >= 1.0.4... yes (10031)
checking for xmlcatalog... /usr/bin/xmlcatalog
checking default xslt processor... xsltproc
checking for lynx... no
checking for SGML/XML trees...	/usr/share/sgml /usr/share/xml
checking for DocBook XML DTD...
/usr/share/sgml/docbook/xml-dtd-4.1.2/docbookx.dtd
checking for DocBook DSSSL stylesheets... no
checking for DocBook XSL stylesheets... no
checking for dia... no
checking for epsffit... yes
checking for epsffit... /usr/bin/epsffit
checking for convert... yes
checking for convert... /usr/bin/convert
checking for epstopdf... no
checking for xmllint... yes
checking for xmllint... /usr/bin/xmllint

Created an attachment (id=20305) [edit]
lire-1.4_rc1.ebuild (broken)

Lire 1.4rc1 was released yesterday, and I modified the old ebuild for the
new
release.  There however is a dependency upon DBD::SQLite 0.28 which does
not
exist in the portage tree.  I'm submitting this ebuild and also going to
submit
a request that the perl module be added.

For the new 1.4rc1 release I've created a new bug report:
http://bugs.gentoo.org/show_bug.cgi?id=32824

This is for the DBD::SQLite 0.28 lack of an ebuild.

It seems that the Lire configuration script is kinda stupid, and is unable
to find the location of the xsl stylesheets it requires for xml transformations.
 I've mentioned this to the Lire guys and they'll probably fix this in an
upcoming release.  However this is a problem with Lire 1.3 and *may* be resolved
in a *future* version of Lire 1.4.  Below are options to configure to tell
it where the xsl stylesheets are.  Perhaps a revision can be made to the
above ebuilds to reflect the need for specification with configure?

DBK_XML_DTD=path_to_docbook_dir/docbookx.dtd \
 DBK_DSSSL_STYLESHEETS=path_to_dbk_dsssl_dir \
 DBK_XSL_STYLESHEETS=path_to_dbk_xsl_dir \
 ./configure [--prefix=path]

The xsl stylesheets don't seem to be ~sparc yet. I'll test these at the weekend
-- I can't imagine any problems, but if necessary we'll go back to making
lire just ~x86 for now. I'd also be inclined to add these under the xml USE
flag maybe?

I don't see any mention of lynx on the Requirements page. I can't find Ploticus
in portage anywhere, but if it's ever added it can be listed as an optional
dependency.

There are a couple of things we can do to fix configure options. If the configure
script doesn't handle variables correctly (it doesn't seem to) we can resort
to some more sed magic to fix things.

I'm inclined to wait for a resolution to bug 32824 so that we can go ahead
with a 1.4rc ebuild straight away. If the Lire people happen to put out another
RC with a fixed configure script before then then so much the better.

I've talked with the Lire guys and they are planning on phasing out the XSL
stylesheet requirement sometime in the future (early 2004?).  They don't
seem interested in fixing configure since they are phasing out the stylesheet.
 I think that DBK_XSL_STYLESHEETS option should let their configure script
find the xsl stylesheets appropriately.  So when the blocking bug gets resolved,
a workaround for configure needs to be implemented (I'd try the above first
then sed magic).  

Their configure script is able to find the xml dtd.  The XML requirement
will remain, so I'm not sure if the USE variable is appropriate.  The XML
stylesheet allows an assortment of outputs other than text.  I consider it
base functionality as opposed to an added feature.

Lynx and ploticus aren't dependencies nor requirements, but they allow additional
functionality, which is why I thought they might fall under a USE variable
or something.

app-text/docbook-xsl-stylesheets 1.62.4 moved to ~sparc so that I can carry
on testing this.

Created an attachment (id=20468) [edit]
revised lire 1.4_rc1 ebuild (broken)

Revised 1.4rc1 ebuild. I've replaced the hardcoded filename with a bit of
bash
that removes the underscore character. I've also added in code to give
configure the paths to the docbook stuff (DTD included for consistency).
Fortunately, configure picks these options up correctly.

For testing purposes, uncommenting the ### lines will remove the configure
check for SQLite until we get an ebuild for it.

A lynx? DEPEND has been added in.

Waiting for bug 32824 before I take this any futher. In the mean time, testing
would be appreciated if people are prepared to install SQLite manually.

Created an attachment (id=30353) [edit]
Lire 1.5 ebuild with updated dependencies

This ebuild successfully installed Lire 1.5 on my workstation, and I am
verifying that it functions properly with some production data (i.e. that the
installed Lire actually produces correct results).

Please, stop the dependancy requirements for lire bugs!  They are duplicates
and only make it harder for bug handlers to work with relevent bugs.  If
dependancies are missed, they should be discussed in this bugs, and not other
bugs.  

My appologies.  I thought that would be the best way to address the dependency
issues.  Thank you for relaying that information to me, I'll be careful not to
confuse the issue in the future.

I should mention that 32824 seems to be fixed now.  I've been able to install
lire with my ebuild and the related new bugs I added.

Alright, so I've reviewed my 1.5 ebuild and it sucks and is wrong in all sorts
of ways.  Since I intend to fix this and get it right, I'm reviewing what was
done  *right* in the Lire 1.4 ebuild and how that meshes with the searches done
by the Lire configure scripts.  Quick note, the 1.5 ebuild only does text for
sure.

GOOD NEWS:
I asked the Lire people to add support for DBK_DSSSL_STYLESHEETS in the next
release.  Basically they do a search for stylesheet/dsssl/docbook/ directory
and I asked if they would add 'stylesheets' to the search path, as this should
work for Gentoo.  It appears as DBK_XML_DTD will be found with the Lire 1.5
configuration.  So by the next release those two variables won't require
anything special in the ebuild to find them.

PROBLEM:
For DBK_XSL_STYLESHEETS there does seem to be a problem.  Lire I don't think
will be able to support this without a link to the current version.  Anyways
the 1.4 ebuild handling appears broken to me. 
'/usr/share/sgml/docbook/xsl-stylesheets-1.62.0/' is returned by running the
command for getting the variable from the 1.4 ebuild.  This directory does not
exist on my system.  A quick check turned up that I have
'/usr/share/sgml/docbook/xsl-stylesheets-1.62.4/', in either case, Lire needs
to be told what the right path is and does not have a good way to search for
it.  I'm unsure of the *proper* way to setup this variable if the path will
change and the 1.4ebuild command no longer works.  (Perhaps there's a bug in
/etc/xml/dockbook?)

Lire 2.0 released: http://logreport.org/ Is there any plan bout ebuild?

Lire 2.0 is out - with many interesting things - andy it seems to depend on
ploticus - of which there is an ebuild in the buglist.

I too would very much like an ebuild for lire :)

Created an attachment (id=49063) [edit]
lire-2.0.1.ebuild

This is an ebuild for Lire-2.0.1.  I've tested this on several x86 machines and
the installation went fine.  If anyone has problems, let me know.

The big changes are that the dependencies changed and that the stylesheets are
now included in lire.  This means the code for finding the stylesheets
installed on the system are no longer required.

Created an attachment (id=49064) [edit]
DBD-SQLite2-0.33.ebuild (Perl dependency that exists in portage tree)

This ebuild provides a required dependency for lire-2.0.1.  DBD-SQLite exists
in the portage tree, however there are 2 versions of SQLite.  SQLite has 2
API's that differ for version 2 and 3.	DBD-SQLite2 is the continuation of the
version 2 api and continues with the 0.XX versions of DBD-SQLite.  DBD-SQLite
version 1.0 and above are supporting the version 3 api.  I'm not sure what the
rationale behind DBD-SQLite being in the portage tree was, but it may be
prudent to include DBD-SQLite2 as a package for the same reasons, or it may be
able to be a slotted version.

Hi,  
  
The ebuild needs an update. The dependency dev-perl/Digest-MD5 has been moved  
to perl-core/Digest-MD5.  
  
Just a question: why isn't it in the portage tree? It seems to be a working  
ebuild... 

Created an attachment (id=69191) [edit]
Updated DB_File and Digest-MD5 depencies

Updated DB_File and Digest-MD5 to be perl-core/DB_File and perl-core/Digest-MD5
instead of the old style dev-perl/DB_File and dev-perl/Digest-MD5

Created an attachment (id=96149) [edit]
New ebuild for actual version of lire. 

I edit old ebuild for lire a this just works fine (until the new lire's
release). I tried to compile lire on 3 computers and it works

Not Found

The requested URL /lire.html/ was not found on this server.
Apache/2.2.3 (Debian) DAV/2 SVN/1.4.2 PHP/5.2.0-8+etch7 mod_ssl/2.2.3
OpenSSL/0.9.8c Server at logreport.org Port 80