Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 835915 - dev-db/tora-3.2-r1 - CMake Error at .../FindPackageHandleStandardArgs.cmake:230 (message):
Summary: dev-db/tora-3.2-r1 - CMake Error at .../FindPackageHandleStandardArgs.cmake:2...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Sergey S. Starikoff
URL:
Whiteboard:
Keywords:
Depends on: 834311
Blocks:
  Show dependency tree
 
Reported: 2022-03-24 09:25 UTC by Toralf Förster
Modified: 2022-07-07 14:34 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge-info.txt (emerge-info.txt,16.50 KB, text/plain)
2022-03-24 09:25 UTC, Toralf Förster
Details
CMakeOutput.log (CMakeOutput.log,52.26 KB, text/plain)
2022-03-24 09:25 UTC, Toralf Förster
Details
dev-db:tora-3.2-r1:20220323-234010.log (dev-db:tora-3.2-r1:20220323-234010.log,4.05 KB, text/plain)
2022-03-24 09:25 UTC, Toralf Förster
Details
emerge-history.txt (emerge-history.txt,141.15 KB, text/plain)
2022-03-24 09:25 UTC, Toralf Förster
Details
environment (environment,118.04 KB, text/plain)
2022-03-24 09:25 UTC, Toralf Förster
Details
etc.portage.tar.bz2 (etc.portage.tar.bz2,15.16 KB, application/x-bzip)
2022-03-24 09:25 UTC, Toralf Förster
Details
logs.tar.bz2 (logs.tar.bz2,4.88 KB, application/x-bzip)
2022-03-24 09:25 UTC, Toralf Förster
Details
temp.tar.bz2 (temp.tar.bz2,28.19 KB, application/x-bzip)
2022-03-24 09:25 UTC, Toralf Förster
Details
tora-3.2-r2.ebuild (tora-3.2-r2.ebuild,2.26 KB, text/plain)
2022-05-02 17:40 UTC, Sergey S. Starikoff
Details
tora-3.2-r2.ebuild (reviewed) (tora-3.2-r2.ebuild,2.27 KB, text/plain)
2022-05-21 14:57 UTC, Sergey S. Starikoff
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Toralf Förster gentoo-dev 2022-03-24 09:25:04 UTC
-- 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"
Comment 1 Toralf Förster gentoo-dev 2022-03-24 09:25:05 UTC
Created attachment 767698 [details]
emerge-info.txt
Comment 2 Toralf Förster gentoo-dev 2022-03-24 09:25:07 UTC
Created attachment 767699 [details]
CMakeOutput.log
Comment 3 Toralf Förster gentoo-dev 2022-03-24 09:25:07 UTC
Created attachment 767700 [details]
dev-db:tora-3.2-r1:20220323-234010.log
Comment 4 Toralf Förster gentoo-dev 2022-03-24 09:25:10 UTC
Created attachment 767701 [details]
emerge-history.txt
Comment 5 Toralf Förster gentoo-dev 2022-03-24 09:25:11 UTC
Created attachment 767702 [details]
environment
Comment 6 Toralf Förster gentoo-dev 2022-03-24 09:25:12 UTC
Created attachment 767703 [details]
etc.portage.tar.bz2
Comment 7 Toralf Förster gentoo-dev 2022-03-24 09:25:13 UTC
Created attachment 767704 [details]
logs.tar.bz2
Comment 8 Toralf Förster gentoo-dev 2022-03-24 09:25:14 UTC
Created attachment 767705 [details]
temp.tar.bz2
Comment 9 Sergey S. Starikoff 2022-03-29 08:27:26 UTC
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
Comment 10 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-03-30 03:23:55 UTC
(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.
Comment 11 Sergey S. Starikoff 2022-03-30 13:59:01 UTC
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.
Comment 12 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-04-13 06:02:46 UTC
(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.
Comment 13 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-04-30 01:33:25 UTC
(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.
Comment 14 Sergey S. Starikoff 2022-05-01 17:01:38 UTC
(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.
Comment 15 Sergey S. Starikoff 2022-05-02 17:40:45 UTC
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
Comment 16 Joonas Niilola gentoo-dev 2022-05-17 11:27:18 UTC
^ 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.
Comment 17 Sergey S. Starikoff 2022-05-21 14:57:43 UTC
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.
Comment 18 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-05-21 15:05:27 UTC
Proxy maintainership, even if not using GitHub, still involves using git really...
Comment 19 Sergey S. Starikoff 2022-05-22 18:11:08 UTC
(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.
Comment 20 Joonas Niilola gentoo-dev 2022-05-23 13:51:28 UTC
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)
Comment 21 Sergey S. Starikoff 2022-05-29 18:41:34 UTC
(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.
Comment 22 Andreas Sturmlechner gentoo-dev 2022-06-07 18:41:51 UTC
ping
Comment 23 Andreas Sturmlechner gentoo-dev 2022-06-07 18:43:54 UTC
(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.
Comment 24 Sergey S. Starikoff 2022-06-10 13:10:18 UTC
(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.
Comment 25 Larry the Git Cow gentoo-dev 2022-07-02 20:40:46 UTC
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(-)
Comment 26 David Seifert gentoo-dev 2022-07-02 20:43:44 UTC
(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.
Comment 27 Sergey S. Starikoff 2022-07-07 14:34:41 UTC
(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.