yum / pup die while trying to upgrade libraw1394-1.2.1-8.fc7 on an i386 system that has kernel-xen installed. The yum error is: --> Processing Conflict: libraw1394 conflicts kernel < 2.6.21-1.3194.fc7 Error: No Package Matching kernel.i686 kernel-xen provides kernel = 2.6.20, so this conflicts with libraw1394. I think probably this needs to be changed to: Requires: kernel >= 2.6.21-1.3194.fc7 Here's the traceback from pup: Summary: TB8a9b4f2f packageSack.py:600:returnNewestByNameArch:PackageSackError: No Package Matching kernel.i686 Traceback (most recent call last): File "/usr/sbin/pup", line 409, in _apply self.applyChanges(self.mainwin) File "/usr/lib/python2.5/site-packages/pirut/__init__.py", line 718, in applyChanges self.checkDeps(mainwin) File "/usr/lib/python2.5/site-packages/pirut/__init__.py", line 481, in checkDeps (result, msgs) = self.buildTransaction() File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 549, in buildTransaction (rescode, restring) = self.resolveDeps() File "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 856, in resolveDeps (checkdep, missing, conflict, errormsgs) = self._processConflict(dep) File "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 662, in _processConflict po = self.pkgSack.returnNewestByNameArch((confpkg.name,confpkg.arch))[0] File "/usr/lib/python2.5/site-packages/yum/packageSack.py", line 308, in returnNewestByNameArch return bestofeach.returnNewestByNameArch(naTup) File "/usr/lib/python2.5/site-packages/yum/packageSack.py", line 600, in returnNewestByNameArch raise PackageSackError, 'No Package Matching %s.%s' % naTup PackageSackError: No Package Matching kernel.i686 Local variables in innermost frame: highdict: {} self: <yum.packageSack.ListPackageSack object at 0xcf868ec> naTup: ('kernel', 'i686') where: None
Ah. I was wondering if kernel-xen might be involved, and forgot that it Provides: kernel = 2.6.20-... What I got locally was... [jarod@ares ~]$ sudo yum --enablerepo=updates-testing upgrade libraw1394 Password: Loading "installonlyn" plugin Setting up Upgrade Process livna-development 100% |=========================| 2.1 kB 00:00 primary.sqlite.bz2 100% |=========================| 100 kB 00:00 updates-testing 100% |=========================| 1.9 kB 00:00 primary.sqlite.bz2 100% |=========================| 200 kB 00:00 rt 100% |=========================| 951 B 00:00 fedora 100% |=========================| 2.1 kB 00:00 primary.sqlite.bz2 100% |=========================| 3.8 MB 00:04 updates 100% |=========================| 1.9 kB 00:00 primary.sqlite.bz2 100% |=========================| 361 kB 00:09 Resolving Dependencies --> Running transaction check filelists.sqlite.bz2 100% |=========================| 409 kB 00:00 ---> Package libraw1394.i386 0:1.2.1-8.fc7 set to be updated --> Processing Dependency: libraw1394 = 1.2.1-7.fc7 for package: libraw1394-devel --> Processing Conflict: libraw1394 conflicts kernel < 2.6.21-1.3194.fc7 Error: No Package Matching kernel.i686 [jarod@ares ~]$ rpm -q kernel kernel-2.6.21-1.3142.fc7.i686 kernel-2.6.21-1.3194.fc7.i686 ...which looks correct enough. As for the Conflicts instead of Requires on the kernel version... I just changed from Req to Conflict to circumvent a kernel getting pulled into buildroots that need libraw1394-devel. This is a bit of a sticky situation... I'm pretty sure that kernel-xen doesn't have the needed firewire support, so libraw1394 really *does* conflict with that kernel-xen. If its flipped back to a Requires: with a sufficiently recent enough version, installing libraw1394 is going to pull in kernel > 2.6.21-something, which can't be obtained from a kernel-xen Provides:... So what's the lesser of two evils here: 1) use a Requires:, which is going to mean people who really only wanted kernel-xen are going to have kernel also pulled in, but will be unable to use libraw1394 (also leads to buildroot bloat) 2) use a Conflicts:, which will leave people unable to have both kernel-xen and libraw1394 installed at the same time, but will eliminate buildroot bloat and prevent people from using a non-functional combo. Of course, I'm just *assuming* the new firewire stack never made it into kernel-xen... (I'll check in a sec). So really, we have two different issues here -- straightening out the Requires/Conflicts bit, and the fact that yum died a horrific death in this situation. The latter definitely shouldn't happen, so I'll clone over a new bug against yum. The former... Now that I think about it, I say we just drop both Requires and Conflicts from the libraw1394 package. The F7 GA kernel has the needed support, so anyone with this libraw1394 ought to have a sufficiently new enough kernel anyway. The kernel-xen case... *shrug*
(In reply to comment #1) [...] > --> Processing Conflict: libraw1394 conflicts kernel < 2.6.21-1.3194.fc7 > Error: No Package Matching kernel.i686 > [jarod@ares ~]$ rpm -q kernel > kernel-2.6.21-1.3142.fc7.i686 > kernel-2.6.21-1.3194.fc7.i686 > > ...which looks correct enough. Well, actually, the Error: text could be improved a bit, since its actually the Conflict that is the problem, not that we don't have a matching kernel.i686.
Nope, no firewire in kernel-xen. [jarod@ares boot]$ grep FIREWIRE config-2.6.21-1.3194.fc7 CONFIG_FIREWIRE=m CONFIG_FIREWIRE_OHCI=m CONFIG_FIREWIRE_SBP2=m [jarod@ares boot]$ grep FIREWIRE config-2.6.20-2925.9.fc7xen [jarod@ares boot]$
Not sure if this info is useful, but I saw this today: [root@pika ~]# yum update ... ... ---> Package xorg-x11-server-Xorg.x86_64 0:1.3.0.0-9.fc7 set to be updated ---> Package kernel.x86_64 0:2.6.21-1.3228.fc7 set to be updated ---> Package nas.x86_64 0:1.9-2.fc7 set to be updated ---> Package gtk2.i386 0:2.10.12-2.fc7 set to be updated ---> Package xdg-user-dirs.x86_64 0:0.8-3.fc7 set to be updated ---> Package gdb.x86_64 0:6.6-15.fc7 set to be updated ---> Package openoffice.org-impress.x86_64 1:2.2.0-14.11 set to be updated --> Processing Conflict: libraw1394 conflicts kernel < 2.6.21-1.3194.fc7 Error: No Package Matching kernel.x86_64 Since I don't use IEEE-1394, I tried: yum --exclude=libraw1394 update and it worked. Retried it again with the new kernel, and it failed again: [root@pika ~]# yum update Loading "installonlyn" plugin Setting up Update Process fedora 100% |=========================| 2.1 kB 00:00 updates 100% |=========================| 1.9 kB 00:00 Resolving Dependencies --> Running transaction check ---> Package libraw1394.i386 0:1.2.1-8.fc7 set to be updated ---> Package libraw1394.x86_64 0:1.2.1-8.fc7 set to be updated --> Processing Conflict: libraw1394 conflicts kernel < 2.6.21-1.3194.fc7 --> Finished Dependency Resolution My kernel info: [root@pika ~]# rpm -q kernel kernel-2.6.21-1.3194.fc7 kernel-2.6.21-1.3228.fc7 [root@pika ~]# uname -a Linux pika.xxxxxx.xxx 2.6.21-1.3194.fc7 #1 SMP Wed May 23 22:47:07 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
This issue is also preventing me from doing an FC6 to F7 yum upgrade: $ sudo yum upgrade ... --> Running transaction check --> Processing Conflict: libraw1394 conflicts kernel < 2.6.21-1.3194.fc7 --> Finished Dependency Resolution Error: libraw1394 conflicts with kernel < 2.6.21-1.3194.fc7 I tried several ways of getting around this (messing with excludes, pre-installing that rpm using --nodeps, etc.), and nothing has worked.
Yeah, I'm just going to push a new libraw1394 on Monday w/o either Requires: or Conflicts: on the kernel included. The F7 GA kernel is sufficiently new enough, so any sane setup should be fine without that. The only snag is the kernel-xen case, where firewire support isn't enabled.
*** Bug 244562 has been marked as a duplicate of this bug. ***
*** Bug 244573 has been marked as a duplicate of this bug. ***
*** Bug 244537 has been marked as a duplicate of this bug. ***
*** Bug 244584 has been marked as a duplicate of this bug. ***
*** Bug 244589 has been marked as a duplicate of this bug. ***
*** Bug 244624 has been marked as a duplicate of this bug. ***
*** Bug 244648 has been marked as a duplicate of this bug. ***
There's a third option, too -- make libraw1394 able to work with either the old or the new stack so that it doesn't matter what kernel you're running on. Realistically, both the requires and the conflicts don't accomplish much as the fact that the kernel is installed doesn't mean that's what the user is running -- they could have compiled their own kernel, etc. So you have to cope with it _anyway_
libraw1394-1.2.1-9.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 244703 has been marked as a duplicate of this bug. ***
*** Bug 244714 has been marked as a duplicate of this bug. ***