On 05/11/2013 15:37, Alex Schuster wrote:
>> Portage and the tree by itself isn't doing it, here's my output:
>>
>> $ emerge -pvt fsrunner
>>
>> These are the packages that would be merged, in reverse order:
>>
>> Calculating dependencies... done!
>> [ebuild  N     ] kde-misc/fsrunner-0.7.5:4  USE="(-aqua) -debug" 18 kB
>>
>> Total: 1 package (1 new), Size of downloads: 18 kB
> 
> Same here, except that it's emerged already.
> 
> OK, I have no clue how to further debug this. But what I did is:
> 
> for (( i=500; i > 0; i-=20 ))
> do
>   emerge -DautvNj $( head -n $i /var/lib/portage/world )
> done
> 
> This failed until $i was 260, so I tried a little more, and removed
> media-sound/kid3 from @world. Along with fsrunner of course. Now, it's
> building.
> 
> This does not make any sense, does it?
> 


Actually, it does make sense, in a weird kind of way

kid3 and fsrunner are not part of KDE proper (i.e. they are not shipped
in the huge KDE tarballs). So they may be inconsistent with the main
release due to no QA checks beyond what the dev does. And I doubt the
gentoo KDE team checks such packages before updating ebuilds.

I would use this approach:

Remove from world every KDE package that is not in kde-base (quickpkg
first to make restores easier), then update world and do a depclean.
Chances are very good it will complete cleanly.

Then emerge all those KDE packages back in using the -t option to emerge
and see what is causing issues.

I think the odds are very good you will find an out-of-sync package that
directly DEPENDS on some old version of Qt (or something equally silly).
That package might even already be in the emerge output, but buried in
the voluminous output portage gives these days

-- 
Alan McKinnon
alan.mckin...@gmail.com


Reply via email to