-- Check for working CXX compiler: /usr/bin/x86_64-pc-linux-gnu-g++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found Git: /usr/bin/git (found version "2.35.1") CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message): Could NOT find Boost (missing: Boost_INCLUDE_DIR system) (Required is at least version "1.48.0") ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_desktop-j4-20220322-112729 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-11.2.1 * clang/llvm (if any): clang version 14.0.0 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/14/bin /usr/lib/llvm/14 14.0.0 Python 3.9.11 Available Ruby profiles: [1] ruby26 (with Rubygems) [2] ruby27 (with Rubygems) [3] ruby31 (with Rubygems) * Available Rust versions: [1] rust-1.59.0 * The following VMs are available for generation-2: *) Eclipse Temurin JDK 11.0.14_p9 [openjdk-bin-11] 2) Eclipse Temurin JDK 8.322_p06 [openjdk-bin-8] Available Java Virtual Machines: [1] openjdk-bin-8 [2] openjdk-bin-11 system-vm The Glorious Glasgow Haskell Compilation System, version 8.10.4 php cli: HEAD of ::gentoo commit 82a46931424ab872e5b04b0dde785024eb8ddee9 Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Wed Mar 23 21:34:22 2022 +0000 2022-03-23 21:34:20 UTC emerge -qpvO dev-db/tora [ebuild N ] dev-db/tora-3.2-r1 USE="postgres -doc -mysql -oracle"
Created attachment 767698 [details] emerge-info.txt
Created attachment 767699 [details] CMakeOutput.log
Created attachment 767700 [details] dev-db:tora-3.2-r1:20220323-234010.log
Created attachment 767701 [details] emerge-history.txt
Created attachment 767702 [details] environment
Created attachment 767703 [details] etc.portage.tar.bz2
Created attachment 767704 [details] logs.tar.bz2
Created attachment 767705 [details] temp.tar.bz2
I've made a check on one my temporarily freezed system with previous (EAPI-6) version of ebuild. It builds tora without errors. This bug follows «[Bug 834311] New: dev-db/tora-3.2-r1: port away from cmake-utils.eclass, EAPI-8 bump» And almost in the same time I've make a check with another custom cmake build in local overlay: updating EAPI from 5 to 7 changes operation of cmake-utils functions (EAPI-5 links corerctly, EAPI-7 — inproper). So, we have: 1. Changing behaviour in EAPI-8 bundled cmake-functions make incomplete simple update EAPI in ebuild header, requireing some other settings. 2. Possibly, upstream uses an obsolete check. In this case we should provide and test a patch. In package's CMakeLists.txt I see just: FIND_PACKAGE(Boost 1.48.0 REQUIRED system) And have no Ideas about what here may be wrong. 3. The last idea is that something is broken in interoprating between cmake functions and base (EAPI) utils. Do you know any other cmake-build boost-dependent package to make some cross-check? P.S. My packages: $ eix -Ic cmake [I] dev-util/cmake (3.22.2@12.02.2022): Cross platform Make $ eix -Ic boost [I] dev-libs/boost (1.78.0-r2(0/1.78.0)@05.02.2022): Boost Libraries for C++ [I] dev-util/boost-build (1.78.0-r1@05.02.2022): A system for large project software construction, simple to use and powerful
(In reply to Sergey S. Starikoff from comment #9) > I've made a check on one my temporarily freezed system with previous > (EAPI-6) version of ebuild. It builds tora without errors. > This bug follows «[Bug 834311] New: dev-db/tora-3.2-r1: port away from > cmake-utils.eclass, EAPI-8 bump» > And almost in the same time I've make a check with another custom cmake > build in local overlay: updating EAPI from 5 to 7 changes operation of > cmake-utils functions (EAPI-5 links corerctly, EAPI-7 — inproper). > To be clear, I think > So, we have: > 1. Changing behaviour in EAPI-8 bundled cmake-functions make incomplete > simple update EAPI in ebuild header, requireing some other settings. > > 2. Possibly, upstream uses an obsolete check. In this case we should provide > and test a patch. > In package's CMakeLists.txt I see just: > FIND_PACKAGE(Boost 1.48.0 REQUIRED system) > And have no Ideas about what here may be wrong. > > 3. The last idea is that something is broken in interoprating between cmake > functions and base (EAPI) utils. > Do you know any other cmake-build boost-dependent package to make some > cross-check? > > P.S. My packages: > $ eix -Ic cmake > [I] dev-util/cmake (3.22.2@12.02.2022): Cross platform Make > $ eix -Ic boost > [I] dev-libs/boost (1.78.0-r2(0/1.78.0)@05.02.2022): Boost Libraries for C++ > [I] dev-util/boost-build (1.78.0-r1@05.02.2022): A system for large project > software construction, simple to use and powerful (In reply to Sergey S. Starikoff from comment #9) > I've made a check on one my temporarily freezed system with previous > (EAPI-6) version of ebuild. It builds tora without errors. > This bug follows «[Bug 834311] New: dev-db/tora-3.2-r1: port away from > cmake-utils.eclass, EAPI-8 bump» > And almost in the same time I've make a check with another custom cmake > build in local overlay: updating EAPI from 5 to 7 changes operation of > cmake-utils functions (EAPI-5 links corerctly, EAPI-7 — inproper). > > So, we have: > 1. Changing behaviour in EAPI-8 bundled cmake-functions make incomplete > simple update EAPI in ebuild header, requireing some other settings. > The changes needed are summarised in the tracker bug (bug 834110). See also https://archives.gentoo.org/gentoo-dev/message/7fc4a62b72c95f1ac71e01e1aad93659. > 2. Possibly, upstream uses an obsolete check. In this case we should provide > and test a patch. > In package's CMakeLists.txt I see just: > FIND_PACKAGE(Boost 1.48.0 REQUIRED system) > And have no Ideas about what here may be wrong. > > 3. The last idea is that something is broken in interoprating between cmake > functions and base (EAPI) utils. > Do you know any other cmake-build boost-dependent package to make some > cross-check? > You can compare with e.g. net-libs/libtorrent-rasterbar: https://github.com/arvidn/libtorrent/blob/RC_2_0/CMakeLists.txt#L798.
For now I suggest to roll-back bump from Bug 834311 for dev-db/tora-3.2-r1 and add hardmasked dev-db/tora-3.2-r2 with EAPI-8 inmstead.
(In reply to Sergey S. Starikoff from comment #11) > For now I suggest to roll-back bump from Bug 834311 for dev-db/tora-3.2-r1 > and add hardmasked dev-db/tora-3.2-r2 with EAPI-8 inmstead. I'm not sure what you mean. Please see my above comment. This is going to be last rited if not fixed.
(In reply to Sam James from comment #12) > (In reply to Sergey S. Starikoff from comment #11) > > For now I suggest to roll-back bump from Bug 834311 for dev-db/tora-3.2-r1 > > and add hardmasked dev-db/tora-3.2-r2 with EAPI-8 inmstead. > > I'm not sure what you mean. Please see my above comment. This is going to be > last rited if not fixed. ping.
(In reply to Sam James from comment #12) > (In reply to Sergey S. Starikoff from comment #11) > > For now I suggest to roll-back bump from Bug 834311 for dev-db/tora-3.2-r1 > > and add hardmasked dev-db/tora-3.2-r2 with EAPI-8 inmstead. > > I'm not sure what you mean. Please see my above comment. This is going to be > last rited if not fixed. Excuse me for long response. A had not enough time for proper debug. Am I right guessing, that cmake eclass could be used to build cmake packages instead of cmake-urils eclass? If so, for me the primary key is: man 5 cmake.eclass Simple update EAPI is unsufficent and looks wrong. For now I plan to try to switch ebuild from cmake-utils eclass to cmake eclass with EAPI=8. In up to week.
Created attachment 776108 [details] tora-3.2-r2.ebuild Re-reading up to date version of man 5 cmake-utils.eclass was also needed. Properly updated to EAPI=8 ebuild - tora-3.2-r2.ebuild Patch: # diff -Naur /usr/portage/gentoo/dev-db/tora/tora-3.2-r1.ebuild tora-3.2-r2.ebuild --- /usr/portage/gentoo/dev-db/tora/tora-3.2-r1.ebuild 2021-04-23 10:09:19.000000000 +0300 +++ tora-3.2-r2.ebuild 2022-05-02 20:24:15.790289981 +0300 @@ -1,9 +1,9 @@ # Copyright 1999-2021 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 -EAPI=6 +EAPI=8 -inherit cmake-utils desktop xdg-utils +inherit cmake desktop xdg-utils if [[ ${PV} == 9999 ]]; then EGIT_REPO_URI="https://github.com/tora-tool/tora" @@ -45,7 +45,7 @@ ) src_prepare() { - cmake-utils_src_prepare + cmake_src_prepare # fixed in master, only care about recent qscintilla lib name: sed -e "/FIND_LIBRARY(QSCINTILLA_LIBRARY/s/qt5scintilla2/qscintilla2_qt5/" \ @@ -75,11 +75,11 @@ -DUSE_PCH=OFF -DENABLE_PGSQL=$(usex postgres) ) - cmake-utils_src_configure + cmake_src_configure } src_install() { - cmake-utils_src_install + cmake_src_install doicon src/icons/${PN}.xpm || die domenu src/${PN}.desktop || die
^ Hey, your ebuild still has $(cmake-utils_use_find_package doc Doxygen) so I doubt it'd work. Then you call $(tc-getPKG_CONFIG) twice without inheriting toolchain-funcs.eclass. And remember to updated the copyright year to 2022 too! Could you make a Github pull request with an updated ebuild? Bugzilla is fine too, but Github PR is much easier for us to handle. Let us know if you find this difficult.
Created attachment 779687 [details] tora-3.2-r2.ebuild (reviewed) (In reply to Joonas Niilola from comment #16) > your ebuild still has > $(cmake-utils_use_find_package doc Doxygen) > so I doubt it'd work. Thank you for review. I've missed it. Fixed. > Then you call > $(tc-getPKG_CONFIG) > twice without inheriting toolchain-funcs.eclass. But ebuild builds successfully without it. Probably it was included recursively. Added directly. > Could you make a Github pull request with an updated ebuild? Bugzilla is > fine too, but Github PR is much easier for us to handle. Let us know if you > find this difficult. I don't like default idea to make a local copy of complete tree to make pull request for single package. Or not enough familiar with git to find how to do it. So, see attached ebuild.
Proxy maintainership, even if not using GitHub, still involves using git really...
(In reply to Sam James from comment #18) > Proxy maintainership, even if not using GitHub, still involves using git > really... My question is not about using git, but about how to create gentoo overlay pull request for package without GitHub account and cloning complete portage tree.
If you sync your repo-tree you could make the ebuild there and provide us with a git-format patch. But again, only if you want to. And if you do, you'll have to remove it before emerge --sync'ng to prevent collisions. Testing the latest ebuild, I get: [ERROR] >>> Not all runs were successful. atom: =dev-db/tora-3.2-r2, USE flags: 'doc -mysql oracle -postgres' atom: =dev-db/tora-3.2-r2, USE flags: '-doc -mysql oracle -postgres' atom: =dev-db/tora-3.2-r2, USE flags: '-doc mysql oracle -postgres' atom: =dev-db/tora-3.2-r2, USE flags: 'doc -mysql oracle postgres' atom: =dev-db/tora-3.2-r2, USE flags: '-doc -mysql oracle postgres' atom: =dev-db/tora-3.2-r2, USE flags: '-doc mysql oracle postgres' atom: =dev-db/tora-3.2-r2, USE flags: 'doc mysql oracle postgres' atom: =dev-db/tora-3.2-r2, USE flags: 'doc mysql oracle -postgres' And as you can clearly see, the 'oracle' USE flag is causing build errors. Can you try? /var/tmp/portage/dev-db/tora-3.2-r2/work/tora-3.2/src/main/tooraclesetting.cpp: In constructor 'toOracleSetting::toOracleSetting(QWidget*)': /var/tmp/portage/dev-db/tora-3.2-r2/work/tora-3.2/src/main/tooraclesetting.cpp:59:38: error: expected type-specifier before 'QIntValidator' 59 | MaxLongInt->setValidator(new QIntValidator(MaxLongInt)); | ^~~~~~~~~~~~~ In file included from /var/tmp/portage/dev-db/tora-3.2-r2/work/tora-3.2/src/core/toconfenum.h:39, from /var/tmp/portage/dev-db/tora-3.2-r2/work/tora-3.2/src/connection/tooracleconfiguration.h:38, from /var/tmp/portage/dev-db/tora-3.2-r2/work/tora-3.2/src/main/tooraclesetting.h:40, from /var/tmp/portage/dev-db/tora-3.2-r2/work/tora-3.2/src/main/tooraclesetting.cpp:35: (also during my first test run I noticed you'll have to depend on dev-libs/boost)
(In reply to Joonas Niilola from comment #20) > If you sync your repo-tree you could make the ebuild there and provide us > with a git-format patch. But again, only if you want to. And if you do, > you'll have to remove it before emerge --sync'ng to prevent collisions. Not only. Together with adding ebuild a need to update Manifest. And, probably, drop present obsolete ebuild. BTW, similiar issue («Could NOT find Boost» with clang system compiler) was reported in #735686. Could you also make a base check for it, because I don't like idea to swich my system to sys-devel/clang? Splitting different issues in single bug is a bad idea. I can confirm *build* issue with USE «oracle» enabled. This should be different bug. I've made some checks. Fixed version really fails to build with Oravle client I expect newer than 12. But the same ebuild, copied into -9999 with dropping obsolete patches builds file with at least 19 version of Oracle client. We should provide newer snapshot. Maybe, asking upstream about new version.
ping
(In reply to Joonas Niilola from comment #20) > And as you can clearly see, the 'oracle' USE flag is causing build errors. > Can you try? That's bug 674874, already known thus must not delay this bug.
(In reply to Andreas Sturmlechner from comment #22) The subject of this bug (migration ebuild from obsolete and incompatible with EAPI=8 cmake-utils eclass to cmake eclass) is done. Recent version of ebuild should be clean, although some additional check will be pretty. The next part is about pull-request. My git experience doesn't fit creation and reviewing pull-requests branch. I've search in wiki.gentoo.org some kind step-py-step guide about creation pull-request in gentoo-friendly style. But not find. I haven't gihub account and for now don't like idea to provide recent github owner any information about my network activities. And I'm not shure, that pull-request, created outside github user is more useful, than ebuild file. Returning to guide referenced above.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e44d9a1359030d2e2522269ee6177f7c24f79fee commit e44d9a1359030d2e2522269ee6177f7c24f79fee Author: David Seifert <soap@gentoo.org> AuthorDate: 2022-07-02 20:40:39 +0000 Commit: David Seifert <soap@gentoo.org> CommitDate: 2022-07-02 20:40:39 +0000 dev-db/tora: drop proxied maintainer Closes: https://bugs.gentoo.org/835915 Signed-off-by: David Seifert <soap@gentoo.org> dev-db/tora/metadata.xml | 19 ++++++------------- 1 file changed, 6 insertions(+), 13 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=48fc8ba627cda504c6577c3cc3d68916bcdbe06d commit 48fc8ba627cda504c6577c3cc3d68916bcdbe06d Author: David Seifert <soap@gentoo.org> AuthorDate: 2022-07-02 20:40:37 +0000 Commit: David Seifert <soap@gentoo.org> CommitDate: 2022-07-02 20:40:37 +0000 dev-db/tora: update EAPI 6 -> 8 Closes: https://bugs.gentoo.org/835915 Signed-off-by: David Seifert <soap@gentoo.org> .../{tora-3.2-r1.ebuild => tora-3.2-r2.ebuild} | 50 ++++++++++------------ 1 file changed, 22 insertions(+), 28 deletions(-)
(In reply to Sergey S. Starikoff from comment #24) > (In reply to Andreas Sturmlechner from comment #22) > > The subject of this bug (migration ebuild from obsolete and incompatible > with EAPI=8 cmake-utils eclass to cmake eclass) is done. > Recent version of ebuild should be clean, although some additional check > will be pretty. > > The next part is about pull-request. > My git experience doesn't fit creation and reviewing pull-requests branch. > I've search in wiki.gentoo.org some kind step-py-step guide about creation > pull-request in gentoo-friendly style. But not find. > I haven't gihub account and for now don't like idea to provide recent github > owner any information about my network activities. > And I'm not shure, that pull-request, created outside github user is more > useful, than ebuild file. Returning to guide referenced above. Sorry, but I have decided to drop you as the proxy maintainer for this package. We don't have the time to discuss whether you agree with getting a Github account or forking git repos. We also spent way more time on the bug than doing it ourselves. Once you're up to speed with git and want to actually contribute, send in a pull request, until then, we won't entertain anymore debates.
(In reply to David Seifert from comment #26) The «debates» points to simple question, followed developer's note, about recommended HOWTO with description of requested action (proper creation of pull-request). Asked because I've don't find sufficient answer on it. Relying on «everebody knows» usually provides most wonderful surprizes.