On 12/13/2010 05:43 PM, Kevin Kofler wrote:
> Jiri Moskovcak wrote:
>> This is not a first time when in see this idea and was already answered
>> - we're the distro and we're responsible for the packages, filling all
>> bugs to the upstream will make more harm then good - e.g. crash caused
>> by ou
Jiri Moskovcak wrote:
> This is not a first time when in see this idea and was already answered
> - we're the distro and we're responsible for the packages, filling all
> bugs to the upstream will make more harm then good - e.g. crash caused
> by our patch or by some library which has different ups
Dave Jones wrote:
> I'm not sure what point you're trying to make, but there's a pretty big
> difference between completely ignoring automatically filed bugs
> (regardless of where they're filed), and automatically filing those bugs
> upstream.
Of course. But that's why I'm advocating doing the la
On 12/13/2010 02:17 PM, Jiri Moskovcak wrote:
> On 12/13/2010 01:14 PM, Jaroslav Reznik wrote:
>> On Thursday, December 09, 2010 06:24:15 pm Jiri Moskovcak wrote:
>>> On 12/09/2010 06:11 PM, Adam Williamson wrote:
On Thu, 2010-12-09 at 17:36 +0100, Jiri Moskovcak wrote:
> so, can we call t
On 12/13/2010 01:14 PM, Jaroslav Reznik wrote:
> On Thursday, December 09, 2010 06:24:15 pm Jiri Moskovcak wrote:
>> On 12/09/2010 06:11 PM, Adam Williamson wrote:
>>> On Thu, 2010-12-09 at 17:36 +0100, Jiri Moskovcak wrote:
so, can we call the RFE: "attach backtrace even when dupe is found" ?
On Mon, Dec 13, 2010 at 12:46:04AM +0100, Jiri Moskovcak wrote:
> > Apropos of nothing: kerneloops reporting seems to have been broken ever
> > since
> > we switched from using the kerneloops client to abrt, but that's another
> > story..
>
> - I reported quite a few oops using abrt (even
On 12/12/2010 06:10 AM, Dave Jones wrote:
> On Sun, Dec 12, 2010 at 02:11:27AM +0100, Kevin Kofler wrote:
> > Dave Jones wrote:
> >
> > > On Sat, Dec 11, 2010 at 12:45:10PM +0100, Jiri Moskovcak wrote:
> > >
> > > > The problem here is that some maintainers doesn't want ABRT
> re
On Sun, Dec 12, 2010 at 02:11:27AM +0100, Kevin Kofler wrote:
> Dave Jones wrote:
>
> > On Sat, Dec 11, 2010 at 12:45:10PM +0100, Jiri Moskovcak wrote:
> >
> > > The problem here is that some maintainers doesn't want ABRT reports at
> > > all even those not yet reported...
> >
> > It'
Dave Jones wrote:
> On Sat, Dec 11, 2010 at 12:45:10PM +0100, Jiri Moskovcak wrote:
>
> > The problem here is that some maintainers doesn't want ABRT reports at
> > all even those not yet reported...
>
> It's arguable that such people are 'maintainers' at all if this is the
> case. I find it
On Sat, Dec 11, 2010 at 12:45:10PM +0100, Jiri Moskovcak wrote:
> The problem here is that some maintainers doesn't want ABRT reports at
> all even those not yet reported...
It's arguable that such people are 'maintainers' at all if this is the case.
I find it quite sad that we have packagers
On 12/11/2010 02:15 PM, Jiri Moskovcak wrote:
will/not operate.
>>
>
> ABRT already has a blacklist configurable in it's config file, but it's
> controlled by ABRT maintainers... the problem or the request here is to
> have a directory like /etc/abrt.d/ where other maintainers can drop a
> con
On 12/11/2010 03:55 PM, Genes MailLists wrote:
> On 12/11/2010 06:45 AM, Jiri Moskovcak wrote:
>
>>
>> If ABRT can tell that the backtrace is same as something previously
>> reported then there is no big harm, as it would only add the reporter to
>> CC and won't be generating much noise..
>> The pr
On 12/11/2010 06:45 AM, Jiri Moskovcak wrote:
>
> If ABRT can tell that the backtrace is same as something previously
> reported then there is no big harm, as it would only add the reporter to
> CC and won't be generating much noise..
> The problem here is that some maintainers doesn't want ABR
On 12/11/2010 02:05 AM, Dave Jones wrote:
> On Fri, Dec 10, 2010 at 10:51:39AM +0100, Jiri Moskovcak wrote:
>
> > > The problem is entirely cosmetic. No data is harmed, the program exits
> > > after that, it's just a child thread and the main process don't
> > > communicate the exit qui
On 12/11/2010 02:55 AM, Kevin Kofler wrote:
> drago01 wrote:
>> Well ABRT should stop filing bugs in bugzilla, it does not scale PERIOD.
>
> IMHO it should file bugs in the upstream bug tracker (even if that tracker
> is not Bugzilla, so it'd have to learn as many different bug tracker APIs as
> po
drago01 wrote:
> Well ABRT should stop filing bugs in bugzilla, it does not scale PERIOD.
IMHO it should file bugs in the upstream bug tracker (even if that tracker
is not Bugzilla, so it'd have to learn as many different bug tracker APIs as
possible).
Gnash upstream actually MIGHT be able to d
On Fri, Dec 10, 2010 at 10:51:39AM +0100, Jiri Moskovcak wrote:
> > The problem is entirely cosmetic. No data is harmed, the program exits
> > after that, it's just a child thread and the main process don't
> > communicate the exit quite right. So, pretty much everyone who uses
> > calibre se
Hi,
On Thu, Dec 9, 2010 at 7:57 PM, Adam Williamson wrote:
>
> if it just invisibly doesn't run, I'd try it again, but if I'm running
> it from the console and it spits out a clear fatal error and crashes,
> yeah, I'm not going to run it again. That'd be pointless.
I would hope that most people
On 12/09/2010 08:57 PM, Kevin Fenzi wrote:
> On Thu, 09 Dec 2010 14:53:20 -0500
> Przemek Klosowski wrote:
>
>> On 12/09/2010 12:05 PM, Adam Williamson wrote:
>>> On Thu, 2010-12-09 at 12:08 +, "Jóhann B. Guðmundsson" wrote:
On 12/09/2010 09:59 AM, Jiri Moskovcak wrote:
> Just a wild
On 12/09/2010 08:57 PM, Adam Williamson wrote:
> On Thu, 2010-12-09 at 14:53 -0500, Przemek Klosowski wrote:
>> On 12/09/2010 12:05 PM, Adam Williamson wrote:
>>> On Thu, 2010-12-09 at 12:08 +, "Jóhann B. Guðmundsson" wrote:
On 12/09/2010 09:59 AM, Jiri Moskovcak wrote:
> Just a wild i
On Thu, 2010-12-09 at 14:53 -0500, Przemek Klosowski wrote:
> On 12/09/2010 12:05 PM, Adam Williamson wrote:
> > On Thu, 2010-12-09 at 12:08 +, "Jóhann B. Guðmundsson" wrote:
> >> On 12/09/2010 09:59 AM, Jiri Moskovcak wrote:
> >>> Just a wild idea - ABRT detects the dupes even locally so we ca
On Thu, 09 Dec 2010 14:53:20 -0500
Przemek Klosowski wrote:
> On 12/09/2010 12:05 PM, Adam Williamson wrote:
> > On Thu, 2010-12-09 at 12:08 +, "Jóhann B. Guðmundsson" wrote:
> >> On 12/09/2010 09:59 AM, Jiri Moskovcak wrote:
> >>> Just a wild idea - ABRT detects the dupes even locally so we
On 12/09/2010 12:05 PM, Adam Williamson wrote:
> On Thu, 2010-12-09 at 12:08 +, "Jóhann B. Guðmundsson" wrote:
>> On 12/09/2010 09:59 AM, Jiri Moskovcak wrote:
>>> Just a wild idea - ABRT detects the dupes even locally so we can make
>>> ABRT to allow reporting the bug to bz only if it happened
On Thu, 2010-12-09 at 18:24 +0100, Jiri Moskovcak wrote:
> On 12/09/2010 06:11 PM, Adam Williamson wrote:
> > On Thu, 2010-12-09 at 17:36 +0100, Jiri Moskovcak wrote:
> >
> >> so, can we call the RFE: "attach backtrace even when dupe is found" ?
> >
> > or, cooler, 'attach backtrace even when dupe
On 12/09/2010 06:11 PM, Adam Williamson wrote:
> On Thu, 2010-12-09 at 17:36 +0100, Jiri Moskovcak wrote:
>
>> so, can we call the RFE: "attach backtrace even when dupe is found" ?
>
> or, cooler, 'attach backtrace even when dupe is found *if current
> backtrace is better than any already attached
On Thu, Dec 9, 2010 at 10:38 AM, Tomas Mraz wrote:
>> 18:53:17 i've heard a modest amount of complaints that abrt is doing
>> more harm than good
>> 18:53:53 along multiple axes, but in particular it's simply too much
>> data for apps like firefox and evo for maintainers to respond to
>> 18:54
On Thu, 2010-12-09 at 17:36 +0100, Jiri Moskovcak wrote:
> so, can we call the RFE: "attach backtrace even when dupe is found" ?
or, cooler, 'attach backtrace even when dupe is found *if current
backtrace is better than any already attached to the bug*'.
--
Adam Williamson
Fedora QA Community Mo
On Thu, 2010-12-09 at 12:08 +, "Jóhann B. Guðmundsson" wrote:
> On 12/09/2010 09:59 AM, Jiri Moskovcak wrote:
> > Just a wild idea - ABRT detects the dupes even locally so we can make
> > ABRT to allow reporting the bug to bz only if it happened more then once
> > (or some other threshold):)
>
* Jiri Moskovcak [09/12/2010 17:42] :
>
> so, can we call the RFE: "attach backtrace even when dupe is found" ?
- "Always attach backtrace"
- "Do not do so in Bugzilla"
Emmanuel
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On 12/09/2010 05:31 PM, Nicolas Mailhot wrote:
>
> Le Jeu 9 décembre 2010 15:52, Ralf Corsepius a écrit :
>
>> It has never done so for me (on fedora 13 + fedora 14). ABRT always
>> instructs me to run debuginfo-install, which will fail for obvious
>> reasons in a normal user environment and thus r
Le Jeu 9 décembre 2010 15:52, Ralf Corsepius a écrit :
> It has never done so for me (on fedora 13 + fedora 14). ABRT always
> instructs me to run debuginfo-install, which will fail for obvious
> reasons in a normal user environment and thus requires me to become root
> (On "real ordinary user" s
On 12/09/2010 03:52 PM, Ralf Corsepius wrote:
> On 12/09/2010 02:59 PM, Jiri Moskovcak wrote:
>> On 12/09/2010 02:04 PM, Ralf Corsepius wrote:
>>> On 12/09/2010 01:27 PM, Jiri Moskovcak wrote:
On 12/09/2010 01:08 PM, "Jóhann B. Guðmundsson" wrote:
> On 12/09/2010 09:59 AM, Jiri Moskovcak w
On 12/09/2010 08:59 AM, Jiri Moskovcak wrote:
>
> - debuginfo-install is just a fallback if ABRT fails to retrieve the
> debuginfo itself (and ABRT doesn't need the root privs, as is *does not*
> install the packages, it just unpacks them)
>
> Jirka
Currently, abrt says the debuginfo packages ar
On 12/09/2010 02:59 PM, Jiri Moskovcak wrote:
> On 12/09/2010 02:04 PM, Ralf Corsepius wrote:
>> On 12/09/2010 01:27 PM, Jiri Moskovcak wrote:
>>> On 12/09/2010 01:08 PM, "Jóhann B. Guðmundsson" wrote:
On 12/09/2010 09:59 AM, Jiri Moskovcak wrote:
> Just a wild idea - ABRT detects the dupe
On 12/09/2010 02:04 PM, Ralf Corsepius wrote:
> On 12/09/2010 01:27 PM, Jiri Moskovcak wrote:
>> On 12/09/2010 01:08 PM, "Jóhann B. Guðmundsson" wrote:
>>> On 12/09/2010 09:59 AM, Jiri Moskovcak wrote:
Just a wild idea - ABRT detects the dupes even locally so we can make
ABRT to allow rep
On 12/09/2010 01:27 PM, Jiri Moskovcak wrote:
> On 12/09/2010 01:08 PM, "Jóhann B. Guðmundsson" wrote:
>> On 12/09/2010 09:59 AM, Jiri Moskovcak wrote:
>>> Just a wild idea - ABRT detects the dupes even locally so we can make
>>> ABRT to allow reporting the bug to bz only if it happened more then o
On 12/09/2010 01:08 PM, "Jóhann B. Guðmundsson" wrote:
> On 12/09/2010 09:59 AM, Jiri Moskovcak wrote:
>> Just a wild idea - ABRT detects the dupes even locally so we can make
>> ABRT to allow reporting the bug to bz only if it happened more then once
>> (or some other threshold):)
>
> Dont we loos
On 02:18:47 pm Thursday, December 09, 2010 Jóhann B. Guðmundsson wrote:
> On 12/09/2010 09:59 AM, Jiri Moskovcak wrote:
> > Just a wild idea - ABRT detects the dupes even locally so we can make
> > ABRT to allow reporting the bug to bz only if it happened more then once
> > (or some other threshold
On 12/09/2010 09:59 AM, Jiri Moskovcak wrote:
> Just a wild idea - ABRT detects the dupes even locally so we can make
> ABRT to allow reporting the bug to bz only if it happened more then once
> (or some other threshold):)
Dont we loose hard to catch odd ball bugs if that's implemented?
JBG
--
d
On 12/09/2010 10:55 AM, Jiri Moskovcak wrote:
> On 12/09/2010 10:38 AM, Tomas Mraz wrote:
>>> 18:53:17 i've heard a modest amount of complaints that abrt is
>>> doing more harm than good
>>> 18:53:53 along multiple axes, but in particular it's simply too
>>> much data for apps like firefox an
On 12/09/2010 10:38 AM, Tomas Mraz wrote:
>> 18:53:17 i've heard a modest amount of complaints that abrt is doing
>> more harm than good
>> 18:53:53 along multiple axes, but in particular it's simply too much
>> data for apps like firefox and evo for maintainers to respond to
>> 18:54:22 i don
> 18:53:17 i've heard a modest amount of complaints that abrt is doing
> more harm than good
> 18:53:53 along multiple axes, but in particular it's simply too much
> data for apps like firefox and evo for maintainers to respond to
> 18:54:22 i don't have any particular suggestions for this (we
42 matches
Mail list logo
