Additions required to the AppData file
by Richard Hughes (semi-automated)
Hi!
First, apologies for the direct email. I'm emailing you directly as you've been listed as the update contact in one or more AppData files. In future versions of the appstream-builder (the program used by distributions to merge all the AppData files in packages into AppStream metadata) we're going to be running a lot less crazy plugins. At the moment we're doing things like parsing .gir files, running nm on binaries and looking up things from arrays of hardcoded data just so we can try and work out what kudos the application deserves. This doesn't scale, and means the machine generating the metadata needs to have all kinds of extra build tools installed.
So, what do I want you to do? Basically, I would like you to:
Add the following data into gnome-abrt.appdata.xml
<kudos>
<kudo>HiDpiIcon</kudo>
<kudo>HighContrast</kudo>
<kudo>ModernToolkit</kudo>
</kudos>
Of course, you don't have to do a release with this fix straight away, and if you have a stable branch it would be a good thing to backport this as well. Nothing bad will happen if we run the automated tools with the kudos already set in the AppData file. If you think any of the other kudos might apply[1], please email me back and we can discuss any new additions.
When you've changed the file and committed, please email me back and I'll mark your application as completed. If you don't want to hear from me ever again just edit the <update_contact> in the AppData file and change it to somebody else. I'm not planning on emailing any of you again this year, so don't worry about me spamming you with even more work to do. If you don't add the manual <kudos> then your application will still be visible in the various software centers, but it may loose some of the stars it got auto-assigned.
Thanks,
Richard
[1] https://git.gnome.org/browse/gnome-software/plain/doc/kudos.md
8 years, 3 months
ABRT allow blacklisting dumps and add user whitelist
by Matej Habrnal
ABRT allow blacklisting dumps and add user whitelist
====================================================
Related bugzillas: #1208713, #1256705
Allow blacklisting applications/exe-paths/packages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Current state
-------------
There is a possibility to blacklist packages or paths in
'/etc/abrt/abrt-action-save-package-data.conf' options 'BlackList' for packages
and option 'BlackListedPaths' for paths.
The blacklisting is not done in time when the crash occurs but while
the abrt-action-save-package-data tool is executing so in 'post-create'
event after the coredumps are written to disk.
Suggestions
-----------
The new blacklisting feature should prevent of dumping blacklisted
executables/paths already in dumping time, therefore it must be moved from
abrt-action-save-package-data to abrt-hook-ccpp.
Have to notice ABRT is marked as a tool for developers and developers want
coredumps of their applications.
If the 'post-create' event fails because of 'abrt-action-save-package-data'
(e.g. the package is blacklisted or the executable file is not signed or don't
belong to any package etc.), the created dump dir, also with coredump, is removed
and developers cannot analyse it. Creating unwanted directories and deleting
them in the next step don't make much sense.
Another example: If the option 'OpenGPGCheck' is set to
'no' and 'ProcessUnpackaged' set to 'yes', it means ABRT catches all crashes on
the system and makes them reportable to the bugzilla or to another bug
tracking system even if it's not possible because usually there is no such
component in bug tracking system.
jfilak suggested to not delete crashes which pass through main blacklisting in
'abrt-hook-ccpp' and at the same time don't pass through
'abrt-action-save-package-data' but mark them as 'not-reportable'. This allows
the developers analyse them later or configure ABRT, for example, to sent all
crashes, even the not reportable one, via email or to FTP server.
Conclusion
----------
1) mark crashes which don't pass through abrt-action-save-package-data as
not-reportable like was mentioned above
2) introduce a new dump dir element, something like 'unsupported', which
disallow reporting crashes only to bug tracking systems
Other things
------------
We have to decided which of abrt-action-save-package-data.conf's options
(OpenGPGCheck, BlackList, ProcessUnpackaged and BlackListedPaths) will stay in
the conf file or which one will be renamed.
My suggestions:
BlackList -> NotSupportPackages
BlackListedPaths -> NotSupportPaths
OpenGPGCheck - without changes
ProcessUnpackaged - without changes, but if its value is 'true', all the
unpackaged apps will be marked as not-reportable (unsupported).
Add user whitelist
~~~~~~~~~~~~~~~~~~
Current state
------------
Is not possible to catch crashes only from given users.
Suggestions
-----------
This option should be added to abrt-hook-ccpp (so to the CCpp.conf file) because
we have to stop processing the crash in the very beginning and do not create and
then remove created dirs like it is done during processing of events.
conclusion
----------
Add option to the CCpp.conf file like 'ProcessCrashFromUsers'. If there are no
user names or the option is not presented, ABRT process crashes from all users.
If there are specified user names, ABRT process crashes from given users.
Matej
8 years, 4 months