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 ;)
On 06/29/2011 03:20 PM, Jiri Moskovcak wrote:
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
On 06/29/2011 12:18 PM, Rahul Sundaram wrote:
On 06/29/2011 03:20 PM, Jiri Moskovcak wrote:
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/29/2011 05:50 AM, Jiri Moskovcak wrote:
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?
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
Why? Is it remembered within the session? Can't it save the bugzilla info within the gnome-keyring?
- 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 ;)
Do we have to do anything to our packages to make this work?
On 06/29/2011 01:16 PM, Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/29/2011 05:50 AM, Jiri Moskovcak wrote:
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?
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
Why? Is it remembered within the session? Can't it save the bugzilla info within the gnome-keyring?
- 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 ;)
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
On Wed, 2011-06-29 at 13:11 +0200, Jiri Moskovcak wrote:
On 06/29/2011 12:18 PM, Rahul Sundaram wrote:
On 06/29/2011 03:20 PM, Jiri Moskovcak wrote:
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.
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
On Wed, 2011-06-29 at 17:24 -0400, Camilo Mesias wrote:
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
https://bugzilla.redhat.com/show_bug.cgi?id=715373
On Wed, 29 Jun 2011 17:24:17 -0400, CM (Camilo) wrote:
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
Known. A faulty libreport update. Look up the existing ticket at http://bugz.fedoraproject.org/libreport if you're interested in background information.
On 06/29/2011 06:44 PM, Adam Williamson wrote:
On Wed, 2011-06-29 at 13:11 +0200, Jiri Moskovcak wrote:
On 06/29/2011 12:18 PM, Rahul Sundaram wrote:
On 06/29/2011 03:20 PM, Jiri Moskovcak wrote:
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.
On Thu, Jun 30, 2011 at 3:51 AM, Jiri Moskovcak jmoskovc@redhat.com wrote:
- 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
On 06/30/2011 12:16 PM, Jeff Spaleta wrote:
On Thu, Jun 30, 2011 at 3:51 AM, Jiri Moskovcak jmoskovc@redhat.com wrote:
- 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 ...
On Thu, Jun 30, 2011 at 9:18 AM, Genes MailLists lists@sapience.com wrote:
Actually I'd prefer to know how to move forward to the new way ...
run rawhide!
-jef
On Thu, Jun 30, 2011 at 8:16 AM, Jeff Spaleta jspaleta@gmail.com wrote:
On Thu, Jun 30, 2011 at 3:51 AM, Jiri Moskovcak jmoskovc@redhat.com wrote:
- 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
On 06/30/2011 12:16 PM, Jeff Spaleta wrote:
On Thu, Jun 30, 2011 at 3:51 AM, Jiri Moskovcak jmoskovc@redhat.com wrote:
- 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/
On 06/30/2011 07:37 PM, Genes MailLists wrote:
On 06/30/2011 12:16 PM, Jeff Spaleta wrote:
On Thu, Jun 30, 2011 at 3:51 AM, Jiri Moskovcakjmoskovc@redhat.com wrote:
- 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.
On Thu, 30 Jun 2011 21:06:17 +0200, JM (Jiri) wrote:
Whats the way forward from here in F15?
gene/
- 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:
And as pointed out in bz, it still needs a corresponding libreport-gtk update that doesn't have the bad Obs/Prov pair anymore.
- 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.
On Fri, 2011-07-01 at 01:23 +0200, Michael Schwendt wrote:
On Thu, 30 Jun 2011 21:06:17 +0200, JM (Jiri) wrote:
Whats the way forward from here in F15?
gene/
- 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:
And as pointed out in bz, it still needs a corresponding libreport-gtk update that doesn't have the bad Obs/Prov pair anymore.
- 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.
On 06/30/2011 08:26 PM, Adam Williamson wrote:
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.
On Thu, 2011-06-30 at 22:04 -0400, Genes MailLists wrote:
On 06/30/2011 08:26 PM, Adam Williamson wrote:
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!
On 06/30/2011 10:44 PM, Adam Williamson wrote:
On Thu, 2011-06-30 at 22:04 -0400, Genes MailLists wrote:
On 06/30/2011 08:26 PM, Adam Williamson wrote:
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 ... :-)
On 07/01/2011 04:04 AM, Genes MailLists wrote:
On 06/30/2011 08:26 PM, Adam Williamson wrote:
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.
On Thu, 30 Jun 2011 17:26:41 -0700, AW (Adam) wrote:
On Fri, 2011-07-01 at 01:23 +0200, Michael Schwendt wrote:
On Thu, 30 Jun 2011 21:06:17 +0200, JM (Jiri) wrote:
Whats the way forward from here in F15?
gene/
- 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:
And as pointed out in bz, it still needs a corresponding libreport-gtk update that doesn't have the bad Obs/Prov pair anymore.
- 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
On Fri, Jul 1, 2011 at 1:57 AM, Michael Schwendt mschwendt@gmail.com wrote:
Adam, Adam, Adam ;) it's this one in "updates": 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
-
Adam Williamson -
Camilo Mesias -
Daniel J Walsh -
Genes MailLists -
Jef Spaleta -
Jiri Moskovcak -
Michael Schwendt -
Rahul Sundaram