Description of problem: Opps, sealert hit an error! Traceback (most recent call last): File "/usr/bin/sealert", line 692, in <module> run_as_dbus_service(username) File "/usr/bin/sealert", line 112, in run_as_dbus_service app = SEAlert(user, dbus_service.presentation_manager, watch_setroubleshootd=True) File "/usr/bin/sealert", line 326, in __init__ from setroubleshoot.browser import BrowserApplet File "/usr/lib/python2.7/site-packages/setroubleshoot/browser.py", line 46, in <module> import report.io.GTKIO ImportError: No module named GTKIO Version-Release number of selected component (if applicable): Name : setroubleshoot Arch : i686 Version : 3.0.35 Release : 1.fc15 How reproducible: always Steps to Reproduce: 1.run setroubleshoot
Please solve this. i have same trouble and same case.
What version of report are you seeing this with? rpm -q report-gtk
[maxx@siamese ~]$ rpm -q report-gtk package report-gtk is not installed I think it has been renamed libreport-gtk, right? [maxx@siamese ~]$ rpm -q libreport-gtk libreport-gtk-2.0.3-1.fc15.i686
yum install report-gtk
I still have report-gtk on F16 I guess libreport-gtk should not have replaced report-gtk or have included all of the python code.
I think the problem is not on the report-gtk, ie on setroubleshoot that can not be adjusted turnover dependencies of the report-gtk to libreport-gtk. so I will change this bug to setroubleshoot components.
This is not an setroubleshoot bug. If a package setroubleshoot and anaconda depends on is updated, the updated package must provide support for the old way of doing things. If libreport-gtk is replacing report-gtk, it should have a provides report-gtk to satisfy setroubleshoot requires. But this is not the problem, the problem is the python packages are gone. import report.io.GTKIO No longer exists, python Python 2.7.1 (r271:86832, Apr 12 2011, 16:15:16) [GCC 4.6.0 20110331 (Red Hat 4.6.0-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import report.io.GTKIO Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: No module named GTKIO Meaning an API has changed in a report update, which is unacceptable. Report people wrote the code within setroubleshoot to implement this, they should not remove it mid stream. If you want to remove this and change the API, you should wait until F16.
I see this too - cf. https://bugzilla.redhat.com/show_bug.cgi?id=716578
BTW yum won't allow fix in https://bugzilla.redhat.com/show_bug.cgi?id=715373#c4 [root@moby ~]# yum install report-gtk Loaded plugins: aliases, auto-update-debuginfo, changelog, downloadonly, fastestmirror, : filter-data, keys, langpacks, list-data, presto, ps, refresh-packagekit, : refresh-updatesd, remove-with-leaves, rpm-warm-cache, show-leaves, tmprepo, : upgrade-helper, verify Loading mirror speeds from cached hostfile * fedora: linux.mirrors.es.net * rpmfusion-free: mirrors.cat.pdx.edu * rpmfusion-free-updates: mirrors.cat.pdx.edu * rpmfusion-nonfree: mirrors.cat.pdx.edu * rpmfusion-nonfree-updates: mirrors.cat.pdx.edu * updates: linux.mirrors.es.net Skipping filters plugin, no data Setting up Install Process Nothing to do
*** Bug 716578 has been marked as a duplicate of this bug. ***
*** Bug 716608 has been marked as a duplicate of this bug. ***
I can confirm that the workaround from Bug 716608, i.e. removing the line (48): import report.io.GTKIO from /usr/lib64/python2.7/site-packages/setroubleshoot/browser.py works. I also notice that this AM there are new libreport{,-gtk} rpms which, by themselves don't solve the problem (i.e. sealert still throws an error until report.py stops looking for the non-existent file.
(In reply to comment #14) > I can confirm that the workaround from Bug 716608, i.e. removing the line (48): > > import report.io.GTKIO > > from /usr/lib64/python2.7/site-packages/setroubleshoot/browser.py works. I also > notice that this AM there are new libreport{,-gtk} rpms which, by themselves > don't solve the problem (i.e. sealert still throws an error until report.py > stops looking for the non-existent file. Me too, though the i386 version in /usr/lib/python2.7/site-packages/setroubleshoot/browser.py...
Removing this will allow the app to start, but later on in the code it uses the reportio for reporting a bug to bugzilla. def submit(self): text_buf = self.error_submit_text.get_buffer() content = text_buf.get_text(text_buf.get_start_iter(), text_buf.get_end_iter()) signature = report.createAlertSignature("selinux-policy", "setroubleshoot", self.alert.get_hash(), self.summary, content) try: rc = report.report(signature, report.io.GTKIO.GTKIO(self.parent.accounts)) except ProtocolError, e: FailDialog(e) self.destroy(self.main_window)
*** Bug 716626 has been marked as a duplicate of this bug. ***
*** Bug 716646 has been marked as a duplicate of this bug. ***
How come libreport did not remove the report package in Rawhide?
*** Bug 716633 has been marked as a duplicate of this bug. ***
How come the report package is still in Rawhide? If this functionality is implemented in some other way, then we need to be told. The report.io.GTKIO is also used in python-meh.
(In reply to comment #16) > Removing this will allow the app to start, but later on in the code it uses the > reportio for reporting a bug to bugzilla. > True I suppose, but at least if the app will run you can use audit2allow - and I needed that.
(In reply to comment #21) > How come the report package is still in Rawhide? If this functionality is > implemented in some other way, then we need to be told. The report.io.GTKIO is > also used in python-meh. I forgot to remove Provides/Obsoletes: report-gtk from libreport in F15.
(In reply to comment #23) > > I forgot to remove Provides/Obsoletes: report-gtk from libreport in F15. But can we still use it as a workaround in F16\Rawhide, until the princciple problem solved?
*** Bug 716801 has been marked as a duplicate of this bug. ***
Yes you can use the workaround, you will not be able to report bugs, but everything else should work.
libreport-2.0.4-2.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/libreport-2.0.4-2.fc15
(In reply to comment #24) > (In reply to comment #23) > > > > > I forgot to remove Provides/Obsoletes: report-gtk from libreport in F15. > > > > But can we still use it as a workaround in F16\Rawhide, > until the princciple problem solved? you can also remove libreport-2.0.4-1 or install the updated one 2.0.4-2 which I just submitted to for testing and then install report-gtk back.
Isn't this a yum related bug too because removed report-gtk which is still required by other packages without any errormessage
(In reply to comment #29) > Isn't this a yum related bug too because removed report-gtk which is still > required by other packages without any errormessage not sure if you mean the same bug, but even when I removed the forgotten provides/obsolete yum still finds the old version which has the wrong provides and then it finds the newer version and uses it in the transaction, but the new version doesn't have the provides/obsoletes, so report-gtk is not installed even with the fixed package in repo - so either yum needs to be fixed or the previous libreport should be removed from repository.
What I wanted to say that it seems to be a bug in yum that yum removes a package because one(!) says its obsolete but several other installed packages still require this package. In my opinion yum should handle this scenario like a missing dependecy and say something like "sorry, but this package is still required by other packaged"
I am unable to use the work around in Comment 28 on F15. I was able to downgrade to libreport-2.0.3-1.fc15.x86_64. However I got "Nothing to do" when trying to install report-gtk. I got this when I tried to reinstall report-gtk: Installed package libreport-gtk-2.0.3-1.fc15.x86_64 (from /libreport-gtk-2.0.3-1.fc15.x86_64) not available. Nothing to do Is there any way to get sealert working again in F15? Thanks, Gene
(In reply to comment #32) > I am unable to use the work around in Comment 28 on F15. I was able to > downgrade to libreport-2.0.3-1.fc15.x86_64. However I got "Nothing to do" when > trying to install report-gtk. I got this when I tried to reinstall report-gtk: > > Installed package libreport-gtk-2.0.3-1.fc15.x86_64 (from > /libreport-gtk-2.0.3-1.fc15.x86_64) not available. > Nothing to do > > Is there any way to get sealert working again in F15? > > Thanks, > Gene See http://pavelmialko.livejournal.com/616.html from bug report link in comment 14.
That only cures half the problem, but at least sealert will start. Modifying the procedure in Comment 28 to the following completely fixes the problem. 1. sudo yum erase libreport* 2. sudo yum install report-gtk 3. sudo yum --nogpgcheck install ./libreport*-2.0.4-2.fc15.x86_64 (after downloading the libreport packages you erased in step 1. from koji) 4. sudo yum install <all the dependent packages erased in step 1.> Just an FYI, the list of deps in step 1. is abrt*, firstboot, python-meh, and setroubleshoot. Also, I tried installing report-gtk with libreport*-2.0.3-1.fc15.x86_64.rpm installed and got the same "Nothing to do" message when trying to install report-gtk. Apparently, libreport broke sealert on day one. :) Gene
Package libreport-2.0.4-2.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libreport-2.0.4-2.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/libreport-2.0.4-2.fc15 then log in and leave karma (feedback).
In response to comment 34, trying to remove libreport* tries to do this (which I cancel): Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Removing: libreport x86_64 2.0.4-1.fc15 @updates 362 k libreport-gtk x86_64 2.0.4-1.fc15 @updates 97 k Removing for dependencies: abrt x86_64 2.0.3-1.fc15 @updates 534 k abrt-addon-ccpp x86_64 2.0.3-1.fc15 @updates 118 k abrt-addon-kerneloops x86_64 2.0.3-1.fc15 @updates 44 k abrt-addon-python x86_64 2.0.3-1.fc15 @updates 16 k abrt-desktop x86_64 2.0.3-1.fc15 @updates 0.0 abrt-gui x86_64 2.0.3-1.fc15 @updates 213 k abrt-plugin-bugzilla x86_64 2.0.3-1.fc15 @updates 37 k abrt-plugin-logger x86_64 2.0.3-1.fc15 @updates 8.5 k anaconda x86_64 15.31-1.fc15 @koji-override-1/$releasever 13 M firstboot x86_64 1.119-1.fc15 @koji-override-0/$releasever 736 k python-meh noarch 0.11-2.fc15 @koji-override-0/$releasever 173 k setroubleshoot x86_64 3.0.35-1.fc15 @updates 278 k Transaction Summary ================================================================================ Remove 14 Package(s) Installed size: 16 M Is this ok [y/N]: Exiting on user Command
Following Comment 35 https://bugzilla.redhat.com/show_bug.cgi?id=715373#c35 I get this on 64 bit F15 - what is the right way to proceed? Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package libreport.x86_64 0:2.0.4-1.fc15 will be updated --> Processing Dependency: libreport = 2.0.4-1.fc15 for package: libreport-gtk-2.0.4-1.fc15.x86_64 ---> Package libreport.x86_64 0:2.0.4-2.fc15 will be an update --> Running transaction check ---> Package libreport-gtk.x86_64 0:2.0.4-1.fc15 will be updated --> Processing Dependency: report-gtk for package: setroubleshoot-3.0.35-1.fc15.x86_64 --> Processing Dependency: report-gtk for package: python-meh-0.11-2.fc15.noarch ---> Package libreport-gtk.x86_64 0:2.0.4-2.fc15 will be an update --> Running transaction check ---> Package libreport-gtk.i686 0:2.0.4-1.fc15 will be installed --> Processing Dependency: libreport = 2.0.4-1.fc15 for package: libreport-gtk-2.0.4-1.fc15.i686 --> Processing Dependency: libreport.so.0 for package: libreport-gtk-2.0.4-1.fc15.i686 --> Processing Dependency: libgnome-keyring.so.0 for package: libreport-gtk-2.0.4-1.fc15.i686 ---> Package libreport-gtk.x86_64 0:2.0.4-1.fc15 will be updated ---> Package setroubleshoot.x86_64 0:3.0.35-1.fc15 will be updated ---> Package setroubleshoot.x86_64 0:3.0.37-1.fc15 will be an update --> Processing Dependency: setroubleshoot-server = 3.0.37-1.fc15 for package: setroubleshoot-3.0.37-1.fc15.x86_64 --> Running transaction check ---> Package libgnome-keyring.i686 0:3.0.3-1.fc15 will be installed ---> Package libreport.i686 0:2.0.4-1.fc15 will be installed ---> Package libreport.x86_64 0:2.0.4-1.fc15 will be updated ---> Package libreport.x86_64 0:2.0.4-1.fc15 will be updated ---> Package setroubleshoot-server.x86_64 0:3.0.35-1.fc15 will be updated ---> Package setroubleshoot-server.x86_64 0:3.0.37-1.fc15 will be an update --> Finished Dependency Resolution Error: Protected multilib versions: libreport-gtk-2.0.4-2.fc15.x86_64 != libreport-gtk-2.0.4-1.fc15.i686 Error: Protected multilib versions: libreport-2.0.4-1.fc15.i686 != libreport-2.0.4-2.fc15.x86_64 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest
To be clear - on my current F15 system I do not have a 32 bit libreport - yum list installed | egrep libreport libreport.x86_64 2.0.4-1.fc15 @updates libreport-gtk.x86_64 2.0.4-1.fc15 @updates So why does the update need one now ?
If your system isn't supposed to have ANY 32-bit packages, you can just use the yum option "--exclude=\*.i686". If it's supposed to have some, you'd have to be more selective with the exclude. My system doesn't have any 32-bit packages, and after doing yum --skip-broken update --exclude=\*.i686 a subsequent yum --skip-broken update said there were no updates available.
Seems that the removing of Provides: report-gtk somehow causes yum to pull i686 packages. I added Provides: report-gtk and built the rpm locally, and then it didn't pull these i686 packages. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
yum -v gives a bit more info on how the i686 packages got there: Not loading "blacklist" plugin, as it is disabled Loading "langpacks" plugin Loading "presto" plugin Loading "refresh-packagekit" plugin Not loading "whiteout" plugin, as it is disabled Adding he_IL to language list Config time: 0.021 Yum Version: 3.2.29 Setting up Package Sacks pkgsack time: 0.373 rpmdb time: 0.000 Setting up Update Process Building updates object up:Obs Init time: 0.276 up:simple updates time: 0.036 up:obs time: 0.006 up:condense time: 0.000 updates time: 0.702 Not Updating Package that is already updated: libreport.x86_64 0:2.0.4-1.fc15 Not Updating Package that is already updated: libreport.x86_64 0:2.0.4-1.fc15 Not Updating Package that is already updated: libreport.x86_64 0:2.0.4-1.fc15 Resolving Dependencies --> Running transaction check ---> Package libreport.x86_64 0:2.0.4-1.fc15 will be updated Checking deps for libreport.x86_64 0:2.0.4-1.fc15 - ud libreport-gtk-2.0.4-1.fc15.x86_64 requires: libreport = 2.0.4-1.fc15 --> Processing Dependency: libreport = 2.0.4-1.fc15 for package: libreport-gtk-2.0.4-1.fc15.x86_64 Potential Provider: libreport.x86_64 0:2.0.4-1.fc15 Mode is ud for provider of libreport = 2.0.4-1.fc15: libreport.x86_64 0:2.0.4-1.fc15 Mode for pkg providing libreport = 2.0.4-1.fc15: ud Trying to update libreport-gtk-2.0.4-1.fc15.x86_64 to resolve dep ---> Package libreport.x86_64 0:2.0.4-2.fc15 will be an update Checking deps for libreport.x86_64 0:2.0.4-2.fc15 - u looking for ('config(libreport)', 'EQ', ('0', '2.0.4', '2.fc15')) as a requirement of libreport.x86_64 0:2.0.4-2.fc15 - u --> Running transaction check ---> Package libreport-gtk.x86_64 0:2.0.4-1.fc15 will be updated Checking deps for libreport-gtk.x86_64 0:2.0.4-1.fc15 - ud setroubleshoot-3.0.37-1.fc15.x86_64 requires: report-gtk --> Processing Dependency: report-gtk for package: setroubleshoot-3.0.37-1.fc15.x86_64 Needed Require is not a package name. Looking up: report-gtk Potential Provider: libreport-gtk.x86_64 0:2.0.4-1.fc15 Mode is ud for provider of report-gtk: libreport-gtk.x86_64 0:2.0.4-1.fc15 Mode for pkg providing report-gtk: ud No update paths found for setroubleshoot-3.0.37-1.fc15.x86_64. Failure! Searching pkgSack for dep: report-gtk libreport-gtk-2.0.4-1.fc15.x86_64 is in providing packages but it is already installed, removing. TSINFO: Marking libreport-gtk-2.0.4-1.fc15.i686 as install for setroubleshoot-3. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
In other words, yum can't see report-gtk, I don't know why, so it looks in the repo and sees that the older version of libreport-gtk provides it. But it's already installed and the updated version doesn't provide it, so it simply tries to install the older version's i686 package, and then fails because of multilib version mismatch. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
*** Bug 716734 has been marked as a duplicate of this bug. ***
(In reply to comment #37) > Following Comment 35 https://bugzilla.redhat.com/show_bug.cgi?id=715373#c35 I > get this on 64 bit F15 - what is the right way to proceed? > > Setting up Update Process > Resolving Dependencies > --> Running transaction check > ---> Package libreport.x86_64 0:2.0.4-1.fc15 will be updated > --> Processing Dependency: libreport = 2.0.4-1.fc15 for package: > libreport-gtk-2.0.4-1.fc15.x86_64 > ... > Error: Protected multilib versions: libreport-gtk-2.0.4-2.fc15.x86_64 != > libreport-gtk-2.0.4-1.fc15.i686 > Error: Protected multilib versions: libreport-2.0.4-1.fc15.i686 != > libreport-2.0.4-2.fc15.x86_64 > ... Here's what worked for me: rpm -e --nodeps libreport libreport-gtk yum install --enablerepo=updates-testing libreport libreport-gtk yum install --enablerepo=updates-testing report-gtk Here's why: One must use rpm --nodeps, since yum insists on checking dependencies and can't know that you're going to immediately, but separately, re-install a newer version and resore the provision of the dependencies. That way, when you get to installing libreport & libreport-gtk, yum doesn't see the bogus provides in the current, broken x86_64 libreport & libreport-gtk and try to compensate by pulling in spurious current, broken i868 versions of libreport & libreport-gtk. Finally, yum will have complained about broken dependencies, i.e. report-gtk, so you need to reinstall report-gtk, but unless you --enablerepo=updates-testing when you install report-gtk, yum's dependency checker will get fooled again by the bogus provides in the current, broken x86_64 libreport & libreport-gtk, since it can't seem to see ignore the provides in the current, broken libreport & libreport-gtk without being able to look at the updates-testing repo. NB The putative "fix" in Comment 40 simply recreates the broken-ness in the updated libreport & libreport-gtk, and almost surely will keep yum from re-installing report-gtk. IMHO, Heiko Adams got it right in Comment 29 and Comment 31. This is an error of intent bug in yum, since yum gets totally bolloxed by the erroneous "Provides/Obsoletes: report-gtk" in the current, broken libreport. It makes my brain hurt trying to think how the current bug can be fixed with an update via yum without issuing updates for the long list of perfectly correct packages that depend on report-gtk. Sigh.
(In reply to comment #44) > Here's what worked for me: > > rpm -e --nodeps libreport libreport-gtk > yum install --enablerepo=updates-testing libreport libreport-gtk > yum install --enablerepo=updates-testing report-gtk Worked for me too, thanks.
Never use --nodeps, yum will complaiun when you do (for good reason). "yum shell" will let you do multiple commands at once.
@James, if you say "never use --nodeps", how do you propose to fix the above? It seems to me that using "rpm -e --nodeps" to remove specific packages and then re-install them from updates-testing is pretty safe.
In reply to Comment 36: Go ahead and erase the 14 packages. Then after getting libreport-gtk and report-gtk squared away, just reinstall the extra 12 dependent packages that were deleted. The procedure in Comment 34 is guaranteed to not break yum. In response to the possibility that there is a yum bug: According to the package info for setroubleshoot and setroubleshoot-server, sealert is part of the setroubleshoot-server package. However, erasing report-gtk does NOT erase setroubleshoot-server. $ sudo yum erase report-gtk ... Removing: report-gtk x86_64 0.20-2.fc15 @fedora 19 k Removing for dependencies: firstboot x86_64 1.119-1.fc15 @fedora 736 k python-meh noarch 0.11-2.fc15 @fedora 173 k setroubleshoot x86_64 3.0.37-1.fc15 @updates-testing 224 k Transaction Summary Is there a missing dependency/requires in setroubleshoot-server? Gene
*** Bug 717536 has been marked as a duplicate of this bug. ***
*** Bug 717547 has been marked as a duplicate of this bug. ***
*** Bug 715212 has been marked as a duplicate of this bug. ***
*** Bug 714147 has been marked as a duplicate of this bug. ***
*** Bug 717277 has been marked as a duplicate of this bug. ***
To everyone on Cc, there's some background in bug 715212 and the bodhi ticket for libreport-2.0.4-2.fc15. The problem is understood, but there are several ways to fix it with further updates (some trivial, some not).
Just to let you all know that, after reading https://bugzilla.redhat.com/show_bug.cgi?id=715212#c6 the following update from rawhide fixed the problem for me: $ sudo yum upgrade libreport --enablerepo=rawhide Loaded plugins: fastestmirror, presto Loading mirror speeds from cached hostfile Setting up Upgrade Process Resolving Dependencies --> Running transaction check ---> Package libreport.x86_64 0:2.0.4-1.fc15 will be updated --> Processing Dependency: libreport = 2.0.4-1.fc15 for package: libreport-gtk-2.0.4-1.fc15.x86_64 ---> Package libreport.x86_64 0:2.0.4-2.fc16 will be an update --> Running transaction check ---> Package libreport-gtk.x86_64 0:2.0.4-1.fc15 will be updated --> Processing Dependency: report-gtk for package: setroubleshoot-3.0.35-1.fc15.x86_64 --> Processing Dependency: report-gtk for package: python-meh-0.11-2.fc15.noarch ---> Package libreport-gtk.x86_64 0:2.0.4-2.fc16 will be an update --> Running transaction check ---> Package libreport-gtk.x86_64 0:2.0.4-1.fc15 will be updated ---> Package report-gtk.x86_64 0:0.21-0.fc16 will be installed --> Processing Dependency: report(x86-64) = 0.21-0.fc16 for package: report-gtk-0.21-0.fc16.x86_64 ---> Package setroubleshoot.x86_64 0:3.0.35-1.fc15 will be updated ---> Package setroubleshoot.x86_64 0:3.0.37-1.fc16 will be an update --> Processing Dependency: setroubleshoot-server = 3.0.37-1.fc16 for package: setroubleshoot-3.0.37-1.fc16.x86_64 --> Running transaction check ---> Package report.x86_64 0:0.20-2.fc15 will be updated --> Processing Dependency: report = 0.20-2.fc15 for package: report-newt-0.20-2.fc15.x86_64 --> Processing Dependency: report = 0.20-2.fc15 for package: report-plugin-bugzilla-0.20-2.fc15.x86_64 --> Processing Dependency: report = 0.20-2.fc15 for package: report-plugin-localsave-0.20-2.fc15.x86_64 --> Processing Dependency: report = 0.20-2.fc15 for package: report-plugin-scp-0.20-2.fc15.x86_64 --> Processing Dependency: report = 0.20-2.fc15 for package: report-plugin-ftp-0.20-2.fc15.x86_64 ---> Package report.x86_64 0:0.21-0.fc16 will be an update ---> Package setroubleshoot-server.x86_64 0:3.0.35-1.fc15 will be updated ---> Package setroubleshoot-server.x86_64 0:3.0.37-1.fc16 will be an update --> Running transaction check ---> Package report-newt.x86_64 0:0.20-2.fc15 will be updated ---> Package report-newt.x86_64 0:0.21-0.fc16 will be an update ---> Package report-plugin-bugzilla.x86_64 0:0.20-2.fc15 will be updated --> Processing Dependency: report-plugin-bugzilla = 0.20-2.fc15 for package: report-config-bugzilla-redhat-com-0.20-2.fc15.x86_64 ---> Package report-plugin-bugzilla.x86_64 0:0.21-0.fc16 will be an update ---> Package report-plugin-ftp.x86_64 0:0.20-2.fc15 will be updated --> Processing Dependency: report-plugin-ftp = 0.20-2.fc15 for package: report-config-ftp-0.20-2.fc15.x86_64 ---> Package report-plugin-ftp.x86_64 0:0.21-0.fc16 will be an update ---> Package report-plugin-localsave.x86_64 0:0.20-2.fc15 will be updated --> Processing Dependency: report-plugin-localsave = 0.20-2.fc15 for package: report-config-localsave-0.20-2.fc15.x86_64 ---> Package report-plugin-localsave.x86_64 0:0.21-0.fc16 will be an update ---> Package report-plugin-scp.x86_64 0:0.20-2.fc15 will be updated --> Processing Dependency: report-plugin-scp = 0.20-2.fc15 for package: report-config-scp-0.20-2.fc15.x86_64 ---> Package report-plugin-scp.x86_64 0:0.21-0.fc16 will be an update --> Running transaction check ---> Package report-config-bugzilla-redhat-com.x86_64 0:0.20-2.fc15 will be updated ---> Package report-config-bugzilla-redhat-com.x86_64 0:0.21-0.fc16 will be an update ---> Package report-config-ftp.x86_64 0:0.20-2.fc15 will be updated ---> Package report-config-ftp.x86_64 0:0.21-0.fc16 will be an update ---> Package report-config-localsave.x86_64 0:0.20-2.fc15 will be updated ---> Package report-config-localsave.x86_64 0:0.21-0.fc16 will be an update ---> Package report-config-scp.x86_64 0:0.20-2.fc15 will be updated ---> Package report-config-scp.x86_64 0:0.21-0.fc16 will be an update --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Updating: libreport x86_64 2.0.4-2.fc16 rawhide 103 k Installing for dependencies: report-gtk x86_64 0.21-0.fc16 rawhide 19 k Updating for dependencies: libreport-gtk x86_64 2.0.4-2.fc16 rawhide 27 k report x86_64 0.21-0.fc16 rawhide 73 k report-config-bugzilla-redhat-com x86_64 0.21-0.fc16 rawhide 14 k report-config-ftp x86_64 0.21-0.fc16 rawhide 14 k report-config-localsave x86_64 0.21-0.fc16 rawhide 14 k report-config-scp x86_64 0.21-0.fc16 rawhide 14 k report-newt x86_64 0.21-0.fc16 rawhide 17 k report-plugin-bugzilla x86_64 0.21-0.fc16 rawhide 29 k report-plugin-ftp x86_64 0.21-0.fc16 rawhide 16 k report-plugin-localsave x86_64 0.21-0.fc16 rawhide 16 k report-plugin-scp x86_64 0.21-0.fc16 rawhide 18 k setroubleshoot x86_64 3.0.37-1.fc16 rawhide 116 k setroubleshoot-server x86_64 3.0.37-1.fc16 rawhide 1.3 M Transaction Summary ================================================================================ Install 1 Package(s) Upgrade 14 Package(s) Total download size: 1.7 M Is this ok [y/N]: y Downloading Packages: Setting up and reading Presto delta metadata rawhide/prestodelta | 596 kB 00:03 Processing delta metadata Package(s) data still to download: 1.7 M (1/15): libreport-2.0.4-2.fc16.x86_64.rpm | 103 kB 00:01 (2/15): libreport-gtk-2.0.4-2.fc16.x86_64.rpm | 27 kB 00:00 (3/15): report-0.21-0.fc16.x86_64.rpm | 73 kB 00:00 (4/15): report-config-bugzilla-redhat-com-0.21-0.fc16.x8 | 14 kB 00:00 (5/15): report-config-ftp-0.21-0.fc16.x86_64.rpm | 14 kB 00:00 (6/15): report-config-localsave-0.21-0.fc16.x86_64.rpm | 14 kB 00:00 (7/15): report-config-scp-0.21-0.fc16.x86_64.rpm | 14 kB 00:00 (8/15): report-gtk-0.21-0.fc16.x86_64.rpm | 19 kB 00:00 (9/15): report-newt-0.21-0.fc16.x86_64.rpm | 17 kB 00:00 (10/15): report-plugin-bugzilla-0.21-0.fc16.x86_64.rpm | 29 kB 00:00 (11/15): report-plugin-ftp-0.21-0.fc16.x86_64.rpm | 16 kB 00:00 (12/15): report-plugin-localsave-0.21-0.fc16.x86_64.rpm | 16 kB 00:00 (13/15): report-plugin-scp-0.21-0.fc16.x86_64.rpm | 18 kB 00:00 (14/15): setroubleshoot-3.0.37-1.fc16.x86_64.rpm | 116 kB 00:01 (15/15): setroubleshoot-server-3.0.37-1.fc16.x86_64.rpm | 1.3 MB 00:05 -------------------------------------------------------------------------------- Total 99 kB/s | 1.7 MB 00:17 Running rpm_check_debug Running Transaction Test Transaction Test Succeeded Running Transaction Updating : report-config-scp-0.21-0.fc16.x86_64 1/29 Updating : report-plugin-scp-0.21-0.fc16.x86_64 2/29 Updating : report-config-localsave-0.21-0.fc16.x86_64 3/29 Updating : report-plugin-localsave-0.21-0.fc16.x86_64 4/29 Updating : report-config-ftp-0.21-0.fc16.x86_64 5/29 Updating : report-plugin-ftp-0.21-0.fc16.x86_64 6/29 Updating : report-0.21-0.fc16.x86_64 7/29 Updating : report-plugin-bugzilla-0.21-0.fc16.x86_64 8/29 Updating : report-config-bugzilla-redhat-com-0.21-0.fc16.x86_64 9/29 Installing : report-gtk-0.21-0.fc16.x86_64 10/29 Updating : libreport-2.0.4-2.fc16.x86_64 11/29 Updating : setroubleshoot-server-3.0.37-1.fc16.x86_64 12/29 Updating : setroubleshoot-3.0.37-1.fc16.x86_64 13/29 Updating : libreport-gtk-2.0.4-2.fc16.x86_64 14/29 Updating : report-newt-0.21-0.fc16.x86_64 15/29 Cleanup : report-newt-0.20-2.fc15.x86_64 16/29 Cleanup : report-config-bugzilla-redhat-com-0.20-2.fc15.x86_64 17/29 Cleanup : report-plugin-bugzilla-0.20-2.fc15.x86_64 18/29 Cleanup : report-plugin-ftp-0.20-2.fc15.x86_64 19/29 Cleanup : report-config-ftp-0.20-2.fc15.x86_64 20/29 Cleanup : report-plugin-localsave-0.20-2.fc15.x86_64 21/29 Cleanup : report-config-localsave-0.20-2.fc15.x86_64 22/29 Cleanup : report-plugin-scp-0.20-2.fc15.x86_64 23/29 Cleanup : report-0.20-2.fc15.x86_64 24/29 Cleanup : report-config-scp-0.20-2.fc15.x86_64 25/29 Cleanup : setroubleshoot-3.0.35-1.fc15.x86_64 26/29 Cleanup : libreport-gtk-2.0.4-1.fc15.x86_64 27/29 Cleanup : libreport-2.0.4-1.fc15.x86_64 28/29 Cleanup : setroubleshoot-server-3.0.35-1.fc15.x86_64 29/29 Dependency Installed: report-gtk.x86_64 0:0.21-0.fc16 Updated: libreport.x86_64 0:2.0.4-2.fc16 Dependency Updated: libreport-gtk.x86_64 0:2.0.4-2.fc16 report.x86_64 0:0.21-0.fc16 report-config-bugzilla-redhat-com.x86_64 0:0.21-0.fc16 report-config-ftp.x86_64 0:0.21-0.fc16 report-config-localsave.x86_64 0:0.21-0.fc16 report-config-scp.x86_64 0:0.21-0.fc16 report-newt.x86_64 0:0.21-0.fc16 report-plugin-bugzilla.x86_64 0:0.21-0.fc16 report-plugin-ftp.x86_64 0:0.21-0.fc16 report-plugin-localsave.x86_64 0:0.21-0.fc16 report-plugin-scp.x86_64 0:0.21-0.fc16 setroubleshoot.x86_64 0:3.0.37-1.fc16 setroubleshoot-server.x86_64 0:3.0.37-1.fc16 Complete!
report-0.22-0.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/report-0.22-0.fc15
(In reply to comment #42) > In other words, yum can't see report-gtk, I don't know why, so it looks in the > repo and sees that the older version of libreport-gtk provides it. > But it's already installed and the updated version doesn't provide it, so it > simply tries to install the older version's i686 package, and then fails > because of multilib version mismatch. > > > > -- > Fedora Bugzappers volunteer triage team > https://fedoraproject.org/wiki/BugZappers yes, the bug persists in fedora 15 yum 64 and 32 bit "yum does not install report-gtk"
I rebuild report-0.22-0.fc15.src.rpm from koji report-0.22-0.fc15.src.rpm report-0.22-0.fc15.x86_64.rpm report-config-bugzilla-redhat-com-0.22-0.fc15.x86_64.rpm report-config-ftp-0.22-0.fc15.x86_64.rpm report-config-localsave-0.22-0.fc15.x86_64.rpm report-config-scp-0.22-0.fc15.x86_64.rpm report-debuginfo-0.22-0.fc15.x86_64.rpm report-gtk-0.22-0.fc15.x86_64.rpm report-newt-0.22-0.fc15.x86_64.rpm report-plugin-bugzilla-0.22-0.fc15.x86_64.rpm report-plugin-ftp-0.22-0.fc15.x86_64.rpm report-plugin-localsave-0.22-0.fc15.x86_64.rpm report-plugin-scp-0.22-0.fc15.x86_64.rpm works, the bug was solved.
(In reply to comment #58) > I rebuild report-0.22-0.fc15.src.rpm from koji > > report-0.22-0.fc15.src.rpm > report-0.22-0.fc15.x86_64.rpm > report-config-bugzilla-redhat-com-0.22-0.fc15.x86_64.rpm > report-config-ftp-0.22-0.fc15.x86_64.rpm > report-config-localsave-0.22-0.fc15.x86_64.rpm > report-config-scp-0.22-0.fc15.x86_64.rpm > report-debuginfo-0.22-0.fc15.x86_64.rpm > report-gtk-0.22-0.fc15.x86_64.rpm > report-newt-0.22-0.fc15.x86_64.rpm > report-plugin-bugzilla-0.22-0.fc15.x86_64.rpm > report-plugin-ftp-0.22-0.fc15.x86_64.rpm > report-plugin-localsave-0.22-0.fc15.x86_64.rpm > report-plugin-scp-0.22-0.fc15.x86_64.rpm > > works, the bug was solved. Really? I just installed the packages from this build: [ankur@ankur ~]$ rpm -qa | egrep "^report" report-config-scp-0.22-0.fc15.x86_64 report-plugin-localsave-0.22-0.fc15.x86_64 report-config-ftp-0.22-0.fc15.x86_64 report-0.22-0.fc15.x86_64 report-config-localsave-0.22-0.fc15.x86_64 report-plugin-bugzilla-0.22-0.fc15.x86_64 report-plugin-scp-0.22-0.fc15.x86_64 report-config-bugzilla-redhat-com-0.22-0.fc15.x86_64 report-plugin-ftp-0.22-0.fc15.x86_64 report-newt-0.22-0.fc15.x86_64 Sealert still cries the same error for me. Is this a common fix that's supposed to work for everyone? Thanks, Ankur
recently libreport got absoleted and setroubleshooter is not working since then
I dont load from yum, only take the srpm from koji and rebuild in mock any problem , work fine.
(In reply to comment #59) > (In reply to comment #58) > > I rebuild report-0.22-0.fc15.src.rpm from koji > > > > report-0.22-0.fc15.src.rpm > > report-0.22-0.fc15.x86_64.rpm > > report-config-bugzilla-redhat-com-0.22-0.fc15.x86_64.rpm > > report-config-ftp-0.22-0.fc15.x86_64.rpm > > report-config-localsave-0.22-0.fc15.x86_64.rpm > > report-config-scp-0.22-0.fc15.x86_64.rpm > > report-debuginfo-0.22-0.fc15.x86_64.rpm > > report-gtk-0.22-0.fc15.x86_64.rpm > > report-newt-0.22-0.fc15.x86_64.rpm > > report-plugin-bugzilla-0.22-0.fc15.x86_64.rpm > > report-plugin-ftp-0.22-0.fc15.x86_64.rpm > > report-plugin-localsave-0.22-0.fc15.x86_64.rpm > > report-plugin-scp-0.22-0.fc15.x86_64.rpm > > > > works, the bug was solved. > > > Really? > > I just installed the packages from this build: > > [ankur@ankur ~]$ rpm -qa | egrep "^report" > report-config-scp-0.22-0.fc15.x86_64 > report-plugin-localsave-0.22-0.fc15.x86_64 > report-config-ftp-0.22-0.fc15.x86_64 > report-0.22-0.fc15.x86_64 > report-config-localsave-0.22-0.fc15.x86_64 > report-plugin-bugzilla-0.22-0.fc15.x86_64 > report-plugin-scp-0.22-0.fc15.x86_64 > report-config-bugzilla-redhat-com-0.22-0.fc15.x86_64 > report-plugin-ftp-0.22-0.fc15.x86_64 > report-newt-0.22-0.fc15.x86_64 > > Sealert still cries the same error for me. > > Is this a common fix that's supposed to work for everyone? > > Thanks, > Ankur I dont see "report-gtk-0.22-0.fc15.x86_64" does is your problem.
Yeah. I just installed it. works for me :) btw, you don't need to rebuild it in mock. you can just download the packages : $ koji download-build --arch=x86_64 251288 (select the arch) and install them.
(In reply to comment #63) > Yeah. I just installed it. works for me :) > > btw, you don't need to rebuild it in mock. you can just download the packages : > > $ koji download-build --arch=x86_64 251288 (select the arch) > > and install them. ok . your problem is just the package report-gtk-0.22?
> $ koji download-build --arch=x86_64 251288 (select the arch) > > and install them. thanks about the info.
(In reply to comment #31) > What I wanted to say that it seems to be a bug in yum that yum removes a > package because one(!) says its obsolete but several other installed packages > still require this package. In my opinion yum should handle this scenario like > a missing dependecy and say something like "sorry, but this package is still > required by other packaged" There is nothing yum can do here because libreport-gtk claims to provide report-gtk: $ rpm -q libreport-gtk libreport-gtk-2.0.4-1.fc15.x86_64 $ rpm -q --provides libreport-gtk libreport-gtk.so.0()(64bit) report-gtk > 0.20 libreport-gtk = 2.0.4-1.fc15 libreport-gtk(x86-64) = 2.0.4-1.fc15 In you words yum would say "I can safely replace report-gtk with libreport-gtk because it provides everything all the other packages need."
report-0.22-0.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
Still getting the sealert error on trying to launch with latest update: report.x86_64 0.22-0.fc15 @updates libreport.x86_64 2.0.4-1.fc15 @updates etc How best to proceed?
I'm seeing this as well (and the Platform should be "All Linux", BTW). Fully updated clean install of F15 x86_64, including the July 3 updates.
Confirm - sealert is still broken - this does not fix the damage yet: rpm -q report libreport libreport-gtk report-0.22-0.fc15.x86_64 libreport-2.0.4-1.fc15.x86_64 libreport-gtk-2.0.4-1.fc15.x86_64 % sealert -b Opps, sealert hit an error! Traceback (most recent call last): File "/usr/bin/sealert", line 692, in <module> run_as_dbus_service(username) File "/usr/bin/sealert", line 112, in run_as_dbus_service app = SEAlert(user, dbus_service.presentation_manager, watch_setroubleshootd=True) File "/usr/bin/sealert", line 326, in __init__ from setroubleshoot.browser import BrowserApplet File "/usr/lib64/python2.7/site-packages/setroubleshoot/browser.py", line 46, in <module> import report.io.GTKIO ImportError: No module named GTKIO
(In reply to comment #68) > Still getting the sealert error on trying to launch with latest update: > > report.x86_64 0.22-0.fc15 @updates > libreport.x86_64 2.0.4-1.fc15 @updates > > etc > > How best to proceed? (In reply to comment #69) > I'm seeing this as well (and the Platform should be "All Linux", BTW). Fully > updated clean install of F15 x86_64, including the July 3 updates. (In reply to comment #70) > Confirm - sealert is still broken - this does not fix the damage yet: > > > rpm -q report libreport libreport-gtk > report-0.22-0.fc15.x86_64 > libreport-2.0.4-1.fc15.x86_64 > libreport-gtk-2.0.4-1.fc15.x86_64 > > % sealert -b > > Opps, sealert hit an error! > > Traceback (most recent call last): > File "/usr/bin/sealert", line 692, in <module> > run_as_dbus_service(username) > File "/usr/bin/sealert", line 112, in run_as_dbus_service > app = SEAlert(user, dbus_service.presentation_manager, > watch_setroubleshootd=True) > File "/usr/bin/sealert", line 326, in __init__ > from setroubleshoot.browser import BrowserApplet > File "/usr/lib64/python2.7/site-packages/setroubleshoot/browser.py", line 46, > in <module> > import report.io.GTKIO > ImportError: No module named GTKIO Please check if you have report-gtk installed. If not, "yum install report-gtk" will fix it. I think report-gtk somehow got removed in the entire fuss, and is therefore not updated (installed in this case). Thanks, Ankur
I did not have report-gtk installed - after installing it, sealert appears to work normally.
Fixed it for me too - but how does this help the users who are not following this bz - and just happily updated their systems - they will stay broken forever - seems to me somehow updating report -should- force report-gtk to be installed if it isn't so users don't have to do it manually ... unless you have a better way to keep users from manually installing report-gtk. As it stands - users are left with broken system - in my view - this current fix does not fix the problem because of the additional manual step required.
Just checked that report-gtk is included in a F15 default install. Since sealert (from the setroubleshoot-server package) doesn't work without it, should it be a requirement?
See bug 718500 ("Missing dependency for sealert").
(In reply to comment #71) Thank you!!! After installing report-gtk, sealert is working again! But I think this should be fixed automatically...
(In reply to comment #76) > (In reply to comment #71) > Thank you!!! After installing report-gtk, sealert is working again! > But I think this should be fixed automatically... Yes, I agree. To get this to work automatically (so that a simple 'yum upgrade' solves this problem) we need to get this update https://admin.fedoraproject.org/updates/libreport-2.0.4-2.fc15 into f15-updates. That update didn't work before because report-0.22-0 wasn't available; now that it is, libreport-2.0.4-2 will solve the problem it was meant to, that is correct the mistaken obsoletes/provides in libreport-2.0.4-2. I think that testing the libreport-2.0.4-2 update and upping its karma will accomplish this. Proper testing of libreport-2.0.4-2 would involve putting a copy of it in a local repo, and making that repo available to your yum, along with a repo containing report-0.22-0 (f15-updates will do), and doing a simple 'yum update'. Through testing of this would involve doing this simple update both with and without report-0.22-0 already installed, and with and without report-gtk-0.22-0 already installed. The primary differences between libreport-2.0.4-2 and libreport-2.0.4-1, and report-0.22-0 and report-0.20-2 are in the provides/requires/obsoletes they have, not in the code the install.
sorry: (In reply to comment #77) > 'yum update'. Through testing of this would involve doing this simple update s/through/thorough/
*** Bug 719580 has been marked as a duplicate of this bug. ***
*** Bug 719692 has been marked as a duplicate of this bug. ***
Well, this AM I had the occasion to update a seldom used F15 laptop (last updated early June). Before I started, report-gtk was installed and sealert worked as expected. After the update, libreport-2.0.4-2.fc15 was installed as was report-0.22-0.fc15. *BUT* report-gtk had been removed and sealert failed. After re-installing report-gtk! This bug should *NOT* be closed. A 'simple' yum update still removed report-gtk and broke sealert.
Wait a minute, the version of libreport should be libreport-2.0.4-1.fc15. That's what's in the updates repo and libreport-2.0.4-2.fc15 is still in updates-testing (though installed, as per Comment 44, on the rest of my machines).
Why is this closed? The bug still exists in a fully updated Fedora 15 (64 bit).
Reopening since https://admin.fedoraproject.org/updates/libreport-2.0.4-2.fc15 WAS in updates-testing, but is no longer. It's been submitted for updates-testing again, but given that its current Status is "obsolete", it's not obvious if it will actually get included in the next push.
*** Bug 719909 has been marked as a duplicate of this bug. ***
Dan, I think there also is a problem in your package: It has Requires: report-gtk while it should have Requires: report-gtk%{?_isa} See https://fedoraproject.org/wiki/Packaging:Guidelines#Requires This is likely to cause bug 718132 which prevents people from updating to the fixed libreport package.
I'm doing a fresh install of Fedora 15 x86_64 from DVD on my netbook. After the first boot, I ran the GUI "Software Update" program. It failed twice. Once was https://bugzilla.redhat.com/show_bug.cgi?id=716752 which is solved as per http://fedoraproject.org/wiki/Common_F15_bugs#.22could_not_add_package_update_for_fedora-release-rawhide-15-3.28noarch.29updates:_fedora-release-rawhide-15-3.noarch.22 The second one could be the subject of this buzilla entry: I get the message could not add package update for report-gtk-0.22-0.fc15(x86_64)updates: report-gtk-0.22-0.fc15.x86_64 If so, I wonder why this isn't a common problem. Googling only gets me one hit: http://www.linuxquestions.org/questions/fedora-35/fedora-15-software-update-issue-888760/ The workaround in that hit seems to work for me. (The update hasn't yet finished.)
*** Bug 720238 has been marked as a duplicate of this bug. ***
Seems like koji doesn't want to push the package once it was marked obsolete (because of bad karma) even when I manually re-request to push it. I'm going to create a new update with just bumped release,which should hopefully fix the yum update problem.
libreport-2.0.4-3.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/libreport-2.0.4-3.fc15
*** Bug 720169 has been marked as a duplicate of this bug. ***
Package libreport-2.0.4-3.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libreport-2.0.4-3.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/libreport-2.0.4-3.fc15 then log in and leave karma (feedback).
*** Bug 720653 has been marked as a duplicate of this bug. ***
*** Bug 720530 has been marked as a duplicate of this bug. ***
libreport-2.0.4-3.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 720839 has been marked as a duplicate of this bug. ***