[gentoo-user] expat upgrade, kdelibs: circular problem?

[gentoo-user] expat upgrade, kdelibs: circular problem?

[brullo nulla]

Hi folks,

I am finally getting through the expat update. I am currently stuck at
kdelibs for what looks like a circular problem (or a linking problem).
Forums and google tell me of problems with kdelibs and expat upgrade,
but mostly qt3 related -this seems not to be the case. The ebuild
stops with:

../dcop/dcopidl/dcopidl ./ksycoca.h > ksycoca.kidl || ( rm -f
ksycoca.kidl ; false )
../dcop/dcopidl/dcopidl: error while loading shared libraries:
libexpat.so.0: cannot open shared object file: No such file or
directory

So I equeried dcopidl, and dcopidl belongs to kdelibs itself!

What does it mean? kdelibs needs a working kdelibs itself to be built
(very strange)? Or when it compiles dcopidl, fails to link it against
the new expat? Or I failed at finding the dcopidl ebuild?

Thanks for your help,
M.
-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] expat upgrade, kdelibs: circular problem?

[Alan McKinnon]

On Monday 17 March 2008, brullo nulla wrote:
> Hi folks,
>
> I am finally getting through the expat update. I am currently stuck
> at kdelibs for what looks like a circular problem (or a linking
> problem). Forums and google tell me of problems with kdelibs and
> expat upgrade, but mostly qt3 related -this seems not to be the case.
> The ebuild stops with:
>
> ../dcop/dcopidl/dcopidl ./ksycoca.h > ksycoca.kidl || ( rm -f
> ksycoca.kidl ; false )
> ../dcop/dcopidl/dcopidl: error while loading shared libraries:
> libexpat.so.0: cannot open shared object file: No such file or
> directory
>
> So I equeried dcopidl, and dcopidl belongs to kdelibs itself!

What output do you get from 'revdep-rebuild -p -i' ?



-- 
Alan McKinnon
alan dot mckinnon at gmail dot com

-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] expat upgrade, kdelibs: circular problem?

[brullo nulla]

>  What output do you get from 'revdep-rebuild -p -i' ?

Here it is:

Evaluating package order...
Warning: Failed to resolve package order.
Will merge in "random" order!
Possible reasons:
- An ebuild is no longer in the portage tree.
- An ebuild is masked, use /etc/portage/packages.keyword
  and/or /etc/portage/package.unmask to unmask it
..... done.
  (/root/.revdep-rebuild.5_order)

All prepared. Starting rebuild...
emerge --oneshot -p =media-plugins/gst-plugins-flac-0.8.11
=net-im/gaim-1.5.0 =x11-wm/compiz-9999 =app-doc/kchmviewer-3.1_p2
=x11-misc/idesk-0.7.5-r1 =x11-misc/basket-1.0.2 =x11-misc/xchm-1.13
=x11-misc/skippy-0.5.0 =media-gfx/gwenview-1.4.1
=media-gfx/hugin-0.6.1-r2 =media-gfx/graphviz-2.12
=kde-misc/ksmoothdock-4.5 =kde-misc/kdiff3-0.9.88
=kde-misc/kooldock-0.4.6 =sys-apps/dbus-1.0.2 =sys-apps/hal-0.5.7.1-r5
=sci-chemistry/xdrawchem-1.9.9 =media-tv/xawtv-3.95-r1
=sys-devel/gcc-4.1.2 =sys-devel/gdb-6.7.1 =net-misc/knetload-2.3
=app-cdr/k3b-1.0.4 =app-office/koffice-1.6.3-r2
=net-p2p/ktorrent-2.2.5 =app-text/ggv-2.8.5 =app-text/evince-2.20.1
=app-editors/nvu-1.0-r4 =app-editors/kile-1.9.3
=x11-libs/libXft-2.1.10 =x11-libs/compizconfig-backend-kconfig-9999
=x11-libs/vte-0.16.9 =x11-libs/pango-1.18.4 =x11-libs/wxGTK-2.8.7.1-r1
=sci-visualization/labplot-1.6.0.1 =games-emulation/gxmame-0.35_beta2
=media-video/avifile-0.7.41.20041001-r1
=media-video/mjpegtools-1.8.0-r1 =sci-astronomy/celestia-1.4.1-r2
=media-sound/rezound-0.12.3_beta =media-sound/audacity-1.3.4-r1
=media-sound/alsaplayer-0.99.76-r3 =media-sound/amarok-1.4.8
=media-sound/grip-3.3.1 =media-sound/picard-0.9.0
=x11-apps/xclock-1.0.2 =x11-terms/gnome-terminal-2.18.4
=media-libs/tunepimp-0.5.3 =net-firewall/guarddog-2.4.0
=dev-python/wxpython-2.4.2.4-r3 =dev-python/wxpython-2.6.4.0
=kde-base/kviewshell-3.5.7 =kde-base/kdesktop-3.5.7
=kde-base/kfloppy-3.5.7 =kde-base/kdepasswd-3.5.7-r1
=kde-base/kcalc-3.5.7 =kde-base/kreadconfig-3.5.6
=kde-base/kview-3.5.7 =kde-base/kicker-3.5.7 =kde-base/kstart-3.5.6
=kde-base/kate-plugins-3.5.7 =kde-base/knotes-3.5.7
=kde-base/kfind-3.5.7 =kde-base/kxsldbg-3.5.5
=kde-base/kdebugdialog-3.5.6 =kde-base/ksysguard-3.5.7
=kde-base/kdcop-3.5.7 =kde-base/ark-3.5.7 =kde-base/libkdegames-3.5.5
=kde-base/superkaramba-3.5.7 =kde-base/klipper-3.5.7
=kde-base/kpager-3.5.7 =kde-base/kwin-3.5.7
=kde-base/kfilereplace-3.5.5 =kde-base/ksmserver-3.5.7
=kde-base/kappfinder-3.5.7 =kde-base/libkdeedu-3.5.7
=kde-base/ksnapshot-3.5.7 =kde-base/kalarm-3.5.7 =kde-base/lisa-3.5.7
=kde-base/kdeartwork-styles-3.5.7 =kde-base/kstars-3.5.7
=kde-base/kgamma-3.5.7 =kde-base/libkcddb-3.5.7
=kde-base/libkmime-3.5.7 =kde-base/kdemultimedia-kfile-plugins-3.5.7
=kde-base/kooka-3.5.7 =kde-base/kscd-3.5.7
=kde-base/certmanager-3.5.7-r1 =kde-base/kopete-3.5.7
=kde-base/ksplashml-3.5.7 =kde-base/nsplugins-3.5.7
=kde-base/khelpcenter-3.5.7 =kde-base/klinkstatus-3.5.5
=kde-base/kontact-3.5.7-r1 =kde-base/libkdepim-3.5.7-r1
=kde-base/kdenetwork-kfile-plugins-3.5.7 =kde-base/libkscan-3.5.7
=kde-base/libkonq-3.5.7 =kde-base/quanta-3.5.7 =kde-base/ktalkd-3.5.7
=kde-base/kscreensaver-3.5.7 =kde-base/kghostview-3.5.7
=kde-base/libkpimidentities-3.5.7 =kde-base/kdelibs-3.5.7-r2
=kde-base/kdeprint-3.5.7 =kde-base/kpdf-3.5.7-r3
=kde-base/khotkeys-3.5.7 =kde-base/konsole-3.5.7
=kde-base/kcontrol-3.5.7-r1 =kde-base/ktnef-3.5.7
=kde-base/kommander-3.5.5 =kde-base/konq-plugins-3.5.7
=kde-base/kdnssd-3.5.7 =kde-base/kxkb-3.5.7 =kde-base/knetattach-3.5.7
=kde-base/kworldclock-3.5.7 =kde-base/kweather-3.5.7
=kde-base/kiconedit-3.5.7 =kde-base/kmix-3.5.7 =kde-base/ktip-3.5.7
=kde-base/kdeartwork-kscreensaver-3.5.7 =kde-base/kdm-3.5.7
=kde-base/kdemultimedia-kioslaves-3.5.7 =kde-base/kdesu-3.5.7
=kde-base/kedit-3.5.7 =kde-base/kdialog-3.5.5
=kde-base/kdeartwork-kwin-styles-3.5.7 =kde-base/kicker-applets-3.5.7
=kde-base/kbackgammon-3.5.5 =kde-base/kcminit-3.5.6
=kde-base/kdvi-3.5.7 =kde-base/ksvg-3.5.7
=kde-base/kdebase-kioslaves-3.5.7-r1 =kde-base/kaudiocreator-3.5.7
=kde-base/kdenetwork-filesharing-3.5.7 =kde-base/akregator-3.5.7-r1
=kde-base/cervisia-3.5.7 =kde-base/libkcal-3.5.7-r1
=kde-base/ksystraycmd-3.5.5 =kde-base/kimagemapeditor-3.5.5
=kde-base/kpersonalizer-3.5.7 =kde-base/konqueror-3.5.7-r3
=kde-base/kate-3.5.7-r1 =kde-base/kmenuedit-3.5.7
=kde-base/kuser-3.5.7 =kde-base/drkonqi-3.5.7
=dev-util/subversion-1.4.6 =dev-util/bazaar-1.4.2-r1
=dev-util/kdevelop-3.5.0 =gnome-base/nautilus-2.20.0-r1
=gnome-base/control-center-2.20.1 =gnome-base/gnome-mount-0.4-r5
=dev-libs/dbus-glib-0.72 =dev-libs/apr-util-0.9.12-r1
=xfce-extra/xfce4-mailwatch-1.0.1 =xfce-extra/xfce4-timer-0.5.1
=xfce-extra/verve-0.3.5

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

Calculating dependencies |
!!! All ebuilds that could satisfy
"=media-plugins/gst-plugins-flac-0.8.11" have been masked.
!!! One of the following masked packages is required to complete your request:
- media-plugins/gst-plugins-flac-0.8.11 (masked by: )

---
However, in the build I was doing, I was using --package-names, and in
that case there was no "mask" problem.

m.
-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] expat upgrade, kdelibs: circular problem?

[Alan McKinnon]

On Monday 17 March 2008, brullo nulla wrote:
> >  What output do you get from 'revdep-rebuild -p -i' ?
>
> Here it is:
>
> Evaluating package order...
> Warning: Failed to resolve package order.
> Will merge in "random" order!
> Possible reasons:
> - An ebuild is no longer in the portage tree.
> - An ebuild is masked, use /etc/portage/packages.keyword
>   and/or /etc/portage/package.unmask to unmask it
> ..... done.
>   (/root/.revdep-rebuild.5_order)

<snip HUGE package list...>

Hmmm. I seem to recall the expat upgrade being similar for me too. 
Unless you receive good advice to the contrary, you could try doing 
what I eventually did:

emerge -avuND world
then 
emerge --skipfirst --resume
as many times as needed to get to the end. Mask and unmask stuff 
manually as required. Eventually it all ends :-) and you are left with 
a consistent system. The final test is to run:

emerge -avuND world
emerge -av --depclean
revdep-rebuild -p -i

and all three should result in nothing to do.

-- 
Alan McKinnon
alan dot mckinnon at gmail dot com

-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] expat upgrade, kdelibs: circular problem?

[Enrico Weigelt]

* brullo nulla <brullonulla@gmail.com> wrote:

> So I equeried dcopidl, and dcopidl belongs to kdelibs itself!
> 
> What does it mean?

Simple: KDE folks still aren't confident with the concept of 
modularity (even it's an standard pattern since about 50 years) ;-P

BTW: if libexpat.so.0 was there before the update and now isn't,
there's an major bug in expat (either the ebuild or the source).

I don't know if the Gentoo QM policies say that those bugs have to
be fixed or relying on the revdep-rebuild workaround is enough. 
In the first case, you should file a bug. Otherwise could leave 
it out to save yourself from personal rants ;-o


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] expat upgrade, kdelibs: circular problem?

[Paul Varner]

On Mon, 2008-03-17 at 19:29 +0100, brullo nulla wrote:
> >  What output do you get from 'revdep-rebuild -p -i' ?
> 
> Here it is:
> 
> Evaluating package order...
> Warning: Failed to resolve package order.
> Will merge in "random" order!
> Possible reasons:
> - An ebuild is no longer in the portage tree.
> - An ebuild is masked, use /etc/portage/packages.keyword
>   and/or /etc/portage/package.unmask to unmask it
> ..... done.
>   (/root/.revdep-rebuild.5_order)

emerge =gentoolkit-0.2.4_rc3 and see what revdep-rebuild gives with that
version.  Unfortunately, the --package-names in gentoolkit-0.2.3 doesn't
work correctly, which causes problems with rebuilding after the expat
upgrade.

Regards,
Paul
-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] expat upgrade, kdelibs: circular problem?

[Alan McKinnon]

On Tuesday 18 March 2008, Enrico Weigelt wrote:
> BTW: if libexpat.so.0 was there before the update and now isn't,
> there's an major bug in expat (either the ebuild or the source).

There's no bug in expat, the OP is doing an *expat*upgrade*, which means 
that libexpat.so.0 was there before and libexpat.so.1 is there now. 
Thus any app that links explicitly to libexpat.so.0 is now broken.

A source based distro like Gentoo runs this risk with every library 
upgrade and sometimes it hits a low level lib with deep dependencies 
like expat. There are only two possible solutions to this:

1. Track the links between every app and every lib, and as soon as one 
is detected with a lib upgrade then fire an event to trigger a 
recompile of the linking app. This solution is so ugly, so error-prone 
that I cannot suffer it to live.

2. Something like revdep-rebuild that scans the system looking for 
errors and is triggered manually by the user.

Getting through these upgrades is a serious PITA. But at least on Gentoo 
we can fix it. Imagine using a binary distro where the packager didn't 
pick this up and you are left stranded with no easy way to fix it...

-- 
Alan McKinnon
alan dot mckinnon at gmail dot com

-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] expat upgrade, kdelibs: circular problem?

[Enrico Weigelt]

* Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On Tuesday 18 March 2008, Enrico Weigelt wrote:
> > BTW: if libexpat.so.0 was there before the update and now isn't,
> > there's an major bug in expat (either the ebuild or the source).
> 
> There's no bug in expat, the OP is doing an *expat*upgrade*, which 
> means that libexpat.so.0 was there before and libexpat.so.1 is there 
> now. Thus any app that links explicitly to libexpat.so.0 is now broken.

If an upgrade breaks primary things, it's simply broken. 
You can now choose, whether the bug is expat or the ebuild/portage.

> 2. Something like revdep-rebuild that scans the system looking for 
> errors and is triggered manually by the user.

This is also ugly and error-prone. After every slightest upgrade 
you have to fear nothing's running anymore and everything has to be 
rebuilt first. If downtimes don't matter, fine. But for critical 
systems, this is very dangerous.

Why not modeling/storing the *runtime* dependencies and doing 
an *clean* MVCC ? Isn't this what slotting was meant for ? ;-P

> Imagine using a binary distro where the packager didn't 
> pick this up and you are left stranded with no easy way to fix it...

Then the package manager's obviously broken ...


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
-- 
gentoo-user@lists.gentoo.org mailing list

Re: [gentoo-user] expat upgrade, kdelibs: circular problem?

[brullo nulla]

Ok, you all can stop ranting about ebuilds etc. being broken. :)

I found the culprit, it seems something wrong in the kdelibs building.
Basically, when kdelibs builds dcopidl,  it happily *says* "oh, this
would need libXft, that in turn has a broken link to libexpat.so.0.
But who cares, let's go along with it!" instead of stopping and
telling me that libXft is broken.

I have no more the relevant compilation output snippet, but that's the
meaning. So, I just emerged libXft, fixing the expat link, and
everything went pretty smooth.

Now I have the problem that Thunderbird starts, but no window comes
out, but it's a different stuff...

m.
-- 
gentoo-user@lists.gentoo.org mailing list