Activity log for bug #1962454

Date Who What changed Old value New value Message
2022-02-28 09:57:46 Daniel van Vugt bug added bug
2022-02-28 10:01:11 Brian Murray bug task added apport (Ubuntu)
2022-02-28 10:08:00 Brian Murray tags rls-jj-incoming
2022-03-10 16:23:32 Brian Murray apport (Ubuntu): importance Undecided Low
2022-03-10 16:23:35 Brian Murray errors: status New Invalid
2022-03-10 16:23:39 Brian Murray apport (Ubuntu): status New Triaged
2022-04-22 07:13:16 Daniel van Vugt bug task added apport
2022-04-22 07:14:20 Daniel van Vugt apport (Ubuntu): importance Low Medium
2022-04-28 16:23:32 Brian Murray tags rls-jj-incoming fr-2321 rls-jj-incoming
2022-04-28 16:23:34 Brian Murray tags fr-2321 rls-jj-incoming jammy
2022-04-28 16:23:50 Brian Murray tags jammy fr-2321 jammy
2022-04-28 16:24:43 Brian Murray nominated for series Ubuntu Jammy
2022-04-28 16:24:43 Brian Murray bug task added apport (Ubuntu Jammy)
2022-04-28 16:24:52 Brian Murray apport (Ubuntu Jammy): status New Triaged
2022-04-28 16:24:54 Brian Murray apport (Ubuntu Jammy): importance Undecided Medium
2022-05-17 23:16:45 Brian Murray apport: assignee Brian Murray (brian-murray)
2022-05-17 23:16:48 Brian Murray apport: status New In Progress
2022-05-17 23:25:31 Brian Murray merge proposal linked https://code.launchpad.net/~apport-hackers/apport/+git/apport/+merge/422775
2022-05-18 18:39:18 Benjamin Drung apport: status In Progress Fix Committed
2022-05-18 18:43:43 Benjamin Drung apport: milestone 2.21.0
2022-06-09 15:38:41 Benjamin Drung apport: status Fix Committed Fix Released
2022-06-09 15:42:03 Benjamin Drung apport: importance Undecided Medium
2022-06-10 08:34:49 Benjamin Drung apport: assignee Brian Murray (brian-murray) Benjamin Drung (bdrung)
2022-06-10 16:31:37 Launchpad Janitor apport (Ubuntu): status Triaged Fix Released
2022-07-04 12:02:33 Łukasz Zemczak apport (Ubuntu Jammy): status Triaged Incomplete
2022-07-11 06:29:55 Daniel van Vugt description For example, I just experienced a crash at: Feb 28 17:31:12 And the JournalErrors entries are: Feb 28 17:31:30 - Feb 28 17:31:41 So don't relate to the crash. But it should be possible to tell journalctl to collect entries starting *before* the crash and cover the full crash timeframe. [Impact] Oops pages show wrong time window in JournalErrors. For example, I just experienced a crash at:   Feb 28 17:31:12 And the JournalErrors entries are:   Feb 28 17:31:30 - Feb 28 17:31:41 So don't relate to the crash. [Test Plan] [Where problems could occur] Worst case - In any part of the bug reporting/collection procedure, since that is what's changing. [Other Info]
2022-07-11 06:39:54 Daniel van Vugt description [Impact] Oops pages show wrong time window in JournalErrors. For example, I just experienced a crash at:   Feb 28 17:31:12 And the JournalErrors entries are:   Feb 28 17:31:30 - Feb 28 17:31:41 So don't relate to the crash. [Test Plan] [Where problems could occur] Worst case - In any part of the bug reporting/collection procedure, since that is what's changing. [Other Info] [Impact] Oops pages show wrong time window in JournalErrors. For example, I just experienced a crash at:   Feb 28 17:31:12 And the JournalErrors entries are:   Feb 28 17:31:30 - Feb 28 17:31:41 So don't relate to the crash. [Test Plan] 1. Find a recent crash report from a relevant Ubuntu release on https://errors.ubuntu.com/ If you're looking at https://errors.ubuntu.com/problem/SOMETHING then scroll down and pick a relevant instance from the Occurrences list. 2. Now you're on a page starting with https://errors.ubuntu.com/oops/ look at the Date and JournalErrors fields. 3. Verify that Date falls within the time range of the JournalErrors entries. [Where problems could occur] Worst case - in any part of the bug reporting/collection procedure, since that is what's changing. [Other Info]
2022-07-11 06:40:01 Daniel van Vugt bug task deleted errors
2022-07-11 06:47:29 Daniel van Vugt description [Impact] Oops pages show wrong time window in JournalErrors. For example, I just experienced a crash at:   Feb 28 17:31:12 And the JournalErrors entries are:   Feb 28 17:31:30 - Feb 28 17:31:41 So don't relate to the crash. [Test Plan] 1. Find a recent crash report from a relevant Ubuntu release on https://errors.ubuntu.com/ If you're looking at https://errors.ubuntu.com/problem/SOMETHING then scroll down and pick a relevant instance from the Occurrences list. 2. Now you're on a page starting with https://errors.ubuntu.com/oops/ look at the Date and JournalErrors fields. 3. Verify that Date falls within the time range of the JournalErrors entries. [Where problems could occur] Worst case - in any part of the bug reporting/collection procedure, since that is what's changing. [Other Info] [Impact] Oops pages show wrong time window in JournalErrors. For example, I just experienced a crash at:   Feb 28 17:31:12 And the JournalErrors entries are:   Feb 28 17:31:30 - Feb 28 17:31:41 So don't relate to the crash. [Test Plan] 1. Find a recent crash report from a relevant Ubuntu release on https://errors.ubuntu.com/ If you're looking at https://errors.ubuntu.com/problem/SOMETHING then scroll down and pick a relevant instance from the Occurrences list. 2. Now you're on a page starting with https://errors.ubuntu.com/oops/ look at Dependencies and verify that apport is a recent enough version to contain the proposed fix. 3. Expand the JournalErrors field and verify the Date field above it falls within the time range of the JournalErrors entries. [Where problems could occur] Worst case - in any part of the bug reporting/collection procedure, since that is what's changing. [Other Info]
2022-07-11 06:58:30 Daniel van Vugt description [Impact] Oops pages show wrong time window in JournalErrors. For example, I just experienced a crash at:   Feb 28 17:31:12 And the JournalErrors entries are:   Feb 28 17:31:30 - Feb 28 17:31:41 So don't relate to the crash. [Test Plan] 1. Find a recent crash report from a relevant Ubuntu release on https://errors.ubuntu.com/ If you're looking at https://errors.ubuntu.com/problem/SOMETHING then scroll down and pick a relevant instance from the Occurrences list. 2. Now you're on a page starting with https://errors.ubuntu.com/oops/ look at Dependencies and verify that apport is a recent enough version to contain the proposed fix. 3. Expand the JournalErrors field and verify the Date field above it falls within the time range of the JournalErrors entries. [Where problems could occur] Worst case - in any part of the bug reporting/collection procedure, since that is what's changing. [Other Info] [Impact] Oops pages show wrong time window in JournalErrors. For example, I just experienced a crash at:   Feb 28 17:31:12 And the JournalErrors entries are:   Feb 28 17:31:30 - Feb 28 17:31:41 So don't relate to the crash. [Test Plan] 1. Find a recent crash report from a relevant Ubuntu release on https://errors.ubuntu.com/ If you're looking at https://errors.ubuntu.com/problem/SOMETHING then scroll down and pick a relevant instance from the Occurrences list. 2. Now you're on a page starting with https://errors.ubuntu.com/oops/ look at Dependencies and verify that apport is a recent enough version to contain the proposed fix. 3. Verify the Date field falls within the time range of the JournalErrors entries. 4. Step 3 might have failed in the case of there being no system log entries at all written to disk around the time of the crash. That does not necessarily mean the test plan has failed. Goto step 1 and pick a different crash. [Where problems could occur] Worst case - in any part of the bug reporting/collection procedure, since that is what's changing. [Other Info]
2022-07-11 06:59:33 Daniel van Vugt description [Impact] Oops pages show wrong time window in JournalErrors. For example, I just experienced a crash at:   Feb 28 17:31:12 And the JournalErrors entries are:   Feb 28 17:31:30 - Feb 28 17:31:41 So don't relate to the crash. [Test Plan] 1. Find a recent crash report from a relevant Ubuntu release on https://errors.ubuntu.com/ If you're looking at https://errors.ubuntu.com/problem/SOMETHING then scroll down and pick a relevant instance from the Occurrences list. 2. Now you're on a page starting with https://errors.ubuntu.com/oops/ look at Dependencies and verify that apport is a recent enough version to contain the proposed fix. 3. Verify the Date field falls within the time range of the JournalErrors entries. 4. Step 3 might have failed in the case of there being no system log entries at all written to disk around the time of the crash. That does not necessarily mean the test plan has failed. Goto step 1 and pick a different crash. [Where problems could occur] Worst case - in any part of the bug reporting/collection procedure, since that is what's changing. [Other Info] [Impact] Oops pages show wrong time window in JournalErrors. For example, I just experienced a crash at:   Feb 28 17:31:12 And the JournalErrors entries are:   Feb 28 17:31:30 - Feb 28 17:31:41 So don't relate to the crash. [Test Plan] 1. Find a recent crash report from a relevant Ubuntu release on https://errors.ubuntu.com/ If you're looking at https://errors.ubuntu.com/problem/SOMETHING then scroll down and pick a relevant instance from the Occurrences list. 2. Now you're on a page starting with https://errors.ubuntu.com/oops/ look at ApportVersion and verify that apport is a recent enough version to contain the proposed fix. 3. Verify the Date field falls within the time range of the JournalErrors entries. 4. Step 3 might have failed in the case of there being no system log entries at all written to disk around the time of the crash. That does not necessarily mean the test plan has failed. Goto step 1 and pick a different crash. [Where problems could occur] Worst case - in any part of the bug reporting/collection procedure, since that is what's changing. [Other Info]
2022-07-11 07:01:29 Daniel van Vugt description [Impact] Oops pages show wrong time window in JournalErrors. For example, I just experienced a crash at:   Feb 28 17:31:12 And the JournalErrors entries are:   Feb 28 17:31:30 - Feb 28 17:31:41 So don't relate to the crash. [Test Plan] 1. Find a recent crash report from a relevant Ubuntu release on https://errors.ubuntu.com/ If you're looking at https://errors.ubuntu.com/problem/SOMETHING then scroll down and pick a relevant instance from the Occurrences list. 2. Now you're on a page starting with https://errors.ubuntu.com/oops/ look at ApportVersion and verify that apport is a recent enough version to contain the proposed fix. 3. Verify the Date field falls within the time range of the JournalErrors entries. 4. Step 3 might have failed in the case of there being no system log entries at all written to disk around the time of the crash. That does not necessarily mean the test plan has failed. Goto step 1 and pick a different crash. [Where problems could occur] Worst case - in any part of the bug reporting/collection procedure, since that is what's changing. [Other Info] [Impact] Oops pages show wrong time window in JournalErrors. For example, I just experienced a crash at:   Feb 28 17:31:12 And the JournalErrors entries are:   Feb 28 17:31:30 - Feb 28 17:31:41 So don't relate to the crash. [Test Plan] 1. Find a recent crash report from a relevant Ubuntu release on https://errors.ubuntu.com/ If you're looking at https://errors.ubuntu.com/problem/SOMETHING then scroll down and pick a relevant instance from the Occurrences list. 2. Now you're on a page starting with https://errors.ubuntu.com/oops/ look at ApportVersion and verify that apport is a recent enough version to contain the proposed fix. 3. Verify the Date field falls within the time range of the JournalErrors entries. Step 3 might have failed in the case of there being no system log entries at all written to disk around the time of the crash. That does not necessarily mean the test plan has failed. Goto step 1 and pick a different crash. Prior to the fix you would almost never find oops pages that would pass the test. After the fix you should find many/most oops pages do pass the test. [Where problems could occur] Worst case - in any part of the bug reporting/collection procedure, since that is what's changing. [Other Info]
2022-07-11 07:04:56 Daniel van Vugt description [Impact] Oops pages show wrong time window in JournalErrors. For example, I just experienced a crash at:   Feb 28 17:31:12 And the JournalErrors entries are:   Feb 28 17:31:30 - Feb 28 17:31:41 So don't relate to the crash. [Test Plan] 1. Find a recent crash report from a relevant Ubuntu release on https://errors.ubuntu.com/ If you're looking at https://errors.ubuntu.com/problem/SOMETHING then scroll down and pick a relevant instance from the Occurrences list. 2. Now you're on a page starting with https://errors.ubuntu.com/oops/ look at ApportVersion and verify that apport is a recent enough version to contain the proposed fix. 3. Verify the Date field falls within the time range of the JournalErrors entries. Step 3 might have failed in the case of there being no system log entries at all written to disk around the time of the crash. That does not necessarily mean the test plan has failed. Goto step 1 and pick a different crash. Prior to the fix you would almost never find oops pages that would pass the test. After the fix you should find many/most oops pages do pass the test. [Where problems could occur] Worst case - in any part of the bug reporting/collection procedure, since that is what's changing. [Other Info] [Impact] Oops pages show wrong time window in JournalErrors. For example, I just experienced a crash at:   Feb 28 17:31:12 And the JournalErrors entries are:   Feb 28 17:31:30 - Feb 28 17:31:41 So don't relate to the crash. [Test Plan] 1. Find a recent crash report from a relevant Ubuntu release on https://errors.ubuntu.com/ If you're looking at https://errors.ubuntu.com/problem/SOMETHING then scroll down and pick a relevant instance from the Occurrences list. 2. Now you're on a page starting with https://errors.ubuntu.com/oops/ look at ApportVersion and verify that apport is a recent enough version to contain the proposed fix. If not then go to step 1. 3. Verify the Date field falls within the time range of the JournalErrors entries. This *may* fail in the case of there being no system log entries at all written to disk around the time of the crash. That does not necessarily mean the test plan has failed. Go to step 1 and pick a different crash. Prior to the fix you would almost never find oops pages that would pass the test. After the fix you should find many/most oops pages do pass the test. [Where problems could occur] Worst case - in any part of the bug reporting/collection procedure, since that is what's changing. [Other Info]
2022-07-11 07:06:14 Daniel van Vugt description [Impact] Oops pages show wrong time window in JournalErrors. For example, I just experienced a crash at:   Feb 28 17:31:12 And the JournalErrors entries are:   Feb 28 17:31:30 - Feb 28 17:31:41 So don't relate to the crash. [Test Plan] 1. Find a recent crash report from a relevant Ubuntu release on https://errors.ubuntu.com/ If you're looking at https://errors.ubuntu.com/problem/SOMETHING then scroll down and pick a relevant instance from the Occurrences list. 2. Now you're on a page starting with https://errors.ubuntu.com/oops/ look at ApportVersion and verify that apport is a recent enough version to contain the proposed fix. If not then go to step 1. 3. Verify the Date field falls within the time range of the JournalErrors entries. This *may* fail in the case of there being no system log entries at all written to disk around the time of the crash. That does not necessarily mean the test plan has failed. Go to step 1 and pick a different crash. Prior to the fix you would almost never find oops pages that would pass the test. After the fix you should find many/most oops pages do pass the test. [Where problems could occur] Worst case - in any part of the bug reporting/collection procedure, since that is what's changing. [Other Info] [Impact] Oops pages show wrong time window in JournalErrors. For example, I just experienced a crash at:   Feb 28 17:31:12 And the JournalErrors entries are:   Feb 28 17:31:30 - Feb 28 17:31:41 So don't relate to the crash. [Test Plan] 1. Find a recent crash report from a relevant Ubuntu release on https://errors.ubuntu.com/ If you're looking at https://errors.ubuntu.com/problem/SOMETHING then scroll down and pick a relevant instance from the Occurrences list. 2. Now you're on a page starting with https://errors.ubuntu.com/oops/ look at ApportVersion and verify that apport is a recent enough version to contain the proposed fix. If not then go to step 1. 3. Verify the Date field falls within the time range of the JournalErrors entries. Step 3 might fail in the case of there being no system log entries from around the time of the crash. That does not necessarily mean the test plan has failed. Go to step 1 and pick a different crash. Prior to the fix you would almost never find oops pages that would pass the test. After the fix you should find many/most oops pages do pass the test. [Where problems could occur] Worst case - in any part of the bug reporting/collection procedure, since that is what's changing. [Other Info]
2022-09-11 23:59:33 Matthieu Clemenceau tags fr-2321 jammy foundations-todo fr-2321 jammy
2022-09-11 23:59:43 Matthieu Clemenceau bug added subscriber Ubuntu Foundations Team
2022-09-15 15:35:23 Matthieu Clemenceau removed subscriber Ubuntu Foundations Team
2022-09-15 15:35:30 Matthieu Clemenceau bug added subscriber Ubuntu Foundations Bugs
2022-09-19 17:20:00 Benjamin Drung description [Impact] Oops pages show wrong time window in JournalErrors. For example, I just experienced a crash at:   Feb 28 17:31:12 And the JournalErrors entries are:   Feb 28 17:31:30 - Feb 28 17:31:41 So don't relate to the crash. [Test Plan] 1. Find a recent crash report from a relevant Ubuntu release on https://errors.ubuntu.com/ If you're looking at https://errors.ubuntu.com/problem/SOMETHING then scroll down and pick a relevant instance from the Occurrences list. 2. Now you're on a page starting with https://errors.ubuntu.com/oops/ look at ApportVersion and verify that apport is a recent enough version to contain the proposed fix. If not then go to step 1. 3. Verify the Date field falls within the time range of the JournalErrors entries. Step 3 might fail in the case of there being no system log entries from around the time of the crash. That does not necessarily mean the test plan has failed. Go to step 1 and pick a different crash. Prior to the fix you would almost never find oops pages that would pass the test. After the fix you should find many/most oops pages do pass the test. [Where problems could occur] Worst case - in any part of the bug reporting/collection procedure, since that is what's changing. [Other Info] [Impact] Oops pages show wrong time window in JournalErrors. For example, I just experienced a crash at:   Feb 28 17:31:12 And the JournalErrors entries are:   Feb 28 17:31:30 - Feb 28 17:31:41 So don't relate to the crash. [Test Plan] 1. Find a recent crash report from a relevant Ubuntu release on https://errors.ubuntu.com/ If you're looking at https://errors.ubuntu.com/problem/SOMETHING then scroll down and pick a relevant instance from the Occurrences list. 2. Now you're on a page starting with https://errors.ubuntu.com/oops/ look at ApportVersion and verify that apport is a recent enough version to contain the proposed fix. If not then go to step 1. 3. Verify the Date field falls within the time range of the JournalErrors entries. Step 3 might fail in the case of there being no system log entries from around the time of the crash. That does not necessarily mean the test plan has failed. Go to step 1 and pick a different crash. Prior to the fix you would almost never find oops pages that would pass the test. After the fix you should find many/most oops pages do pass the test. [Where problems could occur] Worst case - in any part of the bug reporting/collection procedure, since that is what's changing. [Other Info] Due to the huge amount of broken autopkgtest tests, the diff for the SRUs are bigger than desired. The individual commits in https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/apport/ are probably easier to review. * jammy SRU: https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/apport/log/?h=1fa042cc27714c407494b3d6dfd0730bb984f3eb * focal SRU: https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/apport/log/?h=eaa92037c7dfba621719c6f81fd75f6a09e90881
2022-09-19 17:20:08 Benjamin Drung nominated for series Ubuntu Focal
2022-09-19 17:20:08 Benjamin Drung bug task added apport (Ubuntu Focal)
2022-09-20 11:01:04 Heinrich Schuchardt apport (Ubuntu Jammy): status Incomplete Confirmed
2022-09-21 13:50:32 Simon Chopin apport (Ubuntu Focal): importance Undecided Medium
2022-09-21 13:51:42 Simon Chopin apport (Ubuntu Focal): status New Confirmed
2022-10-17 13:00:25 Timo Aaltonen apport (Ubuntu Jammy): status Confirmed Fix Committed
2022-10-17 13:00:27 Timo Aaltonen bug added subscriber Ubuntu Stable Release Updates Team
2022-10-17 13:00:29 Timo Aaltonen bug added subscriber SRU Verification
2022-10-17 13:00:32 Timo Aaltonen tags foundations-todo fr-2321 jammy foundations-todo fr-2321 jammy verification-needed verification-needed-jammy
2022-10-17 13:05:48 Timo Aaltonen apport (Ubuntu Focal): status Confirmed Fix Committed
2022-10-17 13:05:53 Timo Aaltonen tags foundations-todo fr-2321 jammy verification-needed verification-needed-jammy foundations-todo fr-2321 jammy verification-needed verification-needed-focal verification-needed-jammy
2022-11-22 12:52:11 Benjamin Drung tags foundations-todo fr-2321 jammy verification-needed verification-needed-focal verification-needed-jammy foundations-todo fr-2321 jammy verification-done-jammy verification-needed verification-needed-focal
2022-11-22 12:52:24 Benjamin Drung apport (Ubuntu): assignee Benjamin Drung (bdrung)
2022-11-22 15:33:00 Benjamin Drung tags foundations-todo fr-2321 jammy verification-done-jammy verification-needed verification-needed-focal foundations-todo fr-2321 jammy verification-done verification-done-focal verification-done-jammy
2022-11-23 00:49:05 Chris Halse Rogers removed subscriber Ubuntu Stable Release Updates Team
2022-11-23 02:02:38 Launchpad Janitor apport (Ubuntu Focal): status Fix Committed Fix Released
2022-11-23 02:24:28 Launchpad Janitor apport (Ubuntu Jammy): status Fix Committed Fix Released
2022-11-23 09:16:10 Benjamin Drung tags foundations-todo fr-2321 jammy verification-done verification-done-focal verification-done-jammy fr-2321 jammy verification-done verification-done-focal verification-done-jammy
2022-11-23 09:16:12 Benjamin Drung removed subscriber Ubuntu Foundations Bugs