An attempt to install the latest updates produced the following errors from yumex. Machine is x86_64 with all updates except the latest.
jon
Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-chewing-1.2.0.20090818-1.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-m17n-1.1.0.20090211-5.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-hangul-1.1.0.20090328-2.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-rawcode-1.0.0.20090303-3.fc11.x86_64 (installed)
Jonathan Ryshpan wrote:
An attempt to install the latest updates produced the following errors from yumex. Machine is x86_64 with all updates except the latest.
jon
Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-chewing-1.2.0.20090818-1.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-m17n-1.1.0.20090211-5.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-hangul-1.1.0.20090328-2.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-rawcode-1.0.0.20090303-3.fc11.x86_64 (installed)
This type of thing happens from time to time. Lucky for us it isn't a terminal disease. If you desire to update other packages you can always do "yum --skip-broken update". And then chill for a time while the broken issues get resolved.
On Wed, 2009-09-30 at 11:12 +0800, Ed Greshko wrote:
Jonathan Ryshpan wrote:
An attempt to install the latest updates produced the following errors from yumex. Machine is x86_64 with all updates except the latest.
jon
Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-chewing-1.2.0.20090818-1.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-m17n-1.1.0.20090211-5.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-hangul-1.1.0.20090328-2.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-rawcode-1.0.0.20090303-3.fc11.x86_64 (installed)
This type of thing happens from time to time. Lucky for us it isn't a terminal disease. If you desire to update other packages you can always do "yum --skip-broken update". And then chill for a time while the broken issues get resolved.
Just what I planned to do. But it seemed to be a good idea to tell the packagers that there is a problem, otherwise it might be a while before they fixed it (8-).
jon
On 09/30/2009 09:49 AM, Jonathan Ryshpan wrote:
Just what I planned to do. But it seemed to be a good idea to tell the packagers that there is a problem, otherwise it might be a while before they fixed it (8-).
If that's the goal, please use bugzilla. http://bugz.fedoraproject.org/<srpm name> is a shortcut.
Rahul
On Wed, 2009-09-30 at 13:02 +0530, Rahul Sundaram wrote:
Just what I planned to do. But it seemed to be a good idea to tell the packagers that there is a problem, otherwise it might be a while before they fixed it (8-).
If that's the goal, please use bugzilla. http://bugz.fedoraproject.org/<srpm name> is a shortcut.
As you like, though it seems like using a sledgehammer to crack a walnut.
And thanks for the shortcut. Do you have a similar one for a packaging problem?
jon
On 09/30/2009 01:33 PM, Jonathan Ryshpan wrote:
On Wed, 2009-09-30 at 13:02 +0530, Rahul Sundaram wrote:
Just what I planned to do. But it seemed to be a good idea to tell the packagers that there is a problem, otherwise it might be a while before they fixed it (8-).
If that's the goal, please use bugzilla. http://bugz.fedoraproject.org/<srpm name> is a shortcut.
As you like, though it seems like using a sledgehammer to crack a walnut.
Posts in this list are not going to be read by all the maintainers however. Very few are even subscribed to this list in the first place.
And thanks for the shortcut. Do you have a similar one for a packaging problem?
A dependency problem is just a bug and that can be filed in bugzilla. For example,
http://bugz.fedoraproject.org/coreutils
Replace coreutils with the name of the package (note that it should be the source rpm name). You can find that using rpm -qi <packagename>. Alternatively, look for the update at http://admin.fedoraproject.org/updates and add a comment there. You would note that someone has already done that for this problem at
https://admin.fedoraproject.org/updates/F11/FEDORA-2009-10088?_csrf_token=ac...
Rahul
On Tue, 29 Sep 2009 21:19:17 -0700, Jonathan wrote:
But it seemed to be a good idea to tell the packagers that there is a problem, otherwise it might be a while before they fixed it (8-).
I still create public+private extras-repoclosure reports: https://www.redhat.com/archives/fedora-test-list/2009-September/msg00713.htm...
Skipping the updates-testing repo and pushing updates directly into the updates repo is frowned upon.
On Wed, 30 Sep 2009 15:51:52 +0200 Michael Schwendt wrote:
Skipping the updates-testing repo and pushing updates directly into the updates repo is frowned upon.
I still can't understand why the repo update process isn't automated at least to the extent of testing updates on a virtual machine which has all optional packages installed to see if the updates install correctly and the system still boots after the updates.
If it makes it through that elementary test, then go ahead and make the repo public. A test run like that would be quick and easy and catch somewhere around 99% of the problems like this that keep sneaking into the updates.
Tom Horsley wrote:
On Wed, 30 Sep 2009 15:51:52 +0200 Michael Schwendt wrote:
Skipping the updates-testing repo and pushing updates directly into the updates repo is frowned upon.
I still can't understand why the repo update process isn't automated at least to the extent of testing updates on a virtual machine which has all optional packages installed to see if the updates install correctly and the system still boots after the updates.
It's known, but implementing this is *hard*, and there are concerns how it could impact the speed/performance of performing updates. Pushing updates as-is already is a multi-hour operation, mind you.
OK, so a broken dep is found somewhere, now what? Stop the presses, manually find what is broke, restart updates-push from the beginning? Not fun. Hopefully, this scratches the surface to communicate how this is very much a non-trivial thing to do.
Now, if you're interested in helping to make this a reality, I can help facilitate getting in touch with those on the rel-eng side.
-- Rex
On Wed, 30 Sep 2009 09:56:30 -0500 Rex Dieter wrote:
OK, so a broken dep is found somewhere, now what? Stop the presses, manually find what is broke, restart updates-push from the beginning? Not fun.
But what happens now is the presses DON'T stop, but just spew the broken updates to the world. And presumably the whole push-updates process still has to happen again to get the fix pushed to the world. I don't see anything particularly wrong with the "stop the presses" model to postpone things till the updates are in a sane state again.
Tom Horsley wrote:
On Wed, 30 Sep 2009 09:56:30 -0500 Rex Dieter wrote:
OK, so a broken dep is found somewhere, now what? Stop the presses, manually find what is broke, restart updates-push from the beginning? Not fun.
But what happens now is the presses DON'T stop, but just spew the broken updates to the world. And presumably the whole push-updates process still has to happen again to get the fix pushed to the world. I don't see anything particularly wrong with the "stop the presses" model to postpone things till the updates are in a sane state again.
And, if this batch of updates included critical (security or otherwise) fixes, that wouldn't influence your opinion?
-- Rex
On Wed, 30 Sep 2009 11:20:43 -0500 Rex Dieter wrote:
And, if this batch of updates included critical (security or otherwise) fixes, that wouldn't influence your opinion?
No. My system has already been up for a long time without those fixes anyway, but if there is one I'm desperately hot for, I can always grab it directly from updates-testing or koji (or however it is spelled :-).
On Wed, 2009-09-30 at 13:30 -0400, Tom Horsley wrote:
On Wed, 30 Sep 2009 11:20:43 -0500 Rex Dieter wrote:
And, if this batch of updates included critical (security or otherwise) fixes, that wouldn't influence your opinion?
No. My system has already been up for a long time without those fixes anyway, but if there is one I'm desperately hot for, I can always grab it directly from updates-testing or koji (or however it is spelled :-).
Precisely...!
This is the difference in mentality between people who develop as a primary focus and people who actually have to keep a real data center up and running via a sane change control / change management process.
Classic argument between two important groups.
In a production DC, a change like the one discussed here would have had to have been backed out and fixed as a severity 1 issue. Even if it contained critical fixes. The operations management team would have had the developers working 24/7 until it was done, and done right. Then, after everything was fixed, there would be a process review to identify the failure in the overall process, and changes would have then been made to both systems and processes to try and prevent something like this from happening again. Ever.
Cheers,
Chris
Rex Dieter wrote:
Tom Horsley wrote:
On Wed, 30 Sep 2009 09:56:30 -0500 Rex Dieter wrote:
OK, so a broken dep is found somewhere, now what? Stop the presses, manually find what is broke, restart updates-push from the beginning? Not fun.
But what happens now is the presses DON'T stop, but just spew the broken updates to the world. And presumably the whole push-updates process still has to happen again to get the fix pushed to the world. I don't see anything particularly wrong with the "stop the presses" model to postpone things till the updates are in a sane state again.
And, if this batch of updates included critical (security or otherwise) fixes, that wouldn't influence your opinion?
I don't buy breaking the machine to protect it as a security model. But to turn the question around, should critical changes be pushed as a separate task? If there is something critical, which happens rarely, should that go out by itself, and let other changes wait?
The notification tool offers the option of security updates only, so clearly some thought has been given to getting the important stuff visible and available without other updates.
I can't tell if that would be relatively easy, but since the critical stuff is identified now, pushing that separately might be possible, and certainly desirable.
Rex Dieter wrote:
Tom Horsley wrote:
On Wed, 30 Sep 2009 15:51:52 +0200 Michael Schwendt wrote:
Skipping the updates-testing repo and pushing updates directly into the updates repo is frowned upon.
I still can't understand why the repo update process isn't automated at least to the extent of testing updates on a virtual machine which has all optional packages installed to see if the updates install correctly and the system still boots after the updates.
It's known, but implementing this is *hard*, and there are concerns how it could impact the speed/performance of performing updates. Pushing updates as-is already is a multi-hour operation, mind you.
I would hope that the time is proportional to the size of the changes, so preventing sending of something broken would (or should, or might if you prefer) avoid sending broken once and fixed later. That applies to the follow paragraph as well.
OK, so a broken dep is found somewhere, now what? Stop the presses, manually find what is broke, restart updates-push from the beginning? Not fun. Hopefully, this scratches the surface to communicate how this is very much a non-trivial thing to do.
Now, if you're interested in helping to make this a reality, I can help facilitate getting in touch with those on the rel-eng side.
If it would help to catch the low hanging fruit by testing many of the updates, it could be fairly easily done, although it would take a bit of machine effort to run the test. Consider that changes in updates-testing would be subject to some automated sanity check: 1 - create a qcow2 copy of the current sane VM (updated to yesterday) 2 - boot it 3 - have rc.local or similar download a list if packages to install or upgrade over the network (this proves the network worked to start). 4 - run yum and install/upgrade the packages involved 5 - reboot 6 - if the system comes up send a message over the network saying it passed the smoke test (proves the network still works).
Caveats: - it doesn't test changes which break other network drivers or wireless - needs to be run on each primary machine type - doesn't test if the upgrade does what it should - doesn't test display breakage
But it does test being able to apply the upgrades and have a sane system. And that would have caught the latest few dependency issues, and saved a LOT of hassle. It would allow things to be kicked out of the process without false positives.
On Wed, 2009-09-30 at 10:15 -0400, Tom Horsley wrote:
I still can't understand why the repo update process isn't automated at least to the extent of testing updates on a virtual machine which has all optional packages installed to see if the updates install correctly and the system still boots after the updates.
That'd still overlook the problem where someone's built a package that depends on something, but hasn't asked for that dependency. The builder didn't notice it being required, because it was already on their system.
On Wed, Sep 30, 2009 at 4:15 PM, Tom Horsley tom.horsley@att.net wrote:
On Wed, 30 Sep 2009 15:51:52 +0200 Michael Schwendt wrote:
Skipping the updates-testing repo and pushing updates directly into the updates repo is frowned upon.
I still can't understand why the repo update process isn't automated at least to the extent of testing updates on a virtual machine which has all optional packages installed to see if the updates install correctly and the system still boots after the updates.
If it makes it through that elementary test, then go ahead and make the repo public. A test run like that would be quick and easy and catch somewhere around 99% of the problems like this that keep sneaking into the updates.
There are some smart engineers in Fedora and Red Hat camps, it is not a easy nut to crack, but it they had enough encouragement and time they would make a solution. I hope they do.
Cheers!
Michael Schwendt wrote:
On Tue, 29 Sep 2009 21:19:17 -0700, Jonathan wrote:
But it seemed to be a good idea to tell the packagers that there is a problem, otherwise it might be a while before they fixed it (8-).
I still create public+private extras-repoclosure reports: https://www.redhat.com/archives/fedora-test-list/2009-September/msg00713.htm...
And than you for it!
Skipping the updates-testing repo and pushing updates directly into the updates repo is frowned upon.
Ed Greshko wrote:
Jonathan Ryshpan wrote:
An attempt to install the latest updates produced the following errors from yumex. Machine is x86_64 with all updates except the latest.
jon
Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-chewing-1.2.0.20090818-1.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-m17n-1.1.0.20090211-5.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-hangul-1.1.0.20090328-2.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-rawcode-1.0.0.20090303-3.fc11.x86_64 (installed)
This type of thing happens from time to time. Lucky for us it isn't a terminal disease. If you desire to update other packages you can always do "yum --skip-broken update". And then chill for a time while the broken issues get resolved.
Given that the upgrade installs a new kernel (2.6.30.8-64 from memory) which doesn't do networking, more than chill is required. I did this to my production laptop, then managed to do it again on a desktop. Since it happened after midnight, I just saved a dmesg for investigation, I assume all networking is dead since the desktop had the same problem.
Manual booting into an older kernel worked on the desktop, the laptop old kernel doesn't like something in the partial upgrade which did take place, so I'm somewhat hung on that one.
Once upon a time, Bill Davidsen davidsen@tmr.com said:
Given that the upgrade installs a new kernel (2.6.30.8-64 from memory) which doesn't do networking, more than chill is required. I did this to my production laptop, then managed to do it again on a desktop. Since it happened after midnight, I just saved a dmesg for investigation, I assume all networking is dead since the desktop had the same problem.
I loaded 2.6.30.8-64.x86_64 on my desktop at home last night and it worked fine (networking included).
On 09/30/2009 07:10 PM, Bill Davidsen wrote:
Ed Greshko wrote:
Jonathan Ryshpan wrote:
An attempt to install the latest updates produced the following errors from yumex. Machine is x86_64 with all updates except the latest. jon
Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-chewing-1.2.0.20090818-1.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-m17n-1.1.0.20090211-5.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-hangul-1.1.0.20090328-2.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-rawcode-1.0.0.20090303-3.fc11.x86_64 (installed)
This type of thing happens from time to time. Lucky for us it isn't a terminal disease. If you desire to update other packages you can always do "yum --skip-broken update". And then chill for a time while the broken issues get resolved.
Given that the upgrade installs a new kernel (2.6.30.8-64 from memory) which doesn't do networking, more than chill is required. I did this to my production laptop, then managed to do it again on a desktop. Since it happened after midnight, I just saved a dmesg for investigation, I assume all networking is dead since the desktop had the same problem.
Manual booting into an older kernel worked on the desktop, the laptop old kernel doesn't like something in the partial upgrade which did take place, so I'm somewhat hung on that one.
for a while I've gone through *yum --skip-broken update* .... after facing the same problem
Bill Davidsen wrote:
Ed Greshko wrote:
Jonathan Ryshpan wrote:
An attempt to install the latest updates produced the following errors from yumex. Machine is x86_64 with all updates except the latest. jon
Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-chewing-1.2.0.20090818-1.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-m17n-1.1.0.20090211-5.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-hangul-1.1.0.20090328-2.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-rawcode-1.0.0.20090303-3.fc11.x86_64 (installed)
This type of thing happens from time to time. Lucky for us it isn't a terminal disease. If you desire to update other packages you can always do "yum --skip-broken update". And then chill for a time while the broken issues get resolved.
Given that the upgrade installs a new kernel (2.6.30.8-64 from memory) which doesn't do networking, more than chill is required. I did this to my production laptop, then managed to do it again on a desktop. Since it happened after midnight, I just saved a dmesg for investigation, I assume all networking is dead since the desktop had the same problem.
Manual booting into an older kernel worked on the desktop, the laptop old kernel doesn't like something in the partial upgrade which did take place, so I'm somewhat hung on that one.
????
All is working here just fine after skipping the broken updates. So, I've no idea as to what you've managed to accomplish. But since you've decided to keep all the dmesg output for investigation private I suspect nobody will be able to help you either.
Ed Greshko wrote:
Bill Davidsen wrote:
Ed Greshko wrote:
Jonathan Ryshpan wrote:
An attempt to install the latest updates produced the following errors from yumex. Machine is x86_64 with all updates except the latest. jon
Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-chewing-1.2.0.20090818-1.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-m17n-1.1.0.20090211-5.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-hangul-1.1.0.20090328-2.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-rawcode-1.0.0.20090303-3.fc11.x86_64 (installed)
This type of thing happens from time to time. Lucky for us it isn't a terminal disease. If you desire to update other packages you can always do "yum --skip-broken update". And then chill for a time while the broken issues get resolved.
Given that the upgrade installs a new kernel (2.6.30.8-64 from memory) which doesn't do networking, more than chill is required. I did this to my production laptop, then managed to do it again on a desktop. Since it happened after midnight, I just saved a dmesg for investigation, I assume all networking is dead since the desktop had the same problem.
Manual booting into an older kernel worked on the desktop, the laptop old kernel doesn't like something in the partial upgrade which did take place, so I'm somewhat hung on that one.
????
All is working here just fine after skipping the broken updates. So, I've no idea as to what you've managed to accomplish. But since you've decided to keep all the dmesg output for investigation private I suspect nobody will be able to help you either.
Didn't need help, just a few hours sleep and time to spend an hour looking. dmesg actually just showed one NIC not detected, the one needed for networking, of course. Problem solved.
Bill Davidsen wrote:
Ed Greshko wrote:
Bill Davidsen wrote:
Ed Greshko wrote:
Jonathan Ryshpan wrote:
An attempt to install the latest updates produced the following errors from yumex. Machine is x86_64 with all updates except the latest. jon
Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-chewing-1.2.0.20090818-1.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-m17n-1.1.0.20090211-5.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-hangul-1.1.0.20090328-2.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-rawcode-1.0.0.20090303-3.fc11.x86_64 (installed)
This type of thing happens from time to time. Lucky for us it isn't a terminal disease. If you desire to update other packages you can always do "yum --skip-broken update". And then chill for a time while the broken issues get resolved.
Given that the upgrade installs a new kernel (2.6.30.8-64 from memory) which doesn't do networking, more than chill is required. I did this to my production laptop, then managed to do it again on a desktop. Since it happened after midnight, I just saved a dmesg for investigation, I assume all networking is dead since the desktop had the same problem.
Manual booting into an older kernel worked on the desktop, the laptop old kernel doesn't like something in the partial upgrade which did take place, so I'm somewhat hung on that one.
????
All is working here just fine after skipping the broken updates. So, I've no idea as to what you've managed to accomplish. But since you've decided to keep all the dmesg output for investigation private I suspect nobody will be able to help you either.
Didn't need help, just a few hours sleep and time to spend an hour looking. dmesg actually just showed one NIC not detected, the one needed for networking, of course. Problem solved.
Glad to hear it is working again..... Too bad you've decided not to share what the solution to your problem was. It is usually good form when informing folks of an "issue" (that you seem to be connecting with a given update )what the final solution was so as to help others who may encounter the same issue. We are left to wonder...why the NIC wasn't detected...hardware issue?...and what was done to fix the problem...
Ed Greshko wrote:
Bill Davidsen wrote:
Ed Greshko wrote:
Bill Davidsen wrote:
Ed Greshko wrote:
Jonathan Ryshpan wrote:
An attempt to install the latest updates produced the following errors from yumex. Machine is x86_64 with all updates except the latest. jon
Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-chewing-1.2.0.20090818-1.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-m17n-1.1.0.20090211-5.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-hangul-1.1.0.20090328-2.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-rawcode-1.0.0.20090303-3.fc11.x86_64 (installed)
This type of thing happens from time to time. Lucky for us it isn't a terminal disease. If you desire to update other packages you can always do "yum --skip-broken update". And then chill for a time while the broken issues get resolved.
Given that the upgrade installs a new kernel (2.6.30.8-64 from memory) which doesn't do networking, more than chill is required. I did this to my production laptop, then managed to do it again on a desktop. Since it happened after midnight, I just saved a dmesg for investigation, I assume all networking is dead since the desktop had the same problem.
Manual booting into an older kernel worked on the desktop, the laptop old kernel doesn't like something in the partial upgrade which did take place, so I'm somewhat hung on that one.
????
All is working here just fine after skipping the broken updates. So, I've no idea as to what you've managed to accomplish. But since you've decided to keep all the dmesg output for investigation private I suspect nobody will be able to help you either.
Didn't need help, just a few hours sleep and time to spend an hour looking. dmesg actually just showed one NIC not detected, the one needed for networking, of course. Problem solved.
Glad to hear it is working again..... Too bad you've decided not to share what the solution to your problem was. It is usually good form when informing folks of an "issue" (that you seem to be connecting with a given update )what the final solution was so as to help others who may encounter the same issue. We are left to wonder...why the NIC wasn't detected...hardware issue?...and what was done to fix the problem...
The NIC not detected failed on the newest kernel because the upgrade failed before kmod-wl was upgraded. The previous kernel also didn't see the NIC, not sure why, the dmesg just didn't see it. It could have happened in my attempts to manually get things working again. The kernel before that, 2.6.29-?? saw the NIC and was what I finally used to finish the upgrade. I could have moved the machine to a cable and used the other NIC, that is a supported hardware.
Someone wrote and noted that they lost their console and were using a kmod video driver, that sounds like the same problem. They just booted the old kernel.
If there's a lesson here it's that you should keep a few (more than one) previous kernels in case an upgrade has an issue.
On Wed, Sep 30, 2009 at 3:51 AM, Jonathan Ryshpan jonrysh@pacbell.net wrote:
An attempt to install the latest updates produced the following errors from yumex. Machine is x86_64 with all updates except the latest.
jon
Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-chewing-1.2.0.20090818-1.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-m17n-1.1.0.20090211-5.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-hangul-1.1.0.20090328-2.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-rawcode-1.0.0.20090303-3.fc11.x86_64 (installed)
Now I can't build custom Fedora livecd iso because of this failed dependency :( Is there a workaround using livecd-creator or not? When will the new fixed ibus* packages be available?
Everybody can make a mistake, we are all human, but just be quick to fix it, thanks!
Cheers.
On 09/30/2009 09:53 PM, Valent Turkovic wrote:
On Wed, Sep 30, 2009 at 3:51 AM, Jonathan Ryshpan jonrysh@pacbell.net wrote:
An attempt to install the latest updates produced the following errors from yumex. Machine is x86_64 with all updates except the latest.
jon
Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-chewing-1.2.0.20090818-1.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-m17n-1.1.0.20090211-5.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-hangul-1.1.0.20090328-2.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-rawcode-1.0.0.20090303-3.fc11.x86_64 (installed)
Now I can't build custom Fedora livecd iso because of this failed dependency :( Is there a workaround using livecd-creator or not?
Workaround is to use the previous version, of course.
Rahul
On Wed, Sep 30, 2009 at 6:22 PM, Rahul Sundaram sundaram@fedoraproject.org wrote:
On 09/30/2009 09:53 PM, Valent Turkovic wrote:
On Wed, Sep 30, 2009 at 3:51 AM, Jonathan Ryshpan jonrysh@pacbell.net wrote:
An attempt to install the latest updates produced the following errors from yumex. Machine is x86_64 with all updates except the latest.
jon
Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-chewing-1.2.0.20090818-1.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-m17n-1.1.0.20090211-5.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-hangul-1.1.0.20090328-2.fc11.x86_64 (installed) Missing Dependency: libibus.so.0()(64bit) is needed by package ibus-rawcode-1.0.0.20090303-3.fc11.x86_64 (installed)
Now I can't build custom Fedora livecd iso because of this failed dependency :( Is there a workaround using livecd-creator or not?
Workaround is to use the previous version, of course.
Rahul
I don't know how to instruct livecd-creator to use previous versions, and info would be appreciated.
On 09/30/2009 10:00 PM, Valent Turkovic wrote:
I don't know how to instruct livecd-creator to use previous versions, and info would be appreciated.
livecd-creator uses yum which in turns relies on the repositories. I assume you are using a local repository. Remove the latest version and replace it with the older version. Run createrepo -d on it and livecd-creator will use that repository.
Rahul
-
Bill Davidsen -
Chris Adams -
Christopher A Williams -
Ed Greshko -
Jatin K -
Jonathan Ryshpan -
Michael Schwendt -
Rahul Sundaram -
Rex Dieter -
Tim -
Tom Horsley -
Valent Turkovic