No installation ebuild exists for the log reporting system Lire. www.logreport.org Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 20219 [details] lire 1.3 ebuild How does this look? Testing would be much appreciated.
Created attachment 20260 [details] 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 attachment 20305 [details] 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 attachment 20468 [details] 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 attachment 30353 [details] 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 attachment 49063 [details] 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 attachment 49064 [details] 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 attachment 69191 [details] lire-2.0.1-r1.ebuild - 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 attachment 96149 [details] New ebuild for actual version of lire 2.0.2. 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
