| Summary: | emerging gconf-2.12.1 fails (stalls on md5 src_uri ;-) GConf-2.12.1.tar.bz2) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Christopher Zapart <chris.zapart> |
| Component: | [OLD] GNOME | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | 2005.1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Christopher Zapart
2006-01-23 00:43:27 UTC
Previous versions of gconf are also affected by this problem (for example gconf-2.10.1-r1). Other Gentoo ebuilds continue emerging without any problems whatsover. This problem is specific to the gconf ebuild. After manually stepping through the ebuild and portage python scripts I have found
out that the problem is caused by the script /usr/lib/portage/bin/ebuild.sh hanging on
all the empty return functions pkg_*(), for example
pkg_setup()
{
return
}
if one were to comment out calls to all these empty functions (found for example in
dyn_setup()) then the script ebuild executes without problems, it does not hang on
these pkg_* functions.
in addition, echo in the following code does not get executed at all (I manually added
echo in there):
pkg_setup()
{
echo "pkg_setup here"
return
}
Equally, the second echo with #2 does not execute in the dyn_setup function (because
pkg_setup() never really returns anything, somehow it does not execute at all:
dyn_setup()
{
echo "dyn_setup here#1"
pkg_setup
echo "dyn_setup here#2"
}
commenting out all the instances of calls to empty return pkg_ functions of the sort:
pkg_*
{
return
}
finally enabled me to emerge gconf successfully. But no other ebuilds seem to be
affected by these problems (so far). Perhaps other ebuilds do not trigger calls to
empty return functions in the /usr/lib/portage/bin/ebuild.sh script.
So I am leaving this bug as new, unresolved as I have only solved the symptoms but
have been unable to find out the real root causes of the problem.
if you comment the kill_gconf's out and redigest the ebuild, does this make it stop hanging? After upgrading the gconf (plus the whole gnome) successfully yesterday by using the described hack with empty pkg_* functions, today gconf installs OK with and without commenting out kill_gconf in its ebuild. It no longers hangs. The only difference between commenting out kill_gconf and not is an extra warning from ORBit. Output without commenting out kill_gconf: emerge gconf Calculating dependencies ...done! >>> emerge (1 of 1) gnome-base/gconf-2.12.1 to / >>> md5 files ;-) gconf-1.0.8-r3.ebuild >>> md5 files ;-) gconf-1.0.8-r5.ebuild >>> md5 files ;-) gconf-1.0.9.ebuild >>> md5 files ;-) gconf-2.10.1-r1.ebuild >>> md5 files ;-) gconf-2.12.0.ebuild >>> md5 files ;-) gconf-2.12.1.ebuild >>> md5 files ;-) files/digest-gconf-1.0.8-r3 >>> md5 files ;-) files/digest-gconf-1.0.8-r5 >>> md5 files ;-) files/digest-gconf-1.0.9 >>> md5 files ;-) files/gconf-1.0.9-locallock_mdk.patch >>> md5 files ;-) files/gconfd-2-fix.patch >>> md5 files ;-) files/digest-gconf-2.10.1-r1 >>> md5 files ;-) files/digest-gconf-2.12.0 >>> md5 files ;-) files/digest-gconf-2.12.1 >>> md5 src_uri ;-) GConf-2.12.1.tar.bz2 ORBit-WARNING **: No POA found for operation drop_all_caches [-1077415640] >>> Unpacking source... >>> Unpacking GConf-2.12.1.tar.bz2 to /var/tmp/portage/gconf-2.12.1/work WIth kill_gconf commented out: emerge gconf Calculating dependencies ...done! >>> emerge (1 of 1) gnome-base/gconf-2.12.1 to / >>> md5 files ;-) gconf-1.0.8-r3.ebuild >>> md5 files ;-) gconf-1.0.8-r5.ebuild >>> md5 files ;-) gconf-1.0.9.ebuild >>> md5 files ;-) gconf-2.10.1-r1.ebuild >>> md5 files ;-) gconf-2.12.0.ebuild >>> md5 files ;-) gconf-2.12.1.ebuild >>> md5 files ;-) files/digest-gconf-1.0.8-r3 >>> md5 files ;-) files/digest-gconf-1.0.8-r5 >>> md5 files ;-) files/digest-gconf-1.0.9 >>> md5 files ;-) files/gconf-1.0.9-locallock_mdk.patch >>> md5 files ;-) files/gconfd-2-fix.patch >>> md5 files ;-) files/digest-gconf-2.10.1-r1 >>> md5 files ;-) files/digest-gconf-2.12.0 >>> md5 files ;-) files/digest-gconf-2.12.1 >>> md5 src_uri ;-) GConf-2.12.1.tar.bz2 >>> Unpacking source... >>> Unpacking GConf-2.12.1.tar.bz2 to /var/tmp/portage/gconf-2.12.1/work In both cases the installation proceeds as normal, it no longer hangs after the last md5 checksum. So I guess after successfully upgrading gconf by using a manual hack the problem has gone away on its own. seemed to be a local issue. |
