Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Portage becoming more incomprehensible and unmaintainable
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
haarp
Guru
Guru


Joined: 31 Oct 2007
Posts: 535

PostPosted: Mon Oct 28, 2013 12:47 pm    Post subject: Portage becoming more incomprehensible and unmaintainable Reply with quote

Hello,

I've been trying to maintain a system with some additional overlays and a couple of unkeyworded packages, manual useflags, etc. Basically nothing too impressive. But lately, Portage has become really hard to maintain, because the errors are incomprehensible, don't make sense, disappear and reappear on various occasions and are generally a pain. Then there's the fact that calculating dependencies tends to take several minutes, but thats another issue.

Let's have some examples.

1) (This is from memory, can't provide names) I was trying to upgrade some packages to keyworded versions. They depended on a higher version of another package. Let's unkeyword that too. But it didn't want to upgrade that other package with some emerge-typical incomprehensible errors. Eventually I got fed up, and just removed that entire package. Lo and behold, now it offered to emerge the new version I needed, without even complaining once. How does that make sense?


2)
Code:
# emerge -pv talloc

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] sys-libs/talloc-2.0.8  USE="-compat -python*" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB

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

sys-libs/talloc:0

  (sys-libs/talloc-2.0.8::gentoo, installed) pulled in by
    >=sys-libs/talloc-2.0.8[python] required by (sys-libs/tevent-0.9.19::gentoo, installed)

  (sys-libs/talloc-2.0.8::gentoo, ebuild scheduled for merge) pulled in by
    (no parents that aren't satisfied by other packages in this slot)


!!! Enabling --newuse and --update might solve this conflict.
!!! If not, it might help emerge to give a more specific suggestion.

Ok, lots of blah blah. Just say that tevent needs the python useflag on talloc! But let's try what it recommended.

Code:
# emerge -pvNu talloc

These are the packages that would be merged, in order:

Calculating dependencies... done!

Total: 0 packages, Size of downloads: 0 kB

Where'd the error go? Is everything fine suddenly? Well, let's see what happens if we enable the python useflag.
Code:
# USE=python emerge -pv talloc

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] sys-libs/talloc-2.0.8  USE="python -compat" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB

It already IS enabled? Then what is the problem? I can only assume that it wants to disable the useflag for some reason. But none of the errors hint at that, and the emerge with --newuse doesn't either, adding to the confusion.

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

app-emulation/emul-linux-x86-baselibs:0

  (app-emulation/emul-linux-x86-baselibs-20130224::gentoo, installed) pulled in by
    ~app-emulation/emul-linux-x86-baselibs-20130224 required by (app-emulation/emul-linux-x86-qtlibs-20130224::gentoo, installed)
    (and 6 more with the same problem)

  (app-emulation/emul-linux-x86-baselibs-20131008-r3::gentoo, ebuild scheduled for merge) pulled in by
    >=app-emulation/emul-linux-x86-baselibs-20131008[development] required by (app-emulation/wine-1.7.4::gentoo, ebuild scheduled for merge)

What does that even mean? Let's try to decipher emerge-speak.
baselibs-20130224 is installed and pulled in by... itself? No, wait, that in turn is required by qtlibs and 6 more. ok.
baselibs-20131008-r3 is pulled in by... itself with the development useflag? What?? And that is required by Wine, ok.

Now how do I solve this? This isn't much help. I likely have to unkeyword newer qtlibs and "6 other", whatever they may be. But this information is not told anywhere.
On a hunch, I unkeyworded a whole bunch of emul-libs. That now gave me an entire page full of slot conflicts and still wouldn't merge, even with --backtrack=10000. I had to manually unmerge all emul-libs, then suddenly, re-emerging the needed versions was no problem...


4)
Code:
 * Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.

  (media-video/libav-0.8.7::gentoo, installed) pulled in by
    >=media-video/libav-0.8.4[X?,encode?,gsm?,jpeg2k?,mp3?,sdl?,speex?,theora?,threads?,truetype?,vaapi?,vdpau?,x264?] (>=media-video/libav-0.8.4[X,encode,mp3,sdl,threads,truetype,vaapi,vdpau,x264]) required by (virtual/ffmpeg-0.10.3::gentoo, installed)
    media-video/libav required by @selected

  (media-video/vlc-2.1.0::gentoo, ebuild scheduled for merge) pulled in by
    media-video/vlc required by @selected

Attempts at deciphering:
libav-0.8.7 is pulled in by itself and a whole bunch of useflags? With more libav and useflags in brackets? Which is required by the ffmpeg virtual. Oh, and libav is required by @selected, despite not being explicitly selected.
vlc-2.1.0 is pulled in by by @selected. Makes sense, it's what I want to emerge.

So what's the problem here? It doesn't say. I have VLC and libav installed and working. I just want to upgrade VLC to 2.1.0. This is no help.




As can be seen, many of these errors are extremely convoluted, incomprehensible and often give no useful hints on how to solve them. Much patience, time spent deciphering errors, random unkeywording, purging of packages, checking ebuilds to find out what they ACTUALLY depend on, and several minute-long dependency calculations are required to get something keyworded installed these days.

It's getting really bad. And I needed to bring this to attention. Thank you.


Last edited by haarp on Mon Oct 28, 2013 2:18 pm; edited 2 times in total
Back to top
View user's profile Send private message
_______0
Guru
Guru


Joined: 15 Oct 2012
Posts: 521

PostPosted: Mon Oct 28, 2013 1:03 pm    Post subject: Reply with quote

with qt/kde stuff what I do is un-install/re-install the whole stack to overcome those crazy deps.
Back to top
View user's profile Send private message
creaker
l33t
l33t


Joined: 14 Jul 2012
Posts: 651

PostPosted: Mon Oct 28, 2013 1:24 pm    Post subject: Reply with quote

_______0 wrote:
with qt/kde stuff what I do is un-install/re-install the whole stack to overcome those crazy deps.


I do the same for all the packages, no matter are they kde/qt related or no. In general it works. And almost all the collisions may be solved.
But it looks like something wrong in the depths of portage.
Back to top
View user's profile Send private message
wrc1944
Advocate
Advocate


Joined: 15 Aug 2002
Posts: 3432
Location: Gainesville, Florida

PostPosted: Tue Oct 29, 2013 11:49 am    Post subject: Reply with quote

Sometimes (and indeed recently it does seem to be happening more and more) I find the problem is caused by old/obsolete entries somewhere in the /etc/portage files, or a long forgotten world file entry that crept in when I stupidly forgot to use the emerge --oneshot option when I re-emerged a package.

Not to mention that most of my Gentoo installs are ~Arch, and now several years old, so no matter how hard you try to keep it clean and properly maintained, cruft seems to eventually creep in. Especially if portage tells you to manually change USE flags from time-to-time, and then a year or two later something changes and that entry is no longer correct.
_________________
Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.36-r7, gcc-13.2.1_p20230304
kernel-6.7.2 USE=experimental python3_11
Back to top
View user's profile Send private message
haarp
Guru
Guru


Joined: 31 Oct 2007
Posts: 535

PostPosted: Tue Oct 29, 2013 12:11 pm    Post subject: Reply with quote

wrc1944 wrote:
Sometimes (and indeed recently it does seem to be happening more and more) I find the problem is caused by old/obsolete entries somewhere in the /etc/portage files, or a long forgotten world file entry that crept in when I stupidly forgot to use the emerge --oneshot option when I re-emerged a package.

Not to mention that most of my Gentoo installs are ~Arch, and now several years old, so no matter how hard you try to keep it clean and properly maintained, cruft seems to eventually creep in. Especially if portage tells you to manually change USE flags from time-to-time, and then a year or two later something changes and that entry is no longer correct.


portpeek helps a little, but it's also not perfect.


Last edited by haarp on Wed Oct 30, 2013 9:12 am; edited 1 time in total
Back to top
View user's profile Send private message
ArneBab
Guru
Guru


Joined: 24 Jan 2006
Posts: 429
Location: Graben-Neudorf, Germany

PostPosted: Wed Oct 30, 2013 9:11 am    Post subject: Re: Portage becoming more incomprehensible and unmaintainabl Reply with quote

haarp wrote:
As can be seen, many of these errors are extremely convoluted, incomprehensible and often give no useful hints on how to solve them. Much patience, time spent deciphering errors, random unkeywording, purging of packages, checking ebuilds to find out what they ACTUALLY depend on, and several minute-long dependency calculations are required to get something keyworded installed these days.


I have the same problem: I no longer understand the conflict-messages.

Most of these *seem to* have started when I had to replace USE_PYTHON with PYTHON_TARGETS and PYTHON_SINGLE_TARGET for some program. And now I mostly stumble around, wondering how to apply the fix which worked for my system at home with the computer I have here at work…

This used to be just --autounmask-write. Now it’s some conflict I do not understand…
_________________
Being unpolitical means being political without realizing it. - Arne Babenhauserheide ( http://draketo.de )

pkgcore: So fast that it feels unreal - by doing only what is needed.
Back to top
View user's profile Send private message
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Wed Oct 30, 2013 11:54 pm    Post subject: Re: Portage becoming more incomprehensible and unmaintainabl Reply with quote

haarp wrote:
1) (This is from memory, can't provide names) I was trying to upgrade some packages to keyworded versions. They depended on a higher version of another package. Let's unkeyword that too. But it didn't want to upgrade that other package with some emerge-typical incomprehensible errors. Eventually I got fed up, and just removed that entire package. Lo and behold, now it offered to emerge the new version I needed, without even complaining once. How does that make sense?


That is odd, would be nice if this could be reproduced.

haarp wrote:
2)
Code:
!!! Enabling --newuse and --update might solve this conflict.
!!! If not, it might help emerge to give a more specific suggestion.

Ok, lots of blah blah. Just say that tevent needs the python useflag on talloc! But let's try what it recommended.


See the part of the quote of the code that I left behind, did you try that?

haarp wrote:
Code:
# emerge -pvNu talloc

These are the packages that would be merged, in order:

Calculating dependencies... done!

Total: 0 packages, Size of downloads: 0 kB


There is nothing to update and no USE flags have changed; so, it doesn't merge anything.

haarp wrote:
Where'd the error go? Is everything fine suddenly? Well, let's see what happens if we enable the python useflag.
Code:
# USE=python emerge -pv talloc

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] sys-libs/talloc-2.0.8  USE="python -compat" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB

It already IS enabled? Then what is the problem? I can only assume that it wants to disable the useflag for some reason. But none of the errors hint at that, and the emerge with --newuse doesn't either, adding to the confusion.


Yes, it is, your command just wants to rebuild it; besides that, you will not want to pass USE flags on the command line as that will get your system in an inconsistent state.

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

app-emulation/emul-linux-x86-baselibs:0

  (app-emulation/emul-linux-x86-baselibs-20130224::gentoo, installed) pulled in by
    ~app-emulation/emul-linux-x86-baselibs-20130224 required by (app-emulation/emul-linux-x86-qtlibs-20130224::gentoo, installed)
    (and 6 more with the same problem)

  (app-emulation/emul-linux-x86-baselibs-20131008-r3::gentoo, ebuild scheduled for merge) pulled in by
    >=app-emulation/emul-linux-x86-baselibs-20131008[development] required by (app-emulation/wine-1.7.4::gentoo, ebuild scheduled for merge)

What does that even mean? Let's try to decipher emerge-speak.
baselibs-20130224 is installed and pulled in by... itself? No, wait, that in turn is required by qtlibs and 6 more. ok.
baselibs-20131008-r3 is pulled in by... itself with the development useflag? What?? And that is required by Wine, ok.

Now how do I solve this? This isn't much help. I likely have to unkeyword newer qtlibs and "6 other", whatever they may be. But this information is not told anywhere.
On a hunch, I unkeyworded a whole bunch of emul-libs. That now gave me an entire page full of slot conflicts and still wouldn't merge, even with --backtrack=10000. I had to manually unmerge all emul-libs, then suddenly, re-emerging the needed versions was no problem...


Let's be glad this will be replaced by multilib over time; but well, basically since wine is the only one whom needs the old version, you would upgrade wine to a newer version. If that's not possible, you would need to downgrade everything that depends on the new version. The other option is to just wait.

haarp wrote:
4)
Code:
 * Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.

  (media-video/libav-0.8.7::gentoo, installed) pulled in by
    >=media-video/libav-0.8.4[X?,encode?,gsm?,jpeg2k?,mp3?,sdl?,speex?,theora?,threads?,truetype?,vaapi?,vdpau?,x264?] (>=media-video/libav-0.8.4[X,encode,mp3,sdl,threads,truetype,vaapi,vdpau,x264]) required by (virtual/ffmpeg-0.10.3::gentoo, installed)
    media-video/libav required by @selected

  (media-video/vlc-2.1.0::gentoo, ebuild scheduled for merge) pulled in by
    media-video/vlc required by @selected

Attempts at deciphering:
libav-0.8.7 is pulled in by itself and a whole bunch of useflags? With more libav and useflags in brackets? Which is required by the ffmpeg virtual. Oh, and libav is required by @selected, despite not being explicitly selected.
vlc-2.1.0 is pulled in by by @selected. Makes sense, it's what I want to emerge.

So what's the problem here? It doesn't say. I have VLC and libav installed and working. I just want to upgrade VLC to 2.1.0. This is no help.


You have vdpau enabled on vlc, because of that you cannot install <media-video/libav-9.11; now you're going to wonder how I would figure that out given that output, well, I actually can't figure anything from that output but rather remember that I've added that restriction last week to the ebuild as it would otherwise fail to build. This Portage output seems like a bug though, Portage should list the blocker and not the general dependency; because of that, I have filed a bug at https://bugs.gentoo.org/show_bug.cgi?id=489922

haarp wrote:
As can be seen, many of these errors are extremely convoluted, incomprehensible and often give no useful hints on how to solve them. Much patience, time spent deciphering errors, random unkeywording, purging of packages, checking ebuilds to find out what they ACTUALLY depend on, and several minute-long dependency calculations are required to get something keyworded installed these days.

It's getting really bad. And I needed to bring this to attention. Thank you.


Let us know if you have more that you need explained or you consider a bug; because yes, the output can indeed tend to be confusing or not make sense sometimes. Let's try to keep that to a minimum.
Back to top
View user's profile Send private message
haarp
Guru
Guru


Joined: 31 Oct 2007
Posts: 535

PostPosted: Thu Oct 31, 2013 8:00 am    Post subject: Re: Portage becoming more incomprehensible and unmaintainabl Reply with quote

Thanks Tom, but I'm not looking for help on these issues. Rather, I wanted to bring to attention how difficult and useless emerge errors have become, and how complicated solving them is.


TomWij wrote:
haarp wrote:
1) (This is from memory, can't provide names) I was trying to upgrade some packages to keyworded versions. They depended on a higher version of another package. Let's unkeyword that too. But it didn't want to upgrade that other package with some emerge-typical incomprehensible errors. Eventually I got fed up, and just removed that entire package. Lo and behold, now it offered to emerge the new version I needed, without even complaining once. How does that make sense?


That is odd, would be nice if this could be reproduced.

I actually managed to do that with the emul-libs:
Quote:
On a hunch, I unkeyworded a whole bunch of emul-libs. That now gave me an entire page full of slot conflicts and still wouldn't merge, even with --backtrack=10000. I had to manually unmerge all emul-libs, then suddenly, re-emerging the needed versions was no problem...

Basically, unsolvable slot conflicts prevented the merge. I then unmerged all ell emul-libs and re-emerged them, instantly giving me the versions I wanted.


Quote:

haarp wrote:
2)
Code:
!!! Enabling --newuse and --update might solve this conflict.
!!! If not, it might help emerge to give a more specific suggestion.

Ok, lots of blah blah. Just say that tevent needs the python useflag on talloc! But let's try what it recommended.


See the part of the quote of the code that I left behind, did you try that?

I don't get what you're referring to.


Quote:
haarp wrote:
Code:
# emerge -pvNu talloc

These are the packages that would be merged, in order:

Calculating dependencies... done!

Total: 0 packages, Size of downloads: 0 kB


There is nothing to update and no USE flags have changed; so, it doesn't merge anything.

Yep, but why? The previous command wanted to remove the python useflag, why doesn't --newuse? (yes, I tried -pvN without u, same result)
I should probably add that 'emerge -pvDNu world' wanted to remove the python useflag from talloc, but 'emerge -pvNu talloc' didn't. That's the weird inconsistency.


Quote:
you will not want to pass USE flags on the command line as that will get your system in an inconsistent state.

I don't usually do that, it was just to see what would happen. Since Portage these days requires a ton of trial&error, this often comes in handy and is quicker than packages.use.


Quote:
Let's be glad this will be replaced by multilib over time; but well, basically since wine is the only one whom needs the old version, you would upgrade wine to a newer version. If that's not possible, you would need to downgrade everything that depends on the new version. The other option is to just wait.

Nice, but that'll avoid the problem, not make emerge errors more readable or help automatically solve such slot conflicts.


Quote:
You have vdpau enabled on vlc, because of that you cannot install <media-video/libav-9.11; now you're going to wonder how I would figure that out given that output, well, I actually can't figure anything from that output but rather remember that I've added that restriction last week to the ebuild as it would otherwise fail to build. This Portage output seems like a bug though, Portage should list the blocker and not the general dependency; because of that, I have filed a bug at https://bugs.gentoo.org/show_bug.cgi?id=489922

Yep, I managed to figure that out after looking at the ebuild itself. Since libav-9.11 wasn't available, I went with -9.9999. However, VLC failed to build with that, so I went with -9999, which worked.
This is also an example of where unmerging and re-emerging the offending package allowed me to upgrade it, whereas directly upgrading it didn't

On a related note, I'm really starting to hate VLC. Not only is hardware acceleration still broken most of the time (both vaapi and vdpau), vlc is also still not capable of playing HD movies without choppiness, freezes (despite having plenty of spare CPU power), awful seeking, corruption and other annoyances. I'm going to use mplayer2 in the future.
Back to top
View user's profile Send private message
Small_Penguin
Tux's lil' helper
Tux's lil' helper


Joined: 27 May 2005
Posts: 140

PostPosted: Thu Oct 31, 2013 10:12 am    Post subject: Reply with quote

Regarding the confusing dependencies problems, you can often help yourself quickly if you add -O and -1 to the emerge parameters (if you know it is in fact a rather trivial problem and don't want to mess around with many files, use flags and other settings). That will simply merge the package with your desired use flags without further checks, which will often allow you to update the packages depending on it later as well without portage complaining. It's still annoying with --keep-going if a package fails to build and emerge restarts calculating the dependencies, but better than nothing. --depclean does a nice cleanup later.

I agree that emerge world has become slower, but not by much.
Back to top
View user's profile Send private message
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Thu Oct 31, 2013 12:00 pm    Post subject: Re: Portage becoming more incomprehensible and unmaintainabl Reply with quote

haarp wrote:
Thanks Tom, but I'm not looking for help on these issues. Rather, I wanted to bring to attention how difficult and useless emerge errors have become, and how complicated solving them is.


Well, I don't have a problem with that most of the time; but yeah, we should work towards clarifying things more were possible as well as perhaps document some example conflicts to make it more clear they are resolved.

haarp wrote:
I actually managed to do that with the emul-libs:
Quote:
On a hunch, I unkeyworded a whole bunch of emul-libs. That now gave me an entire page full of slot conflicts and still wouldn't merge, even with --backtrack=10000. I had to manually unmerge all emul-libs, then suddenly, re-emerging the needed versions was no problem...

Basically, unsolvable slot conflicts prevented the merge. I then unmerged all ell emul-libs and re-emerged them, instantly giving me the versions I wanted.


Well, mixing stable and unstable is exactly the cause of slot conflicts, it causes you to have to recursively unkeyword more things until you get your system back in a consistent state where everything is back satisfied.

haarp wrote:
Quote:

haarp wrote:
2)
Code:
!!! Enabling --newuse and --update might solve this conflict.
!!! If not, it might help emerge to give a more specific suggestion.

Ok, lots of blah blah. Just say that tevent needs the python useflag on talloc! But let's try what it recommended.


See the part of the quote of the code that I left behind, did you try that?

I don't get what you're referring to.


Those lines that start with !!!.

haarp wrote:
Quote:
haarp wrote:
Code:
# emerge -pvNu talloc

These are the packages that would be merged, in order:

Calculating dependencies... done!

Total: 0 packages, Size of downloads: 0 kB


There is nothing to update and no USE flags have changed; so, it doesn't merge anything.

Yep, but why? The previous command wanted to remove the python useflag, why doesn't --newuse? (yes, I tried -pvN without u, same result)
I should probably add that 'emerge -pvDNu world' wanted to remove the python useflag from talloc, but 'emerge -pvNu talloc' didn't. That's the weird inconsistency.


In your first quote in (2) you have -python* which means you changed from +python to -python which is what the * means (= you have changed it), in the second quote in (2) you have changed it back from -python to +python. So, if you disable it and then enable it without merging it, the status of the package will not change; thus there is nothing to update and no USE flags have changed.

That -D wants to remove python means that some deep dependency (= dependency of dependency of dependency of ...) wants to have that python USE flag on talloc disabled; without -D, it doesn't consider that package as it doesn't check deep dependencies, but with -D it does.

haarp wrote:
Quote:
you will not want to pass USE flags on the command line as that will get your system in an inconsistent state.

I don't usually do that, it was just to see what would happen. Since Portage these days requires a ton of trial&error, this often comes in handy and is quicker than packages.use.


For global flags there is `euse -E ...` and `euse -D ...` from gentoolkit, for local flags (as well as keywording and more) there is https://github.com/radhermit/flaggie which is available as app-portage/flaggie.

haarp wrote:
Quote:
Let's be glad this will be replaced by multilib over time; but well, basically since wine is the only one whom needs the old version, you would upgrade wine to a newer version. If that's not possible, you would need to downgrade everything that depends on the new version. The other option is to just wait.

Nice, but that'll avoid the problem, not make emerge errors more readable or help automatically solve such slot conflicts.


Maybe, maybe not; I'd think the emul-linux packages are one of their kind, though to some point it perhaps still is true. Like with Python targets, see http://bpaste.net/show/145357/

haarp wrote:
Quote:
You have vdpau enabled on vlc, because of that you cannot install <media-video/libav-9.11; now you're going to wonder how I would figure that out given that output, well, I actually can't figure anything from that output but rather remember that I've added that restriction last week to the ebuild as it would otherwise fail to build. This Portage output seems like a bug though, Portage should list the blocker and not the general dependency; because of that, I have filed a bug at https://bugs.gentoo.org/show_bug.cgi?id=489922

Yep, I managed to figure that out after looking at the ebuild itself. Since libav-9.11 wasn't available, I went with -9.9999. However, VLC failed to build with that, so I went with -9999, which worked.
This is also an example of where unmerging and re-emerging the offending package allowed me to upgrade it, whereas directly upgrading it didn't


Yeah, I hope libav gets a new release soon to resolve this.

haarp wrote:
On a related note, I'm really starting to hate VLC. Not only is hardware acceleration still broken most of the time (both vaapi and vdpau), vlc is also still not capable of playing HD movies without choppiness, freezes (despite having plenty of spare CPU power), awful seeking, corruption and other annoyances. I'm going to use mplayer2 in the future.


Which graphics drivers are these? I don't experience this. Did you also try to select some other video output in VLC? I remember having problems with one of them and then switching to the other fixed it. Another option that might help is to increase the cache time to help with seeking; if this is an actual bug that got introduced at a certain version and thus is a regression, feel free to let me know between which versions this was introduced...
Back to top
View user's profile Send private message
haarp
Guru
Guru


Joined: 31 Oct 2007
Posts: 535

PostPosted: Thu Oct 31, 2013 12:23 pm    Post subject: Re: Portage becoming more incomprehensible and unmaintainabl Reply with quote

TomWij wrote:
haarp wrote:
I actually managed to do that with the emul-libs:
Quote:
On a hunch, I unkeyworded a whole bunch of emul-libs. That now gave me an entire page full of slot conflicts and still wouldn't merge, even with --backtrack=10000. I had to manually unmerge all emul-libs, then suddenly, re-emerging the needed versions was no problem...

Basically, unsolvable slot conflicts prevented the merge. I then unmerged all ell emul-libs and re-emerged them, instantly giving me the versions I wanted.


Well, mixing stable and unstable is exactly the cause of slot conflicts, it causes you to have to recursively unkeyword more things until you get your system back in a consistent state where everything is back satisfied.

But that's exactly the point, all emul-libs WERE unkeyworded. Emerge just would've had to upgrade them all, yet it took unmerging all emul-libs temporarily to make it understand that.

Quote:
haarp wrote:
Quote:

haarp wrote:
2)
Code:
!!! Enabling --newuse and --update might solve this conflict.
!!! If not, it might help emerge to give a more specific suggestion.

Ok, lots of blah blah. Just say that tevent needs the python useflag on talloc! But let's try what it recommended.


See the part of the quote of the code that I left behind, did you try that?

I don't get what you're referring to.


Those lines that start with !!!.

That's exactly what I did in the next quote. I just used the short version -Nu instead of --newuse --update.

Quote:
In your first quote in (2) you have -python* which means you changed from +python to -python which is what the * means (= you have changed it)

I haven't. I suspect the ebuild simply changed from IUSE=+python to IUSE=python, because I did not touch that useflag.
Quote:
in the second quote in (2) you have changed it back from -python to +python.

Nope, I didn't. Both were executed in the same environment and no actual merges took place (-p) Do you see why I consider this a weird inconsistency now?
Quote:
That -D wants to remove python means that some deep dependency (= dependency of dependency of dependency of ...) wants to have that python USE flag on talloc disabled; without -D, it doesn't consider that package as it doesn't check deep dependencies, but with -D it does.

That couldn't have been the case. I have manually enabled the python useflag for talloc now, and there are no complaints when I do emerge -DN world. As I said, I suspect the ebuild went from +python to python.

Quote:
haarp wrote:
On a related note, I'm really starting to hate VLC. Not only is hardware acceleration still broken most of the time (both vaapi and vdpau), vlc is also still not capable of playing HD movies without choppiness, freezes (despite having plenty of spare CPU power), awful seeking, corruption and other annoyances. I'm going to use mplayer2 in the future.

Which graphics drivers are these? I don't experience this. Did you also try to select some other video output in VLC? I remember having problems with one of them and then switching to the other fixed it. Another option that might help is to increase the cache time to help with seeking; if this is an actual bug that got introduced at a certain version and thus is a regression, feel free to let me know between which versions this was introduced...

Nvidia 325.15. However, the stuttering, choppiness, freezing, seeking problems, etc also happen with software decoding. It also happens on a friend's PC with the same movie, who uses an older VLC on Mint. So it's definitely a VLC problem, and I'm tired of dealing with it when mplayer works so well.
Back to top
View user's profile Send private message
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Thu Oct 31, 2013 12:34 pm    Post subject: Re: Portage becoming more incomprehensible and unmaintainabl Reply with quote

haarp wrote:
But that's exactly the point, all emul-libs WERE unkeyworded. Emerge just would've had to upgrade them all, yet it took unmerging all emul-libs temporarily to make it understand that.


But their reverse dependencies are not.

haarp wrote:
That's exactly what I did in the next quote. I just used the short version -Nu instead of --newuse --update.


Ah, okay.

haarp wrote:
I haven't. I suspect the ebuild simply changed from IUSE=+python to IUSE=python, because I did not touch that useflag.


Those two IUSE are the same; but well, if you never changed it, that would as well explain why it stayed enabled. But still, I wonder where that * came from.

haarp wrote:
Nope, I didn't. Both were executed in the same environment and no actual merges took place (-p) Do you see why I consider this a weird inconsistency now?


Eh, no, the way I understand the python USE flag was always enabled and never disabled.

haarp wrote:
That couldn't have been the case. I have manually enabled the python useflag for talloc now, and there are no complaints when I do emerge -DN world. As I said, I suspect the ebuild went from +python to python.


I don't see other possibilities, the -D is what you have; but well, perhaps it might have something to do with the default state of the ebuild changing.

haarp wrote:
Nvidia 325.15. However, the stuttering, choppiness, freezing, seeking problems, etc also happen with software decoding. It also happens on a friend's PC with the same movie, who uses an older VLC on Mint. So it's definitely a VLC problem, and I'm tired of dealing with it when mplayer works so well.


True, won't convince you to do something else; just want to be another data point and tell you that on both NVIDIA and Nouveau drivers it works fluent here, so I really wonder what could be a possible cause of this but I guess we won't be able to find that soon. Sometimes these small bugs can decide which program you end up using; but well, if an alternative works much better for your purpose it doesn't really matter then...

I'll keep an eye out to see if there are more reports on this...
Back to top
View user's profile Send private message
haarp
Guru
Guru


Joined: 31 Oct 2007
Posts: 535

PostPosted: Thu Oct 31, 2013 12:58 pm    Post subject: Re: Portage becoming more incomprehensible and unmaintainabl Reply with quote

TomWij wrote:
haarp wrote:
But that's exactly the point, all emul-libs WERE unkeyworded. Emerge just would've had to upgrade them all, yet it took unmerging all emul-libs temporarily to make it understand that.


But their reverse dependencies are not.


The reverse deps are fine. There aren't any that complain about the new version. There was nothing in the way of upgrading the emul-libs.


Quote:
haarp wrote:
I haven't. I suspect the ebuild simply changed from IUSE=+python to IUSE=python, because I did not touch that useflag.


Those two IUSE are the same; but well, if you never changed it, that would as well explain why it stayed enabled. But still, I wonder where that * came from.


Are they? I thought +useflag meant that it's enabled by default for this ebuild, even if it's globally disabled.

Quote:
haarp wrote:
Nope, I didn't. Both were executed in the same environment and no actual merges took place (-p) Do you see why I consider this a weird inconsistency now?


Eh, no, the way I understand the python USE flag was always enabled and never disabled.


It's globally disabled. I only ever enable it on a per-package basis when it's needed.
Back to top
View user's profile Send private message
_______0
Guru
Guru


Joined: 15 Oct 2012
Posts: 521

PostPosted: Thu Oct 31, 2013 2:15 pm    Post subject: Reply with quote

creaker wrote:
_______0 wrote:
with qt/kde stuff what I do is un-install/re-install the whole stack to overcome those crazy deps.


I do the same for all the packages, no matter are they kde/qt related or no. In general it works. And almost all the collisions may be solved.
But it looks like something wrong in the depths of portage.


lololol!

I never thought of going at that lenght! Even for system packages?

I should try even though sounds like an overkill.
Back to top
View user's profile Send private message
ArneBab
Guru
Guru


Joined: 24 Jan 2006
Posts: 429
Location: Graben-Neudorf, Germany

PostPosted: Thu Oct 31, 2013 2:18 pm    Post subject: Re: Portage becoming more incomprehensible and unmaintainabl Reply with quote

TomWij wrote:
Well, mixing stable and unstable is exactly the cause of slot conflicts, it causes you to have to recursively unkeyword more things until you get your system back in a consistent state where everything is back satisfied.


The option of mixing stable and unstable is one of the core advantages of Gentoo over other distributions. You can keep the base system stable and limit experiments to a small set of packages. The keywords even give quite finegrained control over the packages in testing - for example like this:

Code:
=dev-vcs/mercurial-2.7*


This means: Test Mercurial 2.7 and all minor revisions of it, but not 2.8, so it’s a temporary testing package which will move to a null-keyword (no effect) once 2.8 becomes the testing version and all 2.7.x versions have been stabilized (or once any 2.8.x gets stabilized).
_________________
Being unpolitical means being political without realizing it. - Arne Babenhauserheide ( http://draketo.de )

pkgcore: So fast that it feels unreal - by doing only what is needed.
Back to top
View user's profile Send private message
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Fri Nov 01, 2013 2:13 pm    Post subject: Re: Portage becoming more incomprehensible and unmaintainabl Reply with quote

haarp wrote:
Are they? I thought +useflag meant that it's enabled by default for this ebuild, even if it's globally disabled.


That enables it only if the USE flag is globally unset; if you set the USE flag global, the default no longer applies.
Back to top
View user's profile Send private message
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Fri Nov 01, 2013 2:24 pm    Post subject: Re: Portage becoming more incomprehensible and unmaintainabl Reply with quote

ArneBab wrote:
The option of mixing stable and unstable is one of the core advantages of Gentoo over other distributions. You can keep the base system stable and limit experiments to a small set of packages.


While I agree, I have no idea if that feature was made with the intention of mixing branches to a larger extent, besides that it is often labeled as unsupported (eg. bug about a stable program with a ~ keyworded library can be closed). So, one might think whether this is to be considered an advantage? From one point of view, yeah; from the other point, hmm, not so sure...

One of the main disadvantages is those conflicts; but well, they are often worth it to solve and don't take that much time once you get the hang of it (though, they could be more informative). It kind of depends on the set of packages you plan to accept keywords for...
Back to top
View user's profile Send private message
iandoug
l33t
l33t


Joined: 11 Feb 2005
Posts: 816
Location: Cape Town, South Africa

PostPosted: Sun Nov 03, 2013 8:31 am    Post subject: Reply with quote

I am heartened to see that even people of Guru level are confused by the slot conflicts.

Currently I am blocked by the QT slot conflicts. My system is generally on Stable branch except for KDE, which is ~AMD64 in an attempt to use the latest bugfixes in the PIM subsection so that KMail is not entirely @)#(*)@#* $up.

Considering the advice given above, will it be safe for me to unmerge and then re-emerge the qt packages below, to deal with the slot conflicts?

I'm just worried that if I unmerge, I will be left with a broken system and this box is mission-critical...

thanks, Ian

Code:

Calculating dependencies... done!
[ebuild     U ~] dev-qt/qtcore-4.8.5:4 [4.8.4-r5:4] USE="exceptions glib iconv icu qt3support ssl (-aqua) -debug -pch (-c++0x%)" 235,832 kB
[ebuild     U ~] dev-qt/qtscript-4.8.5:4 [4.8.4:4] USE="exceptions iconv jit (-aqua) -debug -pch (-c++0x%)" 0 kB
[ebuild     U ~] dev-qt/qtgui-4.8.5-r1:4 [4.8.4-r1:4] USE="accessibility cups exceptions glib mng qt3support tiff xinerama xv (-aqua) -debug -egl -gtkstyle -nas -nis -pch -trace (-c++0x%) (-dbus%*) (-gif%*)" 0 kB
[ebuild     U ~] dev-qt/qttest-4.8.5:4 [4.8.4:4] USE="exceptions (-aqua) -debug -pch (-c++0x%)" 0 kB
[ebuild  NS    ] sys-kernel/gentoo-sources-3.10.17:3.10.17 [3.2.1-r2:3.2.1-r2, 3.2.12:3.2.12, 3.3.8:3.3.8, 3.5.7:3.5.7, 3.6.11:3.6.11, 3.7.10:3.7.10, 3.8.13:3.8.13, 3.10.7:3.10.7, 3.10.7-r1:3.10.7-r1] USE="-build -deblob -experimental -symlink" 352 kB
[ebuild     U ~] dev-qt/qtdbus-4.8.5:4 [4.8.4:4] USE="exceptions (-aqua) -debug -pch (-c++0x%)" 0 kB
[ebuild     U  ] x11-drivers/nvidia-drivers-325.15 [319.60] USE="X acpi (multilib) tools -pax_kernel" 46,909 kB
[ebuild     U ~] dev-qt/qtsql-4.8.5:4 [4.8.4:4] USE="exceptions mysql qt3support sqlite (-aqua) -debug -firebird -freetds -oci8 -odbc -pch -postgres (-c++0x%)" 0 kB
[ebuild     U ~] dev-qt/qt3support-4.8.5:4 [4.8.4:4] USE="accessibility exceptions (-aqua) -debug -pch (-c++0x%)" 0 kB
[ebuild  N     ] dev-lang/python-exec-0.3.1  PYTHON_TARGETS="(jython2_5) (jython2_7) (python2_6) (python2_7) (python3_2) (-pypy2_0) (-python3_3)" 0 kB
[ebuild     U  ] dev-python/python-exec-10000.1 [0.3.1] PYTHON_TARGETS="(jython2_5) (jython2_7) (python2_6) (python2_7) (python3_2) (-pypy2_0) (-python3_3)" 0 kB
[blocks b      ] <dev-python/python-exec-10000 ("<dev-python/python-exec-10000" is blocking dev-lang/python-exec-0.3.1)
[ebuild     U  ] dev-python/pycrypto-2.6.1 [2.6-r2] USE="gmp -doc" PYTHON_TARGETS="python2_7 python3_2 -python2_6 (-python3_3)" 436 kB
[ebuild     U  ] app-text/poppler-0.24.3:0/43 [0.22.5:0/37] USE="cairo cjk curl cxx introspection jpeg jpeg2k lcms png qt4 tiff utils -debug -doc" 1,471 kB
[ebuild     U  ] net-print/cups-1.6.4 [1.6.2-r5] USE="X acl dbus filters gnutls java pam python ssl threads usb -debug -kerberos -lprng-compat (-selinux) -static-libs -xinetd -zeroconf" LINGUAS="-ca -es -fr -ja -ru" PYTHON_SINGLE_TARGET="python2_7%* -python2_6%" PYTHON_TARGETS="python2_7%* -python2_6%" 8,069 kB
[ebuild     U  ] net-print/cups-filters-1.0.36-r1 [1.0.34-r1] USE="jpeg perl png tiff -static-libs -zeroconf" 1,009 kB
[ebuild     U  ] media-libs/libvisio-0.0.30 [0.0.28] USE="-doc -static-libs" 376 kB


_________________
Asus X570-PRO, Ryzen 7 5800X, GeForce GTX 1650, 32 GB RAM | Asus Sabertooth P990, AMD FX-8150, GeForce GTX 560, 16GB Ram
Back to top
View user's profile Send private message
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Sun Nov 03, 2013 11:21 am    Post subject: Reply with quote

I don't see anything blocking in that output, those are small "b" and thus get automatically resolved.
Back to top
View user's profile Send private message
haarp
Guru
Guru


Joined: 31 Oct 2007
Posts: 535

PostPosted: Sun Nov 03, 2013 12:06 pm    Post subject: Reply with quote

Another small example:


* Messages for package sys-kernel/gentoo-sources-3.10.17:

* If you are upgrading from a previous kernel, you may be interested
* in the following document:
* - General upgrade guide: http://www.gentoo.org/doc/en/kernel-upgrade.xml
*
* The following package has failed to build or install:
*
* (some-category/some-application::gentoo, ebuild scheduled for merge)
*


This is a bit unfortunate. It's a message and an error at the end of a merge session. At a glance, the spacing makes it look like the error belongs to gentoo-sources and not to some-application. Not a big issue, but it causes raised eyebrows for a few seconds every time.
Back to top
View user's profile Send private message
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Sun Nov 03, 2013 12:13 pm    Post subject: Reply with quote

Which package is at fault here? I can change the kernel-2.eclass to resolve this if this is a specific bug with it; or does this happen in general, not just with the kernel output?
Back to top
View user's profile Send private message
haarp
Guru
Guru


Joined: 31 Oct 2007
Posts: 535

PostPosted: Sun Nov 03, 2013 12:14 pm    Post subject: Reply with quote

TomWij wrote:
Which package is at fault here? I can change the kernel-2.eclass to resolve this if this is a specific bug with it; or does this happen in general, not just with the kernel output?

It happens in general. No specific package is at fault.
Back to top
View user's profile Send private message
iandoug
l33t
l33t


Joined: 11 Feb 2005
Posts: 816
Location: Cape Town, South Africa

PostPosted: Sun Nov 03, 2013 12:46 pm    Post subject: Reply with quote

TomWij wrote:
I don't see anything blocking in that output, those are small "b" and thus get automatically resolved.


Thanks for the response, let me be more verbose :-)

Code:

trooper ian # emerge -auvDN world

 * IMPORTANT: 13 news items need reading for repository 'gentoo'.
 * Use eselect news to read news items.


These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  r  U  ] dev-libs/icu-51.2-r1:0/51.2 [51.1:0/51.1] USE="-debug -doc -examples -static-libs" 21,331 kB
[ebuild  rR    ] dev-libs/icu-51.1:0/51.1  USE="-debug -doc -examples -static-libs" 0 kB
[ebuild  rR    ] dev-db/sqlite-3.7.17:3  USE="extensions icu readline secure-delete -debug -doc -static-libs -tcl {-test}" 0 kB
[ebuild     U ~] dev-qt/qtcore-4.8.5:4 [4.8.4-r5:4] USE="exceptions glib iconv icu qt3support ssl (-aqua) -debug -pch (-c++0x%)" 235,832 kB
[ebuild     U ~] dev-qt/qtscript-4.8.5:4 [4.8.4:4] USE="exceptions iconv jit (-aqua) -debug -pch (-c++0x%)" 0 kB
[ebuild     U ~] dev-qt/qtgui-4.8.5-r1:4 [4.8.4-r1:4] USE="accessibility cups exceptions glib mng qt3support tiff xinerama xv (-aqua) -debug -egl -gtkstyle -nas -nis -pch -trace (-c++0x%) (-dbus%*) (-gif%*)" 0 kB
[ebuild     U ~] dev-qt/qttest-4.8.5:4 [4.8.4:4] USE="exceptions (-aqua) -debug -pch (-c++0x%)" 0 kB
[ebuild     U ~] dev-qt/qtdbus-4.8.5:4 [4.8.4:4] USE="exceptions (-aqua) -debug -pch (-c++0x%)" 0 kB
[ebuild     U  ] x11-drivers/nvidia-drivers-325.15 [319.60] USE="X acpi (multilib) tools -pax_kernel" 46,909 kB
[ebuild     U ~] dev-qt/qtsql-4.8.5:4 [4.8.4:4] USE="exceptions mysql qt3support sqlite (-aqua) -debug -firebird -freetds -oci8 -odbc -pch -postgres (-c++0x%)" 0 kB
[ebuild     U ~] dev-qt/qt3support-4.8.5:4 [4.8.4:4] USE="accessibility exceptions (-aqua) -debug -pch (-c++0x%)" 0 kB
[ebuild  N     ] dev-lang/python-exec-0.3.1  PYTHON_TARGETS="(jython2_5) (jython2_7) (python2_6) (python2_7) (python3_2) (-pypy2_0) (-python3_3)" 0 kB
[ebuild     U  ] dev-python/python-exec-10000.1 [0.3.1] PYTHON_TARGETS="(jython2_5) (jython2_7) (python2_6) (python2_7) (python3_2) (-pypy2_0) (-python3_3)" 0 kB
[blocks b      ] <dev-python/python-exec-10000 ("<dev-python/python-exec-10000" is blocking dev-lang/python-exec-0.3.1)
[ebuild     U  ] dev-python/pycrypto-2.6.1 [2.6-r2] USE="gmp -doc" PYTHON_TARGETS="python2_7 python3_2 -python2_6 (-python3_3)" 436 kB
[ebuild     U  ] net-print/cups-1.6.4 [1.6.2-r5] USE="X acl dbus filters gnutls java pam python ssl threads usb -debug -kerberos -lprng-compat (-selinux) -static-libs -xinetd -zeroconf" LINGUAS="-ca -es -fr -ja -ru" PYTHON_SINGLE_TARGET="python2_7%* -python2_6%" PYTHON_TARGETS="python2_7%* -python2_6%" 8,069 kB
[ebuild     U  ] net-print/cups-filters-1.0.36-r1 [1.0.34-r1] USE="jpeg perl png tiff -static-libs -zeroconf" 1,009 kB
[ebuild     U  ] media-libs/libvisio-0.0.30 [0.0.28] USE="-doc -static-libs" 376 kB

Total: 17 packages (14 upgrades, 1 new, 2 reinstalls), Size of downloads: 313,959 kB
Conflict: 1 block

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

dev-libs/icu:0

  (dev-libs/icu-51.1::gentoo, ebuild scheduled for merge) pulled in by
    dev-libs/icu:0/51.1= required by (media-libs/raptor-2.0.9::gentoo, installed)
    dev-libs/icu:0/51.1= required by (sys-apps/gptfdisk-0.8.6::gentoo, installed)
    >=dev-libs/icu-49:0/51.1= required by (dev-qt/qtcore-4.8.4-r5::gentoo, installed)
    dev-libs/icu:0/51.1= required by (media-libs/libcdr-0.0.14::gentoo, installed)
    dev-libs/icu:0/51.1= required by (app-text/libmspub-0.0.6::gentoo, installed)
    dev-libs/icu:0/51.1= required by (dev-libs/libxml2-2.9.1-r1::gentoo, installed)
    dev-libs/icu:0/51.1= required by (media-libs/harfbuzz-0.9.12::gentoo, installed)
    (and 3 more with the same problems)

  (dev-libs/icu-51.2-r1::gentoo, ebuild scheduled for merge) pulled in by
    (no parents that aren't satisfied by other packages in this slot)

dev-qt/qtgui:4

  (dev-qt/qtgui-4.8.5-r1::gentoo, ebuild scheduled for merge) pulled in by
    ~dev-qt/qtgui-4.8.5[accessibility=,aqua=,debug=,qt3support] required by (dev-qt/qt3support-4.8.5::gentoo, ebuild scheduled for merge)
    (and 1 more with the same problem)

  (dev-qt/qtgui-4.8.4-r1::gentoo, installed) pulled in by
    <dev-qt/qtgui-4.8.5:4[accessibility,dbus(+)] required by (kde-base/knotify-4.11.2::gentoo, installed)
    ~dev-qt/qtgui-4.8.4[aqua=,debug=,glib=,qt3support] required by (dev-qt/qtcore-4.8.4-r5::gentoo, installed)
    (and 256 more with the same problems)

dev-qt/qtcore:4

  (dev-qt/qtcore-4.8.5::gentoo, ebuild scheduled for merge) pulled in by
    ~dev-qt/qtcore-4.8.5[aqua=,debug=,qt3support=] required by (dev-qt/qtsql-4.8.5::gentoo, ebuild scheduled for merge)
    (and 5 more with the same problem)

  (dev-qt/qtcore-4.8.4-r5::gentoo, installed) pulled in by
    ~dev-qt/qtcore-4.8.4[aqua=,debug=] required by (dev-qt/qtxmlpatterns-4.8.4::gentoo, installed)
    (and 10 more with the same problem)

dev-qt/qtdbus:4

  (dev-qt/qtdbus-4.8.4::gentoo, installed) pulled in by
    ~dev-qt/qtdbus-4.8.4[aqua=,debug=] required by (dev-qt/qtgui-4.8.4-r1::gentoo, installed)

  (dev-qt/qtdbus-4.8.5::gentoo, ebuild scheduled for merge) pulled in by
    (no parents that aren't satisfied by other packages in this slot)

dev-qt/qtscript:4

  (dev-qt/qtscript-4.8.5::gentoo, ebuild scheduled for merge) pulled in by
    ~dev-qt/qtscript-4.8.5[aqua=,debug=] required by (dev-qt/qtgui-4.8.5-r1::gentoo, ebuild scheduled for merge)

  (dev-qt/qtscript-4.8.4::gentoo, installed) pulled in by
    ~dev-qt/qtscript-4.8.4[aqua=,debug=] required by (dev-qt/qtgui-4.8.4-r1::gentoo, installed)
    (and 1 more with the same problem)

dev-qt/qt3support:4

  (dev-qt/qt3support-4.8.4::gentoo, installed) pulled in by
    ~dev-qt/qt3support-4.8.4[accessibility=,aqua=,debug=] required by (dev-qt/qtdeclarative-4.8.4::gentoo, installed)
    (and 1 more with the same problem)

  (dev-qt/qt3support-4.8.5::gentoo, ebuild scheduled for merge) pulled in by
    ~dev-qt/qt3support-4.8.5[aqua=,debug=] required by (dev-qt/qtgui-4.8.5-r1::gentoo, ebuild scheduled for merge)

dev-qt/qtsql:4

  (dev-qt/qtsql-4.8.4::gentoo, installed) pulled in by
    ~dev-qt/qtsql-4.8.4[aqua=,debug=,qt3support=] required by (dev-qt/qtdeclarative-4.8.4::gentoo, installed)
    (and 1 more with the same problem)

  (dev-qt/qtsql-4.8.5::gentoo, ebuild scheduled for merge) pulled in by
    ~dev-qt/qtsql-4.8.5[aqua=,debug=,qt3support] required by (dev-qt/qt3support-4.8.5::gentoo, ebuild scheduled for merge)


It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously.  If such a conflict exists in
the dependencies of two different packages, then those packages can
not be installed simultaneously. You may want to try a larger value of
the --backtrack option, such as --backtrack=30, in order to see if
that will solve this conflict automatically.

For more information, see MASKED PACKAGES section in the emerge man
page or refer to the Gentoo Handbook.



thanks, Ian
_________________
Asus X570-PRO, Ryzen 7 5800X, GeForce GTX 1650, 32 GB RAM | Asus Sabertooth P990, AMD FX-8150, GeForce GTX 560, 16GB Ram
Back to top
View user's profile Send private message
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Sun Nov 03, 2013 2:48 pm    Post subject: Reply with quote

You need to decide if you want 4.8.4 or 4.8.5; then mask and unmerge the other, then upgrade @world.
Back to top
View user's profile Send private message
Genone
Retired Dev
Retired Dev


Joined: 14 Mar 2003
Posts: 9507
Location: beyond the rim

PostPosted: Mon Nov 04, 2013 9:00 am    Post subject: Reply with quote

If you want to work on improving error messages please start with
Code:
pulled in by (no parents that aren't satisfied by other packages in this slot)
as that one makes no sense at all.
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