FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 10-20-2008, 09:13 AM
Peter Humphrey
 
Default Trying KDE-4

On Monday 20 October 2008 09:46:56 Peter Humphrey wrote:
> On Sunday 19 October 2008 18:52:49 Alan McKinnon wrote:
> > I main underlying reason seems to be that Qt now comes as split-ebuilds
> > and Peter has some monolithic ones installed. It's similar to migrating
> > KDE to split-ebuilds, but on a much smaller scale. Unfortunately
> > there's no easy way to automate this in an ebuild, that would require
> > several new unrelated packages replacing one big one, portage doesn't
> > support that kind of thing. So one has to do it manually, and deal with
> > the resulting recdep-rebuild issues as well ....
>
> Does that mean I have to uninstall PyQt and let KDE-4 pull it back in?

Sorry - I hadn't checked. The only version I have is 3.17.4, so removing it
seems unlikely to help.

--
Rgds
Peter
 
Old 10-20-2008, 12:08 PM
"Daniel Pielmeier"
 
Default Trying KDE-4

Unmerge x11-libs/qt-4.3.3 and try again. If you want to be on the safe
side do a quickpkg =x11-libs/qt-4.3.3 before. The new qt-4.4.x split
ebuilds can not live alongside the non split ebuild.

--
Regards,
Daniel
 
Old 10-21-2008, 09:07 AM
Peter Humphrey
 
Default Trying KDE-4

On Monday 20 October 2008 13:08:30 Daniel Pielmeier wrote:
> Unmerge x11-libs/qt-4.3.3 and try again. If you want to be on the safe
> side do a quickpkg =x11-libs/qt-4.3.3 before. The new qt-4.4.x split
> ebuilds can not live alongside the non split ebuild.

I ran quickpkg and emerge -C on qt-4.3.3, then emerge -upDvN world again.
The block is still there, exactly the same as before.

I've started building a new system from scratch on another disk, and I'm now
about ready to start installing KDE on it. Maybe a clean start is what I
need.

--
Rgds
Peter
 
Old 10-21-2008, 06:46 PM
Daniel Pielmeier
 
Default Trying KDE-4

Peter Humphrey schrieb am 21.10.2008 11:07:
> On Monday 20 October 2008 13:08:30 Daniel Pielmeier wrote:
>> Unmerge x11-libs/qt-4.3.3 and try again. If you want to be on the safe
>> side do a quickpkg =x11-libs/qt-4.3.3 before. The new qt-4.4.x split
>> ebuilds can not live alongside the non split ebuild.
>
> I ran quickpkg and emerge -C on qt-4.3.3, then emerge -upDvN world again.
> The block is still there, exactly the same as before.

Let me quote Alan here:

> I main underlying reason seems to be that Qt now comes as split-ebuilds and
> Peter has some monolithic ones installed. It's similar to migrating KDE to
> split-ebuilds, but on a much smaller scale. Unfortunately there's no easy way
> to automate this in an ebuild, that would require several new unrelated
> packages replacing one big one, portage doesn't support that kind of thing.
> So one has to do it manually, and deal with the resulting recdep-rebuild
> issues as well ....

The problem is that portage is probably not smart enough to do the
upgrade from the non-split to the split ebuilds, so the world update
will always run into this blocker even when qt-4.3.3 is not installed.
Maybe some ebuild depends on >=qt-4.3.3 so it is pulled in and another
one depends on >=qt-4.4.x which also gets pulled in and thus the
blockers. This should be no problem in the normal case as the highest
needed version would be installed. But the new split ebuilds have no
relation to the old monolithic which is probably causing the problems in
this case. The highest available version for monolithic is qt-4.3.3 and
so it is pulled in alongside the new split ebuilds which are also needed
because of a >=4.4.x dependency of other programs.

I remember such problems to when migrating to qt split ebuilds and
simply running emerge world was not enough but I do not remember the
exact procedure which solved this. There were some issues with PyQt4 but
I am not sure if this was related. One thing I would give a try is to
give portage a hand and emerge some of the qt split ebuilds with the
oneshot option. In your case the qt split ebuilds which are blocked:

x11-libs/qt-script-4.4.2, x11-libs/qt-dbus-4.4.2,
x11-libs/qt-qt3support-4.4.2, x11-libs/qt-sql-4.4.2,
x11-libs/qt-gui-4.4.2, x11-libs/qt-svg-4.4.2,
x11-libs/qt-test-4.4.2, x11-libs/qt-core-4.4.2,
x11-libs/qt-webkit-4.4.2, x11-libs/qt-opengl-4.4.2

and then see if portage will be able to continue with the world update.

> I've started building a new system from scratch on another disk, and I'm now
> about ready to start installing KDE on it. Maybe a clean start is what I
> need.
>

I think this could be solved without a reinstall but it is up to you.

Regards,

Daniel
 
Old 10-22-2008, 09:15 AM
Peter Humphrey
 
Default Trying KDE-4

On Tuesday 21 October 2008 19:46:33 Daniel Pielmeier wrote:

> One thing I would give a try is to give portage a hand and emerge some of
> the qt split ebuilds with the oneshot option. In your case the qt split
> ebuilds which are blocked:
>
> x11-libs/qt-script-4.4.2, x11-libs/qt-dbus-4.4.2,
> x11-libs/qt-qt3support-4.4.2, x11-libs/qt-sql-4.4.2,
> x11-libs/qt-gui-4.4.2, x11-libs/qt-svg-4.4.2,
> x11-libs/qt-test-4.4.2, x11-libs/qt-core-4.4.2,
> x11-libs/qt-webkit-4.4.2, x11-libs/qt-opengl-4.4.2
>
> and then see if portage will be able to continue with the world update.

That was a good idea, one that I ought to have thought of but didn't.
Unfortunately, it's made no difference at all. Emerge -upDvN world still
gives the same block:

[blocks B ] x11-libs/qt-core ("x11-libs/qt-core" is blocking
x11-libs/qt-4.3.3)
[blocks B ] <=x11-libs/qt-4.4.0_alpha:4 ("<=x11-libs/qt-4.4.0_alpha:4"
is blocking x11-libs/qt-script-4.4.2, x11-libs/qt-dbus-4.4.2,
x11-libs/qt-qt3support-4.4.2, x11-libs/qt-sql-4.4.2, x11-libs/qt-gui-4.4.2,
x11-libs/qt-svg-4.4.2, x11-libs/qt-test-4.4.2, x11-libs/qt-core-4.4.2,
x11-libs/qt-webkit-4.4.2, x11-libs/qt-opengl-4.4.2)

Total: 160 packages (3 upgrades, 78 new, 65 in new slots, 14 reinstalls),
Size of downloads: 209,150 kB
Conflict: 2 blocks (2 unsatisfied)

To recap, the only version of qt installed is qt-3.3.8-r4, and equery d
=x11-libs/qt-3.3.8-r4 returns 160 packages, all wanting =x11-libs/qt-3*.
Emerge seems to think I have a version4.* of qt installed, but I haven't
apart from the split e-builds I've just installed as above.

$ equery l qt
[ Searching for package 'qt' in all categories among: ]
* installed packages
[I--] [ ] app-emulation/emul-linux-x86-qtlibs-20071210 (0)
[I--] [ ] dev-db/qt-unixODBC-3.3.8 (3)
[I--] [ ] dev-libs/dbus-qt3-old-0.70 (0)
[I--] [ ] sys-apps/qtparted-0.4.5 (0)
[I--] [ ] x11-libs/qt-3.3.8-r4 (3)
[I--] [ ~] x11-libs/qt-core-4.4.2 (4)
[I--] [ ~] x11-libs/qt-dbus-4.4.2 (4)
[I--] [ ~] x11-libs/qt-gui-4.4.2 (4)
[I--] [ ~] x11-libs/qt-opengl-4.4.2 (4)
[I--] [ ~] x11-libs/qt-qt3support-4.4.2 (4)
[I--] [ ~] x11-libs/qt-script-4.4.2 (4)
[I--] [ ~] x11-libs/qt-sql-4.4.2 (4)
[I--] [ ~] x11-libs/qt-svg-4.4.2 (4)
[I--] [ ~] x11-libs/qt-test-4.4.2 (4)
[I--] [ ~] x11-libs/qt-webkit-4.4.2 (4)

I could try removing qt-3.3.8-r4, but first I'd have to back up the whole
system against the probability of being unable to recover from the
resultant smashing of KDE 3.5.

> > I've started building a new system from scratch on another disk, and
> > I'm now about ready to start installing KDE on it. Maybe a clean start
> > is what I need.
>
> I think this could be solved without a reinstall but it is up to you.

Thanks for your help so far; I think though that I'll continue building the
clean system as well in case your optimism proves unfounded. At least with
two systems I can pursue both lines independently.

--
Rgds
Peter
 
Old 10-22-2008, 09:32 AM
Neil Bothwick
 
Default Trying KDE-4

On Wed, 22 Oct 2008 10:15:34 +0100, Peter Humphrey wrote:

> That was a good idea, one that I ought to have thought of but didn't.
> Unfortunately, it's made no difference at all. Emerge -upDvN world
> still gives the same block:
>
> [blocks B ] x11-libs/qt-core ("x11-libs/qt-core" is blocking
> x11-libs/qt-4.3.3)
> [blocks B ] <=x11-libs/qt-4.4.0_alpha:4
> ("<=x11-libs/qt-4.4.0_alpha:4" is blocking x11-libs/qt-script-4.4.2,
> x11-libs/qt-dbus-4.4.2, x11-libs/qt-qt3support-4.4.2,
> x11-libs/qt-sql-4.4.2, x11-libs/qt-gui-4.4.2, x11-libs/qt-svg-4.4.2,
> x11-libs/qt-test-4.4.2, x11-libs/qt-core-4.4.2,
> x11-libs/qt-webkit-4.4.2, x11-libs/qt-opengl-4.4.2)
>
> Total: 160 packages (3 upgrades, 78 new, 65 in new slots, 14
> reinstalls), Size of downloads: 209,150 kB
> Conflict: 2 blocks (2 unsatisfied)
>
> To recap, the only version of qt installed is qt-3.3.8-r4,

Something you are trying to emerge as part of the world update depends on
qt-4.3*, so it is trying to install 4.3 and 4.4, that's the cause of the
block. Blocks aren't always the result of installed packages, only
those that would be installed at the end of the emerge.

> I could try removing qt-3.3.8-r4, but first I'd have to back up the
> whole system against the probability of being unable to recover from
> the resultant smashing of KDE 3.5.

qt3 seems to be unrelated to this, but a full backup is unnecessary.
quickpkg qt3 before unmerging it. If the system goes TU you can emerge -k
it.


--
Neil Bothwick

Nostalgia isn't what it used to be.
 
Old 10-22-2008, 09:46 AM
Alan McKinnon
 
Default Trying KDE-4

On Wednesday 22 October 2008 11:15:34 Peter Humphrey wrote:
> On Tuesday 21 October 2008 19:46:33 Daniel Pielmeier wrote:
> > One thing I would give a try is to give portage a hand and emerge some of
> > the qt split ebuilds with the oneshot option. In your case the qt split
> > ebuilds which are blocked:
> >
> > x11-libs/qt-script-4.4.2, x11-libs/qt-dbus-4.4.2,
> > x11-libs/qt-qt3support-4.4.2, x11-libs/qt-sql-4.4.2,
> > x11-libs/qt-gui-4.4.2, x11-libs/qt-svg-4.4.2,
> > x11-libs/qt-test-4.4.2, x11-libs/qt-core-4.4.2,
> > x11-libs/qt-webkit-4.4.2, x11-libs/qt-opengl-4.4.2
> >
> > and then see if portage will be able to continue with the world update.
>
> That was a good idea, one that I ought to have thought of but didn't.
> Unfortunately, it's made no difference at all. Emerge -upDvN world still
> gives the same block:
>
> [blocks B ] x11-libs/qt-core ("x11-libs/qt-core" is blocking
> x11-libs/qt-4.3.3)
> [blocks B ] <=x11-libs/qt-4.4.0_alpha:4 ("<=x11-libs/qt-4.4.0_alpha:4"
> is blocking x11-libs/qt-script-4.4.2, x11-libs/qt-dbus-4.4.2,
> x11-libs/qt-qt3support-4.4.2, x11-libs/qt-sql-4.4.2, x11-libs/qt-gui-4.4.2,
> x11-libs/qt-svg-4.4.2, x11-libs/qt-test-4.4.2, x11-libs/qt-core-4.4.2,
> x11-libs/qt-webkit-4.4.2, x11-libs/qt-opengl-4.4.2)
>
> Total: 160 packages (3 upgrades, 78 new, 65 in new slots, 14 reinstalls),
> Size of downloads: 209,150 kB
> Conflict: 2 blocks (2 unsatisfied)
>
> To recap, the only version of qt installed is qt-3.3.8-r4, and equery d
> =x11-libs/qt-3.3.8-r4 returns 160 packages, all wanting =x11-libs/qt-3*.
> Emerge seems to think I have a version4.* of qt installed, but I haven't
> apart from the split e-builds I've just installed as above.

No, that is incorrect and your reading of the output is wrong.

Emerge detects blockers by looking at what is currently on the machine or what
it wants to install and seeing if that will block with what is on the machine
or what will be installed.

You do not have to have a package installed to create a block - it can be
caused by something that is due to be emerged (and hence will only be
installed in the future).

Look at the second blocker line. It says:

<=x11-libs/qt-4.4.0_alpha:4

That means:
- a version in SLOT 4
- the version number is less than 4.4.0_alpha is blocking/blocked by qt-4.4.2

You do not have such a package installed. That's cool.

You need to find out why portage thinks it must install such a thing. That's
why I asked you for emerge -t earlier. Find an entry for
<=x11-libs/qt-4.4.0_alpha:4 in that list and look above it to see what pulled
it in. Fix that thing and portage will stop trying to pull in an old version
of qt and your problem will go away.

I earnestly recommend you do not go through a full reinstall. That will teach
you nothing. You need to go through this at least once to learn how to deal
with it, it's a necessary gentoo skill

--
alan dot mckinnon at gmail dot com
 
Old 10-22-2008, 10:00 AM
Alex Schuster
 
Default Trying KDE-4

Neil Bothwick writes:

> On Wed, 22 Oct 2008 10:15:34 +0100, Peter Humphrey wrote:
> > That was a good idea, one that I ought to have thought of but didn't.
> > Unfortunately, it's made no difference at all. Emerge -upDvN world
> > still gives the same block:
[...]
> > To recap, the only version of qt installed is qt-3.3.8-r4,
>
> Something you are trying to emerge as part of the world update depends
> on qt-4.3*, so it is trying to install 4.3 and 4.4, that's the cause of
> the block. Blocks aren't always the result of installed packages, only
> those that would be installed at the end of the emerge.
>
> > I could try removing qt-3.3.8-r4, but first I'd have to back up the
> > whole system against the probability of being unable to recover from
> > the resultant smashing of KDE 3.5.
>
> qt3 seems to be unrelated to this, but a full backup is unnecessary.
> quickpkg qt3 before unmerging it. If the system goes TU you can emerge
> -k it.

I think I have the same conflict. I just solved it by putting this into
package.keywords:
~dev-python/PyQt4-4.4.3
~dev-python/sip-4.7.7

So I upgraded to PyQt4-4.4.3, and this depends on the splitted Qt ebuilds,
while PyQt4 up to version 4.4-r1 wants the old monolithic Qt.

weird ~ # grep x11-libs/qt /usr/portage/dev-python/PyQt4/*.ebuild
/usr/portage/dev-python/PyQt4/PyQt4-4.3.3.ebuild:RDEPEND="=x11-libs/qt-4.3*
/usr/portage/dev-python/PyQt4/PyQt4-4.4-r1.ebuild:RDEPEND="=x11-libs/qt-4*
/usr/portage/dev-python/PyQt4/PyQt4-4.4.2.ebuild:
>=x11-libs/qt-core-4.4.0:4
/usr/portage/dev-python/PyQt4/PyQt4-4.4.3.ebuild:
>=x11-libs/qt-core-4.4.0:4
[...]

Wonko
 
Old 10-22-2008, 11:10 AM
"Daniel Pielmeier"
 
Default Trying KDE-4

2008/10/22 Alex Schuster <wonko@wonkology.org>:
>
> I think I have the same conflict. I just solved it by putting this into
> package.keywords:
> ~dev-python/PyQt4-4.4.3
> ~dev-python/sip-4.7.7
>
> So I upgraded to PyQt4-4.4.3, and this depends on the splitted Qt ebuilds,
> while PyQt4 up to version 4.4-r1 wants the old monolithic Qt.
>
> weird ~ # grep x11-libs/qt /usr/portage/dev-python/PyQt4/*.ebuild
> /usr/portage/dev-python/PyQt4/PyQt4-4.3.3.ebuild:RDEPEND="=x11-libs/qt-4.3*
> /usr/portage/dev-python/PyQt4/PyQt4-4.4-r1.ebuild:RDEPEND="=x11-libs/qt-4*
> /usr/portage/dev-python/PyQt4/PyQt4-4.4.2.ebuild:
>>=x11-libs/qt-core-4.4.0:4
> /usr/portage/dev-python/PyQt4/PyQt4-4.4.3.ebuild:
>>=x11-libs/qt-core-4.4.0:4
> [...]

This is maybe the PyQt issue I did not remember. So I think it is
worth a try. If this is the case portage tries to pull qt-4.4.3
because it is needed by PyQt-4.4 plus the qt split ebuilds which are
needed by some other packages. So putting versions of PyQt and sip in
package.keywords which depemd on qt split ebuilds should solve it. If
I remember right I have this entries in my package.keywords too.
Probably you need oneshot for PyQt and sip too.

--
Regards,
Daniel
 
Old 10-22-2008, 04:42 PM
Peter Humphrey
 
Default Trying KDE-4

On Wednesday 22 October 2008 12:10:15 Daniel Pielmeier wrote:
> 2008/10/22 Alex Schuster <wonko@wonkology.org>:
> > I think I have the same conflict. I just solved it by putting this into
> > package.keywords:
> > ~dev-python/PyQt4-4.4.3
> > ~dev-python/sip-4.7.7
> > [...]
>
> This is maybe the PyQt issue I did not remember. So I think it is
> worth a try. If this is the case portage tries to pull qt-4.4.3
> because it is needed by PyQt-4.4 plus the qt split ebuilds which are
> needed by some other packages. So putting versions of PyQt and sip in
> package.keywords which depemd on qt split ebuilds should solve it. If
> I remember right I have this entries in my package.keywords too.
> Probably you need oneshot for PyQt and sip too.

I've found another way around it on my fresh test system. I had a working
KDE-3.5 system installed on it and upgraded it to version 4, no problem.
Then I tried to install hplip on it and got the same blockers again. By a
process of elimination I found I had to put two entries in package.use:

=dev-python/qscintilla-python-2.1 -qt4
=x11-libs/qscintilla-2.1-r1 -qt4

Then I could install hplip as well.

Now I'm back on the original system, and putting Alex's package.keywords
entries in I find I still have the blockers; his solution isn't working for
me, even after reinstalling PyQt4 and sip. Neither is my own on this
system. But then I'm getting what looks like nonsense from equery, thus:

# equery h qt4
[ Searching for USE flag qt4 in all categories among: ]
* installed packages
[I--] [ ] dev-python/qscintilla-python-2.1 (0)
[I--] [ ] net-print/hplip-2.8.6b (0)
[I--] [ ] x11-libs/qscintilla-2.1-r1 (0)
[I--] [ ] app-text/poppler-bindings-0.8.7 (0)

...but equery u qscintilla and equery u qscintilla-python both return this
line:

- - qt4 : Adds support for the Qt GUI/Application Toolkit version 4.x

So unless I'm misunderstanding the output of equery as well, the qt4 USE
flag both is and is not in use in the two scintilla packages.

After writing the above, I uninstalled hplip and poppler-bindings, then
reinstalled poppler-bindings and ran revdep-rebuild. That hasn't helped
either.

--
Rgds
Peter
 

Thread Tools




All times are GMT. The time now is 12:10 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org