[HEADS-UP] replacing report with libreport

[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.

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]

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]

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]

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.

[Camilo Mesias]

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]

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

[Michael Schwendt]

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]

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]

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]

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]

?Actually I'd prefer to know how to move forward to the new way ...

run rawhide!

-jef

[Jeff Spaleta]

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]

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]

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]

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]

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.

[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.

[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!

[Genes MailLists]

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]

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]

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]

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]

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]

-----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