Sorry for the late answer, this fell through the cracks. Did you actually test that this works? I. e. can a normal user actually read /dev/nvram? Currently the "cat /dev/nvram" is ran as root via attach_root_command_outputs(), and requiring root was the main reason why this "cat" approach was taken in the first place.
Does /dev/nvram actually contain text information and is this a locale/encoding problem? Or is it binary data, and unrelated to encodings?
With 14.10's apport, instead of cat the hook could call "base64 /dev/nvram" or a similar command which provides plaintext. But otherwise I think it would be better to fix attach_root_command_outputs() to get along with binary outputs.
> One dummy question remaining, how getting the tar file from the ascii output file if we need to ?
You can use "apport-unpack" to decode the apport report file into individual files (named by keys), and then just use tar to extract them further.
Sorry for the late answer, this fell through the cracks. Did you actually test that this works? I. e. can a normal user actually read /dev/nvram? Currently the "cat /dev/nvram" is ran as root via attach_ root_command_ outputs( ), and requiring root was the main reason why this "cat" approach was taken in the first place.
Does /dev/nvram actually contain text information and is this a locale/encoding problem? Or is it binary data, and unrelated to encodings?
With 14.10's apport, instead of cat the hook could call "base64 /dev/nvram" or a similar command which provides plaintext. But otherwise I think it would be better to fix attach_ root_command_ outputs( ) to get along with binary outputs.
> One dummy question remaining, how getting the tar file from the ascii output file if we need to ?
You can use "apport-unpack" to decode the apport report file into individual files (named by keys), and then just use tar to extract them further.