FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 07-01-2010, 12:40 PM
Dan Hork
 
Default rebuild of wxGTK without the internal crash handler in Rawhide

Hello,

I will rebuild wxGTK without the internal crash handler for the the
devel/F14 branch so we can use ABRT to report crashes from wxGTK-based
apps. This will mean a rebuild of wxGTK with --disable-catch_segvs and
this change affects all applications linked with wxGTK, because one
symbol is removed from the "base" library. I will take care of
rebuilding the packages in the next days, but the package owners should
still check what is their implementation of the
wxApp::OnFatalExpection() virtual method doing, because it will not be
called anymore. Usually it is used to display the wxGTK-based crash
report. Please let me know if you want to rebuild the package yourself
or if you have some questions.

This is the list of packages that have wxGTK-devel as BuildRequires:

DivFix++
LuxRender
OpenSceneGraph
audacity
bacula
boinc-client
codeblocks
crystalspace
erlang
extrema
fbg
filezilla
fityk
flamerobin
freedink-dfarc
gdl
glest
gnuplot
gspiceui
hugin
iaxclient
kicad
mathgl
mkvtoolnix
mrpt
multiget
nightview
panoglview
perl-Alien-wxWidgets (doesn't look to link with library?)
perl-Wx
pgadmin3
plee-the-bear
plplot
poedit
rapidsvn
scorched3d
scummvm-tools
simdock
sooperlooper
springlobby
toped
trustedqsl
ucblogo
vavoom
wxMaxima
wxPython
xchm
xmlcopyeditor


Dan


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-02-2010, 02:06 AM
Kevin Kofler
 
Default rebuild of wxGTK without the internal crash handler in Rawhide

Dan Hork wrote:
> I will rebuild wxGTK without the internal crash handler for the the
> devel/F14 branch so we can use ABRT to report crashes from wxGTK-based
> apps. This will mean a rebuild of wxGTK with --disable-catch_segvs and
> this change affects all applications linked with wxGTK, because one
> symbol is removed from the "base" library. I will take care of
> rebuilding the packages in the next days, but the package owners should
> still check what is their implementation of the
> wxApp::OnFatalExpection() virtual method doing, because it will not be
> called anymore. Usually it is used to display the wxGTK-based crash
> report. Please let me know if you want to rebuild the package yourself
> or if you have some questions.

Do you really think this is a good idea? IMHO crash reports should go
upstream, so using upstream's crash handler is a much better idea. ABRT
spams our downstream Bugzilla with crash reports which really should go
upstream instead. It's also technically nicer for the crash handler to be in
the app, since it prevents having to dump core and then having an external
process inspect the core dump.

FWIW, we have no plans to disable KCrash/DrKonqi in KDE at this time. We're
already having enough trouble with the small percentage of crashes which
makes it through to ABRT for whatever reason (non-GUI KDE apps (which cannot
currently use KCrash because it's in kdeui), kdesupport stuff, recurring
crashes in autorespawned stuff like plasma-desktop (where KCrash gets
disabled on respawn to prevent infinite respawning loops), KCrash itself
crashing (ugh!)), since those are still hundreds of bugs!

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-02-2010, 10:58 AM
Dan Horák
 
Default rebuild of wxGTK without the internal crash handler in Rawhide

Kevin Kofler p*še v Pá 02. 07. 2010 v 04:06 +0200:
> Dan Horák wrote:
> > I will rebuild wxGTK without the internal crash handler for the the
> > devel/F14 branch so we can use ABRT to report crashes from wxGTK-based
> > apps. This will mean a rebuild of wxGTK with --disable-catch_segvs and
> > this change affects all applications linked with wxGTK, because one
> > symbol is removed from the "base" library. I will take care of
> > rebuilding the packages in the next days, but the package owners should
> > still check what is their implementation of the
> > wxApp::OnFatalExpection() virtual method doing, because it will not be
> > called anymore. Usually it is used to display the wxGTK-based crash
> > report. Please let me know if you want to rebuild the package yourself
> > or if you have some questions.
>
> Do you really think this is a good idea? IMHO crash reports should go
> upstream, so using upstream's crash handler is a much better idea. ABRT
> spams our downstream Bugzilla with crash reports which really should go
> upstream instead. It's also technically nicer for the crash handler to be in
> the app, since it prevents having to dump core and then having an external
> process inspect the core dump.

But the default crash handler only creates a text file with a rather
useless stack trace and the file is stored on the local computer. So in
fact the crash is lost for everybody but the concrete user who usually
can do nothing with it.

If someone from the application maintainers will come with an argument
against, we can discuss a better solution.


Dan


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-02-2010, 11:21 AM
Thomas Janssen
 
Default rebuild of wxGTK without the internal crash handler in Rawhide

On Fri, Jul 2, 2010 at 12:58 PM, Dan Horák <dan@danny.cz> wrote:
> Kevin Kofler p*še v Pá 02. 07. 2010 v 04:06 +0200:
>> Dan Horák wrote:
>> > I will rebuild wxGTK without the internal crash handler for the the
>> > devel/F14 branch so we can use ABRT to report crashes from wxGTK-based
>> > apps. This will mean a rebuild of wxGTK with --disable-catch_segvs and
>> > this change affects all applications linked with wxGTK, because one
>> > symbol is removed from the "base" library. I will take care of
>> > rebuilding the packages in the next days, but the package owners should
>> > still check what is their implementation of the
>> > wxApp::OnFatalExpection() virtual method doing, because it will not be
>> > called anymore. Usually it is used to display the wxGTK-based crash
>> > report. Please let me know if you want to rebuild the package yourself
>> > or if you have some questions.
>>
>> Do you really think this is a good idea? IMHO crash reports should go
>> upstream, so using upstream's crash handler is a much better idea. ABRT
>> spams our downstream Bugzilla with crash reports which really should go
>> upstream instead. It's also technically nicer for the crash handler to be in
>> the app, since it prevents having to dump core and then having an external
>> process inspect the core dump.
>
> But the default crash handler only creates a text file with a rather
> useless stack trace and the file is stored on the local computer.

This question might not be very popular, but do you really think that
a, in your eyes useless stack trace (upstream obviously want that) is
any better than a useless ABRT backtrace? The not popular part comes
in as the ABRT backtrace is useless as almost nobody of the
packagers/maintainers are able to read it (me included) and upstream
doesn't care about it. All that happens is that our BZ gets spammed
with it. Yes, i'm a bit frustrated about this traces :-)

I really really would love to see at least one ABRT developer giving a
class (we have #fedora-classroom for that) "how to read and understand
ABRT backtraces".

--
LG Thomas

Dubium sapientiae initium
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-02-2010, 01:27 PM
Dan Horák
 
Default rebuild of wxGTK without the internal crash handler in Rawhide

Thomas Janssen p*še v Pá 02. 07. 2010 v 13:21 +0200:
> On Fri, Jul 2, 2010 at 12:58 PM, Dan Horák <dan@danny.cz> wrote:
> > Kevin Kofler p*še v Pá 02. 07. 2010 v 04:06 +0200:
> >> Dan Horák wrote:
> >> > I will rebuild wxGTK without the internal crash handler for the the
> >> > devel/F14 branch so we can use ABRT to report crashes from wxGTK-based
> >> > apps. This will mean a rebuild of wxGTK with --disable-catch_segvs and
> >> > this change affects all applications linked with wxGTK, because one
> >> > symbol is removed from the "base" library. I will take care of
> >> > rebuilding the packages in the next days, but the package owners should
> >> > still check what is their implementation of the
> >> > wxApp::OnFatalExpection() virtual method doing, because it will not be
> >> > called anymore. Usually it is used to display the wxGTK-based crash
> >> > report. Please let me know if you want to rebuild the package yourself
> >> > or if you have some questions.
> >>
> >> Do you really think this is a good idea? IMHO crash reports should go
> >> upstream, so using upstream's crash handler is a much better idea. ABRT
> >> spams our downstream Bugzilla with crash reports which really should go
> >> upstream instead. It's also technically nicer for the crash handler to be in
> >> the app, since it prevents having to dump core and then having an external
> >> process inspect the core dump.
> >
> > But the default crash handler only creates a text file with a rather
> > useless stack trace and the file is stored on the local computer.
>
> This question might not be very popular, but do you really think that
> a, in your eyes useless stack trace (upstream obviously want that) is

what upstream? wxGTK upstream (who adds the default handler) is
generally not interested in crashed application. And the application
should build its own handler only if the symbol wxUSE_ON_FATAL_EXCEPTION
is defined by the wxGTK library as it's an optional functionality.

> any better than a useless ABRT backtrace? The not popular part comes
> in as the ABRT backtrace is useless as almost nobody of the
> packagers/maintainers are able to read it (me included) and upstream
> doesn't care about it. All that happens is that our BZ gets spammed
> with it. Yes, i'm a bit frustrated about this traces :-)
>
> I really really would love to see at least one ABRT developer giving a
> class (we have #fedora-classroom for that) "how to read and understand
> ABRT backtraces".

The backtraces ABRT generates are not specific to ABRT, they are normal
backtraces from gdb, so anyone with enough gdb and debugging knowledge
could do it. ABRT ensures that the backtrace is generated with debug
information installed meaning it will contain more useful information.


Dan


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-09-2010, 12:27 PM
Dan Horák
 
Default rebuild of wxGTK without the internal crash handler in Rawhide

Dan Horák p*še v Čt 01. 07. 2010 v 14:40 +0200:
> Hello,
>
> I will rebuild wxGTK without the internal crash handler for the the
> devel/F14 branch so we can use ABRT to report crashes from wxGTK-based
> apps. This will mean a rebuild of wxGTK with --disable-catch_segvs and
> this change affects all applications linked with wxGTK, because one
> symbol is removed from the "base" library. I will take care of
> rebuilding the packages in the next days, but the package owners should
> still check what is their implementation of the
> wxApp::OnFatalExpection() virtual method doing, because it will not be
> called anymore. Usually it is used to display the wxGTK-based crash
> report. Please let me know if you want to rebuild the package yourself
> or if you have some questions.

wxGTK-2.8.11-2 is built in Rawhide and EPEL-6. I will continue
rebuilding the packages from the list below after the koji outage.


Dan

> This is the list of packages that have wxGTK-devel as BuildRequires:
>
> DivFix++
> LuxRender
> OpenSceneGraph
> audacity
> bacula
> boinc-client
> codeblocks
> crystalspace
> erlang
> extrema
> fbg
> filezilla
> fityk
> flamerobin
> freedink-dfarc
> gdl
> glest
> gnuplot
> gspiceui
> hugin
> iaxclient
> kicad
> mathgl
> mkvtoolnix
> mrpt
> multiget
> nightview
> panoglview
> perl-Alien-wxWidgets (doesn't look to link with library?)
> perl-Wx
> pgadmin3
> plee-the-bear
> plplot
> poedit
> rapidsvn
> scorched3d
> scummvm-tools
> simdock
> sooperlooper
> springlobby
> toped
> trustedqsl
> ucblogo
> vavoom
> wxMaxima
> wxPython
> xchm
> xmlcopyeditor
>
>
> Dan
>
>


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-09-2010, 12:27 PM
Dan Horák
 
Default rebuild of wxGTK without the internal crash handler in Rawhide

Dan Horák p*še v Čt 01. 07. 2010 v 14:40 +0200:
> Hello,
>
> I will rebuild wxGTK without the internal crash handler for the the
> devel/F14 branch so we can use ABRT to report crashes from wxGTK-based
> apps. This will mean a rebuild of wxGTK with --disable-catch_segvs and
> this change affects all applications linked with wxGTK, because one
> symbol is removed from the "base" library. I will take care of
> rebuilding the packages in the next days, but the package owners should
> still check what is their implementation of the
> wxApp::OnFatalExpection() virtual method doing, because it will not be
> called anymore. Usually it is used to display the wxGTK-based crash
> report. Please let me know if you want to rebuild the package yourself
> or if you have some questions.

wxGTK-2.8.11-2 is built in Rawhide and EPEL-6. I will continue
rebuilding the packages from the list below after the koji outage.


Dan

> This is the list of packages that have wxGTK-devel as BuildRequires:
>
> DivFix++
> LuxRender
> OpenSceneGraph
> audacity
> bacula
> boinc-client
> codeblocks
> crystalspace
> erlang
> extrema
> fbg
> filezilla
> fityk
> flamerobin
> freedink-dfarc
> gdl
> glest
> gnuplot
> gspiceui
> hugin
> iaxclient
> kicad
> mathgl
> mkvtoolnix
> mrpt
> multiget
> nightview
> panoglview
> perl-Alien-wxWidgets (doesn't look to link with library?)
> perl-Wx
> pgadmin3
> plee-the-bear
> plplot
> poedit
> rapidsvn
> scorched3d
> scummvm-tools
> simdock
> sooperlooper
> springlobby
> toped
> trustedqsl
> ucblogo
> vavoom
> wxMaxima
> wxPython
> xchm
> xmlcopyeditor
>
>
> Dan
>
>


_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 07-16-2010, 10:34 AM
Dan Hork
 
Default rebuild of wxGTK without the internal crash handler in Rawhide

the result of the rebuild are:

failed to build due the removed function, here I will prepare a fix
multiget

failed to build due other problems:
audacity
plee-the-bear
ucblogo


Dan


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-16-2010, 10:58 AM
Michael Schwendt
 
Default rebuild of wxGTK without the internal crash handler in Rawhide

On Fri, 16 Jul 2010 12:34:54 +0200, Dan wrote:

> the result of the rebuild are:
>
> failed to build due the removed function, here I will prepare a fix
> multiget
>
> failed to build due other problems:
> audacity

Likely fall-out from the recent upgrade to GCC 4.5.0 a few days ago.

> plee-the-bear
> ucblogo
>
>
> Dan
>
>
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 06:46 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org