On Mon, 2010-09-20 at 15:35 +0200, Jiri Moskovcak wrote:
Andrew, Gavin, ping?
J.
On 09/18/2010 10:48 AM, Radek Vokal wrote:
> I'm ccing Andrew and Gavin. The server will overlap with the work they
> are doing and we could share some components.
>
> Radek
>
> On 09/16/2010 08:08 PM, Karel Klic wrote:
>> Hi,
>>
>> I have written a document that discusses various aspects and a possible
>> "design" of our retrace server. After spending several days thinking
>> about the server, I believe the retrace server will provide a pretty
>> large improvement in the reliability and usefulness of ABRT (both in the
>> intranet installations, and in Fedora). To me, it seems to be worth
>> implementing.
>>
>> It would be great if someone reads it and points to stupid ideas,
>> unclear stuff etc. New thoughts are welcome and very important in this
>> stage. You can post a diff with your changes.
>>
>> Thanks.
>>
>> Karel
>>
>> (We should also look into the debuginfofs idea. The debuginfofs would
>> also improve ABRT experience a lot.
ABRT already can use external debuginfo store:
/etc/abrt/plugins/CCpp.conf has ReadonlyLocalDebugInfoDirs = DIR1:DIR2
directive.
There is no need to reinvent a special fs for that. If you want
to have a centralized and/or remote storage for it, mount it
using your favorite network filesystem. Bingo.
Now you have a debuginfofs.
I realize that gdb currently will read entire debuginfo file,
not only some parts of it, but Jan and other tools people
know about this inefficiency and this will be improved.
The thing ARBT team can improve a bit on its side is to
document this better and provide a tool to pre-populate
that storage with all debuginfos. Imagine a data center
which runs on RHEL. They might find it practical to download
and store locally (in the datacenter) all RHEL debuginfos.
It's a bit more complex that simply firing up a wget or yum -
"yum install /usr/lib/debug/.build-id/*" wouldn't work -
but should be doable.
--
vda