Discussion:
[HEADS-UP] replacing report with libreport
(too old to reply)
Jiri Moskovcak
2011-06-29 09:50:23 UTC
Permalink
Hi!
I'm going to replace the report library with the new libreport. Today I
plan to replace it in rawhide and if it goes smoothly I'd like to
replace it in F15 as well.

pros:
- libreport is written in C (report is in python), so it's easier to
write bindings for other languages
- it's API compatible with report (it has python bindings)
- it shares configuration with ABRT, so users just need to write their
credentials and defaults only once
- shares the UI with ABRT (the reporting wizard), so users are presented
with the same UI despite of from where they are reporting a problem

cons:
- it has a bit different UI
- account information (e.g: bz loging+password) is forgotten and needs
to be entered again
- some minor breakage expected (hopefully not...)


affected packages (according to repoquery):
- report + subpackages (being obsoleted)
- python-meh
- anaconda
- anaconda-0:15.31-1.fc15.x86_64
- firstboot-0:1.119-1.fc15.x86_64
- system-config-kickstart-0:2.8.7-2.fc15.noarch
- setroubleshoot

As I said, libreport should be API compatible with report, so no changes
should needed, but of course can't be 100% sure if it's bugfree ;)
Rahul Sundaram
2011-06-29 10:18:39 UTC
Permalink
Post by Jiri Moskovcak
Hi!
I'm going to replace the report library with the new libreport. Today I
plan to replace it in rawhide and if it goes smoothly I'd like to
replace it in F15 as well.
Why in Fedora 15? There seems to be no compelling reason to do that

Rahul
Jiri Moskovcak
2011-06-29 11:11:22 UTC
Permalink
Post by Rahul Sundaram
Post by Jiri Moskovcak
Hi!
I'm going to replace the report library with the new libreport. Today I
plan to replace it in rawhide and if it goes smoothly I'd like to
replace it in F15 as well.
Why in Fedora 15? There seems to be no compelling reason to do that
Rahul
And also no reasons against - if proven stable enough in rawhide.

some minor pros:
- since ABRT needs the libreport even in F15 it would be easier for me
to not maintain 2 different versions for F15 and rawhide since the only
difference is the missing python bindings in F15 (this would help avoid
bugs like #715373)

Jirka
Adam Williamson
2011-06-29 16:44:04 UTC
Permalink
Post by Jiri Moskovcak
Post by Rahul Sundaram
Post by Jiri Moskovcak
Hi!
I'm going to replace the report library with the new libreport. Today I
plan to replace it in rawhide and if it goes smoothly I'd like to
replace it in F15 as well.
Why in Fedora 15? There seems to be no compelling reason to do that
Rahul
And also no reasons against - if proven stable enough in rawhide.
It's a clear change to the user experience - presenting a different UI
and forgetting stored logins.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
Camilo Mesias
2011-06-29 21:24:17 UTC
Permalink
Hmm,

something has broken in F15 for me:

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

from setroubleshoot-server-3.0.35-1.fc15.i686
in conjunction with libreport-gtk-2.0.4-1.fc15.i686

-Cam
Adam Williamson
2011-06-29 21:51:23 UTC
Permalink
Post by Camilo Mesias
Hmm,
Opps, sealert hit an error!
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
from setroubleshoot-server-3.0.35-1.fc15.i686
in conjunction with libreport-gtk-2.0.4-1.fc15.i686
https://bugzilla.redhat.com/show_bug.cgi?id=715373
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
Michael Schwendt
2011-06-29 21:51:38 UTC
Permalink
Post by Camilo Mesias
Hmm,
Opps, sealert hit an error!
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
from setroubleshoot-server-3.0.35-1.fc15.i686
in conjunction with libreport-gtk-2.0.4-1.fc15.i686
Known. A faulty libreport update. Look up the existing ticket at
http://bugz.fedoraproject.org/libreport
if you're interested in background information.
Jiri Moskovcak
2011-06-30 11:51:51 UTC
Permalink
Post by Adam Williamson
Post by Jiri Moskovcak
Post by Rahul Sundaram
Post by Jiri Moskovcak
Hi!
I'm going to replace the report library with the new libreport. Today I
plan to replace it in rawhide and if it goes smoothly I'd like to
replace it in F15 as well.
Why in Fedora 15? There seems to be no compelling reason to do that
Rahul
And also no reasons against - if proven stable enough in rawhide.
It's a clear change to the user experience - presenting a different UI
and forgetting stored logins.
- I was afraid, that it would be against some Fedora policy ;) Then just
the rawhide..

J.
Jeff Spaleta
2011-06-30 16:16:39 UTC
Permalink
Post by Jiri Moskovcak
- I was afraid, that it would be against some Fedora policy ;) Then just
the rawhide..
Okay if this isn't coming to F15, can you provide the sufficient
instructions on how to revert the libreport packages from F15 updates
testing so that the packages that require report-gtk will work
properly again.

I'm not pointing fingers. I just want to know, from you, the package
maintainer, how to back out of the semi brokenness introduced by the
malformed obsoletes in the updates-testing package that is now a dead
end if
this isn't going to firm up as an official update.


-jef
Genes MailLists
2011-06-30 17:18:42 UTC
Permalink
Post by Jeff Spaleta
Post by Jiri Moskovcak
- I was afraid, that it would be against some Fedora policy ;) Then just
the rawhide..
Okay if this isn't coming to F15, can you provide the sufficient
instructions on how to revert the libreport packages from F15 updates
testing so that the packages that require report-gtk will work
properly again.
I'm not pointing fingers. I just want to know, from you, the package
maintainer, how to back out of the semi brokenness introduced by the
malformed obsoletes in the updates-testing package that is now a dead
end if
this isn't going to firm up as an official update.
Actually I'd prefer to know how to move forward to the new way ...
Jeff Spaleta
2011-06-30 17:25:09 UTC
Permalink
?Actually I'd prefer to know how to move forward to the new way ...
run rawhide!

-jef
Jeff Spaleta
2011-06-30 17:31:19 UTC
Permalink
Post by Jeff Spaleta
Post by Jiri Moskovcak
- I was afraid, that it would be against some Fedora policy ;) Then just
the rawhide..
Okay if this isn't coming to F15, can you provide the sufficient
instructions on how to revert the libreport packages from F15 updates
testing so that the packages that require report-gtk will work
properly again.
Pardon, this weird report-gtk provides change has already made it to
updates released. So its actually a bigger deal as the change
has already been injected into F15 packages and is impacting packages.
Seems you jumped the gun with regard to the
provides change. What's the plan to unbreak Fedora 15 systems that
have pulled in the libreport with the report-gtk provides if you
aren't
going to continue forward with the API change in F15 and get the other
packages that have been using the older report fixed to use the new
libreport API?

-jef
Genes MailLists
2011-06-30 17:37:01 UTC
Permalink
Post by Jeff Spaleta
Post by Jiri Moskovcak
- I was afraid, that it would be against some Fedora policy ;) Then just
the rawhide..
Okay if this isn't coming to F15, can you provide the sufficient
instructions on how to revert the libreport packages from F15 updates
testing so that the packages that require report-gtk will work
properly again.
I'm not pointing fingers. I just want to know, from you, the package
maintainer, how to back out of the semi brokenness introduced by the
malformed obsoletes in the updates-testing package that is now a dead
end if
this isn't going to firm up as an official update.
Am I misremembering? I recall an official update which broke sealert -
the libreport fix from updates testing never installed as it was broken
and never was pushed stable.

So now F15 stock with official stable updates only, has a broken
sealert (maybe other things).

Whats the way forward from here in F15?

gene/
Jiri Moskovcak
2011-06-30 19:06:17 UTC
Permalink
Post by Genes MailLists
Post by Jeff Spaleta
Post by Jiri Moskovcak
- I was afraid, that it would be against some Fedora policy ;) Then just
the rawhide..
Okay if this isn't coming to F15, can you provide the sufficient
instructions on how to revert the libreport packages from F15 updates
testing so that the packages that require report-gtk will work
properly again.
I'm not pointing fingers. I just want to know, from you, the package
maintainer, how to back out of the semi brokenness introduced by the
malformed obsoletes in the updates-testing package that is now a dead
end if
this isn't going to firm up as an official update.
Am I misremembering? I recall an official update which broke sealert -
the libreport fix from updates testing never installed as it was broken
and never was pushed stable.
So now F15 stock with official stable updates only, has a broken
sealert (maybe other things).
Whats the way forward from here in F15?
gene/
1. bumping the version of the report-gtk package should do the trick - I
already contacted the maintainer and ask him to do - as this seems to
work for rawhide:

https://bugzilla.redhat.com/show_bug.cgi?id=715373#c55

2. fix the yum so it can handle this situation better
3. last resort would be asking rel-engs to remove the broken libreport
from the stable repositories (if it's even possible)

J.
Michael Schwendt
2011-06-30 23:23:29 UTC
Permalink
Post by Jiri Moskovcak
Post by Genes MailLists
Whats the way forward from here in F15?
gene/
1. bumping the version of the report-gtk package should do the trick - I
already contacted the maintainer and ask him to do - as this seems to
https://bugzilla.redhat.com/show_bug.cgi?id=715373#c55
And as pointed out in bz, it still needs a corresponding libreport-gtk
update that doesn't have the bad Obs/Prov pair anymore.
Post by Jiri Moskovcak
3. last resort would be asking rel-engs to remove the broken libreport
from the stable repositories (if it's even possible)
Won't happen, because it is installed on users' machines already, and I doubt
we would like an unknown number of users to fix this mess themselves.
Adam Williamson
2011-07-01 00:26:41 UTC
Permalink
Post by Michael Schwendt
Post by Jiri Moskovcak
Post by Genes MailLists
Whats the way forward from here in F15?
gene/
1. bumping the version of the report-gtk package should do the trick - I
already contacted the maintainer and ask him to do - as this seems to
https://bugzilla.redhat.com/show_bug.cgi?id=715373#c55
And as pointed out in bz, it still needs a corresponding libreport-gtk
update that doesn't have the bad Obs/Prov pair anymore.
Post by Jiri Moskovcak
3. last resort would be asking rel-engs to remove the broken libreport
from the stable repositories (if it's even possible)
Won't happen, because it is installed on users' machines already, and I doubt
we would like an unknown number of users to fix this mess themselves.
Well, updates-testing is 'you get to keep both halves' territory.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
Genes MailLists
2011-07-01 02:04:15 UTC
Permalink
Post by Adam Williamson
Well, updates-testing is 'you get to keep both halves' territory.
wasn't it stable that broke things (sealert stopped working for example
after a stable update) - and then something from updates testing was
supposed to fix it? But it never made it to stable.
Adam Williamson
2011-07-01 02:44:14 UTC
Permalink
Post by Genes MailLists
Post by Adam Williamson
Well, updates-testing is 'you get to keep both halves' territory.
wasn't it stable that broke things (sealert stopped working for example
after a stable update) - and then something from updates testing was
supposed to fix it? But it never made it to stable.
I dunno, I kinda lost track. You might be right!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
Genes MailLists
2011-07-01 03:09:29 UTC
Permalink
Post by Adam Williamson
Post by Genes MailLists
Post by Adam Williamson
Well, updates-testing is 'you get to keep both halves' territory.
wasn't it stable that broke things (sealert stopped working for example
after a stable update) - and then something from updates testing was
supposed to fix it? But it never made it to stable.
I dunno, I kinda lost track. You might be right!
hah ... :-)
Jiri Moskovcak
2011-07-01 06:26:09 UTC
Permalink
Post by Genes MailLists
Post by Adam Williamson
Well, updates-testing is 'you get to keep both halves' territory.
wasn't it stable that broke things (sealert stopped working for example
after a stable update) - and then something from updates testing was
supposed to fix it? But it never made it to stable.
yes, this update:
https://admin.fedoraproject.org/updates/libreport-2.0.4-2.fc15
has the fixed prov/obs, but has wrong karma because it doesn't work
without the report update...

J.
Michael Schwendt
2011-07-01 09:57:35 UTC
Permalink
Post by Adam Williamson
Post by Michael Schwendt
Post by Jiri Moskovcak
Post by Genes MailLists
Whats the way forward from here in F15?
gene/
1. bumping the version of the report-gtk package should do the trick - I
already contacted the maintainer and ask him to do - as this seems to
https://bugzilla.redhat.com/show_bug.cgi?id=715373#c55
And as pointed out in bz, it still needs a corresponding libreport-gtk
update that doesn't have the bad Obs/Prov pair anymore.
Post by Jiri Moskovcak
3. last resort would be asking rel-engs to remove the broken libreport
from the stable repositories (if it's even possible)
Won't happen, because it is installed on users' machines already, and I doubt
we would like an unknown number of users to fix this mess themselves.
Well, updates-testing is 'you get to keep both halves' territory.
Adam, Adam, Adam ;) it's this one in "updates":
https://admin.fedoraproject.org/updates/libreport-2.0.4-1.fc15
Jeff Spaleta
2011-07-01 17:51:18 UTC
Permalink
Post by Michael Schwendt
https://admin.fedoraproject.org/updates/libreport-2.0.4-1.fc15
Is there an open ticket about the report package that needs to be
bumped to get this cleaned up. It seems from the ticket traffic I've
ready you've figured out a minimally disruptive packaging fix for the
report package. Has the report package maintainer(s) weighed in?
Again, not pointing fingers as to who should be doing the work to
clean it up, I'm just trying to figure out where the hold up is in
cleaning this up as expediently as possible.


-jef

Daniel J Walsh
2011-06-29 11:16:12 UTC
Permalink
Post by Jiri Moskovcak
Hi!
I'm going to replace the report library with the new libreport. Today I
plan to replace it in rawhide and if it goes smoothly I'd like to
replace it in F15 as well.
Hasn't this already reached F15? Have you readded the GTKIO stuff?
Post by Jiri Moskovcak
- libreport is written in C (report is in python), so it's easier to
write bindings for other languages
- it's API compatible with report (it has python bindings)
- it shares configuration with ABRT, so users just need to write their
credentials and defaults only once
- shares the UI with ABRT (the reporting wizard), so users are presented
with the same UI despite of from where they are reporting a problem
- it has a bit different UI
- account information (e.g: bz loging+password) is forgotten and needs
to be entered again
Why? Is it remembered within the session? Can't it save the bugzilla
info within the gnome-keyring?
Post by Jiri Moskovcak
- some minor breakage expected (hopefully not...)
- report + subpackages (being obsoleted)
- python-meh
- anaconda
- anaconda-0:15.31-1.fc15.x86_64
- firstboot-0:1.119-1.fc15.x86_64
- system-config-kickstart-0:2.8.7-2.fc15.noarch
- setroubleshoot
As I said, libreport should be API compatible with report, so no changes
should needed, but of course can't be 100% sure if it's bugfree ;)
Do we have to do anything to our packages to make this work?
Jiri Moskovcak
2011-06-29 11:24:03 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Jiri Moskovcak
Hi!
I'm going to replace the report library with the new libreport. Today I
plan to replace it in rawhide and if it goes smoothly I'd like to
replace it in F15 as well.
Hasn't this already reached F15? Have you readded the GTKIO stuff?
Post by Jiri Moskovcak
- libreport is written in C (report is in python), so it's easier to
write bindings for other languages
- it's API compatible with report (it has python bindings)
- it shares configuration with ABRT, so users just need to write their
credentials and defaults only once
- shares the UI with ABRT (the reporting wizard), so users are presented
with the same UI despite of from where they are reporting a problem
- it has a bit different UI
- account information (e.g: bz loging+password) is forgotten and needs
to be entered again
Why? Is it remembered within the session? Can't it save the bugzilla
info within the gnome-keyring?
Post by Jiri Moskovcak
- some minor breakage expected (hopefully not...)
- report + subpackages (being obsoleted)
- python-meh
- anaconda
- anaconda-0:15.31-1.fc15.x86_64
- firstboot-0:1.119-1.fc15.x86_64
- system-config-kickstart-0:2.8.7-2.fc15.noarch
- setroubleshoot
As I said, libreport should be API compatible with report, so no changes
should needed, but of course can't be 100% sure if it's bugfree ;)
Do we have to do anything to our packages to make this work?
- mentioned packages should change:
Requires: report{-gtk} to Requires: libreport{-gtk}

- but that's not needed right now since libreport provides report{-gtk}
- the references to report should be removed once we're done with the
transition
Continue reading on narkive:
Loading...