Please see attached screenshot. Retracing failed as expected because I
run it from F13, but error code indicates success. It should indicate
A few minor notes while I am at it:
(1) Log has two extra empty lines at the end:
Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again
I think they should not be emitted.
(2) I guess it might be useful if log starts with "Connecting to URL"
message. Consider what would happen if server doesn't respond:
user would have no idea what's going on - he will see blank log
2011/2/22 Denys Vlasenko <vda.linux(a)googlemail.com>:
>> > The point is, "oh, sometimes we want to save hostname" is not
>> > the last time we want to add saving of something.
>> > There will be more "we want to save <foo>" in the future,
>> > both for standard installation, and for people running
>> > custom-configured abrt on servers.
>> > Making in necessary to hack abrt's C source to achieve it
>> > wasn't a good situation.
>> > abrt_event.conf was invented in part to provide the feature
>> > which allows to do it WITHOUT hacking on C code.
>> > hostnames saving your patch removed was in C because it was
>> > coded before we had abrt_event.conf
>> > Since we now _have_ abrt_event.conf, we can use it.
> Vladimir Vinogradov wrote:
>> According to this we can put there also uname (-r -m -n), and even
>> `yum provides -q `cat executable` | grep \: -m 1 | cut -f 1 -d \-`
>> (isn't too much?) to save a "component", respectively cut out parts of
> component should be removed altogether, it is trivially
> derivable from package name.
> Saving package name by querying RPM database has advantages of not requiring
> RPM libraries for abrt, which makes it trivial to adapt it for distributions
> which do not use RPM for package management.
ABRT uses rpm libraries only in
Reviewing internal logic of abrt-action-save-package-data.c I started
from working out substitutive abrt-action-save-hostinfo.sh as basic
After commenting respective parts of c code it became obvious that
almost no payload will remain in abrt-action-save-package-data.c.
Except of some for now interesting logic - if path or package is
blacklisted, we cancel all operations. The fact is such behaviour is
implemented in EVENT=post-create binary.
Thus, question is what if we'll move that checks in the earliest
place, into hooks? If it already blacklisted, should we save anything
in /var/spool/abrt that will push daemon to action?
This is a first draft of how we'd like to deal with the user interface
for events. Since every event can consist of many executables scripts,
etc.. it's quite hard to provide an UI for it. So we decided that every
event will have a XML file with this content:
- description of what this event does
- description of every configurable option
- option will have:
- type: text, password, number (any others?)
- name: name of the represented environment variable
- label: text to show in UI
- empty: if the option can be empty (defaults to "no")
- description a tooltip to show when move the mouse over the option
- others if you find anything anything else useful
<description>Send the colelcted information to the Fedora bugzilla (you
will need a bugzilla account to use this)</description>
<option type="text" name="bz_login">
<description>Username to use to log into your bugzilla
<option type="password" name="bz_password">
<description>Password for your bugzilla account</description>
- these xml files will live in /usr/share/abrt/events/<EVENTS_NAME>.xml
- the default values (like bz URL) for events will be stored in
- and can be also read from ~/.abrt/events/<EVENT_NAME>.conf
- but not stored by any abrt application, this file will have to be
provided by user if he don't want to use any of the options below:
- gtk UI will store the settings in gnome-keyring
- kde UI will store the settings in the kwallet
- etc, ...
making Retrace Server able to handle F15 crashes, I found a problem. So
far, we are using tmpfs for chroots, because it is significantly faster
to retrace in memory than on HDD. Everything works perfectly for F14
(and also RHEL6), however for F15 it does not.
F15 introduces file capabilities and these are not working in tmpfs. It
is a kernel problem, probably fixed in rawhide (and F15?)
https://bugzilla.redhat.com/show_bug.cgi?id=648653 (not tested). Retrace
on ext4 HDD works, but of course, it is much slower. With both our
testing machines running RHEL-6 and test day approaching, we should
think what to do.