** Description changed: [ Impact ] This bug revolves around the error reporting story in Ubuntu, which is what's behind https://errors.ubuntu.com . GNOME is generating error reports that include a `ShellJournal` field [1], but `whoopsie` (the service uploading the report) doesn't allow it. That means the error reporting story for GNOME crashes isn't great, and slows down the fixing of bugs in this particular situation. More generally, the proposed fix would add the current `ShellJournal` field, because it's the name currently in use in GNOME, but also adds a more generic `JournalAll` field, that only has a better naming, in the goal of deprecating the `ShellJournal` field when GNOME is updated. `JournalAll` would in effect allow any other application to include generic `journalctl` output. [ Test Plan ] - TODO: actually develop what the test plan is. It boils down to "generate a - report with those two added fields and content bigger than 1KB, make `whoopsie` - upload it, and make sure the uploaded report still has the fields" + * Put the two crash files attached to this bug in an empty folder (see their description for details). + * From that folder, run the following to make sure both crashes would be candidate for upload: + touch _usr_libexec_gnome-shell-calendar-server.1000.upload _usr_libexec_gnome-shell-calendar-server_smaller_fields.1000.upload + * Then, still from that folder, run the `whoopsie` under test with the following: + CRASH_DB_URL=https://daisy.ubuntu.com APPORT_REPORT_DIR=$(pwd) CRASH_DB_IDENTIFIER=bug-2130649-verification-$(lsb_release -cs) whoopsie --no-polling -f - * detailed instructions how to reproduce the bug + This should report two OOPSes being reported with a line like the following: + [13:24:52] Reported OOPS ID bd7ad35e-c9f9-11f0-a191-fa163e171f02 - * these should allow someone who is not familiar with the affected - package to reproduce the bug and verify that the updated package - fixes the problem. - - * if other testing is appropriate to perform before landing this - update, this should also be described here. + Gather the two UUIDs and go to each OOPS page (https://errors.ubuntu.com/oops/<uuid>). + With a non-fixed `whoopsie`, only `JournalError` will appear on the non "smaller_fields" crash report, whereas all three fields will be there with a fixed `whoopsie`. + With the "smaller_fields" crash, all three fields should always be there. [ Where problems could occur ] * `whoopsie` is a C application doing networking and parsing. Many things could - go wrong, but the patch only adds two lines to an allow-list, so hopefully if - it's working today, it shouldn't break too much. + go wrong, but the patch only adds two lines to an allow-list, so hopefully if + it's working today, it shouldn't break too much. * `whoopsie` isn't directly useful to an Ubuntu system, and is actually not - enabled by default on Ubuntu Server. It's only triggered when some change - happen in `/var/crash` (like file creation). Hopefully if it's broken, the user - impact is very limited, and only Ubuntu development (crash reporting) would see - the effects. + enabled by default on Ubuntu Server. It's only triggered when some change + happen in `/var/crash` (like file creation). Hopefully if it's broken, the user + impact is very limited, and only Ubuntu development (crash reporting) would see + the effects. [ Other Info ] This was first discussed on Matrix [2], as well as in person with the Desktop team. [1]: https://salsa.debian.org/gnome-team/gnome-shell/-/blob/ubuntu/latest/debian/source_gnome-shell.py?ref_type=heads#L42 [2]: https://matrix.to/#/!QMtJBibTYYOCvXJEdv:ubuntu.com/$aZlRcLJiPXDNk_sWwfkDTtcKZrJ3L4iUaMZ_HvK1WdI?via=ubuntu.com&via=matrix.org&via=matrix.debian.social
** Description changed: [ Impact ] This bug revolves around the error reporting story in Ubuntu, which is what's behind https://errors.ubuntu.com . GNOME is generating error reports that include a `ShellJournal` field [1], but `whoopsie` (the service uploading the report) doesn't allow it. That means the error reporting story for GNOME crashes isn't great, and slows down the fixing of bugs in this particular situation. More generally, the proposed fix would add the current `ShellJournal` field, because it's the name currently in use in GNOME, but also adds a more generic `JournalAll` field, that only has a better naming, in the goal of deprecating the `ShellJournal` field when GNOME is updated. `JournalAll` would in effect allow any other application to include generic `journalctl` output. [ Test Plan ] + To perform this test plan, one need to be part of the `error-tracker- + access` LP group. + * Put the two crash files attached to this bug in an empty folder (see their description for details). * From that folder, run the following to make sure both crashes would be candidate for upload: - touch _usr_libexec_gnome-shell-calendar-server.1000.upload _usr_libexec_gnome-shell-calendar-server_smaller_fields.1000.upload + touch _usr_libexec_gnome-shell-calendar-server.1000.upload _usr_libexec_gnome-shell-calendar-server_smaller_fields.1000.upload * Then, still from that folder, run the `whoopsie` under test with the following: - CRASH_DB_URL=https://daisy.ubuntu.com APPORT_REPORT_DIR=$(pwd) CRASH_DB_IDENTIFIER=bug-2130649-verification-$(lsb_release -cs) whoopsie --no-polling -f + CRASH_DB_URL=https://daisy.ubuntu.com APPORT_REPORT_DIR=$(pwd) CRASH_DB_IDENTIFIER=bug-2130649-verification-$(lsb_release -cs) whoopsie --no-polling -f This should report two OOPSes being reported with a line like the following: - [13:24:52] Reported OOPS ID bd7ad35e-c9f9-11f0-a191-fa163e171f02 + [13:24:52] Reported OOPS ID bd7ad35e-c9f9-11f0-a191-fa163e171f02 Gather the two UUIDs and go to each OOPS page (https://errors.ubuntu.com/oops/<uuid>). With a non-fixed `whoopsie`, only `JournalError` will appear on the non "smaller_fields" crash report, whereas all three fields will be there with a fixed `whoopsie`. With the "smaller_fields" crash, all three fields should always be there. [ Where problems could occur ] * `whoopsie` is a C application doing networking and parsing. Many things could go wrong, but the patch only adds two lines to an allow-list, so hopefully if it's working today, it shouldn't break too much. * `whoopsie` isn't directly useful to an Ubuntu system, and is actually not enabled by default on Ubuntu Server. It's only triggered when some change happen in `/var/crash` (like file creation). Hopefully if it's broken, the user impact is very limited, and only Ubuntu development (crash reporting) would see the effects. [ Other Info ] This was first discussed on Matrix [2], as well as in person with the Desktop team. [1]: https://salsa.debian.org/gnome-team/gnome-shell/-/blob/ubuntu/latest/debian/source_gnome-shell.py?ref_type=heads#L42 [2]: https://matrix.to/#/!QMtJBibTYYOCvXJEdv:ubuntu.com/$aZlRcLJiPXDNk_sWwfkDTtcKZrJ3L4iUaMZ_HvK1WdI?via=ubuntu.com&via=matrix.org&via=matrix.debian.social ** Description changed: [ Impact ] This bug revolves around the error reporting story in Ubuntu, which is what's behind https://errors.ubuntu.com . GNOME is generating error reports that include a `ShellJournal` field [1], but `whoopsie` (the service uploading the report) doesn't allow it. That means the error reporting story for GNOME crashes isn't great, and slows down the fixing of bugs in this particular situation. More generally, the proposed fix would add the current `ShellJournal` field, because it's the name currently in use in GNOME, but also adds a more generic `JournalAll` field, that only has a better naming, in the goal of deprecating the `ShellJournal` field when GNOME is updated. `JournalAll` would in effect allow any other application to include generic `journalctl` output. [ Test Plan ] - To perform this test plan, one need to be part of the `error-tracker- + To perform this test plan, one needs to be part of the `error-tracker- access` LP group. * Put the two crash files attached to this bug in an empty folder (see their description for details). * From that folder, run the following to make sure both crashes would be candidate for upload: touch _usr_libexec_gnome-shell-calendar-server.1000.upload _usr_libexec_gnome-shell-calendar-server_smaller_fields.1000.upload * Then, still from that folder, run the `whoopsie` under test with the following: CRASH_DB_URL=https://daisy.ubuntu.com APPORT_REPORT_DIR=$(pwd) CRASH_DB_IDENTIFIER=bug-2130649-verification-$(lsb_release -cs) whoopsie --no-polling -f This should report two OOPSes being reported with a line like the following: [13:24:52] Reported OOPS ID bd7ad35e-c9f9-11f0-a191-fa163e171f02 Gather the two UUIDs and go to each OOPS page (https://errors.ubuntu.com/oops/<uuid>). With a non-fixed `whoopsie`, only `JournalError` will appear on the non "smaller_fields" crash report, whereas all three fields will be there with a fixed `whoopsie`. With the "smaller_fields" crash, all three fields should always be there. [ Where problems could occur ] * `whoopsie` is a C application doing networking and parsing. Many things could go wrong, but the patch only adds two lines to an allow-list, so hopefully if it's working today, it shouldn't break too much. * `whoopsie` isn't directly useful to an Ubuntu system, and is actually not enabled by default on Ubuntu Server. It's only triggered when some change happen in `/var/crash` (like file creation). Hopefully if it's broken, the user impact is very limited, and only Ubuntu development (crash reporting) would see the effects. [ Other Info ] This was first discussed on Matrix [2], as well as in person with the Desktop team. [1]: https://salsa.debian.org/gnome-team/gnome-shell/-/blob/ubuntu/latest/debian/source_gnome-shell.py?ref_type=heads#L42 [2]: https://matrix.to/#/!QMtJBibTYYOCvXJEdv:ubuntu.com/$aZlRcLJiPXDNk_sWwfkDTtcKZrJ3L4iUaMZ_HvK1WdI?via=ubuntu.com&via=matrix.org&via=matrix.debian.social -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2130649 Title: whoopsie drops the ShellJournal field To manage notifications about this bug go to: https://bugs.launchpad.net/whoopsie/+bug/2130649/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
