Does your code take care to only pick crashes which are generated while checkbox was running? It seems a little greedy to me to attach all existing ones, especially since attaching .crash files directly to a bug which is going to be public might inadvertedly expose a lot of private data from the user (and many crash reports might be entirely unrelated to the checkbox run). Also, please note that we have no way to auomatically reprocess .crash file bug attachments.
> This means that you will want to do some pre-processing of the .crash files *on the system where the crash occurred* before shipping the crash file off somewhere else, in order for it to be useful.
Right, you want to at least call add_package_info() and add_hooks_info() on them. But before I elaborate on that, I want to stress that it is _really_ not a good idea to attach /var/crash/*.crash to reported bugs. What is your actual goal on those? With the limited bug description here I don't feel that this approach is the right solution.
Does your code take care to only pick crashes which are generated while checkbox was running? It seems a little greedy to me to attach all existing ones, especially since attaching .crash files directly to a bug which is going to be public might inadvertedly expose a lot of private data from the user (and many crash reports might be entirely unrelated to the checkbox run). Also, please note that we have no way to auomatically reprocess .crash file bug attachments.
> This means that you will want to do some pre-processing of the .crash files *on the system where the crash occurred* before shipping the crash file off somewhere else, in order for it to be useful.
Right, you want to at least call add_package_info() and add_hooks_info() on them. But before I elaborate on that, I want to stress that it is _really_ not a good idea to attach /var/crash/*.crash to reported bugs. What is your actual goal on those? With the limited bug description here I don't feel that this approach is the right solution.