Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
resolving Qt4 slot conflicts: +egl +debug +aqua
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
ExecutorElassus
Veteran
Veteran


Joined: 11 Mar 2004
Posts: 1453
Location: Berlin, Germany

PostPosted: Mon Jan 16, 2017 1:27 pm    Post subject: resolving Qt4 slot conflicts: +egl +debug +aqua Reply with quote

So, background: I am trying to install the git version of frescobaldi, which doesn't (but should!) have a "live" ebuild in portage. This version uses qt5, and depends on python-poppler-qt5 for music display (both frescobaldi and python-poppler-qt5 can be found here).

I'm encountering a number of problems, and I'm hoping one of you can help.

1) compilation of python-poppler-qt5 fails with the following:
Code:
 $ python3 setup.py build
running build
running build_ext
building 'popplerqt5' extension
x86_64-pc-linux-gnu-g++ -pthread -fPIC -I/usr/include/poppler/qt5 -I/usr/include/poppler -I/usr/include/python3.5m -I/usr/include/python3.5m -I/usr/include/qt5 -I/usr/include/qt5/QtCore -I/usr/include/qt5/QtGui -I/usr/include/qt5/QtXml -c build/temp.linux-x86_64-3.5/sippopplerqt5cmodule.cpp -o build/temp.linux-x86_64-3.5/build/temp.linux-x86_64-3.5/sippopplerqt5cmodule.o
In file included from /usr/include/qt5/QtCore/qglobal.h:83:0,
                 from /usr/include/qt5/QtCore/qmetatype.h:44,
                 from /usr/include/qt5/QtCore/QMetaType:1,
                 from build/temp.linux-x86_64-3.5/sipAPIpopplerqt5.h:12,
                 from build/temp.linux-x86_64-3.5/sippopplerqt5cmodule.cpp:7:
/usr/include/qt5/QtCore/qcompilerdetection.h:562:6: error: #error Qt requires a C++11 compiler and yours does not seem to be that.
 #    error Qt requires a C++11 compiler and yours does not seem to be that.

But I'm using gcc-5.4.0, and I understand that gcc has been using C++11 since version 5. Why is compilation failing this check?
(on a related note, sip breaks ABI compatibility with python-poppler-qt4, as per this bug.)

2) So then I read up on C++11, and decide to revdep-rebuild everything that might depend on the old libraries. I do:
Code:
 # revdep-rebuild -p --library 'libstdc++.so.6' -- --exclude gcc


and a couple odd things happen. First, I see this:
Code:
 * Assign files to packages

 !!! Dependant orphaned files: No installed package was found for the following:
   * /usr/lib64/gcc/x86_64-pc-linux-gnu/5.4.0/libubsan.so.0.0.0
   * /usr/lib64/clang/3.9.1/lib/linux/libclang_rt.asan-i386.so
   * /usr/lib64/gcc/x86_64-pc-linux-gnu/5.4.0/libcc1.so.0.0.0
   * /usr/lib64/gcc/x86_64-pc-linux-gnu/5.3.0/libcc1.so.0.0.0
   * /usr/lib64/gcc/x86_64-pc-linux-gnu/5.4.0/32/libasan.so.2.0.0
   * /usr/lib64/gcc/x86_64-pc-linux-gnu/5.4.0/32/libubsan.so.0.0.0
   * /usr/lib64/gcc/x86_64-pc-linux-gnu/5.3.0/libtsan.so.0.0.0
   * /usr/lib64/gcc/x86_64-pc-linux-gnu/5.4.0/libtsan.so.0.0.0
   * /usr/lib64/gcc/x86_64-pc-linux-gnu/5.4.0/liblsan.so.0.0.0
   * /usr/lib64/gcc/x86_64-pc-linux-gnu/5.3.0/32/libasan.so.2.0.0
   * /usr/lib64/gcc/x86_64-pc-linux-gnu/5.3.0/libasan.so.2.0.0
   * /usr/lib64/gcc/x86_64-pc-linux-gnu/5.3.0/32/libubsan.so.0.0.0
   * /usr/lib64/gcc/x86_64-pc-linux-gnu/5.3.0/libubsan.so.0.0.0
   * /usr/lib64/clang/3.9.1/lib/linux/libclang_rt.asan-x86_64.so
   * /usr/lib64/gcc/x86_64-pc-linux-gnu/5.4.0/plugin/libcc1plugin.so.0.0.0
   * /usr/lib64/gcc/x86_64-pc-linux-gnu/5.4.0/libasan.so.2.0.0
   * /usr/lib64/gcc/x86_64-pc-linux-gnu/5.3.0/plugin/libcc1plugin.so.0.0.0
   * /usr/lib64/gcc/x86_64-pc-linux-gnu/5.3.0/liblsan.so.0.0.0
   * Warning: "kde-apps/svgpart-16.04.2" ebuild not found..
   !! Could not find ebuild for kde-apps/svgpart:4/16.04
   * Warning: "kde-apps/ark-4.14.3-r1" ebuild not found..
   !! Could not find ebuild for kde-apps/ark:4/4.14
   !! Could not find ebuild for kde-apps/ark
   Installed package: kde-apps/ark is no longer available
   * Warning: "kde-apps/keditbookmarks-16.08.2" ebuild not found..
   * Warning: "kde-frameworks/networkmanager-qt-5.25.0" ebuild not found..
   !! Could not find ebuild for kde-frameworks/networkmanager-qt:5/5.25
   * Warning: "kde-apps/kfmclient-16.04.2" ebuild not found..
   !! Could not find ebuild for kde-apps/kfmclient:4/16.04
   * Warning: "net-misc/vidalia-0.3.1" ebuild not found..
   !! Could not find ebuild for net-misc/vidalia:0
   !! Could not find ebuild for net-misc/vidalia
   Installed package: net-misc/vidalia is no longer available
   * Warning: "kde-apps/kdebase-kioslaves-16.04.3-r1" ebuild not found..

So, I have a bunch of files that are out of the portage tree. How do I resolve these? Should I care?

3) Lastly, there's this block at the bottom of the list:

Code:
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

dev-qt/qtgui:4

  (dev-qt/qtgui-4.8.7:4/4::gentoo, ebuild scheduled for merge) pulled in by
    dev-qt/qtgui:4 (Argument)

  (dev-qt/qtgui-4.8.7:4/4::gentoo, installed) pulled in by
    ~dev-qt/qtgui-4.8.7[aqua=,debug=,egl=,qt3support=,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,
abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] required by (dev-qt/qtopengl-4.8.7:4/4::gentoo, ebuild scheduled for merge)
                                     ^^^^                                                                                                                                                                                                                                                                                           


It might be possible to solve this slot collision
by applying all of the following changes:
   - dev-qt/qtsvg-4.8.7 (Change USE: +debug +aqua)
   - dev-qt/qtcore-4.8.7-r2 (Change USE: +debug +aqua)
   - dev-qt/qtwebkit-4.8.7 (Change USE: +debug +aqua)
   - dev-qt/qtdeclarative-4.8.7 (Change USE: +debug +aqua)
   - dev-qt/qtopengl-4.8.7 (Change USE: +debug +egl +aqua)
   - dev-qt/designer-4.8.7 (Change USE: +debug +aqua)
   - dev-qt/qt3support-4.8.7 (Change USE: +debug +aqua)
   - dev-qt/qtgui-4.8.7 (Change USE: +debug +aqua)
   - dev-qt/qtmultimedia-4.8.7 (Change USE: +debug +aqua)


What is this? Why do I need to add debug, aqua, and egl support to all these packages? Why does qtopengl:4 require it? Is there a way I could get rid of all these old qt4 packages?

Thanks for the help,

EE
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 9315

PostPosted: Mon Jan 16, 2017 2:22 pm    Post subject: Reply with quote

When did you last run --depclean?

Switching to GCC-5 on a system that bad in shape is a very bad idea.
Back to top
View user's profile Send private message
ExecutorElassus
Veteran
Veteran


Joined: 11 Mar 2004
Posts: 1453
Location: Berlin, Germany

PostPosted: Mon Jan 16, 2017 2:25 pm    Post subject: Reply with quote

last depclean run was about a year ago, maybe more.

Should I go through and clear out old packages first?

Cheers,

EE
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 9315

PostPosted: Mon Jan 16, 2017 3:02 pm    Post subject: Reply with quote

Yes. Make sure emerge --depclean -p is clean (and does not remove packages you want), check that eclean -d distfiles does not report any unavailable installed versions, check that emerge -uvpDN world does not come up with new dependencies or conflicts. Then make the GCC switch and rebuild. Basically that's what you do before any scary update.
Back to top
View user's profile Send private message
ExecutorElassus
Veteran
Veteran


Joined: 11 Mar 2004
Posts: 1453
Location: Berlin, Germany

PostPosted: Mon Jan 16, 2017 3:17 pm    Post subject: Reply with quote

alright, I'll proceed. But what exactly do you mean by "make the GCC switch"? gcc-config has been reporting the 5.* compiler as default for over a year now. What remains to be "switched"?

Cheers,

EE
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 9315

PostPosted: Mon Jan 16, 2017 4:04 pm    Post subject: Re: resolving Qt4 slot conflicts: +egl +debug +aqua Reply with quote

ExecutorElassus wrote:
2) So then I read up on C++11, and decide to revdep-rebuild everything that might depend on the old libraries. I do:
Code:
 # revdep-rebuild -p --library 'libstdc++.so.6' -- --exclude gcc

Because you talk about it as if you have never done it?
Back to top
View user's profile Send private message
ExecutorElassus
Veteran
Veteran


Joined: 11 Mar 2004
Posts: 1453
Location: Berlin, Germany

PostPosted: Mon Jan 16, 2017 6:51 pm    Post subject: Reply with quote

I ran that command against libstdc++.so.5 back when the switch to gcc-5* first happened, but not since.

Anyway, now I've gone back and manually decleaned a bunch of packages (depclean, for some reason, misses a lot of dependencies that equery is able to find). However, running revdep-rebuild still results in the slot conflict with qtgui, namely:

Code:
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

dev-qt/qtgui:4

  (dev-qt/qtgui-4.8.7:4/4::gentoo, ebuild scheduled for merge) pulled in by
    dev-qt/qtgui:4 (Argument)

  (dev-qt/qtgui-4.8.7:4/4::gentoo, installed) pulled in by
    ~dev-qt/qtgui-4.8.7[aqua=,debug=,egl=,qt3support=,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,
abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] required by (dev-qt/qtopengl-4.8.7:4/4::gentoo, ebuild scheduled for merge)
                                     ^^^^                                                                                                                                                                                                                                                                                           


It might be possible to solve this slot collision
by applying all of the following changes:
   - dev-qt/qtsvg-4.8.7 (Change USE: +aqua +debug)
   - dev-qt/qtwebkit-4.8.7 (Change USE: +aqua +debug)
   - dev-qt/qtmultimedia-4.8.7 (Change USE: +aqua +debug)
   - dev-qt/qtopengl-4.8.7 (Change USE: +aqua +egl +debug)
   - dev-qt/qtcore-4.8.7-r2 (Change USE: +aqua +debug)
   - dev-qt/qtgui-4.8.7 (Change USE: +aqua +debug)
   - dev-qt/qt3support-4.8.7 (Change USE: +aqua +debug)
   - dev-qt/designer-4.8.7 (Change USE: +aqua +debug)
   - dev-qt/qtdeclarative-4.8.7 (Change USE: +aqua +debug)

And again I am uncertain as to why I should have to add all those USE flags to all those packages. It seems as if qtopengl is forcing a USE flag onto qtgui, and all the other packages have to match it as well. This seems excessive; is there a way around this? Can I explicitly disable egl support (or rather, more pointedly: avoid having to install debug and aqua) for all those packages?

Cheers,

EE

UPDATE: I added debug and aqua to all those packages in my package.use, and now I get errors like this:

Code:
dev-qt/qt3support:4

  (dev-qt/qt3support-4.8.7:4/4::gentoo, ebuild scheduled for merge) pulled in by
    ~dev-qt/qt3support-4.8.7[aqua=,debug=,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,
abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] required by (dev-qt/qtgui-4.8.7:4/4::gentoo, ebuild scheduled for merge)
                                   ^^^^^^                                                                                                                                                                                                                                                                             
    dev-qt/qt3support:4 (Argument)

  (dev-qt/qt3support-4.8.7:4/4::gentoo, installed) pulled in by
    ~dev-qt/qt3support-4.8.7[accessibility=,aqua=,debug=,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,
abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] required by (dev-qt/qtdeclarative-4.8.7:4/4::gentoo, installed)
                                                  ^^^^^^                                                                                                                                                                                                                                                                   
    ~dev-qt/qt3support-4.8.7[aqua=,debug=,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,
abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] required by (dev-qt/qtgui-4.8.7:4/4::gentoo, installed)
                                   ^^^^^^                               

What is the error here? I can't see how the first one is different from the second, or how I would fix it. The command I used was:
Code:
USE="aqua debug" emerge -1 --backtrack=100 dev-qt/qtsql:4 dev-qt/qt3support:4 dev-qt/qtscript:4 dev-qt/qtcore:4 dev-qt/qtgui:4

and I got similar errors for every package.

Can you explain what I'm doing wrong here?
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 9315

PostPosted: Mon Jan 16, 2017 8:04 pm    Post subject: Reply with quote

ExecutorElassus wrote:
I ran that command against libstdc++.so.5 back when the switch to gcc-5* first happened, but not since.

Then that's good, it just wasn't clear from the beginning.

ExecutorElassus wrote:
(depclean, for some reason, misses a lot of dependencies that equery is able to find).

Then your world file is polluted with those packages.

ExecutorElassus wrote:
However, running revdep-rebuild still results in the slot conflict with qtgui, namely:

What do you hope to gain from revdep-rebuild? Nothing in here points to an issue where that obsolete package will help.

ExecutorElassus wrote:
And again I am uncertain as to why I should have to add all those USE flags to all those packages.

Forget about those USE flags, do _not_ add them, instead scan your package.use for bogus entries regarding dev-qt/*.
Back to top
View user's profile Send private message
ct85711
Veteran
Veteran


Joined: 27 Sep 2005
Posts: 1791

PostPosted: Mon Jan 16, 2017 8:16 pm    Post subject: Reply with quote

well first off, generally you should not add the debug USE flag. Beyond that, looking at qtgui ebuild, it does indeed depend on those packages listed above on all of them having the same USE flags. I generally like using the -v to help show all the use flags for the packages.
Back to top
View user's profile Send private message
ExecutorElassus
Veteran
Veteran


Joined: 11 Mar 2004
Posts: 1453
Location: Berlin, Germany

PostPosted: Tue Jan 17, 2017 7:11 am    Post subject: Reply with quote

asturm wrote:


ExecutorElassus wrote:
However, running revdep-rebuild still results in the slot conflict with qtgui, namely:

What do you hope to gain from revdep-rebuild? Nothing in here points to an issue where that obsolete package will help.



Well, here's the root of the problem: I'm trying to compile python-poppler-qt5, which is not in the portage tree but available from github. I run 'python3 setup.py install' in the requisite directory, and I get an error about how the compiler "does not appear to support C++11". Since I've been using gcc-5* for over a year, I'm not sure why I'm getting this error (it might be a bug with the package itself). I was given to understand that one needed to rebuild packages linked against older gcc versions, so that's where revdep-rebuild came in.

Secondly, I have a bunch of qt4 stuff still in the system because I still use a couple older KDE packages (they still have not completely migrated everything, and a lot of the frameworks5 packages don't work outside of the KDE environment, but that's a different discussion). The program I'm ultimately trying to use is frescobaldi, and it still depends on a bunch of obsolete stuff.

Anyway, I'm going through package.use now, trying to resolve some of this. It turns out that ruby is just as fussy about matching USE flags, so I'm having to make sure all of those match as well. It's very tiresome.

Once I clean up package.use, I'll come back and ask for help with my original couple questions (namely, why python-poppler-qt5 doesn't think my gcc supports C++11, why I have a bunch of orphaned files and whether I can safely remove them).

Cheers,

EE
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 9315

PostPosted: Tue Jan 17, 2017 7:20 am    Post subject: Reply with quote

ExecutorElassus wrote:
Anyway, I'm going through package.use now, trying to resolve some of this. It turns out that ruby is just as fussy about matching USE flags, so I'm having to make sure all of those match as well. It's very tiresome.

I'm sure you know `grep`, it will do wonders here. ;)

Concerning the original error, the problem seems to be python-poppler-qt5 itself. It might be solved by running `append-cxxflags -std=c++11` in src_prepare using flag-o-matic.eclass.
Back to top
View user's profile Send private message
ExecutorElassus
Veteran
Veteran


Joined: 11 Mar 2004
Posts: 1453
Location: Berlin, Germany

PostPosted: Tue Jan 17, 2017 10:40 am    Post subject: Reply with quote

I was just using nano, which has its own search function.

As for python-poppler-qt5: can you explain a bit more what you're suggesting I do with src_prepare? I've never used flag-o-matic, and I don't see a file called "src_prepare" in python-poppler-qt5's directories.

Cheers,

EE
Back to top
View user's profile Send private message
mir3x
Guru
Guru


Joined: 02 Jun 2012
Posts: 455

PostPosted: Tue Jan 17, 2017 1:19 pm    Post subject: Reply with quote

>> 1) compilation of python-poppler-qt5 fails with the following:

Qt5.7 requires c++11, gcc6.x automatically uses it.
gcc5.x and 4.x not.
All u need is to pass -std=c++11 to CXXFLAGS
CXXFLAGS=-std=c++11 emerge python-poppler-qt5

( seems its not ebuild so u can try hacking setup.py and add CXXFLAGS there or something like that )

>> 3) just remove all qt4 confilicting packages, they will be pulled back if needed:D ( dont add aqua or debug)
_________________
Sent from Windows
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 9315

PostPosted: Tue Jan 17, 2017 1:39 pm    Post subject: Reply with quote

ExecutorElassus wrote:
As for python-poppler-qt5: can you explain a bit more what you're suggesting I do with src_prepare? I've never used flag-o-matic, and I don't see a file called "src_prepare" in python-poppler-qt5's directories.

https://devmanual.gentoo.org/ebuild-writing/functions/src_prepare/index.html

If you don't see an src_prepare phase in that ebuild, then it's just using the default so far.
Back to top
View user's profile Send private message
ExecutorElassus
Veteran
Veteran


Joined: 11 Mar 2004
Posts: 1453
Location: Berlin, Germany

PostPosted: Tue Jan 17, 2017 1:59 pm    Post subject: Reply with quote

Ah, I see the source of the confusion. I'm not using an ebuild for python-poppler-qt5 (so far as I know, nobody's made one [but they should!]). I am cloning directly from the git repository (here), and then running the setup instructions given in the INSTALL file. This is, then, entirely a python3-run installation, so I'm not sure how to instruct the installer to use gcc with C++11 enabled. Is there a way to do that?

Cheers,

EE
Back to top
View user's profile Send private message
Hu
Administrator
Administrator


Joined: 06 Mar 2007
Posts: 22757

PostPosted: Wed Jan 18, 2017 3:00 am    Post subject: Reply with quote

I suggest that you be the one to make such an ebuild, since you are trying to use a package that would clearly benefit from one. Wrapping it in an ebuild would ensure that each time you start over, you get a clean baseline, free of any interference from failed prior runs. The installer should have selected C++11 mode automatically. Since it does not, and since it claims to require C++11 mode, I would classify that as a bug in upstream's installer. As others in the post said, you could probably fix this by adding -std=c++11 or -std=gnu++11 to the compiler flags. If upstream follows convention, that would be $CXXFLAGS.
Back to top
View user's profile Send private message
ExecutorElassus
Veteran
Veteran


Joined: 11 Mar 2004
Posts: 1453
Location: Berlin, Germany

PostPosted: Wed Jan 18, 2017 9:37 am    Post subject: Reply with quote

well, ok, though I have no experience with writing ebuilds at all. So I just cribbed from a couple others, and here's what I have so far:

This is /usr/local/portage/dev-python/python-poppler-qt5/python-poppler-qt5-9999.ebuild
Code:
# Copyright 1999-2017 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

EAPI=5
PYTHON_COMPAT=( python{2_7,3_5} )

inherit distutils-r1 eutils

DESCRIPTION="A python binding for libpoppler-qt5"
HOMEPAGE="https://github.com/wbsoft/python-poppler-qt5"
EGIT_REPO_URI="https://github.com/wbsoft/python-poppler-qt5"
EGIT_CLONE_TYPE="shallow"

IUSE=""
LICENSE="GPL-2"
SLOT="0"
KEYWORDS="~amd64 ~x86"

RDEPEND="app-text/poppler:=[qt5]
        dev-python/PyQt5[${PYTHON_USEDEP}]
        >=dev-python/python-poppler-0.12.0
        >=dev-python/sip-4.9.1"
DEPEND="${RDEPEND}"

src_prepare() {
        disutils-r1_src_prepare
        export CXXFLAGS="$CXXFLAGS -std=c++11"
}


now, I get the following error:

Code:
>>> Emerging (2 of 2) dev-python/python-poppler-qt5-9999::x-portage
>>> Unpacking source...
>>> Source unpacked in /var/tmp/portage/dev-python/python-poppler-qt5-9999/work
/etc/portage/bashrc: line 3: cd: /var/tmp/portage/dev-python/python-poppler-qt5-9999/work/python-poppler-qt5-9999: No such file or directory
 * ERROR: dev-python/python-poppler-qt5-9999::x-portage failed (prepare phase):
 *   The source directory '/var/tmp/portage/dev-python/python-poppler-qt5-9999/work/python-poppler-qt5-9999' doesn't exist


how do I deal with setting up the working directories? I'm not sure that it actually downloaded anything, or unpacked it anywhere. How do I set up the ebuild to use the git repository, and build using python?

Cheers,

EE
Back to top
View user's profile Send private message
ExecutorElassus
Veteran
Veteran


Joined: 11 Mar 2004
Posts: 1453
Location: Berlin, Germany

PostPosted: Wed Jan 18, 2017 9:50 am    Post subject: Reply with quote

UPDATE: whoops, needed to add 'git-r3' to the inherit line. Now I get a little further. Now I get this:

Code:
# emerge python-poppler-qt5
Calculating dependencies... done!

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) dev-python/python-poppler-qt5-9999::x-portage
>>> Unpacking source...
Initialized empty Git repository in /var/portage/distfiles/git3-src/wbsoft_python-poppler-qt5.git/
 * Fetching https://github.com/wbsoft/python-poppler-qt5 ...
git fetch https://github.com/wbsoft/python-poppler-qt5 +HEAD:refs/git-r3/HEAD --depth 1
remote: Counting objects: 31, done.
remote: Compressing objects: 100% (28/28), done.
remote: Total 31 (delta 0), reused 20 (delta 0), pack-reused 0
Unpacking objects: 100% (31/31), done.
From https://github.com/wbsoft/python-poppler-qt5
 * [new ref]                    -> refs/git-r3/HEAD
git symbolic-ref refs/git-r3/dev-python/python-poppler-qt5/0/__main__ refs/git-r3/HEAD
 * Checking out https://github.com/wbsoft/python-poppler-qt5 to /var/tmp/portage/dev-python/python-poppler-qt5-9999/work/python-poppler-qt5-9999 ...
git checkout --quiet refs/git-r3/HEAD
GIT NEW branch -->
   repository:               https://github.com/wbsoft/python-poppler-qt5
   at the commit:            ca7af7bcb69312c192e59226358e180958208b03
>>> Source unpacked in /var/tmp/portage/dev-python/python-poppler-qt5-9999/work
>>> Preparing source in /var/tmp/portage/dev-python/python-poppler-qt5-9999/work/python-poppler-qt5-9999 ...
/var/tmp/portage/dev-python/python-poppler-qt5-9999/temp/environment: line 4234: disutils-r1_src_prepare: command not found
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/dev-python/python-poppler-qt5-9999/work/python-poppler-qt5-9999 ...
>>> Source configured.
>>> Compiling source in /var/tmp/portage/dev-python/python-poppler-qt5-9999/work/python-poppler-qt5-9999 ...
 * python2_7: running distutils-r1_run_phase distutils-r1_python_compile
/usr/bin/python2.7 setup.py build
running build
running build_ext
building 'popplerqt5' extension
/usr/bin/sip -I /usr/share/sip -t POPPLER_V0_28_0 -c /var/tmp/portage/dev-python/python-poppler-qt5-9999/work/python-poppler-qt5-9999-python2_7/temp.linux-x86_64-2.7 -b /var/tmp/portage/dev-python/python-poppler-qt5-9999/work/python-poppler-qt5-9999-python2_7/temp.linux-x86_64-2.7/poppler-qt5.sbf -I /usr/share/sip/PyQt5 -x VendorID -t WS_X11 -t Qt_5_7_1 -x Py_v3 poppler-qt5.sip
sip: Deprecation warning: poppler-qt5.sip:1: %Module version numbers are deprecated and ignored
[SNIP]
In file included from /var/tmp/portage/dev-python/python-poppler-qt5-9999/work/python-poppler-qt5-9999-python2_7/temp.linux-x86_64-2.7/sippopplerqt5QList0600QLinkedList0100QPointF.cpp:7:0:
types.sip: In function ‘int convertTo_QList_0600QLinkedList_0100QPointF(PyObject*, void**, int*, PyObject*)’:
/var/tmp/portage/dev-python/python-poppler-qt5-9999/work/python-poppler-qt5-9999-python2_7/temp.linux-x86_64-2.7/sipAPIpopplerqt5.h:1761:67: error: ‘sipWrapperType {aka struct _sipWrapperType}’ has no member named ‘type’
 #define sipReleaseInstance(p, wt, s)    sipReleaseType((p), (wt)->type, (s))
                                                                   ^
types.sip:231:7: note: in expansion of macro ‘sipReleaseInstance’
       sipReleaseInstance(t, sipClass_TYPE, state);
       ^
/var/tmp/portage/dev-python/python-poppler-qt5-9999/work/python-poppler-qt5-9999-python2_7/temp.linux-x86_64-2.7/sipAPIpopplerqt5.h:1761:67: error: ‘sipWrapperType {aka struct _sipWrapperType}’ has no member named ‘type’
 #define sipReleaseInstance(p, wt, s)    sipReleaseType((p), (wt)->type, (s))
                                                                   ^
types.sip:236:5: note: in expansion of macro ‘sipReleaseInstance’
     sipReleaseInstance(t, sipClass_TYPE, state);
     ^
error: command 'x86_64-pc-linux-gnu-g++' failed with exit status 1


So, again, is this a problem with upstream? Or did I misconfigure the ebuild?

Cheers,

EE
Back to top
View user's profile Send private message
Hu
Administrator
Administrator


Joined: 06 Mar 2007
Posts: 22757

PostPosted: Thu Jan 19, 2017 2:31 am    Post subject: Reply with quote

Both, I think. You misspelled a command in the ebuild: you wrote disutils, but the proper spelling is distutils. However, I do not think that mistake would cause the upstream build to fail in this way. You probably need help from someone familiar with this package.
Back to top
View user's profile Send private message
ExecutorElassus
Veteran
Veteran


Joined: 11 Mar 2004
Posts: 1453
Location: Berlin, Germany

PostPosted: Fri Jan 27, 2017 2:36 pm    Post subject: Reply with quote

Thank you for the tip. I fixed my ebuild.

However, now it still fails, and so I think it's an issue with upstream. Unfortunately, "upstream" is actually just one guy who also has a day job, so the issue I filed on the github page has thus far gone unanswered.

Would it help if I submitted the ebuild to gentoo's bugzilla, and see if other devs can have a crack at it?

Cheers,

EE
Back to top
View user's profile Send private message
Hu
Administrator
Administrator


Joined: 06 Mar 2007
Posts: 22757

PostPosted: Sat Jan 28, 2017 2:48 am    Post subject: Reply with quote

I think it is fine to ask for help. I am not sure if that is the right way to seek help for this part of Gentoo.
Back to top
View user's profile Send private message
jok
n00b
n00b


Joined: 26 Jan 2008
Posts: 22
Location: Finland

PostPosted: Fri Feb 17, 2017 9:41 pm    Post subject: Reply with quote

ExecutorElassus wrote:
Thank you for the tip. I fixed my ebuild.

However, now it still fails, and so I think it's an issue with upstream. Unfortunately, "upstream" is actually just one guy who also has a day job, so the issue I filed on the github page has thus far gone unanswered.

Would it help if I submitted the ebuild to gentoo's bugzilla, and see if other devs can have a crack at it?

Cheers,

EE

The upstream patch for dev-python/sip-4.19 attached to https://bugs.gentoo.org/show_bug.cgi?id=606704#c8
should get rid of the "error: ‘sipWrapperType {aka struct _sipWrapperType}’ has no member named ‘type’"

I saved it as /etc/portage/patches/dev-python/sip-4.19-r0/sip-wrappedtype-606704.patch, fixed for clean -p1 application
and rebuilding sip with that solved that same error for dev-python/python-poppler-qt4.

(fix: change the first two lines from
Code:

--- sip/sipgen/gencode.c   2017-02-13 11:30:10.747904230 +0100
+++ sip/sipgen/gencode.c.new   2017-02-13 11:31:14.731903986 +0100
to
Code:

--- a/sipgen/gencode.c  2017-02-13 11:30:10.747904230 +0100
+++ b/sipgen/gencode.c  2017-02-13 11:31:14.731903986 +0100
)
Back to top
View user's profile Send private message
ExecutorElassus
Veteran
Veteran


Joined: 11 Mar 2004
Posts: 1453
Location: Berlin, Germany

PostPosted: Fri Feb 17, 2017 11:02 pm    Post subject: Reply with quote

holy crap, that fixed it!

thanks for the help. So now, I have an ebuild that (so far as I can tell) successfully installs python-poppler-qt5, which is something that apparently the Frescobaldi package requires. Would this be something useful to post somewhere?

Cheers,

EE
Back to top
View user's profile Send private message
jok
n00b
n00b


Joined: 26 Jan 2008
Posts: 22
Location: Finland

PostPosted: Fri Feb 17, 2017 11:24 pm    Post subject: Reply with quote

Since you already have a github account, I'd suggest making a pull request (or two (or three)) to get the sip fix, python-poppler-qt5 and frescobaldi-3 in the main tree.
I know I'd be happy to have one less Qt4 anchor installed :wink:
Back to top
View user's profile Send private message
Hu
Administrator
Administrator


Joined: 06 Mar 2007
Posts: 22757

PostPosted: Sat Feb 18, 2017 1:46 am    Post subject: Reply with quote

If you have the time to get it merged, I recommend doing so. Eventually, someone else will want to use this, and it would help them if your fix is already present by default when they arrive.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum