ABRT unusable again
 

On 02/07/2010 03:15 AM, Karel Klic wrote:
> Kevin Kofler wrote:
>> Stefan Schulze Frielinghaus wrote:
>>> However, in the meantime I stopped reporting crashes via ABRT because I
>>> think it raises the load for a package maintainer to high while the
>>> report should go directly to upstream. Bothering the maintainer first
>>> instead of upstream is not the right thing to do.
>>
>> +1, in fact that's the biggest design failure in ABRT (in its current state)
>> and basically makes it useless. Gathering backtraces is something that needs
>> to be handled by upstream projects (like KDE does with KCrash/DrKonqi), not
>> distributions.

To end-users, it's irrelevant "who is supposed to fix something". Their
complaints are against the product call Fedora and thus expect "Fedora
to fix their product".

That said: It's irrelevant to Toyota car owners, which supplier
manufactured the parts which have caused Toyota to call back 1000 of
their cars - To them it's Toyota who is reponisible, and Toyota's duty
to fix this issue.

> Some maintainers fix crashes in their packages and then send the fixes
> to the upstream, and some don't. Some crashes are caused by
> distribution-specific environment, and some are not :) It's not clear
> whether we should report crashes directly to the upstream.

History tells, low quality automated bug reports to be ignored and to
cause a lot of bad blood. Debian for instance has an unfortunate history
in doing so - You're better off to learn from their historic mistakes!

> For some packages, reporting upstream could work well (Firefox,
> OpenOffice.org come to my mind).
You mean big, well-known projects with a fully-blown up infrastructure
and bureaucracy in place. It's naive to expect such an infrastructure to
be in place for all projects.

> However, many packages have
> unresponsive/dead upstream, upstream without issue tracker etc.
Read my previous sentence.

Also take into account that many upstreams will consider automated bug
reports, to be "simply SPAM", esp. when the find them to be of low
quality. If you're lucky, they will simply ignore them, if you're less
lucky, they will confront you with very harsh responses.


Finally: Why are we discussing this here?

This is all should have been part of ABRT's concepts, its upstream
should have considered and resolved before unleashing ABRT.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Sun Feb 7 10:30:02 2010
Return-path: <bounce-debian-user=tom=linux-archive.org@lists.debian.org>
Envelope-to: tom@linux-archive.org
Delivery-date: Sun, 07 Feb 2010 09:46:11 +0200
Received: from liszt.debian.org ([82.195.75.100]:56974)
by s2.java-tips.org with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.69)
(envelope-from <bounce-debian-user=tom=linux-archive.org@lists.debian.org>)
id 1Ne1qL-0000N2-Iz
for tom@linux-archive.org; Sun, 07 Feb 2010 09:46:09 +0200
Received: from localhost (localhost [127.0.0.1])
by liszt.debian.org (Postfix) with QMQP
id 5460C2D0C32; Sun, 7 Feb 2010 08:14:14 +0000 (UTC)
Old-Return-Path: <gpall@ccf.auth.gr>
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on liszt.debian.org
X-Spam-Level:
X-Spam-Status: No, score=-10.9 required=4.0 tests=FOURLA,LDOSUBSCRIBER,
LDO_WHITELIST autolearn=failed version=3.2.5
X-Original-To: lists-debian-user@liszt.debian.org
Delivered-To: lists-debian-user@liszt.debian.org
Received: from localhost (localhost [127.0.0.1])
by liszt.debian.org (Postfix) with ESMTP id 7B6D22D0C5A
for <lists-debian-user@liszt.debian.org>; Sun, 7 Feb 2010 08:14:07 +0000 (UTC)
X-Virus-Scanned: at lists.debian.org with policy bank en-ht
X-Amavis-Spam-Status: No, score=-5.4 tagged_above=-10000 required=5.3
tests=[BAYES_00=-2, BODY_8BITS=1.5, FOURLA=0.1, LDO_WHITELIST=-5]
autolearn=ham
Received: from liszt.debian.org ([127.0.0.1])
by localhost (lists.debian.org [127.0.0.1]) (amavisd-new, port 2525)
with ESMTP id HZ1YC2RqjuBH for <lists-debian-user@liszt.debian.org>;
Sun, 7 Feb 2010 08:14:00 +0000 (UTC)
X-policyd-weight: using cached result; rate: -7
Received: from hermes3.ccf.auth.gr (hermes3.ccf.auth.gr [155.207.1.69])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client CN "AUTH Mail Servers", Issuer "AUTH Network Operations Center Certification Authority R3" (not verified))
by liszt.debian.org (Postfix) with ESMTPS id DD01E2D0C32
for <debian-user@lists.debian.org>; Sun, 7 Feb 2010 08:13:59 +0000 (UTC)
Received: from [192.168.1.200] (79.103.199.184.dsl.dyn.forthnet.gr [79.103.199.184])
(authenticated bits=0)
by hermes3.ccf.auth.gr (8.14.3/8.14.3) with ESMTP id o178DqQe002933
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
Sun, 7 Feb 2010 10:13:54 +0200
Message-ID: <4B6E7640.2@ccf.auth.gr>
Date: Sun, 07 Feb 2010 10:13:52 +0200
From: =?UTF-8?B?zpPOuc+Oz4HOs86/z4IgzqDOrM67zrvOsc+C?=
<gpall@ccf.auth.gr>
User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090707)
MIME-Version: 1.0
To: Matthew Moore <anonymous.jondoe@gmail.com>
CC: debian-user@lists.debian.org, ml@well-adjusted.de, zlinuxman@wowway.com
Subject: Re: KMS, vga=791 and intel xorg driver
References: <4B6DE0C2.4040709@ccf.auth.gr> <201002061644.28915.anonymous.jondoe@gmail.com>
In-Reply-To: <201002061644.28915.anonymous.jondoe@gmail.com>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060402030006030204000309"
X-Virus-Scanned: clamav-milter 0.95.3 at hermes1
X-Virus-Status: Clean
X-Rc-Virus: 2007-09-13_01
X-Rc-Spam: 2008-11-04_01
Resent-Message-ID: <mwvQn8YDg5B.A.OS.WZnbLB@liszt>
Resent-From: debian-user@lists.debian.org
X-Mailing-List: <debian-user@lists.debian.org> archive/latest/568995
X-Loop: debian-user@lists.debian.org
List-Id: <debian-user.lists.debian.org>
List-Post: <mailto:debian-user@lists.debian.org>
List-Help: <mailto:debian-user-request@lists.debian.org?subject=help>
List-Subscribe: <mailto:debian-user-request@lists.debian.org?subject=subscribe>
List-Unsubscribe: <mailto:debian-user-request@lists.debian.org?subject=unsubscribe>
Precedence: list
Resent-Sender: debian-user-request@lists.debian.org
Resent-Date: Sun, 7 Feb 2010 08:14:14 +0000 (UTC)

This is a cryptographically signed message in MIME format.

--------------ms060402030006030204000309
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Matthew Moore wrote:
> On Saturday February 6 2010 2:36:02 pm =CE=93=CE=B9=CF=8E=CF=81=CE=B3=CE=
=BF=CF=82 =CE=A0=CE=AC=CE=BB=CE=BB=CE=B1=CF=82 wrote:
> =20
>> So I removed vga=3D791 and problems with getting a console were resolv=
ed.
>>
>> In order to have a good resolution for my console while the pc is
>> booting, I used the
>> GRUB_GFXMODE=3D1440x900 directive in the grub2 config, but while it st=
arts
>> at this resolution, after the message 'Loading the initial image' (or
>> something like that), it reverts again to a very low analysis. How can=
I
>> fix that?
>> =20
>
> I think that you need to append "video=3Di915" to the linux command lin=
e, via=20
> the variable GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub. This spec=
ifies=20
> the KMS driver for the kernel to use.=20
>
> When KMS gets loaded, it resets the console's scrollback buffer. Since =
the KMS=20
> driver gets loaded late in the boot process in Debian (later than in mo=
st=20
> other distro's), you won't be able to see any of your boot messages onc=
e your=20
> machine reaches login. Apparently this is going to be fixed in the futu=
re.
>
> MM
>
> =20

Thanks for your answers everybody!
So, I got it working by adding

video=3Di915:modeset=3D1

to the GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub.

I also want to add that I don't see happening what Matthew wrote. I can s=
ee all the boot messages while the machine boots, and after the machine r=
eaches login prompt. Even now, from the X session, if I press CTRL-F1 I g=
et to the console where there are the boot messages, and at the bottom, t=
he login prompt.

Cheers,
Giorgos




--------------ms060402030006030204000309
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCS qGSIb3DQEHAQAAoIIhHjCC
CAswggbzoAMCAQICBQEAAAARMA0GCSqGSIb3DQEBBQUAMIGVMQ swCQYDVQQGEwJHUjFEMEIG
A1UEChM7SGVsbGVuaWMgQWNhZGVtaWMgYW5kIFJlc2VhcmNoIE luc3RpdHV0aW9ucyBDZXJ0
LiBBdXRob3JpdHkxQDA+BgNVBAMTN0hlbGxlbmljIEFjYWRlbW ljIGFuZCBSZXNlYXJjaCBJ
bnN0aXR1dGlvbnMgUm9vdENBIDIwMDYwHhcNMDkwMjE4MTEzOT A5WhcNMTcwMjE2MTEzOTA5
WjCBnjELMAkGA1UEBhMCR1IxLTArBgNVBAoTJEFyaXN0b3RsZS BVbml2ZXJzaXR5IG9mIFRo
ZXNzYWxvbmlraTE7MDkGA1UEAxMyQXJpc3RvdGxlIFVuaXZlcn NpdHkgb2YgVGhlc3NhbG9u
aWtpIENlbnRyYWwgQ0EgUjIxIzAhBgkqhkiG9w0BCQEWFHBraW FkbWluQGNjZi5hdXRoLmdy
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAymcX6u ssFCSCQe80wltOvHEQWwQp
SVqqy3i9CcjyogzeF7IRQEjMQghyvMwDteFJEpr4e9CDrWd6sp N6lmtDuh3/6iiRpfiRHUf5
zXqmR/7qf6ykpKPyuu/xbqwqoQOOLIHomRtE2EiC3XxcdaAjhDrwYrf7Yfh6Kv6PEUw8f Vwx
GYl47itXxFdiT2kW01K+IUKTbWdkQmPuz2FK4imfbbKyDpl8vW 6a6w3Tv38HyTCNlxLh0uad
V+jsV9ZxdvvX1BWoVer/CjQdgWVwl9IX0wiN8ydDpyv3jMDd2xtMID0tUBbR3hUrezCy9S S5
QalstDWhF9JNTacGuvq2tpllTQIDAQABo4IEVTCCBFEwDwYDVR 0TAQH/BAUwAwEB/zALBgNV
HQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgAHMB0GA1UdDgQWBB QYbmzt1V97ykSHIJYF2nkO
/mstPjAfBgNVHREEGDAWgRRwa2lhZG1pbkBjY2YuYXV0aC5ncjA XBgNVHRIEEDAOgQxjYUBo
YXJpY2EuZ3IwRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NybH YxLmhhcmljYS5nci9IYXJp
Y2FSb290Q0EyMDA2L2NybHYxLmRlci5jcmwwIwYJYIZIAYb4Qg EEBBYWFG5zX3Jldm9rZV9x
dWVyeS5waHA/MDYGCWCGSAGG+EIBAgQpFidodHRwOi8vY3JsdjEuaGFyaWNhLm dyL0hhcmlj
YVJvb3RDQTIwMDYwRwYJYIZIAYb4QgEIBDoWOGh0dHA6Ly93d3 cuaGFyaWNhLmdyL2RvY3Vt
ZW50cy9IYXJpY2FSb290Q0EyMDA2L0NQUy5odG1sMIGaBglghk gBhvhCAQ0EgYwWgYlUaGlz
IGNlcnRpZmljYXRlIGlzIHN1YmplY3QgdG8gR3JlZWsgbGF3cy BhbmQgb3VyIENQUy4gVGhp
cyBDZXJ0aWZpY2F0ZSBtdXN0IG9ubHkgYmUgdXNlZCBmb3IgYW NhZGVtaWMsIHJlc2VhcmNo
IG9yIGVkdWNhdGlvbmFsIHB1cnBvc2VzLjCBwgYDVR0jBIG6MI G3gBS4ju9E3e77Dxz/oWSX
qpKot3CoGKGBm6SBmDCBlTELMAkGA1UEBhMCR1IxRDBCBgNVBA oTO0hlbGxlbmljIEFjYWRl
bWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlvbnMgQ2VydC4gQX V0aG9yaXR5MUAwPgYDVQQD
EzdIZWxsZW5pYyBBY2FkZW1pYyBhbmQgUmVzZWFyY2ggSW5zdG l0dXRpb25zIFJvb3RDQSAy
MDA2ggEAMDEGCCsGAQUFBwEBBCUwIzAhBggrBgEFBQcwAYYVaH R0cDovL29jc3AuaGFyaWNh
LmdyMIIBQAYDVR0gBIIBNzCCATMwggEvBgwrBgEEAYHPEQEAAQ AwggEdMDMGCCsGAQUFBwIB
FidodHRwOi8vd3d3LmhhcmljYS5nci9kb2N1bWVudHMvQ1BTLm h0bWwwgeUGCCsGAQUFBwIC
MIHYMEoWQ0hlbGxlbmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaC BJbnN0aXR1dGlvbnMgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBiVRoaXMgY2VydG lmaWNhdGUgaXMgc3ViamVj
dCB0byBHcmVlayBsYXdzIGFuZCBvdXIgQ1BTLiBUaGlzIENlcn RpZmljYXRlIG11c3Qgb25s
eSBiZSB1c2VkIGZvciBhY2FkZW1pYywgcmVzZWFyY2ggb3IgZW R1Y2F0aW9uYWwgcHVycG9z
ZXMuMA0GCSqGSIb3DQEBBQUAA4IBAQAbK+ZXLqS+WkzrInBy5d eMBNjH9JJ4m9+rQ5IACPPv
hxW0uOLHJEW039yR0tibmLN4i2RFmVvujsoW8ec4qLf1Z4b2jO JHB3lAXKXz0bh5UGp8Bl4a
CWA8m0G2SctcZB0WiKO8TQ88LlhIsY5sYxjsKdPuJBSg9ap5kG rPFOed7igsuBEWQS/3/qGs
ubvQq+Mgt2COUCtRfdzvPA9s9+h0eGRQmkrgaYOLS8G7XuJLBb 9lDkLKe8i8pwrUThKBWjsZ
knyYikPM6w+lWsXkWBMNtRBO/FFq42prfLOtrZi0nnpREkBqP3VS2C6e17PREEr7TguCJQLw
T2UWXEn2OPSsMIIIJzCCBw+gAwIBAgIFAwAAAAUwDQYJKoZIhv cNAQEFBQAwgZ4xCzAJBgNV
BAYTAkdSMS0wKwYDVQQKEyRBcmlzdG90bGUgVW5pdmVyc2l0eS BvZiBUaGVzc2Fsb25pa2kx
OzA5BgNVBAMTMkFyaXN0b3RsZSBVbml2ZXJzaXR5IG9mIFRoZX NzYWxvbmlraSBDZW50cmFs
IENBIFIyMSMwIQYJKoZIhvcNAQkBFhRwa2lhZG1pbkBjY2YuYX V0aC5ncjAeFw0wOTA1MjAx
MjI2MDBaFw0xMzA1MTkxMjI2MDBaMIHQMQswCQYDVQQGEwJHUj EtMCsGA1UEChMkQXJpc3Rv
dGxlIFVuaXZlcnNpdHkgb2YgVGhlc3NhbG9uaWtpMSkwJwYDVQ QLEyBDZW50cmFsIENvbW11
bmljYXRpb24gRmFjaWxpdGllczFCMEAGA1UEAxM5QVVUSCBOZX R3b3JrIE9wZXJhdGlvbnMg
Q2VudGVyIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFIzMSMwIQ YJKoZIhvcNAQkBFhRwa2lh
ZG1pbkBjY2YuYXV0aC5ncjCCASIwDQYJKoZIhvcNAQEBBQADgg EPADCCAQoCggEBANA3ZSQs
ZqfOymWVAqntzbz68zN/lQiWkjurjCDXITK/oNT0kK/OF8kuHUEYTsPRqBiJxT81o3G2J3/G
sa7DhOsusEJb5+1WAxubmo+fZ/xEgQIyAt+fKP/Oc5WcSv1hnLuoeg10wRlW4J6jobc3/1pL
L4pRXv1UlQiLbVvvb3SDcrDtAeboML7poJ5b801NNM9l+L2fux VG7NwArqkdLnQAg2Sz3haa
8dvI29yP0WDDqlF1Yg4ZCIQ03TPTNxviybRMvPzIQ6OUA/1M5AmyLEFPGgIwdlFG6Tc/jFVI
+UCLRcsefdy4GMihUTXOZxZRU1wo5RmeQ5XUgV2SuzCNEcECAw EAAaOCBDYwggQyMA8GA1Ud
EwEB/wQFMAMBAf8wCwYDVR0PBAQDAgEGMBEGCWCGSAGG+EIBAQQEAwI ABzAdBgNVHQ4EFgQU
UhdFbxbXkAqAbXl73mG+9LFPOd8wHwYDVR0RBBgwFoEUcGtpYW RtaW5AY2NmLmF1dGguZ3Iw
HwYDVR0SBBgwFoEUcGtpYWRtaW5AY2NmLmF1dGguZ3IwRwYDVR 0fBEAwPjA8oDqgOIY2aHR0
cDovL2NybHYxLnBraS5hdXRoLmdyL0F1dGhDZW50cmFsQ0FSMi 9jcmx2MS5kZXIuY3JsMCMG
CWCGSAGG+EIBBAQWFhRuc19yZXZva2VfcXVlcnkucGhwPzA3Bg lghkgBhvhCAQIEKhYoaHR0
cDovL2NybHYxLnBraS5hdXRoLmdyL0F1dGhDZW50cmFsQ0FSMj A4BglghkgBhvhCAQgEKxYp
aHR0cDovL3d3dy5wa2kuYXV0aC5nci9kb2N1bWVudHMvQ1BTLm h0bWwwgZoGCWCGSAGG+EIB
DQSBjBaBiVRoaXMgY2VydGlmaWNhdGUgaXMgc3ViamVjdCB0by BHcmVlayBsYXdzIGFuZCBv
dXIgQ1BTLiBUaGlzIENlcnRpZmljYXRlIG11c3Qgb25seSBiZS B1c2VkIGZvciBhY2FkZW1p
YywgcmVzZWFyY2ggb3IgZWR1Y2F0aW9uYWwgcHVycG9zZXMuMI HGBgNVHSMEgb4wgbuAFBhu
bO3VX3vKRIcglgXaeQ7+ay0+oYGbpIGYMIGVMQswCQYDVQQGEw JHUjFEMEIGA1UEChM7SGVs
bGVuaWMgQWNhZGVtaWMgYW5kIFJlc2VhcmNoIEluc3RpdHV0aW 9ucyBDZXJ0LiBBdXRob3Jp
dHkxQDA+BgNVBAMTN0hlbGxlbmljIEFjYWRlbWljIGFuZCBSZX NlYXJjaCBJbnN0aXR1dGlv
bnMgUm9vdENBIDIwMDaCBQEAAAARMDMGCCsGAQUFBwEBBCcwJT AjBggrBgEFBQcwAYYXaHR0
cDovL29jc3AucGtpLmF1dGguZ3IwggEgBgNVHSAEggEXMIIBEz CCAQ8GCysGAQQBvB0CAAIE
MIH/MDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnBraS5hdXRoLmdyL2 RvY3VtZW50cy9DUFMu
cGhwMIHGBggrBgEFBQcCAjCBuTArFiRBcmlzdG90bGUgVW5pdm Vyc2l0eSBvZiBUaGVzc2Fs
b25pa2kwAwIBARqBiVRoaXMgY2VydGlmaWNhdGUgaXMgc3Viam VjdCB0byBHcmVlayBsYXdz
IGFuZCBvdXIgQ1BTLiBUaGlzIENlcnRpZmljYXRlIG11c3Qgb2 5seSBiZSB1c2VkIGZvciBh
Y2FkZW1pYywgcmVzZWFyY2ggb3IgZWR1Y2F0aW9uYWwgcHVycG 9zZXMuMA0GCSqGSIb3DQEB
BQUAA4IBAQDIQPsLpSF6c45SXeARSjqvOIsGDuu6f1sGpxK0rF FjdEe8Gd4MPUXxVrfAaZgD
O2QGO9KQw4DvftE/GgOcZSFNcfIH5NqnKrSqmTrJatqHiPP/FUtqnCvM0yNBeyxdg/3rQTGT
e/dFqQ7UEg3QG4oiX5MdkFvvCYI46jFmZZC298Fm2IVHgqXEKbRK pUk3sUyV9bQZObGKfVMi
+vXsvNEbUSQhKaUaOg1hzOTp8WVguL4afMza4Y1bUZw4/7985A3tNnlw4HvEDTPVyyfroCWt
Sv/P8iTp208hZrGPuojL0AQYu8ry+eyLcOQFePi0SgGkAibdEqYQL dT1ZZhWthjCMIIIbjCC
B1agAwIBAgIFBAAAAC4wDQYJKoZIhvcNAQEFBQAwgdAxCzAJBg NVBAYTAkdSMS0wKwYDVQQK
EyRBcmlzdG90bGUgVW5pdmVyc2l0eSBvZiBUaGVzc2Fsb25pa2 kxKTAnBgNVBAsTIENlbnRy
YWwgQ29tbXVuaWNhdGlvbiBGYWNpbGl0aWVzMUIwQAYDVQQDEz lBVVRIIE5ldHdvcmsgT3Bl
cmF0aW9ucyBDZW50ZXIgQ2VydGlmaWNhdGlvbiBBdXRob3JpdH kgUjMxIzAhBgkqhkiG9w0B
CQEWFHBraWFkbWluQGNjZi5hdXRoLmdyMB4XDTA5MTExNjAwMD AwMFoXDTEwMTExNjIzNTk1
OVowgd8xCzAJBgNVBAYTAkdSMS0wKwYDVQQKEyRBcmlzdG90bG UgVW5pdmVyc2l0eSBvZiBU
aGVzc2Fsb25pa2kxIjAgBgNVBAsTGU5ldHdvcmsgT3BlcmF0aW 9ucyBDZW50ZXIxQTA/BgNV
BAsTOENsYXNzIEIgLSBQcml2YXRlIEtleSBjcmVhdGVkIGFuZC BzdG9yZWQgaW4gc29mdHdh
cmUgQ1NQMRgwFgYDVQQDEw9HZW9yZ2lvcyBQYWxsYXMxIDAeBg kqhkiG9w0BCQEWEWdwYWxs
QGNjZi5hdXRoLmdyMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ KBgQCsvnmDQVLmXNeYqXYT
aIBcQU0e4pbX10wEeIWgw/Lx/mL6f5jAdxp7w6qImQmJTCzZbean+M0tda8AU0WRerzjnoWu
H/VWRMGMVmGuPvulYrPP/zZo7KbPs73KrK9h/P/+Vr31dv3DWHMs/+Z89lIdsIECmJgNfOX8
ZbVb1EX+lQIDAQABo4IEwDCCBLwwDAYDVR0TAQH/BAIwADARBglghkgBhvhCAQEEBAMCBaAw
DgYDVR0PAQH/BAQDAgXgMEkGA1UdJQRCMEAGCCsGAQUFBwMCBggrBgEFBQcDBA YKKwYBBAGC
NwoDBAYIKwYBBQUHAwMGCCsGAQUFBwMIBgorBgEEAYI3FAICMC kGCSsGAQQBgjcUAgQcHhoA
UwBtAGEAcgB0AGMAYQByAGQAVQBzAGUAcjAdBgNVHQ4EFgQU08 dF6BfjRrCUXm2LPmWlo0lF
UEMwgc8GA1UdIwSBxzCBxIAUUhdFbxbXkAqAbXl73mG+9LFPOd +hgaSkgaEwgZ4xCzAJBgNV
BAYTAkdSMS0wKwYDVQQKEyRBcmlzdG90bGUgVW5pdmVyc2l0eS BvZiBUaGVzc2Fsb25pa2kx
OzA5BgNVBAMTMkFyaXN0b3RsZSBVbml2ZXJzaXR5IG9mIFRoZX NzYWxvbmlraSBDZW50cmFs
IENBIFIyMSMwIQYJKoZIhvcNAQkBFhRwa2lhZG1pbkBjY2YuYX V0aC5ncoIFAwAAAAUwHwYD
VR0SBBgwFoEUcGtpYWRtaW5AY2NmLmF1dGguZ3IwMwYIKwYBBQ UHAQEEJzAlMCMGCCsGAQUF
BzABhhdodHRwOi8vb2NzcC5wa2kuYXV0aC5ncjBDBgNVHR8EPD A6MDigNqA0hjJodHRwOi8v
Y3JsdjEucGtpLmF1dGguZ3IvQXV0aE5vY0NBUjMvY3JsdjEuZG VyLmNybDCBmgYJYIZIAYb4
QgENBIGMFoGJVGhpcyBjZXJ0aWZpY2F0ZSBpcyBzdWJqZWN0IH RvIEdyZWVrIGxhd3MgYW5k
IG91ciBDUFMuIFRoaXMgQ2VydGlmaWNhdGUgbXVzdCBvbmx5IG JlIHVzZWQgZm9yIGFjYWRl
bWljLCByZXNlYXJjaCBvciBlZHVjYXRpb25hbCBwdXJwb3Nlcy 4wMwYJYIZIAYb4QgECBCYW
JGh0dHA6Ly9jcmx2MS5wa2kuYXV0aC5nci9BdXRoTm9jQ0FSMz AjBglghkgBhvhCAQQEFhYU
bnNfcmV2b2tlX3F1ZXJ5LnBocD8wNwYJYIZIAYb4QgEIBCoWKG h0dHA6Ly93d3cucGtpLmF1
dGguZ3IvZG9jdW1lbnRzL0NQUy5waHAwggEgBgNVHSAEggEXMI IBEzCCAQ8GCysGAQQBvB0C
AAIEMIH/MDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnBraS5hdXRoLmdyL2 RvY3VtZW50cy9D
UFMucGhwMIHGBggrBgEFBQcCAjCBuTArFiRBcmlzdG90bGUgVW 5pdmVyc2l0eSBvZiBUaGVz
c2Fsb25pa2kwAwIBARqBiVRoaXMgY2VydGlmaWNhdGUgaXMgc3 ViamVjdCB0byBHcmVlayBs
YXdzIGFuZCBvdXIgQ1BTLiBUaGlzIENlcnRpZmljYXRlIG11c3 Qgb25seSBiZSB1c2VkIGZv
ciBhY2FkZW1pYywgcmVzZWFyY2ggb3IgZWR1Y2F0aW9uYWwgcH VycG9zZXMuMDMGA1UdEQQs
MCqgKAYKKwYBBAGCNxQCA6AaDBhncGFsbEBwY2xhYnMuaXRjLm F1dGguZ3IwDQYJKoZIhvcN
AQEFBQADggEBAG5IT1DgdhKGY7JeGLdjKpnIvMrXfdZTTbKP2C ry3hOE5CEmmhuVWJ1nk9V2
5H9gW3+1nyvRW1ZKz/Av/pbWsPRLfWq8Wg7JCk0RSsS+y0M8lya/XkKDaENLiZE3CxfLZLKj
CkY7F8QBnzpznI0brx0r6SFVx6xGJsVLTsrncv97kKRrxkjYWE aYj2dXZX3PFuAHouWOMUG6
YswoCkbEIArqc6e0eyyCXwcjDj7fXeyhyiX8St7kzJLxzOdp8W RzGu4+8B23Wud2XbyRaFrq
8v7Gyskic4eTSKEmGAdVtLDfwHt/rXpgNEh3uNpx6ipWLl0CM2NlCiC0Zxz4ep+zSU0wgghu
MIIHVqADAgECAgUEAAAALjANBgkqhkiG9w0BAQUFADCB0DELMA kGA1UEBhMCR1IxLTArBgNV
BAoTJEFyaXN0b3RsZSBVbml2ZXJzaXR5IG9mIFRoZXNzYWxvbm lraTEpMCcGA1UECxMgQ2Vu
dHJhbCBDb21tdW5pY2F0aW9uIEZhY2lsaXRpZXMxQjBABgNVBA MTOUFVVEggTmV0d29yayBP
cGVyYXRpb25zIENlbnRlciBDZXJ0aWZpY2F0aW9uIEF1dGhvcm l0eSBSMzEjMCEGCSqGSIb3
DQEJARYUcGtpYWRtaW5AY2NmLmF1dGguZ3IwHhcNMDkxMTE2MD AwMDAwWhcNMTAxMTE2MjM1
OTU5WjCB3zELMAkGA1UEBhMCR1IxLTArBgNVBAoTJEFyaXN0b3 RsZSBVbml2ZXJzaXR5IG9m
IFRoZXNzYWxvbmlraTEiMCAGA1UECxMZTmV0d29yayBPcGVyYX Rpb25zIENlbnRlcjFBMD8G
A1UECxM4Q2xhc3MgQiAtIFByaXZhdGUgS2V5IGNyZWF0ZWQgYW 5kIHN0b3JlZCBpbiBzb2Z0
d2FyZSBDU1AxGDAWBgNVBAMTD0dlb3JnaW9zIFBhbGxhczEgMB 4GCSqGSIb3DQEJARYRZ3Bh
bGxAY2NmLmF1dGguZ3IwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMI GJAoGBAKy+eYNBUuZc15ip
dhNogFxBTR7iltfXTAR4haDD8vH+Yvp/mMB3GnvDqoiZCYlMLNlt5qf4zS11rwBTRZF6vOOe
ha4f9VZEwYxWYa4++6Vis8//Nmjsps+zvcqsr2H8//5WvfV2/cNYcyz/5nz2Uh2wgQKYmA18
5fxltVvURf6VAgMBAAGjggTAMIIEvDAMBgNVHRMBAf8EAjAAMB EGCWCGSAGG+EIBAQQEAwIF
oDAOBgNVHQ8BAf8EBAMCBeAwSQYDVR0lBEIwQAYIKwYBBQUHAw IGCCsGAQUFBwMEBgorBgEE
AYI3CgMEBggrBgEFBQcDAwYIKwYBBQUHAwgGCisGAQQBgjcUAg IwKQYJKwYBBAGCNxQCBBwe
GgBTAG0AYQByAHQAYwBhAHIAZABVAHMAZQByMB0GA1UdDgQWBB TTx0XoF+NGsJRebYs+ZaWj
SUVQQzCBzwYDVR0jBIHHMIHEgBRSF0VvFteQCoBteXveYb70sU 8536GBpKSBoTCBnjELMAkG
A1UEBhMCR1IxLTArBgNVBAoTJEFyaXN0b3RsZSBVbml2ZXJzaX R5IG9mIFRoZXNzYWxvbmlr
aTE7MDkGA1UEAxMyQXJpc3RvdGxlIFVuaXZlcnNpdHkgb2YgVG hlc3NhbG9uaWtpIENlbnRy
YWwgQ0EgUjIxIzAhBgkqhkiG9w0BCQEWFHBraWFkbWluQGNjZi 5hdXRoLmdyggUDAAAABTAf
BgNVHRIEGDAWgRRwa2lhZG1pbkBjY2YuYXV0aC5ncjAzBggrBg EFBQcBAQQnMCUwIwYIKwYB
BQUHMAGGF2h0dHA6Ly9vY3NwLnBraS5hdXRoLmdyMEMGA1UdHw Q8MDowOKA2oDSGMmh0dHA6
Ly9jcmx2MS5wa2kuYXV0aC5nci9BdXRoTm9jQ0FSMy9jcmx2MS 5kZXIuY3JsMIGaBglghkgB
hvhCAQ0EgYwWgYlUaGlzIGNlcnRpZmljYXRlIGlzIHN1YmplY3 QgdG8gR3JlZWsgbGF3cyBh
bmQgb3VyIENQUy4gVGhpcyBDZXJ0aWZpY2F0ZSBtdXN0IG9ubH kgYmUgdXNlZCBmb3IgYWNh
ZGVtaWMsIHJlc2VhcmNoIG9yIGVkdWNhdGlvbmFsIHB1cnBvc2 VzLjAzBglghkgBhvhCAQIE
JhYkaHR0cDovL2NybHYxLnBraS5hdXRoLmdyL0F1dGhOb2NDQV IzMCMGCWCGSAGG+EIBBAQW
FhRuc19yZXZva2VfcXVlcnkucGhwPzA3BglghkgBhvhCAQgEKh YoaHR0cDovL3d3dy5wa2ku
YXV0aC5nci9kb2N1bWVudHMvQ1BTLnBocDCCASAGA1UdIASCAR cwggETMIIBDwYLKwYBBAG8
HQIAAgQwgf8wNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cucGtpLm F1dGguZ3IvZG9jdW1lbnRz
L0NQUy5waHAwgcYGCCsGAQUFBwICMIG5MCsWJEFyaXN0b3RsZS BVbml2ZXJzaXR5IG9mIFRo
ZXNzYWxvbmlraTADAgEBGoGJVGhpcyBjZXJ0aWZpY2F0ZSBpcy BzdWJqZWN0IHRvIEdyZWVr
IGxhd3MgYW5kIG91ciBDUFMuIFRoaXMgQ2VydGlmaWNhdGUgbX VzdCBvbmx5IGJlIHVzZWQg
Zm9yIGFjYWRlbWljLCByZXNlYXJjaCBvciBlZHVjYXRpb25hbC BwdXJwb3Nlcy4wMwYDVR0R
BCwwKqAoBgorBgEEAYI3FAIDoBoMGGdwYWxsQHBjbGFicy5pdG MuYXV0aC5ncjANBgkqhkiG
9w0BAQUFAAOCAQEAbkhPUOB2EoZjsl4Yt2Mqmci8ytd91lNNso/YKvLeE4TkISaaG5VYnWeT
1Xbkf2Bbf7WfK9FbVkrP8C/+ltaw9Et9arxaDskKTRFKxL7LQzyXJr9eQoNoQ0uJkTcLF8tk
sqMKRjsXxAGfOnOcjRuvHSvpIVXHrEYmxUtOyudy/3uQpGvGSNhYRpiPZ1dlfc8W4Aei5Y4x
QbpizCgKRsQgCupzp7R7LIJfByMOPt9d7KHKJfxK3uTMkvHM52 nxZHMa7j7wHbda53ZdvJFo
Wury/sbKySJzh5NIoSYYB1W0sN/Ae3+temA0SHe42nHqKlYuXQIzY2UKILRnHPh6n7NJTTGC
BCEwggQdAgEBMIHaMIHQMQswCQYDVQQGEwJHUjEtMCsGA1UECh MkQXJpc3RvdGxlIFVuaXZl
cnNpdHkgb2YgVGhlc3NhbG9uaWtpMSkwJwYDVQQLEyBDZW50cm FsIENvbW11bmljYXRpb24g
RmFjaWxpdGllczFCMEAGA1UEAxM5QVVUSCBOZXR3b3JrIE9wZX JhdGlvbnMgQ2VudGVyIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5IFIzMSMwIQYJKoZIhvcNAQ kBFhRwa2lhZG1pbkBjY2Yu
YXV0aC5ncgIFBAAAAC4wCQYFKw4DAhoFAKCCApwwGAYJKoZIhv cNAQkDMQsGCSqGSIb3DQEH
ATAcBgkqhkiG9w0BCQUxDxcNMTAwMjA3MDgxMzUyWjAjBgkqhk iG9w0BCQQxFgQUtfyva4nU
oUmGIljh+WiErKOUk/4wXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI hvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBS sOAwIHMA0GCCqGSIb3DQMC
AgEoMIHrBgkrBgEEAYI3EAQxgd0wgdowgdAxCzAJBgNVBAYTAk dSMS0wKwYDVQQKEyRBcmlz
dG90bGUgVW5pdmVyc2l0eSBvZiBUaGVzc2Fsb25pa2kxKTAnBg NVBAsTIENlbnRyYWwgQ29t
bXVuaWNhdGlvbiBGYWNpbGl0aWVzMUIwQAYDVQQDEzlBVVRIIE 5ldHdvcmsgT3BlcmF0aW9u
cyBDZW50ZXIgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUjMxIz AhBgkqhkiG9w0BCQEWFHBr
aWFkbWluQGNjZi5hdXRoLmdyAgUEAAAALjCB7QYLKoZIhvcNAQ kQAgsxgd2ggdowgdAxCzAJ
BgNVBAYTAkdSMS0wKwYDVQQKEyRBcmlzdG90bGUgVW5pdmVyc2 l0eSBvZiBUaGVzc2Fsb25p
a2kxKTAnBgNVBAsTIENlbnRyYWwgQ29tbXVuaWNhdGlvbiBGYW NpbGl0aWVzMUIwQAYDVQQD
EzlBVVRIIE5ldHdvcmsgT3BlcmF0aW9ucyBDZW50ZXIgQ2VydG lmaWNhdGlvbiBBdXRob3Jp
dHkgUjMxIzAhBgkqhkiG9w0BCQEWFHBraWFkbWluQGNjZi5hdX RoLmdyAgUEAAAALjANBgkq
hkiG9w0BAQEFAASBgEp/pDn2TaJ2gDUqpFYFaUpvWggzgp9OdiwRy1dvLxDfqtRW27vnqX kP
FEqfyTLHVV9e8WG2vKdViufYmi8U4peXA2X8/IFZU08q25WTy5GJPROFiOiVqfZhVJ/2g9C5
qL1HhbCcpdBms9RJMQwPHntk1o6aJsquTORY+Xszy3MOAAAAAA AA
--------------ms060402030006030204000309--


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

ABRT unusable again
 

On So, 2010-02-07 at 09:03 +0100, Ralf Corsepius wrote:
> On 02/07/2010 03:15 AM, Karel Klic wrote:
> > Kevin Kofler wrote:
> >> Stefan Schulze Frielinghaus wrote:
> >>> However, in the meantime I stopped reporting crashes via ABRT because I
> >>> think it raises the load for a package maintainer to high while the
> >>> report should go directly to upstream. Bothering the maintainer first
> >>> instead of upstream is not the right thing to do.
> >>
> >> +1, in fact that's the biggest design failure in ABRT (in its current state)
> >> and basically makes it useless. Gathering backtraces is something that needs
> >> to be handled by upstream projects (like KDE does with KCrash/DrKonqi), not
> >> distributions.
>
> To end-users, it's irrelevant "who is supposed to fix something". Their
> complaints are against the product call Fedora and thus expect "Fedora
> to fix their product".
>
> That said: It's irrelevant to Toyota car owners, which supplier
> manufactured the parts which have caused Toyota to call back 1000 of
> their cars - To them it's Toyota who is reponisible, and Toyota's duty
> to fix this issue.

But Toyota's employees do not do that after work in their free time.
They get paid for it. If someone is paying me to fix bugs for upstream
that's fine and I will try to fix every reported bug. I guess a lot of
Fedora package maintainers do their packaging stuff in their spare free
time and would say it is not the right thing to offload the work to
them.

The analogy between Toyota and Fedora does not convince me ;-)

cheers,
Stefan

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

ABRT unusable again
 

On Sun, 07 Feb 2010 11:20:04 +0100, Stefan wrote:

> On So, 2010-02-07 at 09:03 +0100, Ralf Corsepius wrote:
> >
> > To end-users, it's irrelevant "who is supposed to fix something". Their
> > complaints are against the product call Fedora and thus expect "Fedora
> > to fix their product".
> >
> > That said: It's irrelevant to Toyota car owners, which supplier
> > manufactured the parts which have caused Toyota to call back 1000 of
> > their cars - To them it's Toyota who is reponisible, and Toyota's duty
> > to fix this issue.
>
> But Toyota's employees do not do that after work in their free time.
> They get paid for it. If someone is paying me to fix bugs for upstream
> that's fine and I will try to fix every reported bug. I guess a lot of
> Fedora package maintainers do their packaging stuff in their spare free
> time and would say it is not the right thing to offload the work to
> them.
>
> The analogy between Toyota and Fedora does not convince me ;-)

That's likely. Because the analogy isn't obvious - and reducing it to a
relationship between a paying customer and a paid worker makes it even
less obvious.

There is an analogy actually. Regardless of whether the Fedora Project
consists of many volunteers, who do unpaid stuff in their spare time,
Fedora delivers a product and will have to deal with its consumers and
negative feedback. The fact that the product is free (as in "free beer")
should not imply that it is worse than a commercial product. How far would
you want to go with regard to a fat disclaimer about "no warranties",
"free of charge", "no support", "hobbyist developers", to lower a
consumer's expectations? A huge sticker on top of the product to
advertise against trying it out? What is the added value we [at Fedora]
try to add? Surely it isn't that we just lump together software in form of
RPM packages _without_ testing and _without_ carefully picking releases
and compatible components. Even if we don't guarantee anything, there must
be something quality related, which _we_ _try_ to offer.

It's clear that if upstream software quality is poor and if nobody works
on improving the software, it is more difficult for the Fedora packager to
deliver quality. To shrug one's shoulders in reply to problem reports is
the wrong way, however. And the more problem reports, the more important
it gets to do something. As a last resort, software could get retired and
removed from "The Product".

--
Michael Schwendt
Fedora release 12 (Constantine) - Linux 2.6.31.12-174.2.3.fc12.i686.PAE
http://mschwendt.fedorapeople.org/staticbutstat.html
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

ABRT unusable again
 

I don't want to answer all of the messages, so I'll try to sum all of it
in this one...


On 02/05/2010 09:46 PM, Christoph Wickert wrote:

What's wrong with ABRT? ALl the backtraces I get are unusable again. If
Thunar crashes, not even Thunar-debuginfo gets installed.

abrt 1.0 worked here, then came 1.0.2 which was broken. 1.0.3 was
working again, but got superseded be 1.0.4 only a few of days later.
This means that most of the time, all the bugs submitted are basically
useless.



Unfortunately that's true, it was different problem every time, but the
result is the useless backtrace. This shouldn't happen anymore as we now
have more extensive testing before releasing a new version.



For me as the maintainer it is a lot of work to reply to all these
useless reports and for our users it's just frustrating if all their
reports get closed INSUFFICIENT_DATA.



If the current situation is really so bad, we can auto-close all of the
bugs reported by the broken versions of ABRT, because I guess they would
just sit there until bugzapping period.



If the situation doesn't change any time soon, we IMHO should consider
disabling abrt until the issues are fixed.



It's already fixed in 1.0.6, which sits in testing repo. In F12 there is
a pending kernel update which (if gets to F12 without change) will
prevent ABRT from detecting C/C++ apps crashes, so it will probably make
abrt silent for a while.



Now some answers for issues mentioned in this thread:

ABRT doesn't work by design:
- it actually does work, but it's bug detection/analyse is too general
for some apps, this is something we know about and it's not in our
powers to fix (it's not even considered a bug). This is actually the
reason why is ABRT extendible by plugins and every devel who maintains
some bigger app can write it's own abrt plugin to make the reports to
suit his needs. If devel doesn't want to get ABRT reports at all, he can
always send me an email and it can be added to ABRT blacklist.


I feel the Fedora community is being abused to evaluate a
semi-functional piece of SW's "yet uncooked" concepts:
- tha ABRT's concept is used for a while in other distros and ABRT
itself is in Fedora since F10, but nobody cared to take a look at it and
add some comments/ideas. I don't want to start a fight about
non-finished apps in Fedora, but I won't silently ignore it, I remeber
quite well the how finished and stable was the last major release of one
of the major desktop environment or I remember times when I had to use
web mail instead of my favourite client to write an email, because it
wasn't stable (and both were in stable Fedora release).



Nice idea. IMO it should only allow to submit reports after some sanity
checks:
- ABRT uses the code from Dr.Konqui to rate the backtrace and doesn't
allow user to send it if the rate is bellow 3 (the scale is 0-4), but
the bug in GUI let user to send even the bad BT.


I believe ABRT shouldn't file a bug report unless it is filled in
properly:

- we can change to GUI, so it won't let users fill a report without
providing a steps to reproduce


History tells, low quality automated bug reports to be ignored and to
cause a lot of bad blood. Debian for instance has an unfortunate history
in doing so - You're better off to learn from their historic mistake:
- times changes, Linux is now used by people who actually use it for
work not for the "fun of using Linux" and these people doesn't want to
spend time going thru bugzilla and filling some report. Yes, I agree we
should learn and in this we should learn from someone more desktop
oriented then Debian (maybe even from some non-Linux os??)


What needs to be fixed here is bugzilla not ABRT, we need a "report
upstream" button:
- the best would be to fix both. what we need to ease the life of
maintainers is a middle layer between ABRT (users) and
bugzilla(developers) something like mozilla
has(http://crash-stats.mozilla.com/).



Surely you're not suggesting holding up a decent kernel from going to
stable while waiting for Abrt ?
- there is no need to wait for ABRT when talking about the pending
kernel update update for F12, there is nothing what ABRT can do to work
with that kernel.



Anyway, there should be a tool in ABRT suite, that allows a package
maintainer to reconstruct a complete backtrace from an incomplete on,
using only the list of involved packages, with there evr(+arch):
- you can never get the whole BT without a coredump - you can get
recreating should be a matter of a simple script and we can provide it
as part of ABRT if devels would use it.



I hope I've cleared few things and will be happy to answer any of you
further questions and RFEs.


Jirka
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

ABRT unusable again
 

On So, 2010-02-07 at 12:52 +0100, Michael Schwendt wrote:
[...]
> There is an analogy actually. Regardless of whether the Fedora Project
> consists of many volunteers, who do unpaid stuff in their spare time,
> Fedora delivers a product and will have to deal with its consumers and
> negative feedback. The fact that the product is free (as in "free beer")
> should not imply that it is worse than a commercial product.

I completely agree and most open source software proofs that, but this
was not the question. The question was if the package maintainer should
be triggered first instead of upstream which increases the load for the
package maintainer who might not be able to handle all of these requests
in the end because it is not his/her full time job.

> It's clear that if upstream software quality is poor and if nobody works
> on improving the software, it is more difficult for the Fedora packager to
> deliver quality. To shrug one's shoulders in reply to problem reports is
> the wrong way, however. And the more problem reports, the more important
> it gets to do something. As a last resort, software could get retired and
> removed from "The Product".

This is at least a good point to me. ABRT might point out software which
needs more attention. If it is not possible to provide the needed power,
then the package should be removed to keep the expected stability of
Fedora.

cheers,
Stefan

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

ABRT unusable again
 

On Sun, 07 Feb 2010 14:23:13 +0100, Stefan wrote:

> The question was if the package maintainer should
> be triggered first instead of upstream which increases the load for the
> package maintainer who might not be able to handle all of these requests
> in the end because it is not his/her full time job.

Well, that isn't straight-forward to answer IMO.

First of all, upstream may not be paid either for working on the software
_and_ on incoming problem reports. What sort of "support" and response
time can you expect from upstream in that case?

Secondly, the package maintainer should be informed about what is broken
with the chosen/packaged software release. Certainly you don't ask for
upstream to filter out *all* reports from all distributions, to return
distribution-specific ones into a dist's own bug tracking system, and to
work on incomplete backtraces or problems that aren't trivial to reproduce
in the absence of the original bug reporter. Depending on the software
quality it may be that upstream cannot handle all that either.

Fedora packages are not fire'n'forget releases. Even if you forwarded
every bugzilla ticket to upstream, you would still need to monitor the
status of the forwarded reports or fix issues yourself, provided that they
matter to you. Whether they should matter to you also depends on project
strategies and goals and whether Fedora wants to deliver added value. In
some cases, the product (or individual packages) may suffer from
insufficient contributor resources, and a single package maintainer
may not be enough.

> ABRT might point out software which
> needs more attention.

That is not its task. Bugzilla statistical queries could examine packages
for a high number of open/unresponded tickets, a growing number of
tickets closed by the bugzapper scripts at dist EOL, a low update
frequency, and a package owner who isn't responsive for other packages
either.


--
Michael Schwendt
Fedora release 12 (Constantine) - Linux 2.6.31.12-174.2.3.fc12.i686.PAE
http://mschwendt.fedorapeople.org/staticbugstat.html
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

ABRT unusable again
 

On So, 2010-02-07 at 15:34 +0100, Michael Schwendt wrote:
> On Sun, 07 Feb 2010 14:23:13 +0100, Stefan wrote:
>
> > The question was if the package maintainer should
> > be triggered first instead of upstream which increases the load for the
> > package maintainer who might not be able to handle all of these requests
> > in the end because it is not his/her full time job.
>
> Well, that isn't straight-forward to answer IMO.
>
> First of all, upstream may not be paid either for working on the software
> _and_ on incoming problem reports. What sort of "support" and response
> time can you expect from upstream in that case?
>
> Secondly, the package maintainer should be informed about what is broken
> with the chosen/packaged software release. Certainly you don't ask for
> upstream to filter out *all* reports from all distributions, to return
> distribution-specific ones into a dist's own bug tracking system, and to
> work on incomplete backtraces or problems that aren't trivial to reproduce
> in the absence of the original bug reporter. Depending on the software
> quality it may be that upstream cannot handle all that either.
>
> Fedora packages are not fire'n'forget releases. Even if you forwarded
> every bugzilla ticket to upstream, you would still need to monitor the
> status of the forwarded reports or fix issues yourself, provided that they
> matter to you. Whether they should matter to you also depends on project
> strategies and goals and whether Fedora wants to deliver added value. In
> some cases, the product (or individual packages) may suffer from
> insufficient contributor resources, and a single package maintainer
> may not be enough.

Hmm yeah. I see the problem. It would even get worse when e.g. some
patches are applied to the package, then upstream couldn't even debug
properly.

Nasty situation ;-) I will think about it. Hopefully it was not too off
topic.

Thanks for letting me know,
Stefan

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

ABRT unusable again
 

Michael Schwendt wrote:
> Secondly, the package maintainer should be informed about what is broken
> with the chosen/packaged software release. Certainly you don't ask for
> upstream to filter out *all* reports from all distributions, to return
> distribution-specific ones into a dist's own bug tracking system,

Most problems are not distribution-specific. For the ones which are, they
can close the bugs as DOWNSTREAM, NOTOURBUG or whatever their Bugzilla uses
for that case and tell the user to report them to the distribution. It's
less work for them do to that for the few bugs which happen to be
distribution-specific than for us to do the opposite for the common case.

> and to work on incomplete backtraces or problems that aren't trivial to
> reproduce in the absence of the original bug reporter.

That's why bugs should not be forwarded by us, but filed directly upstream.

> Fedora packages are not fire'n'forget releases.

Once upstream fixes the issue (which will result in bugmail to the
reporter), it's OK to file a bug to us asking us to backport the fix. But if
the package is maintained properly (like e.g. KDE), the next release with
the fix will be pushed soon anyway.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

ABRT unusable again
 

Michael Schwendt wrote:
> As a last resort, software could get retired and removed from "The
> Product".

I'm not sure not shipping something at all is better for the user than
shipping it with bugs, even if they never get fixed. Often even a buggy
software is better than nothing.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

ABRT unusable again
 

Karel Klic wrote:
> Christoph Wickert wrote:
>> For me as the maintainer it is a lot of work to reply to all these
>> useless reports and for our users it's just frustrating if all their
>> reports get closed INSUFFICIENT_DATA.
>
> I am now going to write a script which detects all the backtraces
> without debuginfo in Bugzilla, and closes the bugs as INSUFFICIENT_DATA
> with an apology. I do not know how many of them are in Bugzilla, but
> those can be detected and closed automatically (more info soon, it
> should be hacked together quickly).

The script to find backtraces without debuginfo has been written[1]. I
placed the list of found bugs to the Fedora wiki [2]. IMHO only bugs
with 2 comments should be closed, because 2 comments mean that the
package maintainer did not touch the bug (ABRT adds 2 comments to every
bug it creates). We can close 129 bugs this way.

> Also a script [1] which finds all the duplicate backtraces (we can find)
> in Bugzilla has been written. Those duplicates were made by older ABRT
> versions without good duplicate detection. ~900 bugs can be closed with
> this script. Hopefully it removes some burden from package maintainers.
>
> [1] https://fedorahosted.org/abrt/browser/src/Backtrace/abrt-bz-dupchecker
Its 551 bugs that can be closed as duplicates, not 900. I placed the
list of affected bugs to the Fedora wiki [3].

So I'd like to close over 600 bugs in Bugzilla using scripts. Is there
some Fedora policy regulating this?

[1] https://fedorahosted.org/abrt/browser/scripts/abrt-bz-ratingfixer
[2] https://fedoraproject.org/wiki/User:Kklic/ABRT_Incomplete_Backtraces
[3] https://fedoraproject.org/wiki/User:Kklic/ABRT_Duplicates

Best Regards,
Karel
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel