--> Processing Dependency: libcmis-0.4.so.4 for package: 1:libreoffice-core-4.2.1.1-1.fc20.i686 --> Finished Dependency Resolution Error: Package: 1:libreoffice-core-4.2.1.1-1.fc20.i686 (updates-testing) Requires: libcmis-0.4.so.4 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest ;---- yum clean all yum update
libcmis-0.4.1-2.fc20,mdds-0.10.2-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/libcmis-0.4.1-2.fc20,mdds-0.10.2-1.fc20
*** Bug 1068958 has been marked as a duplicate of this bug. ***
*** Bug 1068966 has been marked as a duplicate of this bug. ***
Can I inquire as to how the release / update process allows package updates to enter the repositories without *all* of their dependencies being present? I've lost track of how many times yum has told me 'You could try using --skip-broken to work around the problem'. Is it a race condition somewhere in the repository mirroring process? This happens *way* too often!
(In reply to M. Edward (Ed) Borasky from comment #4) > Can I inquire as to how the release / update process allows package updates > to enter the repositories without *all* of their dependencies being present? > I've lost track of how many times yum has told me 'You could try using > --skip-broken to work around the problem'. Is it a race condition somewhere > in the repository mirroring process? This happens *way* too often! Yes. The current situation is really not acceptable. There needs to be a mechanism put into place to prevent this situation from occurring.
I did not mean to clear the needinfo flag here.
(In reply to M. Edward (Ed) Borasky from comment #4) > Can I inquire as to how the release / update process allows package updates > to enter the repositories without *all* of their dependencies being present? > I've lost track of how many times yum has told me 'You could try using > --skip-broken to work around the problem'. Is it a race condition somewhere > in the repository mirroring process? This happens *way* too often! It it a side effect of how building of dependent packages works. To do that, I need to build all the depending packages (libcmis and mdds in this case), then request buildroot overrides for them (which basically makes them available in updates-testing) and build the dependent package(s) (libreoffice). Then I need to take care to include _all_ of them in the update. Which I forgot to do. So, while the buildroot overrides are active, all the packages are available in updates-testing and there is no problem. But after they expire, the packages that are not part of the update are lost, resulting in broken dependencies. In this case, it has been made even worse when the update was pushed to stable just after the expiration...
Appreciate the explanation, but still should be something in place to prevent this from occurring.
(In reply to Bill Gianopoulos from comment #5) > (In reply to M. Edward (Ed) Borasky from comment #4) > > Can I inquire as to how the release / update process allows package updates > > to enter the repositories without *all* of their dependencies being present? > > I've lost track of how many times yum has told me 'You could try using > > --skip-broken to work around the problem'. Is it a race condition somewhere > > in the repository mirroring process? This happens *way* too often! > > Yes. The current situation is really not acceptable. There needs to be a > mechanism put into place to prevent this situation from occurring. I suppose the only reliable solution is to avoid multi-package updates. Which works for me: after this experience, the next request to rebase libreoffice in released Fedora is very likely to be closed WONTFIX, with a comment "Just install Rawhide."
i.e. the push to stable should have failed.
This is an issue we have all the time and not just related to Libreoffice. Had the same issue with the last kernel upgrade because dependent packages were only available on 32-bit and no 64-bit packages. Also this is not pointed at Libreoffice just second time in a week type issue.
(In reply to David Tardon from comment #7) > (In reply to M. Edward (Ed) Borasky from comment #4) > > Can I inquire as to how the release / update process allows package updates > > to enter the repositories without *all* of their dependencies being present? > > I've lost track of how many times yum has told me 'You could try using > > --skip-broken to work around the problem'. Is it a race condition somewhere > > in the repository mirroring process? This happens *way* too often! > > It it a side effect of how building of dependent packages works. To do that, > I need to build all the depending packages (libcmis and mdds in this case), > then request buildroot overrides for them (which basically makes them > available in updates-testing) and build the dependent package(s) > (libreoffice). Then I need to take care to include _all_ of them in the > update. Which I forgot to do. So, while the buildroot overrides are active, > all the packages are available in updates-testing and there is no problem. > But after they expire, the packages that are not part of the update are > lost, resulting in broken dependencies. In this case, it has been made even > worse when the update was pushed to stable just after the expiration... Seems like there should be something in the infrastructure to gate package entry to updates on presence of dependencies in updates. After all, yum can figure out something is missing. Is there an open bug on this specific issue - packages entering 'updates' before all their dependencies do - rather than having to file a new bug each time yum comes up with a missing dependency?
(In reply to David Tardon from comment #9) > Which works for me: after this experience, the next request to rebase > libreoffice in released Fedora is very likely to be closed WONTFIX, with a > comment "Just install Rawhide." Could be possible test again before update to stable,after expiration, most used packages? Wait for Fed21 (5 months) to have LibreOffice 4.2 could be not a nice choice.
I should point out here that libreoffice got caught up in a second time this week type issue. Less than a week ago, the 3.13 kernel update (which could not be blamed one anyone other than fedora) had the same issue. 3.13 kernel was posted but only worked on 32-bit systems because 64-bit dependencies had not yet been released.
Buildroot overrides are NOT automatically available in updates-testing. (They need to be pushed like any other update, preferably in one group with the dependent package(s).) The testers simply installed them manually from Koji.
(In reply to Kevin Kofler from comment #15) > Buildroot overrides are NOT automatically available in updates-testing. > (They need to be pushed like any other update, preferably in one group with > the dependent package(s).) The testers simply installed them manually from > Koji. Can't some automatic process stop a package from going init "updates" before all of its dependencies are there?
I downloaded the rpm indicated in comment 1. When I tried to install it with yum, then new libreoffice rpms were also required. As I already had these on hand, I added them, and the install proceeded, well not quite. Duing the update, I got error messages indicating a problem with libreoffice-core. I conjecture that this particular rpm was truncated, and I was unaware of this fact when I started the update. As a result, all of libreoffice except libreoffice-core was updated. When I tried to run libreoffice, it crashed, producing a ABRT. I tried to report that, but after a couple of hours downloading a gig of debuginfo's, I got a message saying my backtrace was unusable. I solved my problem by simply using yumdownloader to complete my libreoffice-core rpm and updating libreoffice-core, which updated by itself. Conclusions: 1) When attempting to update a set of packages in which the versions must stay in phase, updating must be blocked if all packages cannont be updated simultaneously. If a problem still occurs during the update, the update should backtrack to the previous version. Thus, the software being updated would not be at risk of becoming usable. 2) Probable usability of backtraces should be established early in the bug reporting process. If average users are subjected to the frustrations I experienced, they may well be unwilling to participate in the bug reporting process. In this case, the cause of the abot was known, but would have been difficult to diagnose because of the unusable backtrace.
(In reply to Peter H. Jones from comment #17) > 2) Probable usability of backtraces should be established early in the bug > reporting process. If average users are subjected to the frustrations I > experienced, they may well be unwilling to participate in the bug reporting > process. In this case, the cause of the abot was known, but would have been > difficult to diagnose because of the unusable backtrace. I totally avoid using abrt / libreport or hows it called. I simply don't trust it. I don't trust what data it collects from my running system with critical personal data on it. Years ago I caught backtraces with "gdb bt full" or simply dumped logs with its abort messages. But these days your /var/ folder is being filled up with hundrets of megabytes of all kind of coredumps that I really don't pay attention for anymore. Earlier abrt from Fedora was kind of easy. You got shown the coredump and then decide whether you cut&paste that information. Nowadays abrt hides all that information from me, making it difficult for me to decide whether I want to sent that bugreport or not. 99% of the time I simply ignore the reports and hope someone else does it for me.
(In reply to Peter H. Jones from comment #17) > Conclusions: > > 1) When attempting to update a set of packages in which the versions must > stay in phase, updating must be blocked if all packages cannont be updated > simultaneously. If a problem still occurs during the update, the update > should backtrack to the previous version. Thus, the software being updated > would not be at risk of becoming usable. > > 2) Probable usability of backtraces should be established early in the bug > reporting process. If average users are subjected to the frustrations I > experienced, they may well be unwilling to participate in the bug reporting > process. In this case, the cause of the abot was known, but would have been > difficult to diagnose because of the unusable backtrace. I had these issues also a number of times. While an automatic dependency system for updates / testing repos is indeed desirable, it is a complex thing to implement and IMHO I would not want to be responsible. Considering the number of packages and a seemingly endless number of dependency iterations I would say the sytem works quite well. Even the package maintainers like David seem to be human after all ;). In this case I'd say yum did a its job; it crashes and does nothing by default. Using '--skip-broken' will circumvent the dep problem and keep LibreOffice working. If you need the newest build, 'yum update yum update libcmis --enablerepo=updates-testing' will work tomorrow lastest and after that libreoffice should update fine again.
*** Bug 1069160 has been marked as a duplicate of this bug. ***
libcmis-0.4.1-2.fc20, mdds-0.10.2-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
This is really bad. Like many other here, IMHO the failure here the lake of a proper automated test system for dependencies when a human try to push a package. This obviously means for people like me considering a possibility to contribute packages to the fedora project, that it wouls be way harder than I would first imagine has the weight on my shoulders is way bigger as one would expect. How far does this system goes in term of not checking human errors ? Meaning how good must I be before being able to contribute ? Please fix it the proper way : improve automated testing. Stop the most as you can the blame on people for mistakes that would certainly happen again and again.
--> Finished Dependency Resolution Error: Package: 1:libreoffice-core-4.2.1.1-1.fc20.x86_64 (updates) Requires: libcmis-0.4.so.4()(64bit) You could try using --skip-broken to work around the problem ** Found 2 pre-existing rpmdb problem(s), 'yum check' output follows: audit-2.3.2-1.fc20.x86_64 has missing requires of audit-libs = ('0', '2.3.2', '1.fc20') audit-2.3.3-1.fc20.x86_64 is a duplicate with audit-2.3.2-1.fc20.x86_64
(In reply to Fedora Update System from comment #21) > libcmis-0.4.1-2.fc20, mdds-0.10.2-1.fc20 has been pushed to the Fedora 20 > stable repository. If problems still persist, please make note of it in > this bug report. It's working now on my system. But I still want to either file a bug or start a discussion on some mailing list about why there isn't an automatic gate that kepps packages out of 'updates' until all their dependencies are in 'fedora' or 'updates'. Which mailing list would that be? This seems like a good time to do this, since F21's schedule isn't firmed up yet and there's talk of replacing 'yum' with another package manager. As long as we're 'refactoring' package management, we might as well close this annoying loophole in the process.
(In reply to Robin Hack from comment #23) > --> Finished Dependency Resolution > Error: Package: 1:libreoffice-core-4.2.1.1-1.fc20.x86_64 (updates) > Requires: libcmis-0.4.so.4()(64bit) > You could try using --skip-broken to work around the problem > ** Found 2 pre-existing rpmdb problem(s), 'yum check' output follows: > audit-2.3.2-1.fc20.x86_64 has missing requires of audit-libs = ('0', > '2.3.2', '1.fc20') > audit-2.3.3-1.fc20.x86_64 is a duplicate with audit-2.3.2-1.fc20.x86_64 Maybe try package-cleanup --cleandupes --noscripts
*** Bug 1069325 has been marked as a duplicate of this bug. ***
$ sudo yum clean all; yum update <snip> --> Finished Dependency Resolution Error: Package: 1:libreoffice-core-4.2.1.1-1.fc20.x86_64 (updates) Requires: libcmis-0.4.so.4()(64bit) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest $ sudo yum update --skip-broken <snip> Packages skipped because of dependency problems: firebird-libfbembed-2.5.2.26539.0-8.fc20.x86_64 from fedora libabw-0.0.2-1.fc20.x86_64 from updates libe-book-0.0.3-1.fc20.x86_64 from updates libeot-0.01-1.fc20.x86_64 from updates libetonyek-0.0.3-1.fc20.x86_64 from updates libfreehand-0.0.0-3.fc20.x86_64 from fedora 1:libreoffice-calc-4.2.1.1-1.fc20.x86_64 from updates 1:libreoffice-core-4.2.1.1-1.fc20.x86_64 from updates 1:libreoffice-draw-4.2.1.1-1.fc20.x86_64 from updates 1:libreoffice-emailmerge-4.2.1.1-1.fc20.x86_64 from updates 1:libreoffice-graphicfilter-4.2.1.1-1.fc20.x86_64 from updates 1:libreoffice-impress-4.2.1.1-1.fc20.x86_64 from updates 1:libreoffice-kde-4.2.1.1-1.fc20.x86_64 from updates 1:libreoffice-langpack-en-4.2.1.1-1.fc20.x86_64 from updates 1:libreoffice-math-4.2.1.1-1.fc20.x86_64 from updates 1:libreoffice-opensymbol-fonts-4.2.1.1-1.fc20.noarch from updates 1:libreoffice-pdfimport-4.2.1.1-1.fc20.x86_64 from updates 1:libreoffice-pyuno-4.2.1.1-1.fc20.x86_64 from updates 1:libreoffice-ure-4.2.1.1-1.fc20.x86_64 from updates 1:libreoffice-writer-4.2.1.1-1.fc20.x86_64 from updates
(In reply to Paul Lipps from comment #27) > $ sudo yum clean all; yum update > > <snip> > > --> Finished Dependency Resolution > Error: Package: 1:libreoffice-core-4.2.1.1-1.fc20.x86_64 (updates) > Requires: libcmis-0.4.so.4()(64bit) It may take some more hours that your mirror is updated, too. I just updated successfully and libreoffice 4.2 is running.
(In reply to markusN from comment #28) > (In reply to Paul Lipps from comment #27) > > $ sudo yum clean all; yum update > > > > <snip> > > > > --> Finished Dependency Resolution > > Error: Package: 1:libreoffice-core-4.2.1.1-1.fc20.x86_64 (updates) > > Requires: libcmis-0.4.so.4()(64bit) > > It may take some more hours that your mirror is updated, too. > I just updated successfully and libreoffice 4.2 is running. It works. Thank you.