Connie,
Thanks for the info.
I just had this happen last night on yet another system; this time an
i386 (I was playing around on a test system to see if I could reproduce
the errors). It seems that when I updated all of my packages with all
of the repos checked (one or two at a time) in yumex it causes this
problem.
I was watching it this time, and I observed the moment when it happened
-- it was during the atrpms repo update, where yumex came back with the
usual "package update complete", and then right after I clicked "ok" it
froze with another window which gave a transaction failure notice (this
should have happened BEFORE the update was carried out). The failure
notice was on the screen for less than a second, so I couldn't make out
the exact package(s) in conflict or missing.
At this point the yumex application froze and never came back. Fearing
there may be partial installs, I tried the update again (new yumex
session). This time there were very few package updates which would
pass the transaction test (listing python missing deps and freetype
conflicts).
Once again, this is not any attack on atrpms -- I have no idea what has
caused this. I can only suspect there is some bug in yum which is only
exposed under certain conditions, or some problem with one or more of
the packages in one or more of the repos.
I will certainly be more cautious when selecting repos in the future.
However, it would have been nice to know which combinations would result
in conflicts and overall chaos. I also did not imagine that yum/yumex
would allow the system to break so easily (and thoroughly), especially
on a stable distribution.
In any case, I now have several backup/rebuild/restore jobs (so much for
the long weekend! :-)).
Still, I wanted to let you guys know I really appreciate the work you
continue to do with the distribution, repo management, and this support
list (and I'm sure that is no small task!). -Michael
Connie Sieh wrote:
> On Thu, 31 Aug 2006, Michael Malik wrote:
>
>> Firstly, I want to apologize for the confusion -- I did not mean to make
>> this an attack on the atrpms repo.
>>
>> Second, I never removed anything related to python -- at least none that
>> I know of (perhaps some other update removed it?). I have only used the
>> check-box repos available in yumex on SL43, which includes atrpms, dag,
>> dries, macromedia, rhaps, sl-base, sl-bugfix-44, sl-contrib, sl-errata,
>> sl-fastbug, and sl-testing.
>>
>> By the way, the only conflicts or transaction errors I have ever had
>> have been with the atrpms versions, and it appears that I am not alone
>> in experiencing these beecrypt/python problems -- there are many such
>> cases one can find with a google search of the error message. I
>> suspected there was some common error in the way SL43, yum, yumex,
>> python, beecrypt, and freetype are updated.
>>
>> So it now appears that my system is broken because I used the included
>> repo config to perform updates -- which, to me sounds like some kind of
>
> All of the repos were never intented to be used at the same time. We will
> update out documentation to note this.
>
> -Connie Sieh
>
>> bug. Note that I did not remove ANYTHING with the --nodeps option. To
>> update my system I have used "yum update", yumex, "apt-get update", and
>> smart. I have not changed the repo config, except by way of the check
>> boxes in yumex. I have removed packages in the past, but only through
>> yumex, and nothing called python*.
>>
>> Oh well, I guess I shall start all over on three different systems,
>> since all three have this problem.
>>
>> Axel Thimm wrote:
>>> Dear FUDder,
>>>
>>> On Thu, Aug 31, 2006 at 04:30:46PM -0600, Michael Malik wrote:
>>>> For the freetype error with yumex, I have only selected the sl-base and
>>>> sl-errata, but at some time I must have used atrpms to install some
>>>> incompatible-with-everything and impossible-to-remove version of
>>>> freetype (note the conflicting packages end in .at).
>>> don't be too fast on judging things, it may well turn the other way
>>> round like it does in this case. Allow-me-to-tear-you-apart.
>>>
>>> python 2.3 and python 2.4 have no common abi, so python 2.4 will not
>>> replace 2.3. It looks like you removed python 2.3 from your system
>>> under the false assumption that a greater python replaces the previous
>>> one - since every other system tool in RHEL4/SL4 is using python 2.3
>>> your system looks rather broken now. You also had to use --nodeps to
>>> rip it out. You thus broke at the very least the following packages
>>> directly and all further dependent packages, too (like any pygtk based
>>> package, e.g. every python based gui in RHEL4/SL4):
>>>
>>> libpython2.3.so.1.0()(64bit) is needed by (installed) postgresql-pl-7.4.13-2.RHEL4.1.x86_64
>>> python-abi = 2.3 is needed by (installed) system-config-printer-0.6.116.5-1.x86_64
>>> python-abi = 2.3 is needed by (installed) gnome-python2-2.6.0-3.x86_64
>>> python-abi = 2.3 is needed by (installed) alchemist-1.0.34-1.i386
>>> python-abi = 2.3 is needed by (installed) pyparted-1.6.8-2.x86_64
>>> python-abi = 2.3 is needed by (installed) alchemist-1.0.34-1.x86_64
>>> python2 >= 2.3 is needed by (installed) pygtk2-2.4.0-1.x86_64
>>> python2 >= 2.3 is needed by (installed) pyorbit-2.0.1-1.x86_64
>>> python >= 2.3 is needed by (installed) rhpl-0.148.3-1.x86_64
>>> python >= 0:2.3 is needed by (installed) python-ldap-2.0.1-2.x86_64
>>> python = 2.3.4-14.2 is needed by (installed) python-docs-2.3.4-14.2.x86_64
>>> python >= 2.3.2 is needed by (installed) sip-4.1-1.x86_64
>>> python >= 2.3 is needed by (installed) system-config-lvm-1.0.19-1.0.noarch
>>> python >= 2.3 is needed by (installed) MySQL-python-1.0.0-1.RHEL4.1.x86_64
>>> python >= 2.3 is needed by (installed) system-config-cluster-1.0.27-1.0.noarch
>>> python >= 2.3 is needed by (installed) system-switch-im-0.1.2-3.noarch
>>> python >= 2.3.2 is needed by (installed) PyQt-3.13-1.x86_64
>>> python >= 2.3.3 is needed by (installed) system-config-kickstart-2.5.16.1-1.noarch
>>> python >= 2.3 is needed by (installed) authconfig-4.6.10-rhel4.3.x86_64
>>> python >= 2.3 is needed by (installed) mx-2.0.5-3.x86_64
>>> python >= 2.3 is needed by (installed) system-switch-mail-0.5.25-3.noarch
>>> python = 2.3.4-14.2 is needed by (installed) python-tools-2.3.4-14.2.x86_64
>>> python = 2.3.4-14.2 is needed by (installed) python-devel-2.3.4-14.2.x86_64
>>> python >= 2.3 is needed by (installed) system-switch-mail-gnome-0.5.25-3.noarch
>>> python = 2.3.4-14.2 is needed by (installed) tkinter-2.3.4-14.2.x86_64
>>> /usr/bin/python is needed by (installed) python-tools-2.3.4-14.2.x86_64
>>> /usr/lib64/python2.3 is needed by (installed) gamin-python-0.1.1-4.EL4.x86_64
>>>
>>> And that wasn't induced by ATrpms python24, which *coinstalls* with
>>> the system python. Somehow you removed python from your system and
>>> even the repo that carries it, e.g. sl-base. smart check will probably
>>> also list all python tools now missing python.
>>>
>>> Finally there are more repos enabled than what you claimed, I see for
>>> example rf tags, too.
>>>
>>> Anyway the moment you started operating on the system with rpm -e
>>> --nodeps it was doomed. You probably didn't do it only with the python
>>> package.
>>>
>>> I'd reinstall from scratch and avoid rpm --nodeps like hell as well as
>>> randomly using 3rd party repos - at least incompatible-with-everything
>>> and impossible-to-remove ATrpms - so you don't start FUDing again.
>>>
>>> Sorry, you asked for it.
>>>
>>>>> Michael Malik wrote:
>>>>>> Here is a problem I have been experiencing for many weeks (see below),
>>>>>> waiting for perhaps a bug fix or newer version of one of the update
>>>>>> applications. I have tried to resolve this with apt-get, yum, and
>>>>>> smart -- none have worked for me. I can't see why the new packages
>>>>>> require python 2.3 when I have python 2.4 installed -- is there no
>>>>>> backward compatibility built into python24?
>
|
