| 2012-08-20 20:46:47 |
Steve Langasek |
bug |
|
|
added bug |
| 2012-08-20 20:51:23 |
Steve Langasek |
summary |
we should not report crashes to daisy that are not reported to LP due to out-of-date binaries on disk |
don't report python crashes for programs that don't match the file on disk (like for kernel crashes) |
|
| 2012-08-20 20:51:29 |
Steve Langasek |
apport (Ubuntu): status |
New |
Triaged |
|
| 2012-08-20 20:51:31 |
Steve Langasek |
apport (Ubuntu): importance |
Undecided |
High |
|
| 2012-08-20 20:51:38 |
Steve Langasek |
nominated for series |
|
Ubuntu Precise |
|
| 2012-08-20 20:51:38 |
Steve Langasek |
bug task added |
|
apport (Ubuntu Precise) |
|
| 2012-08-20 20:51:38 |
Steve Langasek |
nominated for series |
|
Ubuntu Quantal |
|
| 2012-08-20 20:51:38 |
Steve Langasek |
bug task added |
|
apport (Ubuntu Quantal) |
|
| 2012-08-20 20:53:20 |
Steve Langasek |
apport (Ubuntu Precise): status |
New |
Triaged |
|
| 2012-08-20 20:53:22 |
Steve Langasek |
apport (Ubuntu Precise): importance |
Undecided |
High |
|
| 2012-08-20 20:53:29 |
Steve Langasek |
apport (Ubuntu Quantal): assignee |
|
Brian Murray (brian-murray) |
|
| 2012-08-20 21:49:01 |
Brian Murray |
summary |
don't report python crashes for programs that don't match the file on disk (like for kernel crashes) |
don't report crashes for programs that don't match the file on disk (like for kernel crashes) |
|
| 2012-09-06 23:43:49 |
Launchpad Janitor |
branch linked |
|
lp:~brian-murray/apport/bug-1039220 |
|
| 2012-09-07 18:26:25 |
Brian Murray |
apport (Ubuntu Quantal): status |
Triaged |
In Progress |
|
| 2012-09-07 19:57:40 |
Brian Murray |
description |
Every crash report that gets fixed in a package upload winds up with some fuzziness in the bucket showing a small number of crash reports in the very version that fixes it. E.g.:
https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fbin%2Fubuntuone-installer%3AGError%3Afinished%3Afunction
(bug #853060)
This makes it impossible to tell with certainty by looking at errors.ubuntu.com if a crash is really fixed, or if it's just been made less frequent. We need to have good data here to be able to use errors.u.c for decision making around SRU publication.
The suspicion is that the rule preventing launchpad bugs from being filed when the running process doesn't match the file on disk is not being applied correctly to whoopsie. It definitely should be.
(It's possible that this is therefore a duplicate of bug #1020994. I'm not sure, I haven't looked at the code.)
I would also argue that, if this happens in the "system service" case, we should not show the user any crash dialog for it either, so long as we don't have support for leading them to a targeted update to fix the crash. We get no useful crash information from the user in this case, and the risk of confusion from the dialog is great when it's a system service crash. As a matter of policy, front-end applications need to be resilient in the face of failures of back-end daemons.
ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: apport 2.4-0ubuntu8
ProcVersionSignature: Ubuntu 3.5.0-10.10-generic 3.5.1
Uname: Linux 3.5.0-10-generic x86_64
ApportVersion: 2.4-0ubuntu8
Architecture: amd64
Date: Mon Aug 20 12:34:10 2012
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
PackageArchitecture: all
SourcePackage: apport
UpgradeStatus: Upgraded to quantal on 2012-06-11 (70 days ago)
modified.conffile..etc.apport.crashdb.conf: [modified]
mtime.conffile..etc.apport.crashdb.conf: 2012-05-04T17:01:02 |
TEST CASE:
1) sudo vi /etc/default/apport
2) set enabled=1
3) sudo service apport start
4) install lp-grab-attachments
5) lp-grab-attachments 2039920 (should crash with a keyerror)
6) close the apport dialog regarding the application crashing (via the X in the corner)
7) vi $(which lp-grab-attachments)
8) modify copyright year or some comment
9) ubuntu-bug /var/crash/_usr_bin_lp-grab-attachments.*crash
10) observe apport dialog that this is unreportable and click okay
11) ls -l /var/crash (observe _usr_bin_lp-grab-attachments .upload and .uploaded files)
12) remove _usr_bin_lp-grab-attachments files in /var/crash
13) install package from -proposed, follow test case and there should *not* be a .upload or .uploaded file as seen in step 11
Every crash report that gets fixed in a package upload winds up with some fuzziness in the bucket showing a small number of crash reports in the very version that fixes it. E.g.:
https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fbin%2Fubuntuone-installer%3AGError%3Afinished%3Afunction
(bug #853060)
This makes it impossible to tell with certainty by looking at errors.ubuntu.com if a crash is really fixed, or if it's just been made less frequent. We need to have good data here to be able to use errors.u.c for decision making around SRU publication.
The suspicion is that the rule preventing launchpad bugs from being filed when the running process doesn't match the file on disk is not being applied correctly to whoopsie. It definitely should be.
(It's possible that this is therefore a duplicate of bug #1020994. I'm not sure, I haven't looked at the code.)
I would also argue that, if this happens in the "system service" case, we should not show the user any crash dialog for it either, so long as we don't have support for leading them to a targeted update to fix the crash. We get no useful crash information from the user in this case, and the risk of confusion from the dialog is great when it's a system service crash. As a matter of policy, front-end applications need to be resilient in the face of failures of back-end daemons.
ProblemType: BugDistroRelease: Ubuntu 12.10
Package: apport 2.4-0ubuntu8
ProcVersionSignature: Ubuntu 3.5.0-10.10-generic 3.5.1
Uname: Linux 3.5.0-10-generic x86_64
ApportVersion: 2.4-0ubuntu8
Architecture: amd64
Date: Mon Aug 20 12:34:10 2012InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
PackageArchitecture: allSourcePackage: apport
UpgradeStatus: Upgraded to quantal on 2012-06-11 (70 days ago)
modified.conffile..etc.apport.crashdb.conf: [modified]
mtime.conffile..etc.apport.crashdb.conf: 2012-05-04T17:01:02 |
|
| 2012-09-10 10:42:48 |
Martin Pitt |
bug |
|
|
added subscriber Martin Pitt |
| 2012-09-19 13:40:23 |
Didier Roche-Tolomelli |
apport (Ubuntu Quantal): importance |
High |
Medium |
|
| 2012-09-19 13:40:51 |
Didier Roche-Tolomelli |
apport (Ubuntu Precise): importance |
High |
Medium |
|
| 2012-09-24 19:58:24 |
Launchpad Janitor |
branch linked |
|
lp:~brian-murray/apport/no-unreportable |
|
| 2012-10-15 19:56:42 |
Brian Murray |
description |
TEST CASE:
1) sudo vi /etc/default/apport
2) set enabled=1
3) sudo service apport start
4) install lp-grab-attachments
5) lp-grab-attachments 2039920 (should crash with a keyerror)
6) close the apport dialog regarding the application crashing (via the X in the corner)
7) vi $(which lp-grab-attachments)
8) modify copyright year or some comment
9) ubuntu-bug /var/crash/_usr_bin_lp-grab-attachments.*crash
10) observe apport dialog that this is unreportable and click okay
11) ls -l /var/crash (observe _usr_bin_lp-grab-attachments .upload and .uploaded files)
12) remove _usr_bin_lp-grab-attachments files in /var/crash
13) install package from -proposed, follow test case and there should *not* be a .upload or .uploaded file as seen in step 11
Every crash report that gets fixed in a package upload winds up with some fuzziness in the bucket showing a small number of crash reports in the very version that fixes it. E.g.:
https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fbin%2Fubuntuone-installer%3AGError%3Afinished%3Afunction
(bug #853060)
This makes it impossible to tell with certainty by looking at errors.ubuntu.com if a crash is really fixed, or if it's just been made less frequent. We need to have good data here to be able to use errors.u.c for decision making around SRU publication.
The suspicion is that the rule preventing launchpad bugs from being filed when the running process doesn't match the file on disk is not being applied correctly to whoopsie. It definitely should be.
(It's possible that this is therefore a duplicate of bug #1020994. I'm not sure, I haven't looked at the code.)
I would also argue that, if this happens in the "system service" case, we should not show the user any crash dialog for it either, so long as we don't have support for leading them to a targeted update to fix the crash. We get no useful crash information from the user in this case, and the risk of confusion from the dialog is great when it's a system service crash. As a matter of policy, front-end applications need to be resilient in the face of failures of back-end daemons.
ProblemType: BugDistroRelease: Ubuntu 12.10
Package: apport 2.4-0ubuntu8
ProcVersionSignature: Ubuntu 3.5.0-10.10-generic 3.5.1
Uname: Linux 3.5.0-10-generic x86_64
ApportVersion: 2.4-0ubuntu8
Architecture: amd64
Date: Mon Aug 20 12:34:10 2012InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
PackageArchitecture: allSourcePackage: apport
UpgradeStatus: Upgraded to quantal on 2012-06-11 (70 days ago)
modified.conffile..etc.apport.crashdb.conf: [modified]
mtime.conffile..etc.apport.crashdb.conf: 2012-05-04T17:01:02 |
TEST CASE:
1) sudo vi /etc/default/apport
2) set enabled=1
3) sudo service apport start
4) install lp-grab-attachments
5) lp-grab-attachments 2039920 (should crash with a keyerror)
6) close the apport dialog regarding the application crashing (via the X in the corner)
7) sudo vi $(which lp-grab-attachments)
8) modify copyright year or some comment
9) ubuntu-bug /var/crash/_usr_bin_lp-grab-attachments.*crash
10) observe apport dialog that this is unreportable and click okay
11) ls -l /var/crash (observe _usr_bin_lp-grab-attachments .upload and .uploaded files)
12) remove _usr_bin_lp-grab-attachments files in /var/crash
13) reinstall lptools
13) install package from -proposed, follow test case and there should *not* be a .upload or .uploaded file as seen in step 11
Every crash report that gets fixed in a package upload winds up with some fuzziness in the bucket showing a small number of crash reports in the very version that fixes it. E.g.:
https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fbin%2Fubuntuone-installer%3AGError%3Afinished%3Afunction
(bug #853060)
This makes it impossible to tell with certainty by looking at errors.ubuntu.com if a crash is really fixed, or if it's just been made less frequent. We need to have good data here to be able to use errors.u.c for decision making around SRU publication.
The suspicion is that the rule preventing launchpad bugs from being filed when the running process doesn't match the file on disk is not being applied correctly to whoopsie. It definitely should be.
(It's possible that this is therefore a duplicate of bug #1020994. I'm not sure, I haven't looked at the code.)
I would also argue that, if this happens in the "system service" case, we should not show the user any crash dialog for it either, so long as we don't have support for leading them to a targeted update to fix the crash. We get no useful crash information from the user in this case, and the risk of confusion from the dialog is great when it's a system service crash. As a matter of policy, front-end applications need to be resilient in the face of failures of back-end daemons.
ProblemType: BugDistroRelease: Ubuntu 12.10
Package: apport 2.4-0ubuntu8
ProcVersionSignature: Ubuntu 3.5.0-10.10-generic 3.5.1
Uname: Linux 3.5.0-10-generic x86_64
ApportVersion: 2.4-0ubuntu8
Architecture: amd64
Date: Mon Aug 20 12:34:10 2012InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
PackageArchitecture: allSourcePackage: apport
UpgradeStatus: Upgraded to quantal on 2012-06-11 (70 days ago)
modified.conffile..etc.apport.crashdb.conf: [modified]
mtime.conffile..etc.apport.crashdb.conf: 2012-05-04T17:01:02 |
|
| 2012-10-15 23:14:10 |
Launchpad Janitor |
branch linked |
|
lp:~ubuntu-core-dev/ubuntu/quantal/apport/ubuntu |
|
| 2012-10-18 19:40:50 |
Steve Langasek |
description |
TEST CASE:
1) sudo vi /etc/default/apport
2) set enabled=1
3) sudo service apport start
4) install lp-grab-attachments
5) lp-grab-attachments 2039920 (should crash with a keyerror)
6) close the apport dialog regarding the application crashing (via the X in the corner)
7) sudo vi $(which lp-grab-attachments)
8) modify copyright year or some comment
9) ubuntu-bug /var/crash/_usr_bin_lp-grab-attachments.*crash
10) observe apport dialog that this is unreportable and click okay
11) ls -l /var/crash (observe _usr_bin_lp-grab-attachments .upload and .uploaded files)
12) remove _usr_bin_lp-grab-attachments files in /var/crash
13) reinstall lptools
13) install package from -proposed, follow test case and there should *not* be a .upload or .uploaded file as seen in step 11
Every crash report that gets fixed in a package upload winds up with some fuzziness in the bucket showing a small number of crash reports in the very version that fixes it. E.g.:
https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fbin%2Fubuntuone-installer%3AGError%3Afinished%3Afunction
(bug #853060)
This makes it impossible to tell with certainty by looking at errors.ubuntu.com if a crash is really fixed, or if it's just been made less frequent. We need to have good data here to be able to use errors.u.c for decision making around SRU publication.
The suspicion is that the rule preventing launchpad bugs from being filed when the running process doesn't match the file on disk is not being applied correctly to whoopsie. It definitely should be.
(It's possible that this is therefore a duplicate of bug #1020994. I'm not sure, I haven't looked at the code.)
I would also argue that, if this happens in the "system service" case, we should not show the user any crash dialog for it either, so long as we don't have support for leading them to a targeted update to fix the crash. We get no useful crash information from the user in this case, and the risk of confusion from the dialog is great when it's a system service crash. As a matter of policy, front-end applications need to be resilient in the face of failures of back-end daemons.
ProblemType: BugDistroRelease: Ubuntu 12.10
Package: apport 2.4-0ubuntu8
ProcVersionSignature: Ubuntu 3.5.0-10.10-generic 3.5.1
Uname: Linux 3.5.0-10-generic x86_64
ApportVersion: 2.4-0ubuntu8
Architecture: amd64
Date: Mon Aug 20 12:34:10 2012InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
PackageArchitecture: allSourcePackage: apport
UpgradeStatus: Upgraded to quantal on 2012-06-11 (70 days ago)
modified.conffile..etc.apport.crashdb.conf: [modified]
mtime.conffile..etc.apport.crashdb.conf: 2012-05-04T17:01:02 |
[Impact]
Reporting of crashes against currently-installed versions of packages, which this is not the version of package on disk, results in garbage data in the errors.ubuntu.com graphs that make it impossible to know with certainty that a given version of a package fixed a given crash. This severely hinders our reliance on errors.ubuntu.com for SRU validation.
[TEST CASE]
1) sudo vi /etc/default/apport
2) set enabled=1
3) sudo service apport start
4) install lp-grab-attachments
5) lp-grab-attachments 2039920 (should crash with a keyerror)
6) close the apport dialog regarding the application crashing (via the X in the corner)
7) sudo vi $(which lp-grab-attachments)
8) modify copyright year or some comment
9) ubuntu-bug /var/crash/_usr_bin_lp-grab-attachments.*crash
10) observe apport dialog that this is unreportable and click okay
11) ls -l /var/crash (observe _usr_bin_lp-grab-attachments .upload and .uploaded files)
12) remove _usr_bin_lp-grab-attachments files in /var/crash
13) reinstall lptools
13) install package from -proposed, follow test case and there should *not* be a .upload or .uploaded file as seen in step 11
[Regression Potential]
Worst-case scenario is that some crashes that should be reported fail to be reported as a result of a bug in this change.
Every crash report that gets fixed in a package upload winds up with some fuzziness in the bucket showing a small number of crash reports in the very version that fixes it. E.g.:
https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fbin%2Fubuntuone-installer%3AGError%3Afinished%3Afunction
(bug #853060)
This makes it impossible to tell with certainty by looking at errors.ubuntu.com if a crash is really fixed, or if it's just been made less frequent. We need to have good data here to be able to use errors.u.c for decision making around SRU publication.
The suspicion is that the rule preventing launchpad bugs from being filed when the running process doesn't match the file on disk is not being applied correctly to whoopsie. It definitely should be.
(It's possible that this is therefore a duplicate of bug #1020994. I'm not sure, I haven't looked at the code.)
I would also argue that, if this happens in the "system service" case, we should not show the user any crash dialog for it either, so long as we don't have support for leading them to a targeted update to fix the crash. We get no useful crash information from the user in this case, and the risk of confusion from the dialog is great when it's a system service crash. As a matter of policy, front-end applications need to be resilient in the face of failures of back-end daemons.
ProblemType: BugDistroRelease: Ubuntu 12.10
Package: apport 2.4-0ubuntu8
ProcVersionSignature: Ubuntu 3.5.0-10.10-generic 3.5.1
Uname: Linux 3.5.0-10-generic x86_64
ApportVersion: 2.4-0ubuntu8
Architecture: amd64
Date: Mon Aug 20 12:34:10 2012InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
PackageArchitecture: allSourcePackage: apport
UpgradeStatus: Upgraded to quantal on 2012-06-11 (70 days ago)
modified.conffile..etc.apport.crashdb.conf: [modified]
mtime.conffile..etc.apport.crashdb.conf: 2012-05-04T17:01:02 |
|
| 2012-10-18 19:43:11 |
Steve Langasek |
apport (Ubuntu Quantal): status |
In Progress |
Fix Committed |
|
| 2012-10-18 19:43:13 |
Steve Langasek |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2012-10-18 19:43:15 |
Steve Langasek |
bug |
|
|
added subscriber SRU Verification |
| 2012-10-18 19:43:17 |
Steve Langasek |
tags |
amd64 apport-bug quantal running-unity |
amd64 apport-bug quantal running-unity verification-needed |
|
| 2012-10-18 20:55:56 |
C de-Avillez |
tags |
amd64 apport-bug quantal running-unity verification-needed |
amd64 apport-bug quantal running-unity verification-done |
|
| 2012-10-18 20:56:19 |
Brian Murray |
description |
[Impact]
Reporting of crashes against currently-installed versions of packages, which this is not the version of package on disk, results in garbage data in the errors.ubuntu.com graphs that make it impossible to know with certainty that a given version of a package fixed a given crash. This severely hinders our reliance on errors.ubuntu.com for SRU validation.
[TEST CASE]
1) sudo vi /etc/default/apport
2) set enabled=1
3) sudo service apport start
4) install lp-grab-attachments
5) lp-grab-attachments 2039920 (should crash with a keyerror)
6) close the apport dialog regarding the application crashing (via the X in the corner)
7) sudo vi $(which lp-grab-attachments)
8) modify copyright year or some comment
9) ubuntu-bug /var/crash/_usr_bin_lp-grab-attachments.*crash
10) observe apport dialog that this is unreportable and click okay
11) ls -l /var/crash (observe _usr_bin_lp-grab-attachments .upload and .uploaded files)
12) remove _usr_bin_lp-grab-attachments files in /var/crash
13) reinstall lptools
13) install package from -proposed, follow test case and there should *not* be a .upload or .uploaded file as seen in step 11
[Regression Potential]
Worst-case scenario is that some crashes that should be reported fail to be reported as a result of a bug in this change.
Every crash report that gets fixed in a package upload winds up with some fuzziness in the bucket showing a small number of crash reports in the very version that fixes it. E.g.:
https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fbin%2Fubuntuone-installer%3AGError%3Afinished%3Afunction
(bug #853060)
This makes it impossible to tell with certainty by looking at errors.ubuntu.com if a crash is really fixed, or if it's just been made less frequent. We need to have good data here to be able to use errors.u.c for decision making around SRU publication.
The suspicion is that the rule preventing launchpad bugs from being filed when the running process doesn't match the file on disk is not being applied correctly to whoopsie. It definitely should be.
(It's possible that this is therefore a duplicate of bug #1020994. I'm not sure, I haven't looked at the code.)
I would also argue that, if this happens in the "system service" case, we should not show the user any crash dialog for it either, so long as we don't have support for leading them to a targeted update to fix the crash. We get no useful crash information from the user in this case, and the risk of confusion from the dialog is great when it's a system service crash. As a matter of policy, front-end applications need to be resilient in the face of failures of back-end daemons.
ProblemType: BugDistroRelease: Ubuntu 12.10
Package: apport 2.4-0ubuntu8
ProcVersionSignature: Ubuntu 3.5.0-10.10-generic 3.5.1
Uname: Linux 3.5.0-10-generic x86_64
ApportVersion: 2.4-0ubuntu8
Architecture: amd64
Date: Mon Aug 20 12:34:10 2012InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
PackageArchitecture: allSourcePackage: apport
UpgradeStatus: Upgraded to quantal on 2012-06-11 (70 days ago)
modified.conffile..etc.apport.crashdb.conf: [modified]
mtime.conffile..etc.apport.crashdb.conf: 2012-05-04T17:01:02 |
[Impact]
Reporting of crashes against currently-installed versions of packages, which this is not the version of package on disk, results in garbage data in the errors.ubuntu.com graphs that make it impossible to know with certainty that a given version of a package fixed a given crash. This severely hinders our reliance on errors.ubuntu.com for SRU validation.
[TEST CASE]
1) install lptools
2) lp-grab-attachments 2039920 (should crash with a keyerror)
3) close the apport dialog regarding the application crashing (via the X in the corner)
4) sudo vi $(which lp-grab-attachments)
5) modify copyright year or some comment
6) ubuntu-bug /var/crash/_usr_bin_lp-grab-attachments.*crash
7) Check the send error repot check box and click continue
8) ls -l /var/crash (observe _usr_bin_lp-grab-attachments .upload and .uploaded files)
9) remove _usr_bin_lp-grab-attachments files in /var/crash
10) reinstall lptools
11) install package from -proposed, follow test case and there should *not* be a .upload or .uploaded file as seen in step 8
[Regression Potential]
Worst-case scenario is that some crashes that should be reported fail to be reported as a result of a bug in this change.
Every crash report that gets fixed in a package upload winds up with some fuzziness in the bucket showing a small number of crash reports in the very version that fixes it. E.g.:
https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fbin%2Fubuntuone-installer%3AGError%3Afinished%3Afunction
(bug #853060)
This makes it impossible to tell with certainty by looking at errors.ubuntu.com if a crash is really fixed, or if it's just been made less frequent. We need to have good data here to be able to use errors.u.c for decision making around SRU publication.
The suspicion is that the rule preventing launchpad bugs from being filed when the running process doesn't match the file on disk is not being applied correctly to whoopsie. It definitely should be.
(It's possible that this is therefore a duplicate of bug #1020994. I'm not sure, I haven't looked at the code.)
I would also argue that, if this happens in the "system service" case, we should not show the user any crash dialog for it either, so long as we don't have support for leading them to a targeted update to fix the crash. We get no useful crash information from the user in this case, and the risk of confusion from the dialog is great when it's a system service crash. As a matter of policy, front-end applications need to be resilient in the face of failures of back-end daemons.
ProblemType: BugDistroRelease: Ubuntu 12.10
Package: apport 2.4-0ubuntu8
ProcVersionSignature: Ubuntu 3.5.0-10.10-generic 3.5.1
Uname: Linux 3.5.0-10-generic x86_64
ApportVersion: 2.4-0ubuntu8
Architecture: amd64
Date: Mon Aug 20 12:34:10 2012InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
PackageArchitecture: allSourcePackage: apport
UpgradeStatus: Upgraded to quantal on 2012-06-11 (70 days ago)
modified.conffile..etc.apport.crashdb.conf: [modified]
mtime.conffile..etc.apport.crashdb.conf: 2012-05-04T17:01:02 |
|
| 2012-10-24 23:24:03 |
Brian Murray |
apport (Ubuntu Quantal): status |
Fix Committed |
Fix Released |
|
| 2012-10-26 22:57:30 |
Brian Murray |
apport (Ubuntu Precise): status |
Triaged |
In Progress |
|
| 2012-10-26 22:57:36 |
Brian Murray |
apport (Ubuntu Precise): assignee |
|
Brian Murray (brian-murray) |
|
| 2012-10-28 15:48:36 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/quantal-proposed/apport |
|
| 2012-11-04 16:44:13 |
Launchpad Janitor |
apport (Ubuntu): status |
In Progress |
Fix Released |
|
| 2012-11-06 18:54:25 |
Adam Conrad |
apport (Ubuntu Precise): status |
In Progress |
Fix Committed |
|
| 2012-11-06 18:54:30 |
Adam Conrad |
tags |
amd64 apport-bug quantal running-unity verification-done |
amd64 apport-bug quantal running-unity |
|
| 2012-11-06 18:54:30 |
Adam Conrad |
tags |
amd64 apport-bug quantal running-unity |
amd64 apport-bug quantal running-unity verification-needed |
|
| 2012-11-06 19:54:06 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/precise-proposed/apport |
|
| 2012-11-06 22:24:52 |
Brian Murray |
tags |
amd64 apport-bug quantal running-unity verification-needed |
amd64 apport-bug quantal running-unity verification-done |
|
| 2012-11-14 03:59:54 |
Scott Kitterman |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2012-11-14 04:00:24 |
Launchpad Janitor |
apport (Ubuntu Precise): status |
Fix Committed |
Fix Released |
|
| 2012-12-04 10:40:41 |
Launchpad Janitor |
branch linked |
|
lp:~ubuntu-core-dev/ubuntu/precise/apport/ubuntu |
|
