| Summary: | =dev-db/tora-3.2 version bump and update live ebuild | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Sergey S. Starikoff <Ikonta> |
| Component: | Current packages | Assignee: | Sergey S. Starikoff <Ikonta> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | asturm, haubi, mephinet, orodruinlair, proxy-maint |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 541604 | ||
| Bug Blocks: | 634970 | ||
| Attachments: |
tora-9999.ebuild.patch
tora_new_ebuild.patch tora-3.2.ebuild.diff tora-3.2_failed_build.log.xz tora-3.2_graphiz-2.40_build.log.xz pch_build.log.xz |
||
|
Description
Sergey S. Starikoff
2016-03-20 17:12:50 UTC
The patch in tora-9999.ebuild.patch sadly is unusable. This looks like it is intended to update a live ebuild. The diff appears to be made beteen a versione ebuild and the live. It also mixes cvs with git style ebuilds. Please try again. The patch in attachment 428654 [details, diff] works fine - it looks like it was forked from an earlier version of the 9999 ebuild - however as noted it does have some things that need to be addressed. Some of these can be highlighted by `repoman full` within the ebuild directory. The header is incorrect - see ${PORTDIR}/header.txt. Additionally, SRC_URI points to "${PN}-master.tar.gz" - a non-version-pinned archive with no actual URI - when not being called as "9999". This can't be used for versioned ebuilds, both because the version isn't pinned and because there is no URI from which to get the archive initially. Lastly, the dependency on dev-db/postgresql should be slotted, either with a specific version number or using a slot operator[0]. Based on comment 0, I haven't performed any buildtesting using the patched 9999 ebuild. Obviously this is in no rush until bug 541604 is resolved. Thanks! 0: https://devmanual.gentoo.org/general-concepts/dependencies/index.html#slot-dependencies (In reply to Sam Jorna (wraeth) from comment #2) > Additionally, SRC_URI points to "${PN}-master.tar.gz" - a non-version-pinned > archive with no actual URI - when not being called as "9999". This can't be > used for versioned ebuilds, both because the version isn't pinned and > because there is no URI from which to get the archive initially. Historically dev-db/tora uses the same ebuild for snapshot and live version. ${PN}-master.tar.gz is my test distiles snapshot. On the time to update versioned snapshot it will be updated to proper value. > Lastly, the dependency on dev-db/postgresql should be slotted, either with a > specific version number or using a slot operator[0]. dev-db/tora provides poor dev-db/postgresql support, probably without versioning. > Obviously this is in no rush until bug 541604 is resolved. Not exactly so. In bug #541604 we need in (5) slot to build TOra3 with it's default QT5 GUI. But when upstream will return buildability with Qt4, we could and probably should update versioned snapshot, masking qt5 USE as "-qt5". I'll monitor it (dev-db/tora buildability with Qt4 GUI). (In reply to Ian Delaney from comment #1) > The patch in tora-9999.ebuild.patch sadly is unusable. This looks like it > is intended to update a live ebuild. Ebuild was significantly updated and needs some further revision. Next time I'll attach complete ebuild, not patch. About versioning of dev-db/tora see my answer above. (In reply to Sam Jorna (wraeth) from comment #2) > Obviously this is in no rush until bug 541604 is resolved. The alternative to fix of #541604 is override default and use bundled version of x11-libs/qscintilla. But I don't find it good enough. 2016-04-03 upstream released 3.0.0 version. But qt4 build is still (on only in release, but till now, i.e. latest snapshot) broken, see possible blocker https://github.com/tora-tool/tora/issues/42 Correct build of qt5 GUI requires unavailable package (see bug #541604). Yes!!! Today's git snapshot is buildable and looks normally operable. Created attachment 476244 [details, diff]
tora_new_ebuild.patch
proxy-maint, please upload sources snapshot and update ebuilds.
Previous version =dev-db/tora-3.0.0_pre20140929-r2 AFAIR is incompatible with recent packages and should be dropped.
Thanks a lot, Sergey, I really missed tora, and I'm glad it's back! Applying your patch to create tora-9999.ebuild from the old tora-3.0.0_pre20140929-r2.ebuild, and running # ebuild tora-9999.ebuild compile results in: CMake Error at CMakeLists.txt:212 (find_package): By not providing "FindQt5Sql.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "Qt5Sql", but CMake did not find one. and also: CMake Error at cmake/modules/FindQScintilla.cmake:99 (MESSAGE): Cannot find QScintilla2 header So I guess qtsql and qscintilla are not runtime, but build dependencies. Furthermore, qscintilla must be compiled with qt5 -qt4 for the build to succeed. After fixing that, buildind succeeds. Created attachment 499596 [details, diff]
tora-3.2.ebuild.diff
I've switched the ebuild unconditionally to Qt5 and fixed all errors obvious to me. Someone else needs to test though.
Please let's get this to tree or last-rite the package.
(In reply to Andreas Sturmlechner from comment #10) > I've switched the ebuild unconditionally to Qt5 and fixed all errors obvious > to me. Someone else needs to test though. One expected error in your patch: For a time ago optional build with Oracle was broken. I.e. although build system provided feature of build without Oracle's support, build itself failed. Thatis why I've made this dependency hard. Have you tested this bug fixed? The second question is about Oracle compatibility. You've required legacy Oracle 11. For rather long ago TOra had an issues building with Oracle 12 client. But it was fixed. So, we have just a temporary Gentoo packaging… feature, described in bug #589146 (In reply to Sergey S. Starikoff from comment #11) > One expected error in your patch: > For a time ago optional build with Oracle was broken. I.e. although build > system provided feature of build without Oracle's support, build itself > failed. > Thatis why I've made this dependency hard. > Have you tested this bug fixed? I haven't tested at all (and mentioned that). ;) However, tora[oracle] is forced in base/package.use.force so we do not have to remove the flag. No one? (In reply to Andreas Sturmlechner from comment #13) > No one? I can try to perform a test in about next week. To do it, can you fix source snapshot (for example tar.xz) in you devspace? But I can perform a test with Oracle and Postgresql, I'm not Mysql-user, so it will be right to find somebody, who uses it. And the next question is about description both Oracle 11 and Oracle 12 client compatibility. Have you nay ideas? I'm not sure why you need the source snapshot in a devspace, when we can pull the package from upstream. (In reply to Andreas Sturmlechner from comment #15) > I'm not sure why you need the source snapshot in a devspace, when we can > pull the package from upstream. 3.2 Release seens to include some commits, not present in succeed snapshot. For now trying to build 3.2 Release I've got an issue with added feature: * basic ER drawing in Browser (depends on Graphviz) * SQL query joining graph (depends on Graphviz) Adding media-gfx/graphviz (built 2.38.0-r1 version with 'X cairo gtk nls pdf' uses enabled) into dependencies don't fix it. This package also has qt4 use, but has no qt5 use. Probably, it is a reason of failure. Possible workaround is to roll-back on pre ER-enabled commit (i.e. push not 3.2, but pre 3.2 release). (In reply to Sergey S. Starikoff from comment #16) Thanks for trying. > For now trying to build 3.2 Release I've got an issue with added feature: What exactly is your issue? > This package also has qt4 use, but has no qt5 use. > Probably, it is a reason of failure. USE=qt4 just builds a frontend, it will be irrelevant for rdeps. > Possible workaround is to roll-back on pre ER-enabled commit (i.e. push not > 3.2, but pre 3.2 release). Can't it be disabled via cmake build option instead? Created attachment 505052 [details] tora-3.2_failed_build.log.xz (In reply to Andreas Sturmlechner from comment #17) > > For now trying to build 3.2 Release I've got an issue with added feature: > What exactly is your issue? See attached build log file. For my experience it has no clear error. > > Possible workaround is to roll-back on pre ER-enabled commit (i.e. push not > > 3.2, but pre 3.2 release). > Can't it be disabled via cmake build option instead? I've seen CMake* files. There is no option to switch it off. Can you test with graphviz-2.40 and tora-9999 instead? Created attachment 511586 [details] tora-3.2_graphiz-2.40_build.log.xz (In reply to Andreas Sturmlechner from comment #19) > Can you test with graphviz-2.40 and tora-9999 instead? graphviz-2.40 ebuild suggest only qt4 version of gvedit. But TOra requires qt5. Copying it into graphviz-2.40-r1 in local overlay and changing qt4 to qt5 I've got buildable qt5 version. Today's snapshot build failed with similiar error, see attached log file. I suggest for now in Gentoo try pre 3.2 release commits to find newest buildable to update portage version. And ask upstream about 3.2 relese error. Are you suggesting tora upstream is depending on an impossible version of graphviz? No, they surely don't, and it would be the very first graphviz rdep to depend on its Qt gui. As you say it fails to build for you just the same anyway. gvedit is a binary; in your log there is no call to gvedit, and it would be very odd anyway. Please don't build with localised messages, it limits their use for others considerably. (In reply to Sergey S. Starikoff from comment #20) > I suggest for now in Gentoo try pre 3.2 release commits to find newest > buildable to update portage version. > And ask upstream about 3.2 relese error. Yes, you are listed as maintainer. Can you do that, please? Build error suggests missing 'loki/Factory_alt.h', that took me to https://sourceforge.net/p/tora/bugs/894/ Changing to `rm -r extlibs/{loki,qscintilla2}` in line 62 fixes that issue, but unfortunately it later fails with a Qt5 related error (probably because I use 5.9 already). The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6b3b10d5bbaa2fee74692e4483dd6444fbea325a commit 6b3b10d5bbaa2fee74692e4483dd6444fbea325a Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2017-10-21 22:30:02 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2017-12-25 20:58:01 +0000 dev-db/tora: 3.2 version bump Bug: https://bugs.gentoo.org/577850 Package-Manager: Portage-2.3.12, Repoman-2.3.3 dev-db/tora/Manifest | 1 + dev-db/tora/files/tora-3.2-missing-header.patch | 21 +++++ dev-db/tora/tora-3.2.ebuild | 105 ++++++++++++++++++++++++ dev-db/tora/tora-9999.ebuild | 100 ++++++++++++---------- 4 files changed, 183 insertions(+), 44 deletions(-)} One upstream backport later this is now in tree. Builds fine and starts. If anyone is using this, please test so we can get rid of old. Created attachment 511790 [details]
pch_build.log.xz
For me with Qt 5.7.1 TOra generally builds and work.
dev-db/tora -postgres -doc -mysql -pch
build succeed, works.
dev-db/tora postgres -doc -mysql -pch
build succeed, works both with Oracle and Postgresql.
mysql build not tested because I have no database server to test.
dev-db/tora postgres -doc -mysql pch
failes with error:
make[2]: *** [src/CMakeFiles/tora_gch.dir/build.make:61: src/precompiled_linux.h.gch/.c++] Error 1
make[2]: Leaving directory '/var/tmp/portage/dev-db/tora-3.2/work/tora-3.2_build'
make[1]: *** [CMakeFiles/Makefile2:302: src/CMakeFiles/tora_gch.dir/all] Error 2
Complete build log in attach.
I'm not enought familiar with some common features.
If pch is something important, whe can temporarily for tora-3.2 mask it off and work with upstream.
If not, we could drop this use, fixing feature off as it done for some other options.
Thanks for testing, please also try with USE=-oracle. For me it builds and starts fine, so I'm going to un-force the flag. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2591ec4c9f7ad173c32d2bff9c46ddd7eec89203 commit 2591ec4c9f7ad173c32d2bff9c46ddd7eec89203 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2017-12-28 10:03:33 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2017-12-28 10:17:29 +0000 dev-db/tora: Drop old Closes: https://bugs.gentoo.org/577850 Package-Manager: Portage-2.3.19, Repoman-2.3.6 dev-db/tora/Manifest | 1 - dev-db/tora/tora-3.0.0_pre20140929-r2.ebuild | 84 ---------------------------- 2 files changed, 85 deletions(-) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d0324afc9683504c59285d8d835a0c45d56cff29 commit d0324afc9683504c59285d8d835a0c45d56cff29 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2017-12-28 10:13:38 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2017-12-28 10:17:30 +0000 dev-db/tora: Drop USE=pch, it breaks build Bug: https://bugs.gentoo.org/577850 Package-Manager: Portage-2.3.19, Repoman-2.3.6 dev-db/tora/tora-3.2.ebuild | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cf1b98702c1481042fabacd6bb4f57bded94833c commit cf1b98702c1481042fabacd6bb4f57bded94833c Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2017-12-28 10:07:18 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2017-12-28 10:17:30 +0000 profiles: Drop obsolete dev-db/tora[oracle] package.use.force Bug: https://bugs.gentoo.org/577850 profiles/base/package.use.force | 4 ---- 1 file changed, 4 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c46fb8d6fbe8260410bc5ed74394f4664d0d6af6 commit c46fb8d6fbe8260410bc5ed74394f4664d0d6af6 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2017-12-28 10:02:52 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2017-12-28 10:17:29 +0000 profiles: Unmask >=dev-db/tora-3.2 Tested-by: Sergey S. Starikoff <Ikonta@yandex.ru> Bug: https://bugs.gentoo.org/577850 profiles/package.mask | 4 ---- 1 file changed, 4 deletions(-)} (In reply to Andreas Sturmlechner from comment #26) > Thanks for testing, please also try with USE=-oracle. For me it builds and > starts fine, so I'm going to un-force the flag. Thank you! Really, in 3.2 this… feature was fixed. It build without Oracle support, although my test may be not very clear, because I have dev-db/oracle-instantclient-basic installed. For me it also builds, starts and (dev-deb/tora[postgres]) works with database. With only upstream interface issue: simple select on direct connection requires commit or rollback. BTW, dev-db/sqldeveloper has the same issue, but not on direct connection, but when database link is used. But unforsing is not enough. In such case we must verify at least one database back-end is selected. Changing default state of oracle USE to "on". P.S. Please, drop obsolete version dev-db/tora-3.0.0_pre20140929-r2, because it is obsolete (requires Qt4) and should be unbuildable now. P.P.S. In a time I plan to perform a review of ebuild messages. (In reply to Sergey S. Starikoff from comment #28) > But unforsing is not enough. > In such case we must verify at least one database back-end is selected. > Changing default state of oracle USE to "on". Thanks for testing. As it now works without oracle, I would favor a default backend that is not fetch-restricted. postgres? (In reply to Andreas Sturmlechner from comment #29) > Thanks for testing. As it now works without oracle, I would favor a default > backend that is not fetch-restricted. postgres? Because I've don't yet tested tora with mysql, the only tested and not fetch-restricted back-end is postgres. So, it should be default. Turning off forcing Oracle back-end prior to build we must enshure, that user select's at least one database back-end (excuse me, I don't remember a solution of this task). P.S. I'm thinking about some more improvements of ebuild, but they'll be discussed in a separate bug. |
