Spec URL: https://raw.github.com/Hubbitus/Fedora-packaging/5571c2bf2ecf9598e85162d0a36441949f6f7cb1/SPECS/tora.spec SRPM URL: http://hubbitus.info/rpm/Fedora18/tora/tora-3-0.1.svn4651.fc18.src.rpm Description: TOra - Toolkit for Oracle TOra is supported for running with an Oracle 8.1.7 or newer client installation. It has been verified to work with Oracle 10g and 11g. This RPM is built to work with PostgreSQL and MySQL. Oracle should work also, but does not tested (not in Fedora). Fedora Account System Username: hubbitus
General: 1. The help files should not go into %{_libdir}. 2. The Summary and %description focuses very much on Oracle, while the appropriate BuildRequires are commented out. The resulting binary and the summary/description should match. 3. I would recommend maintaining the .desktop file as a separate source file. Running rpmlint -i on the resulting .rpm: 1. There is an incorrect free software foundation address in the README file. Upstream should be informed. http://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address 2. There are only non binary files in /usr/lib so they should be in /usr/share (see helpfile comment above) 3. /usr/share/doc/tora-3/NEWS: The character encoding of this file is not UTF-8. Consider converting it in the specfile's %prep section for example using iconv(1). 4. Binary tora: Each executable in standard binary directories should have a man page. Running rpmlint -i on the .src.rpm: 1. There are some bogus dates in the changelog. Disclaimer: I'm not an approved fedora packager, so this review is probably not perfect at all.
Matthias, thank you for the comments. Upstream informed about incorrect FSF address - https://sourceforge.net/p/tora/bugs/872/ Unfortunately I nothing can do with absent manual if it is not present by upstream author. Other issues addressed. Changes: https://github.com/Hubbitus/Fedora-packaging/commit/15a46bad57d6d97dbfa1171d3373d15fc39ceb42 Spec:https://raw.github.com/Hubbitus/Fedora-packaging/15a46bad57d6d97dbfa1171d3373d15fc39ceb42/SPECS/tora.spec Srpm: http://hubbitus.info/rpm/Fedora19/tora/tora-3-0.2.svn4651.fc19.src.rpm
- %global everywhere, no %define - URL SHOULD BE http://torasql.com/ - No need to specify BuildRequires: qt-devel >= 4.3.0, as 4.3.0 is really ancient. - Remove "TOra - Toolkit for Oracle" in %description. - Your version is still older than listed: http://sourceforge.net/projects/tora/files/tora-experimental/ - install --mode=644 is not enough, use install -pm644. - I tried to build oracle related stuffs in the past but actually I need some closed source packages. And I can see #- BuildRequires: oracle-instantclient-devel = %%{oraclever} #- BuildRequires: oracle-instantclient-sqlplus = %%{oraclever} in your spec, any explanation?
Hi Christopher. Thank you, I have address most mentioned issues. (In reply to Christopher Meng from comment #3) > - I tried to build oracle related stuffs in the past but actually I need > some closed source packages. And I can see > > #- BuildRequires: oracle-instantclient-devel = %%{oraclever} > #- BuildRequires: oracle-instantclient-sqlplus = %%{oraclever} > in your spec, any explanation? Yes, to use it with oracle you need Oracle proprietary libraries. We have no such libs in Fedora. And I even did not tried do that as my searches was to Postgres GUI (it is because I package also pgmodeler). It come from Remi Collet rpm and you may uncomment it when try build with Oracle support. At least who will try do that can read it in spec comments. I have add it. Unfortunately I found several bundled libraries which is stop issue. https://sourceforge.net/p/tora/bugs/873/ I'll post files later, when can resolve bundles issue. Without it it useless.
Just out of curiosity, what's wrong with our license? Its GPL ver. 2 with link time exception for commercial version of QT. The same one was used by KDE for many years. Since QT is LGPL now I will remove this one - it does not make any sense anymore. The newest version must be compiled with Oracle client headers and libs. These libs do NOT have to be shipped with the application. Also the main application does not depend on Oracle client libs, all the Oracle dependent code is put into separate plugin - this one still must have link time an exception for Oracle client libs. Or I can re-license the plugin under BSD license if anybody outraged.
(In reply to ibre5041 from comment #5) > Just out of curiosity, what's wrong with our license? Its GPL ver. 2 with > link time exception for commercial version of QT. The same one was used by > KDE for many years. Since QT is LGPL now I will remove this one - it does > not make any sense anymore. > > The newest version must be compiled with Oracle client headers and libs. > These libs do NOT have to be shipped with the application. Also the main > application does not depend on Oracle client libs, all the Oracle dependent > code is put into separate plugin - this one still must have link time an > exception for Oracle client libs. > > Or I can re-license the plugin under BSD license if anybody outraged. Oh I have it. They moved - physically. Fixed in upstream.
I'd like to see the new SPEC & SRPM based on previous comments and improvements. BTW the URL has changed to torasql.com Add missing hicolor-icon-theme dep. Move %files after %post* but before %changelog. Then I will start the final review.
Thank you Christopher. But unfortunately we can't continue until bundled libs issue will be lifted.
The issue with bundled libs can not be resolved by Tora development team either. The version of the ANTLR3 parser runtime you use (3.2) is buggy and causes segfaults. Moreover is has different API. Our code requires API ver. 3.5 and also needs the latest SEGFAULT fixes from the ANTLR3 git trunk. We can use external libs: loki and qscitilla. But we still need our internal (bundled) libs: - antlr3c (our is stable and has the right API version) - antlr3cpp (this one was not packaged yet) - trotl (our internal lib not used anywhere else) - libermodel (our internal lib not used anywhere else) Ivan
I looks like it started moving forward. We depend on the bug 1026440. Thx Pavel
Hello, Ivan. Off course your libs which is part of project itself may be stay there. And I also hope we could make step forward if linked antlr3cpp will be updated.
At this moment it's OK. All mine patches(pull requests) for antlr3cpp are applied in trunk. But in the future I'm going to work on this project too and would like to use mine changes also in Tora project.
Great news! Is it meant you are became on of co-author of antlr3cpp and there no more needs to have separate copy in tora project?
I have "bad" news. I found some memory leak in antlr3cpp and did fix it. At this moment mine patch waits in github's pull request queue. But I do not want to use un-patched version of antlr3cpp in Tora.
Bad news better than nothing. Could you please provide link on pull-request to track it?
Here is it: https://github.com/antlr/antlr3/pull/145
Christopher, ping.
Reviewer did not answer in months. Clear assignment.
This is an automatic check from review-stats script. This review request ticket hasn't been updated for some time. We're sorry it is taking so long. If you're still interested in packaging this software into Fedora repositories, please respond to this comment clearing the NEEDINFO flag. You may want to update the specfile and the src.rpm to the latest version available and to propose a review swap on Fedora devel mailing list to increase chances to have your package reviewed. If this is your first package and you need a sponsor, you may want to post some informal reviews. Read more at https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group. Without any reply, this request will shortly be considered abandoned and will be closed. Thank you for your patience.
This is an automatic action taken by review-stats script. The ticket submitter failed to clear the NEEDINFO flag in a month. As per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews we consider this ticket as DEADREVIEW and proceed to close it.