"The system detected a problem, do you want to report it?" dialog

[Robert Heller]

I'm getting this "The system detected a problem, do you want to report it?"
dialog. It does not say what the problem is. How do I find out what the
problem is? I am not interested in reporting it. I suspect it is something
stupid that I can fix, but I cannot figure out how to find out what is wrong.
This is with Ubuntu 14.04 LTS. I am used to CentOS and used to a less
pointy-clicky user interface, where one gets real error messages, not these
silly "idiot light" dianostics.
--
Robert Heller -- 978-544-6933
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
***@deepsoft.com -- Webhosting Services

[Oliver Grawert]

hi,

Post by Robert Heller
I'm getting this "The system detected a problem, do you want to
report it?" 
dialog. It does not say what the problem is.  How do I find out what
the 
problem is?  I am not interested in reporting it.  I suspect it is
something 
stupid that I can fix, but I cannot figure out how to find out what
is wrong.  
This is with Ubuntu 14.04 LTS.  I am used to CentOS and used to a
less 
pointy-clicky user interface, where one gets real error messages, not
these 
silly "idiot light" dianostics.

it is a two-dialog setup ... confirm the first one ... the second one
has a details option where you can find out whats wrong ...

ciao
oli

[Robert Heller]

Post by Oliver Grawert
hi,

Post by Robert Heller
I'm getting this "The system detected a problem, do you want to
report it?" 
dialog. It does not say what the problem is.  How do I find out what
the 
problem is?  I am not interested in reporting it.  I suspect it is
something 
stupid that I can fix, but I cannot figure out how to find out what
is wrong.  
This is with Ubuntu 14.04 LTS.  I am used to CentOS and used to a
less 
pointy-clicky user interface, where one gets real error messages, not
these 
silly "idiot light" dianostics.

it is a two-dialog setup ... confirm the first one ... the second one
has a details option where you can find out whats wrong ...

How do I get the second step? The report just dismisses the diallog, just
like the cancel. I presumed that the report button sends a report somewhere.

Post by Oliver Grawert
ciao
oliContent-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABEKAAYFAluAogQACgkQSsOT+6LQaTZVXgCg7uLo9RI4oCaBwnM8Onw+xZ5Y
nmcAoM82muUgYW1V6a+4bX0Cavc5zWat
=HJdt
-----END PGP SIGNATURE-----
MIME-Version: 1.0

[Oliver Grawert]

hi,

 

Post by Oliver Grawert
it is a two-dialog setup ... confirm the first one ... the second one
has a details option where you can find out whats wrong ...

How do I get the second step?  The report just dismisses the diallog,
just 
like the cancel.  I presumed that the report button sends a report
somewhere.

confirming the first dialog initializes the report *collection*. the
second one allows you to inspect contents and to confirm/deny the
sending of the data.

ciao
oli

[Robert Heller]

Post by Oliver Grawert
hi,

 

Post by Oliver Grawert
it is a two-dialog setup ... confirm the first one ... the second one
has a details option where you can find out whats wrong ...

How do I get the second step?  The report just dismisses the diallog,
just 
like the cancel.  I presumed that the report button sends a report
somewhere.

confirming the first dialog initializes the report *collection*. the
second one allows you to inspect contents and to confirm/deny the
sending of the data.

I'm not seeing this.

Post by Oliver Grawert
ciao
oliContent-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABEKAAYFAluBGrUACgkQSsOT+6LQaTaOYACeNuliknxG2lUUG6sd9CkD4xl2
Vp0Ani9ACu6bSPtWotcayCvwQivGtuKm
=866k
-----END PGP SIGNATURE-----
MIME-Version: 1.0

[Oliver Grawert]

hi,

Post by Robert Heller
 

Post by Oliver Grawert
confirming the first dialog initializes the report *collection*. the
second one allows you to inspect contents and to confirm/deny the
sending of the data.

I'm not seeing this.

First dialog:

https://imgur.com/a/eTcVV1R

(click "Report problem" here ... that starts the collection ...)

Second dialog:

https://imgur.com/a/YKf8GWi

(uncheck the "send" checkbox and click the "Show details" button to see
info about the app that crashed ...)

ciao
oli

[Robert Heller]

Post by Oliver Grawert
hi,

Post by Robert Heller
 

Post by Oliver Grawert
confirming the first dialog initializes the report *collection*. the
second one allows you to inspect contents and to confirm/deny the
sending of the data.

I'm not seeing this.

https://imgur.com/a/eTcVV1R
(click "Report problem" here ... that starts the collection ...)
https://imgur.com/a/YKf8GWi

I don't seem to be getting the second dialog.

Post by Oliver Grawert
(uncheck the "send" checkbox and click the "Show details" button to see
info about the app that crashed ...)
ciao
oli
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABEKAAYFAluBUPEACgkQSsOT+6LQaTYB2QCgz75oVx9CHpyr65C3d0BeHXze
6GYAn2MOqr+FLrD6KzhttHD2HQ84o618
=g54V
-----END PGP SIGNATURE-----
MIME-Version: 1.0

[Robert Heller]

Post by Oliver Grawert
hi,

Post by Robert Heller
 

Post by Oliver Grawert
confirming the first dialog initializes the report *collection*. the
second one allows you to inspect contents and to confirm/deny the
sending of the data.

I'm not seeing this.

https://imgur.com/a/eTcVV1R

OK, it is taking like forever to download the image. I'm guessing imgur.com
needs to download 5meg of JavaScript and advertising before it actually
downloads the image. Not real usable under dialup.

Is there some way to get the system to just display an error message?

Post by Oliver Grawert
(click "Report problem" here ... that starts the collection ...)
https://imgur.com/a/YKf8GWi
(uncheck the "send" checkbox and click the "Show details" button to see
info about the app that crashed ...)
ciao
oli
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABEKAAYFAluBUPEACgkQSsOT+6LQaTYB2QCgz75oVx9CHpyr65C3d0BeHXze
6GYAn2MOqr+FLrD6KzhttHD2HQ84o618
=g54V
-----END PGP SIGNATURE-----
MIME-Version: 1.0

[Oliver Grawert]

hi,

Post by Robert Heller
 
Is there some way to get the system to just display an error message?

you could indeed monitor you logs instead ... 

the two fold setup of the dislogs is there for a reason, the first
dialog only intercepts signals from applications, it does not do
anything else (capturing apps that receive SIGILL, SIGBRT, SIGFPE,
SIGSEV, SIGPIPE and SIGBUS)... it does not do anything else than that
and collecting the respective PID for the crashed process. 

only clicking the "Report problem" button does actually start any data
capturing/collecting for the given PID then which is why they do not
work separately (without a crash signal and PID the second part of the
tool cant really collect anything).

If you say you dont get the second dialog at all ... are you running a
default ubuntu kernel ? IIRC there are some config options and defaults
that are needed for proper error reporting to work at all
(/proc/sys/kernel/core_pattern comes to mind here), a non-standard
kernel might not have all needed bits enabled ...

if you cant find anything in the logs, also, take a look at /var/crash
if there is anything in it ...

ciao
oli

[Robert Heller]

Post by Oliver Grawert
hi,

Post by Robert Heller
 
Is there some way to get the system to just display an error message?

you could indeed monitor you logs instead ... 
the two fold setup of the dislogs is there for a reason, the first
dialog only intercepts signals from applications, it does not do
anything else (capturing apps that receive SIGILL, SIGBRT, SIGFPE,
SIGSEV, SIGPIPE and SIGBUS)... it does not do anything else than that
and collecting the respective PID for the crashed process. 

I should be able to at least report the process that crashed and which signal
was caught.

Post by Oliver Grawert
only clicking the "Report problem" button does actually start any data
capturing/collecting for the given PID then which is why they do not
work separately (without a crash signal and PID the second part of the
tool cant really collect anything).
If you say you dont get the second dialog at all ... are you running a
default ubuntu kernel ? IIRC there are some config options and defaults
that are needed for proper error reporting to work at all
(/proc/sys/kernel/core_pattern comes to mind here), a non-standard
kernel might not have all needed bits enabled ...

I am running a stock kernel.

Post by Oliver Grawert
if you cant find anything in the logs, also, take a look at /var/crash
if there is anything in it ...

I checked /var/log/syslog, but did not see anything there.

I guess I'll have to check /var/crash/...

Post by Oliver Grawert
ciao
oliContent-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABEKAAYFAluBYAAACgkQSsOT+6LQaTYRIgCcCzwM8s9cEIkhlF5lyCagYqfL
GaIAn0WK6/XtAgkjf9PG9qnFWF1f/k0H
=jde0
-----END PGP SIGNATURE-----
MIME-Version: 1.0

[Colin Law]

Post by Oliver Grawert
hi,

Post by Robert Heller

Post by Oliver Grawert
confirming the first dialog initializes the report *collection*. the
second one allows you to inspect contents and to confirm/deny the
sending of the data.

I'm not seeing this.

https://imgur.com/a/eTcVV1R
(click "Report problem" here ... that starts the collection ...)
https://imgur.com/a/YKf8GWi
(uncheck the "send" checkbox and click the "Show details" button to see
info about the app that crashed ...)

Has this possibly changed since 14.04?

Colin

Post by Oliver Grawert
ciao
oli
--
ubuntu-users mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

[Ralf Mardorf]

Post by Robert Heller
How do I get the second step?

I don't know, but you could take a look in /var/crash/.

Reportedly you could disable apport in /etc/default/apport or disable
crash reporting as described by the Wiki, see
https://wiki.ubuntu.com/Apport#How_to_enable_apport .

If all Ubuntu users would remove apport and whoopsie and stop manually
reporting bugs, Ubuntu perhaps would consider to drop the complicated,
unusable bug tracker and migrate to a "normal", sane bug tracker, that
easily allows to manually report bugs, as it could be done for most, if
not all other FLOSS projects.

[***@moonstudio ~]$ apt list -qqa 'whoopsie'
whoopsie/xenial-updates 0.2.52.5 amd64
whoopsie/xenial 0.2.52 amd64

[***@moonstudio ~]$ apt list -qqa 'apport'
apport/xenial-updates,xenial-updates,xenial-security,xenial-security
2.20.1-0ubuntu2.18 all apport/xenial,xenial 2.20.1-0ubuntu2 all

Note, even debugging information collected _without_ root privileges
could contain sensitive data, such as passwords and credit card data.

The Wiki claims that by default apport crash report for stable releases
is disabled for privacy reasons, see
https://wiki.ubuntu.com/Apport#Why_is_apport_disabled_by_default.3F .

"Arguments" pro Ubuntu's bug tracking policy, such as "End users do not
know how to prepare a report that is really useful for developers, like
building a package with debug symbols, operating gdb,
etc." ( https://wiki.ubuntu.com/Apport#What_is_this_all_about.3F )
are utter nonsense. An one-year-old doesn't know how to boil water, an
elementary school child does know how to do it. Bug reports are
like "boiling water", they are not like "construction of rockets".

[Colin Law]

Post by Ralf Mardorf
...
If all Ubuntu users would remove apport and whoopsie and stop manually
reporting bugs, Ubuntu perhaps would consider to drop the complicated,
unusable bug tracker and migrate to a "normal", sane bug tracker, that
easily allows to manually report bugs, as it could be done for most, if
not all other FLOSS projects.

What is complicated about OKing two dialogs to allow the crash to be
reported? That is all one has to do in this situation.

Colin

[Ralf Mardorf]

Post by Colin Law

Post by Ralf Mardorf
...
If all Ubuntu users would remove apport and whoopsie and stop
manually reporting bugs, Ubuntu perhaps would consider to drop the
complicated, unusable bug tracker and migrate to a "normal", sane
bug tracker, that easily allows to manually report bugs, as it could
be done for most, if not all other FLOSS projects.

What is complicated about OKing two dialogs to allow the crash to be
reported? That is all one has to do in this situation.

Auto-reports are bad. I'm not aware of many project that asks for
"auto-reports". AFAIK they are Ubuntu, Mozilla, bloated desktop
environments and perhaps a few other, while IIRC Ubuntu is the only
project that makes reporting bugs manually hard, more or less
impossible.

It's complicated to report a bug manually to the Ubuntu bug tracker.

Ubuntu is the only FLOSS project I know, that makes manually reporting
bugs more or less impossible.

If you know any other project where a user cannot simply create an
account, log in and easily report a bug manually, let me know.

If it nowadays should be easy to manually report a bug to the Ubuntu
bug tracker, please provide a step by step guide and share how easy it
has become.

[Colin Law]

Post by Ralf Mardorf
Auto-reports are bad.

Why?
Have you researched what the auto reports are used for?

Post by Ralf Mardorf
It's complicated to report a bug manually to the Ubuntu bug tracker.

That (even if true, which it is not in my experience) is irrelevant to
this thread, which is about the auto reports

Colin

[Ralf Mardorf]

Post by Colin Law

Post by Ralf Mardorf
Auto-reports are bad.

Why?

A daemon needs to run.
Users don't understand what they are doing, by just clicking ok, so it's
a security risk. It's easy to help the user to manually report a bug.

Post by Colin Law
Have you researched what the auto reports are used for?

Yes, they are good for absolutely nothing, but to offend privacy and to
avoid helping users to learn.

Post by Colin Law

Post by Ralf Mardorf
It's complicated to report a bug manually to the Ubuntu bug tracker.

That (even if true, which it is not in my experience) is irrelevant to
this thread, which is about the auto reports

Feel free to explain how to do it! It is relevant, perhaps more users
would decide to remove whoopsie and apport.

[Colin Law]

Post by Ralf Mardorf

Post by Colin Law

Post by Ralf Mardorf
Auto-reports are bad.

Why?

A daemon needs to run.
Users don't understand what they are doing, by just clicking ok, so it's
a security risk. It's easy to help the user to manually report a bug.

My understanding is that auto-reports are anonymised.

Post by Ralf Mardorf

Post by Colin Law
Have you researched what the auto reports are used for?

Yes, they are good for absolutely nothing, but to offend privacy and to
avoid helping users to learn.

Did you find this in your research? I think that is useful to some.
Then the developer can tunnel into the data to find what the crashes
are in a particular app.
https://errors.ubuntu.com/

Post by Ralf Mardorf

Post by Colin Law

Post by Ralf Mardorf
It's complicated to report a bug manually to the Ubuntu bug tracker.

That (even if true, which it is not in my experience) is irrelevant to
this thread, which is about the auto reports

Feel free to explain how to do it! It is relevant, perhaps more users
would decide to remove whoopsie and apport.

How to manually report a bug is irrelevant to this thread, if you want
help with that then please start a new thread.

Colin

[Ralf Mardorf]

Post by Colin Law

Post by Ralf Mardorf
Users don't understand what they are doing, by just clicking ok, so
it's a security risk.

My understanding is that auto-reports are anonymised.

Then edit the Wiki!
===================

"Why is apport disabled by default?

Apport is not enabled by default in stable releases, even if it is
installed. The automatic crash interception component of apport is
disabled by default in stable releases for a number of reasons:

Apport collects potentially sensitive data, such as core dumps,
stack traces, and log files. They can contain passwords, credit
card numbers, serial numbers, and other private material.

This is mitigated by the fact that it presents you what will be
sent to the bug tracker, and that all crash report bugs are private
by default, limited to the Ubuntu bug triaging team. We can
reasonably expect developers and technically savvy users, who run
the development release, to be aware of this and judge whether it
is appropriate to file a crash report. But we shouldn't assume that
every Ubuntu user of stable releases is able to do so. In 12.04 and
up this is transparently handled by whoopsie, see ErrorTracker.
During the development release we already collect thousands of
crash reports, much more than we can ever fix. Continuing to
collect those for stable releases is not really useful, since The
most important crashes have already been discovered in the
development release.

The less important ones are not suitable for getting fixed in
stable releases (see
https://wiki.ubuntu.com/StableReleaseUpdates Asking users to
send crash reports to us is insincere, since we can't possibly
answer and deal with all of them. Data collection from apport
takes a nontrivial amount of CPU and I/O resources, which slow
down the computer and don't allow you to restart the crashed
program for several seconds.

Note apport does not trap SIGABRT signals. If you are getting such a
signal, then please see DebuggingProgramCrash." -
https://wiki.ubuntu.com/Apport#Why_is_apport_disabled_by_default.3F

Post by Colin Law
This is with Ubuntu 14.04 LTS.

It's a stable release ( https://wiki.ubuntu.com/Releases ). Colin
perhaps will correct the Wiki.

[Oliver Grawert]

hi,

Post by Ralf Mardorf

Post by Colin Law

Post by Ralf Mardorf
Users don't understand what they are doing, by just clicking ok, so
it's a security risk.

My understanding is that auto-reports are anonymised.

Then edit the Wiki!
===================
"Why is apport disabled by default?

this is not true since 16.04 anymore i think (also the wiki is pretty
outdated as you can see by the old theme of the screenshots (they are
from 12.04 or so)). 

the UI changed into the two dialog setup, data is anonymized, whoopsie
got massively improved since it got added in 12.04 to not massively hit
system ressources anymore. check a 16.04 install (if you have one), you
should see "enabled=1" in /etc/default/apport there.

dont trust wiki data ... it is usually outdated ;)
(but you can indeed at any time change and improve it as you noted
yourself, feel free ;) )

ciao
oli

[Ralf Mardorf]

data is anonymized, whoopsie got massively improved since it got added
in 12.04 to not massively hit system ressources anymore. check a 16.04
install (if you have one), you should see "enabled=1"
in /etc/default/apport there.
dont trust wiki data

In which way is data "anonymized"? There should be a reliable source
available, explaining detailed how this is granted. IMO it's impossible
to grant this.

[***@moonstudio ~]$ lsb_release -a
LSB Version: core-9.20160110ubuntu0.2-amd64:core-9.20160110ubuntu0.2-noarch:security-9.20160110ubuntu0.2-amd64:security-9.20160110ubuntu0.2-noarch
Distributor ID: Ubuntu
Description: Ubuntu 16.04.5 LTS
Release: 16.04
Codename: xenial
[***@moonstudio ~]$ ls -l /etc/default/apport
ls: cannot access '/etc/default/apport': No such file or directory
[***@moonstudio ~]$ apt list -qqa 'whoopsie'
whoopsie/xenial-updates 0.2.52.5 amd64
whoopsie/xenial 0.2.52 amd64

[***@moonstudio ~]$ apt list -qqa 'apport'
apport/xenial-updates,xenial-updates,xenial-security,xenial-security 2.20.1-0ubuntu2.18 all
apport/xenial,xenial 2.20.1-0ubuntu2 all

You even wouldn't find harmless, but redundant software on my Linux
installs, e.g.

[***@moonstudio ~]$ apt list -qqa '*command-not-found*'
command-not-found/xenial-updates,xenial-updates 0.3ubuntu16.04.2 all
command-not-found/xenial,xenial 0.3ubuntu16.04 all

command-not-found-data/xenial-updates 0.3ubuntu16.04.2 amd64
command-not-found-data/xenial 0.3ubuntu16.04 amd64

While I've got permission to edit the Wiki, I don't have any source of
information to edit the Wiki correctly. Let alone that I'm an opponent.
A seconder with enough information should edit the Wiki.

I don't see how any changes to apport and whoopsie could at lest make
those arguments invalid:

"During the development release we already collect thousands of crash
reports, much more than we can ever fix. Continuing to collect those
for stable releases is not really useful, since

The most important crashes have already been discovered in the
development release.

The less important ones are not suitable for getting fixed in
stable releases (see https://wiki.ubuntu.com/StableReleaseUpdates

Asking users to send crash reports to us is insincere, since we
can't possibly answer and deal with all of them."

[Oliver Grawert]

hi,

Post by Ralf Mardorf
 
You even wouldn't find harmless, but redundant software on my Linux
installs, e.g.
command-not-found/xenial-updates,xenial-updates 0.3ubuntu16.04.2 all
command-not-found/xenial,xenial 0.3ubuntu16.04 all
command-not-found-data/xenial-updates 0.3ubuntu16.04.2 amd64
command-not-found-data/xenial 0.3ubuntu16.04 amd64

well, so you got some "ubuntu based" install there, but not an ubuntu
install that used one of the ubuntu installers and has gotten the
ubuntu defaults ... 

that makes it indeed hard to judge issues or properly give support for
ubuntu given you will never have the actual defaults for comparison or
packages that people ask about in this ML ... but i think we had this
topic in the past ... ;)

on a properly installed ubuntu that used one of the desktop, live-
server or alternate installers you will always find apport, it is a
standard belonging to all official tasks and an expected feature for
something that calls itself "Ubuntu".

while it might be a nice anecdote for you that you do have packages
removed on your system or installed it in a non-standard way that didnt
bring in the default packages, it is in no way helpful for this support
thread nor does it contribute any useful information to solve roberts
problem ...

ciao
oli

[Ralf Mardorf]

Post by Oliver Grawert
while it might be a nice anecdote for you that you do have packages
removed on your system or installed it in a non-standard way that didnt
bring in the default packages, it is in no way helpful for this support
thread nor does it contribute any useful information to solve roberts
problem ...

Hi,

so if I give a pointer to /var/crash/ it's not helpful, but if you do
so, it is?

Post by Oliver Grawert
you could take a look in /var/crash/
if you cant find anything in the logs, also, take a look at /var/crash
if there is anything in it

Let alone that a lot of threads are completely unrelated to the used
Ubuntu flavour or what ever customized minimal install is used.

Regards,
Ralf

[Oliver Grawert]

hi,

Post by Ralf Mardorf
 
so if I give a pointer to /var/crash/ it's not helpful, but if you do
so, it is?

well, now *you* are bikeshedding ... ;) 

indeed it is helpful either way, but pointing out in a very wordy way
that *your* install does not have /etc/default/apport, that you also
uninstalled command-not-found, bragging about how redundant some
software in ubuntu is and whatnot, is simply adding noise...

ciao
oli

[Peter Flynn]

Post by Ralf Mardorf

Post by Colin Law

Post by Ralf Mardorf
Auto-reports are bad.

Why?

A daemon needs to run.
Users don't understand what they are doing, by just clicking ok, so it's
a security risk.

I've heard that, but I don't understand why. The daemon just sends
something (by email? sftp? https?) to a hard-wired address. No user
intervention is possible. Sure, it has details of the user's system, but
it HAS to, that's its job.

Post by Ralf Mardorf
It's easy to help the user to manually report a bug.

I wish it were. The user will not normally know what process triggered
the error (that's the job of the system), nor will they know what action
triggered it (it may or may not have been the foreground process), and
if they're anything like most users, they type and click so fast that by
the time the error window has appeared, they cannot identify what they
were typing or clicking, or whereabouts on the screen. All they can do
is report the name of the foreground process, and perhaps the name of
the open document or the active URI. The error might have occurred in a
hidden or off-screen process and be wholly unrelated to the active
foreground process. Helping users to report bugs manually is HARD.

Post by Ralf Mardorf

Post by Colin Law
Have you researched what the auto reports are used for?

Yes, they are good for absolutely nothing, but to offend privacy and to
avoid helping users to learn.

I wonder if there is a way we can redesign the error dialog window to
help the learning process and mitigate the privacy concerns?

///Peter

[Oliver Grawert]

hi,

Post by Ralf Mardorf

Post by Ralf Mardorf
Auto-reports are bad.

Why?

A daemon needs to run.
Users don't understand what they are doing, by just clicking ok, so it's
a security risk. 

I've heard that, but I don't understand why. The daemon just sends 
something (by email? sftp? https?) to a hard-wired address. No user 
intervention is possible. Sure, it has details of the user's system,
but 
it HAS to, that's its job.

early apport versions actually ran a daemon ... since 16.04 thats not
true anymore, apport is socket activated based on syscalls from the
kernel when an app produces one of the SIG*'s i listed in a former mail
... it then triggers the UI popoup and asks if it is allowed to collect
data, no daemon involved anymore ... 

if the request for collection is confirmed, whoopsie kicks in and
collects a core dump that gets sent to errors.ubuntu.com ...

manual input is not even required anymore, if you take a look at the
bottom table of the https://errors.ubuntu.com/ page you will see that
it simply now collects heuristicts about how often a bug happens based
on comparison of the core dumps, nowadays it is actually the ubuntu
developers or the QA that create a bug though this page by clicking the
"Create" link on the right, next to an issue entry ... more frequently
occuring issues bubble up on that table to raise awareness, the QA team
regulary checks this page .... 

"End Users" are actually not much involved at all in this process
anymre (they can still always use the manual reporting page [1] though,
that was always there if you wanted to manually report a bug) but their
consent is requred to allow sending data to the error tracker ...

ciao
oli

[1] https://launchpad.net/ubuntu/+filebug

[Peter Flynn]

On 25/08/18 11:07, Ralf Mardorf wrote:
[...]

Post by Ralf Mardorf
Auto-reports are bad. I'm not aware of many project that asks for
"auto-reports". AFAIK they are Ubuntu, Mozilla, bloated desktop
environments and perhaps a few other,

In general, yes they're bad. But asking end-users for dev-style reports
is not going to get many responses.

Post by Ralf Mardorf
while IIRC Ubuntu is the only project that makes reporting bugs
manually hard, more or less impossible. It's complicated to report a
bug manually to the Ubuntu bug tracker.

I based my earlier comments on my last decade which has largely been
Ubuntu on the desktop, so I had assumed other system were equally
unusable. My apologies if I have done them an injustice.

Post by Ralf Mardorf
Ubuntu is the only FLOSS project I know, that makes manually reporting
bugs more or less impossible.

I gave up reporting bugs to bug-trackers long ago because they were
either ignored, or merged into another unrelated error by someone who
hadn't bothered to read what I wrote. Some of the bugs are still there
because the developers don't regard them as important, and some are
still being argued over twelve years later :-)

Post by Ralf Mardorf
If you know any other project where a user cannot simply create an
account, log in and easily report a bug manually, let me know.

First, when such an error occurs, the LAST thing the user wants to do is
go through the loop of creating an account and waiting for the email
confirmation, which may or may not arrive. Bug-reporters need to let
end-users use their Gmail or FB or other pseudo-identity QUICKLY.

Second, a detailed bug report usable by the developers is perhaps not
something an end user can write easily. It takes knowledge and
understanding of the terminology and awareness of the executing environment.

But bug-reporting IS a big problem, and I don't know if there is a
global solution.

///Peter

[Robert Heller]

Post by Peter Flynn
[...]

Post by Ralf Mardorf
Auto-reports are bad. I'm not aware of many project that asks for
"auto-reports". AFAIK they are Ubuntu, Mozilla, bloated desktop
environments and perhaps a few other,

In general, yes they're bad. But asking end-users for dev-style reports
is not going to get many responses.

Post by Ralf Mardorf
while IIRC Ubuntu is the only project that makes reporting bugs
manually hard, more or less impossible. It's complicated to report a
bug manually to the Ubuntu bug tracker.

I based my earlier comments on my last decade which has largely been
Ubuntu on the desktop, so I had assumed other system were equally
unusable. My apologies if I have done them an injustice.

Post by Ralf Mardorf
Ubuntu is the only FLOSS project I know, that makes manually reporting
bugs more or less impossible.

I gave up reporting bugs to bug-trackers long ago because they were
either ignored, or merged into another unrelated error by someone who
hadn't bothered to read what I wrote. Some of the bugs are still there
because the developers don't regard them as important, and some are
still being argued over twelve years later :-)

Post by Ralf Mardorf
If you know any other project where a user cannot simply create an
account, log in and easily report a bug manually, let me know.

First, when such an error occurs, the LAST thing the user wants to do is
go through the loop of creating an account and waiting for the email
confirmation, which may or may not arrive. Bug-reporters need to let
end-users use their Gmail or FB or other pseudo-identity QUICKLY.
Second, a detailed bug report usable by the developers is perhaps not
something an end user can write easily. It takes knowledge and
understanding of the terminology and awareness of the executing environment.

+1

*End Users* really should be reporting bugs to their "System Manager". Or if
they don't have such a thing, they probably should be finding a Guru to talk
to first.

Maybe "End Users" would be better off reporting the bug "here" or someplace
like "Ask Ubuntu". This would get the bug to someone with the understanding of
the system to try to reproduce the problem and then that person could then
file a bug report that would in fact be useful.

The auto-reporting thing can be problematical.

Post by Peter Flynn
But bug-reporting IS a big problem, and I don't know if there is a
global solution.
///Peter

--
Robert Heller -- 978-544-6933
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
***@deepsoft.com -- Webhosting Services

[Peter Flynn]

On 25/08/18 20:48, Robert Heller wrote:
[...]

Post by Robert Heller
*End Users* really should be reporting bugs to their "System
Manager". Or if they don't have such a thing, they probably should
be finding a Guru to talk to first.

My guess is that a large majority of Linux users are solo and don't have
a sysadm to talk to (I'd love to know real figures, though). In my last
job I was the unofficial sysadm for Linux because I was the only person
with a high enough profile using it for other users to notice me in an
ocean of corporate Windows.

Post by Robert Heller
Maybe "End Users" would be better off reporting the bug "here" or
someplace like "Ask Ubuntu". This would get the bug to someone with
the understanding of the system to try to reproduce the problem and
then that person could then file a bug report that would in fact be
useful.

Most neophytes probably don't know what "here" (mailing list) exists.
They might find Ask Ubuntu. I'd say most of them Google until they find
a page that describes a problem matching their error message. More
experienced users pick it up as they go along and become adepts :-)

///Peter

[Robert Heller]

Post by Peter Flynn
[...]

Post by Robert Heller
*End Users* really should be reporting bugs to their "System
Manager". Or if they don't have such a thing, they probably should
be finding a Guru to talk to first.

My guess is that a large majority of Linux users are solo and don't have
a sysadm to talk to (I'd love to know real figures, though). In my last
job I was the unofficial sysadm for Linux because I was the only person
with a high enough profile using it for other users to notice me in an
ocean of corporate Windows.

Post by Robert Heller
Maybe "End Users" would be better off reporting the bug "here" or
someplace like "Ask Ubuntu". This would get the bug to someone with
the understanding of the system to try to reproduce the problem and
then that person could then file a bug report that would in fact be
useful.

Most neophytes probably don't know what "here" (mailing list) exists.
They might find Ask Ubuntu. I'd say most of them Google until they find
a page that describes a problem matching their error message. More
experienced users pick it up as they go along and become adepts :-)

And I expect that most "bugs" are not really bugs but some sort of
misconfiguration or (as was for me) a problem like an undersized file system
that ran out of space (probably not likely for neophytes, since the default
("dumb") mode for most installers is to use the whole or most of the disk for
one file system.

Post by Peter Flynn
///Peter

--
Robert Heller -- 978-544-6933
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
***@deepsoft.com -- Webhosting Services

[Ralf Mardorf]

I've taken a look at the apport packages files and read the provided
man pages. It's not described what signals trigger a report. It's not
mentioned that sensible data is detected and removed. The term used
here, that the report is "anonymised" sucks out loud. What is
"anonymised" for? What does it mean? It's a vague claim!

I tried to take a look if upstream provides more details, so I visited
the Debian tracker.

https://tracker.debian.org/pkg/apport

The homepage link, links against the outdated Wiki.

It can't be more opaque.

Actually two subscribers with an ubuntu.com email address argue without
providing a valid source of information. They are not willing to fix the
Wiki. The only thing a user could verify without reading the source
code, is that a socket is used.

It's argued that I shouldn't say anything about apport and whoopsie,
since I don't have them installed and didn't tested them.

Before I install something, let alone that before I run something like
this, I want to get official information. I've done hours of research!
There is no information, but an outdated Wiki.

Should users trust apport and whoopsie blindly? What do I miss?

[Oliver Grawert]

hi,

Post by Ralf Mardorf
I tried to take a look if upstream provides more details, so I
visited
the Debian tracker.
https://tracker.debian.org/pkg/apport
The homepage link, links against the outdated Wiki.

ubuntu is upstream for apport ... 
the upstream source is at:

https://code.launchpad.net/~apport-hackers/apport/trunk

ciao
oli

[Ralf Mardorf]

Post by Oliver Grawert
hi,

Post by Ralf Mardorf
I tried to take a look if upstream provides more details, so I visited
the Debian tracker.
https://tracker.debian.org/pkg/apport
The homepage link, links against the outdated Wiki.

ubuntu is upstream for apport ...
https://code.launchpad.net/~apport-hackers/apport/trunk

Hi,

the first thing I see is a security update, see

https://bazaar.launchpad.net/~apport-hackers/apport/trunk/revision/3202.

We don't need to worry abut such issues, if we manually report bugs.

Regards,
Ralf

[Oliver Grawert]

hi,

Post by Ralf Mardorf
 
We don't need to worry abut such issues, if we manually report bugs.

if you manually report bugs software has no security issues ???

all software has security issues all the time, i dont get how the way
to collect crashes helps with that ... if you wouldnt run a kernel you
would never have any driver problems either :P

and as i said in other posts in this thread you are always able to
manually report any bugs ... apport is a tool to help the QA team to
collect the heuristics to identify the really serious issues that show
up on several millions of systems; even on the ones from actual end
users ... you could collect and send all this data quietly without
bothering anyone with UI popups ... 

...but history tells that you then get called names for producing
"spyware" like when you try to anonymize and encrypt amazon searches of
users to protect their privacy and data that normally goes through the
net competely unprotected, so this is why the apport popup exists ... 

apport does not replace manual bug filing in any way at all ... we get
such bugs from enthusiasts all day long, it collects additional data
from millions and millions of simple non-enthusiast end users that
ubuntu has, to improve the product :)

ciao
oli

[Ralf Mardorf]

Post by Oliver Grawert

Post by Ralf Mardorf
We don't need to worry abut such issues, if we manually report bugs.

if you manually report bugs software has no security issues ???

If you manually report bugs, you don't need to use a tool to report
bugs, that could suffer from a security issue. This is very important,
since you claim that the tool to report bugs does "anonymize" the
reported data, while you don't quote a source to underpin this claim.
However, even if it should be able to remove all sensible data, it still
could suffer from a security issue. If you don't use a tool to report a
bug, no tool could suffer from a security issue.

[Robert Heller]

Post by Ralf Mardorf

Post by Oliver Grawert

Post by Ralf Mardorf
We don't need to worry abut such issues, if we manually report bugs.

if you manually report bugs software has no security issues ???

If you manually report bugs, you don't need to use a tool to report
bugs, that could suffer from a security issue. This is very important,
since you claim that the tool to report bugs does "anonymize" the
reported data, while you don't quote a source to underpin this claim.
However, even if it should be able to remove all sensible data, it still
could suffer from a security issue. If you don't use a tool to report a
bug, no tool could suffer from a security issue.

Right. Only the bug reporting site code (eg Bugzilla or Launchpad or whatever)
has to worry about security issues.
--
Robert Heller -- 978-544-6933
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
***@deepsoft.com -- Webhosting Services

[Oliver Grawert]

hi,

Post by Ralf Mardorf

Post by Oliver Grawert

Post by Ralf Mardorf
We don't need to worry abut such issues, if we manually report bugs.

if you manually report bugs software has no security issues ???

If you manually report bugs, you don't need to use a tool to report
bugs, that could suffer from a security issue. This is very
important,
since you claim that the tool to report bugs does "anonymize" the
reported data, while you don't quote a source to underpin this claim.
However, even if it should be able to remove all sensible data, it still
could suffer from a security issue. If you don't use a tool to report a
bug, no tool could suffer from a security issue.

well, again, you didnt read what i wrote ... 

the tool does not "file bugs" it sends core dumps and crash reports a
package maintainer defined to https://errors.ubuntu.com/ if there
should be bugs resulting from this, they are created by developers or
the QA team monitoring the tables on that page by using the "Create"
link in the right column of the table ...

users that file bugs use https://launchpad.net/ubuntu to file bugs ...

you are missing the point of the apport tool and you are missing the
point that all software can have bugs and security issues at all time,
a security issue in a quality assurance tool is neither worse or better
than a security issue in the kernel, they are all equally awful and all
need fixing ASAP after being detected... 

if you have tens of millions of users of which only a very small
fraction will ever manually file bugs, there is only automation to get
you enough info to keep the quality level high enough to provide an
enterprise class product.

and no matter how much you dis-like apport, it wont go away, it is an
essential part of the ubuntu infrastructure, it s used by nearly every
ubuntu package maintainer to receive the package specific info they
require for debugging, it is deeply integrated into archive management,
package build processes and QA processes, the little bit of UI you see
from it is only a very small portion of what apport is as a whole.

ciao
oli

[Ralf Mardorf]

Post by Oliver Grawert
it sends core dumps and crash reports

Without containing sensible data? Note, sensible data are not only
passwords, even the used CPU, graphics, RAM could be sensible data if
collected when not necessary. Those statistics don't provide any useful
information about crashes from really used apps, since by default
Ubuntu starts all kinds of services not each user does need.

The policy mentioned by the Wiki is ok. Excerpts from the outdated Wiki
https://wiki.ubuntu.com/Apport?action=logout&logout=logout#Why_is_apport_disabled_by_default.3F :

"We can reasonably expect developers and technically savvy users, who
run the development release, to be aware of this and judge whether it
is appropriate to file a crash report."

"During the development release we already collect thousands of crash
reports, much more than we can ever fix. Continuing to collect those
for stable releases is not really useful, since

The most important crashes have already been discovered in the
development release.

The less important ones are not suitable for getting fixed in
stable releases (see https://wiki.ubuntu.com/StableReleaseUpdates

Asking users to send crash reports to us is insincere, since we
can't possibly answer and deal with all of them."

Post by Oliver Grawert
no matter how much you dis-like apport, it wont go away, it is an
essential part of the ubuntu infrastructure

I dislike if the policy changed!

[Ralf Mardorf]

Post by Oliver Grawert
you are missing the point of the apport tool and you are missing the
point that all software can have bugs and security issues at all time,
a security issue in a quality assurance tool is neither worse or better
than a security issue in the kernel

Sure, you don't have any argument at all, so you continue with the same
wishi washi again and again.

The kernel is needed, no kernel, no operating system.

Apport isn't needed, it's even not useful at all, see the Wiki:
"Asking users to send crash reports to us is insincere, since we
can't possibly answer and deal with all of them."

By the original policy it was disabled for stable releases.

Why don't you provide a source for the claim that those reports do not
contain sensible data!

[Oliver Grawert]

hi,

Post by Ralf Mardorf
 
Apport isn't needed, it's even not useful at all,

on what base do you found this statement ... ? 

a large portion of the main archive would likely not build anymore if
you took away apport, it is essential ubuntu infrastructure, many
packages are deeply integrated with it, CI would fail, builds would
fail and autopkgtests would likely fail too (preventing any promotion
of packages from -proposed to the archive)...

pretty please stop this constant pointless ranting against ubuntu
technology it is not helpful, it does not contribute anything valuable
to "Ubuntu user technical support" ...

- update-grub wont go away even if you keep spreading your hate
against 
  it.
- apport wont go away either. whether or not *you* understand its 
  usefulness, level of integration in the archive or essential 
  requirement in the infrastructure.
- the selection of packages you call "bloated" will not be cut down no 
  matter how much you brag about it. 

given the constant hate you expose for the setup that ubuntu provides
you i'm always surprised again that you are still posting on this list.

... and given how off topic this whole thread is once again due to you
(again !!!) insisting how wrong and badly ubuntu is assembled without
even minimally accepting technical reality or the fact that there is
more technological implementation detail to a topic than your selfish
POV, i'll finish my participation in this thread with this post here
and now ...

ciao
oli

[Ralf Mardorf]

hate

You might hate a lot, I don't feel 'hate'. I have to object your
insinuation. Also stop your intentional misrepresentations, just
because you run out of arguments and you are unwilling to underpin a
claim by posting a link to an official source.

[Ralf Mardorf]

hi,

Post by Ralf Mardorf
 
Apport isn't needed, it's even not useful at all,

on what base do you found this statement ... ? 

You could read the answer to your question, if you would quote the
complete sentence, on Sun, 26 Aug 2018 19:08:51 +0200, Ralf Mardorf

"Asking users to send crash reports to us is insincere, since we
can't possibly answer and deal with all of them."

[Ralf Mardorf]

Post by Colin Law

Post by Ralf Mardorf
...
If all Ubuntu users would remove apport and whoopsie and stop manually
reporting bugs, Ubuntu perhaps would consider to drop the complicated,
unusable bug tracker and migrate to a "normal", sane bug tracker, that
easily allows to manually report bugs, as it could be done for most, if
not all other FLOSS projects.

What is complicated about OKing two dialogs to allow the crash to be
reported? That is all one has to do in this situation.

Even if I shouldn't consider auto-reports as bad, why does somebody want
to run a crash daemon on e.g. a real-time environment that needs all
resources and that should run stable?

What if a bug doesn't crash or if that auto-thingy is buggy itself?

What about feature requests, e.g. asking to compile a package with
additional flags?

Btw. don't recommend just to click two times ok! The user first needs to
remove passwords and other sensible information from a bug report.

[Ralf Mardorf]

Post by Ralf Mardorf

Post by Colin Law

Post by Ralf Mardorf
...
If all Ubuntu users would remove apport and whoopsie and stop manually
reporting bugs, Ubuntu perhaps would consider to drop the complicated,
unusable bug tracker and migrate to a "normal", sane bug tracker, that
easily allows to manually report bugs, as it could be done for most, if
not all other FLOSS projects.

What is complicated about OKing two dialogs to allow the crash to be
reported? That is all one has to do in this situation.

Even if I shouldn't consider auto-reports as bad, why does somebody want
to run a crash daemon on e.g. a real-time environment that needs all
resources and that should run stable?
What if a bug doesn't crash or if that auto-thingy is buggy itself?
What about feature requests, e.g. asking to compile a package with
additional flags?
Btw. don't recommend just to click two times ok! The user first needs to
remove passwords and other sensible information from a bug report.

If the user has got no root privileges, how could the user report bugs
using this auto-crap?

[Peter Flynn]

Post by Colin Law

Post by Ralf Mardorf
...
If all Ubuntu users would remove apport and whoopsie and stop manually
reporting bugs, Ubuntu perhaps would consider to drop the complicated,
unusable bug tracker and migrate to a "normal", sane bug tracker, that
easily allows to manually report bugs, as it could be done for most, if
not all other FLOSS projects.

What is complicated about OKing two dialogs to allow the crash to be
reported? That is all one has to do in this situation.

You mean it doesn't ask you to create an account on a bug-reporting web
site and write your own report?

That would be a major improvement; in which case I withdraw my objection.

///Peter

[Oliver Grawert]

hi,

Post by Peter Flynn

Post by Colin Law

Post by Ralf Mardorf
...
If all Ubuntu users would remove apport and whoopsie and stop manually
reporting bugs, Ubuntu perhaps would consider to drop the
complicated,
unusable bug tracker and migrate to a "normal", sane bug tracker, that
easily allows to manually report bugs, as it could be done for most, if
not all other FLOSS projects.

What is complicated about OKing two dialogs to allow the crash to be
reported? That is all one has to do in this situation.

You mean it doesn't ask you to create an account on a bug-reporting
web 
site and write your own report?
That would be a major improvement; in which case I withdraw my
objection.

well, it actually *did* open a browser with a launchapd page in the
past (until 14.10 i think) but this isnt the case anymore (so this
major imrovement happened a while ago) ... see my other mail that
describes the process that is used since 16.04 ...

ciao
oli

[Peter Flynn]

On 25/08/18 21:31, Oliver Grawert wrote:
[...]

Post by Oliver Grawert
well, it actually *did* open a browser with a launchapd page in the
past (until 14.10 i think) but this isnt the case anymore (so this
major imrovement happened a while ago) ... see my other mail that
describes the process that is used since 16.04 ...

Thanks very much for the update. This is a big improvement.

It also shows that it must be longer than I thought since I had one of
those random unexpected popups...I get error messages all the time, but
they are from applications, not the OS.

///Peter

[Peter Flynn]

Post by Robert Heller
I'm getting this "The system detected a problem, do you want to
report it?" dialog. It does not say what the problem is.

I've had these from time to time and they're a pain in the OSS.

Post by Robert Heller
How do I find out what the problem is? I am not interested in
reporting it.

I always assumed that clicking "Report" would auto-generate a report and
send it, but it doesn't. It opens a browser window onto whatever
report-a-bug web site the developers use, where you have to create a
username and password (and go through the email confirmation loop) and
then write your own report on what went wrong — when in all likelihood
you don't know what went wrong. If the devs want people to report
errors, which I assume they do, they MUST create a better system for
doing so.

I *would* be interested in sending an auto-generated report, and I
wouldn't mind adding a note about the state of the system when it
happened, but I'm an end user, not a developer (these days).
Unfortunately the current developers assume everyone is running a full
suite of dev analytic tools and that they are able to pinpoint the cause
of the error themselves. In this they err.

Post by Robert Heller
I suspect it is something stupid that I can fix, but I
cannot figure out how to find out what is wrong.

If you know the date/time, look in /var/log/syslog or /etc/messages or
wherever your system logs its messages and see if there is anything
unusual happening. It's probably not wise to ignore it: those messages
tend only to appear when something serious is happening.

I've also had them come up when there's a hardware problem that the
software can't identify, so the next time you bring the system down, don
a grounding wrist strap, open the box and reseat the cards, clean the
fluff, and make sure it all looks OK.

Post by Robert Heller
This is with Ubuntu 14.04 LTS. I am used to CentOS and used to a less
pointy-clicky user interface, where one gets real error messages, not
these silly "idiot light" dianostics.

14.04 is getting a little long in the tooth but should still be stable.

I had many CentOS systems in my last job, but CentOS was hopelessly out
of date for what we wanted to do, although it was stable. Fortunately
they were servers, so there weren't any popups: all access was command
line and all error messages were on the console.

///Peter

[Robert Heller]

Post by Peter Flynn

Post by Robert Heller
I'm getting this "The system detected a problem, do you want to
report it?" dialog. It does not say what the problem is.

I've had these from time to time and they're a pain in the OSS.

Post by Robert Heller
How do I find out what the problem is? I am not interested in
reporting it.

I always assumed that clicking "Report" would auto-generate a report and
send it, but it doesn't. It opens a browser window onto whatever
report-a-bug web site the developers use, where you have to create a
username and password (and go through the email confirmation loop) and
then write your own report on what went wrong — when in all likelihood
you don't know what went wrong. If the devs want people to report
errors, which I assume they do, they MUST create a better system for
doing so.
I *would* be interested in sending an auto-generated report, and I
wouldn't mind adding a note about the state of the system when it
happened, but I'm an end user, not a developer (these days).
Unfortunately the current developers assume everyone is running a full
suite of dev analytic tools and that they are able to pinpoint the cause
of the error themselves. In this they err.

I eventually figured out the problem. It was a *week old* error that I had
already seen and in fact already "cured". A week ago Friday I did a system
update (apt-get update;apt-get dist-upgrade) and ran out of space on the /boot
file system -- it was too small. I was running apt-get in a terminal window,
saw the error an then *manually* (apt-get purge) removed the old kernel that
would have been removed with apt-get autoremove. I then resumed the apt-get
dist-upgrade (successfully) and scheduled (in my mind) a disk re-partitioning
job the following Friday, that I in fact did. It was at this point that the
*stupid* dialog box popped up wanting to report a problem, that I in fact had
already fixed (or was about too)... In this case it was not a "bug", but
merely a system config type of problem, that was easy to fix, something *I* am
an old hand at, since I have been dealing with admining Linux machines for
decades, including major system upgrades, replacing disks, etc.

In other words, the "error" popup was totally extranious, unnecessary and
quite anoying. Is there any reason not to get rid of this silliness? Oh, and
I don't really want the users of these machines to be randomly reporting
"bugs" in any case. I'd rather they just tell me when something goes wrong.

Post by Peter Flynn

Post by Robert Heller
I suspect it is something stupid that I can fix, but I
cannot figure out how to find out what is wrong.

If you know the date/time, look in /var/log/syslog or /etc/messages or
wherever your system logs its messages and see if there is anything
unusual happening. It's probably not wise to ignore it: those messages
tend only to appear when something serious is happening.
I've also had them come up when there's a hardware problem that the
software can't identify, so the next time you bring the system down, don
a grounding wrist strap, open the box and reseat the cards, clean the
fluff, and make sure it all looks OK.

Post by Robert Heller
This is with Ubuntu 14.04 LTS. I am used to CentOS and used to a less
pointy-clicky user interface, where one gets real error messages, not
these silly "idiot light" dianostics.

14.04 is getting a little long in the tooth but should still be stable.

I know, but I am not one to randomly upgrade machines to the "latest" version
on a whim, which often causes all sorts of problems, mostly subtle. These
machines are being used by people who are not Linux experts and who need the
machines to "Just Work" and not randomly change in non-trivial ways.

I will upgrade these machines but in a careful, planned fashion.

Post by Peter Flynn
I had many CentOS systems in my last job, but CentOS was hopelessly out
of date for what we wanted to do, although it was stable. Fortunately
they were servers, so there weren't any popups: all access was command
line and all error messages were on the console.
///Peter

[Peter Flynn]

On 25/08/18 20:29, Robert Heller wrote:
[...]

Post by Robert Heller
I eventually figured out the problem. It was a *week old* error that I had
already seen and in fact already "cured".

Excellent diagnosis, thank you.

Post by Robert Heller
In other words, the "error" popup was totally extranious, unnecessary

As you describe it, the error dialog was itself a bug. *That*'s what
needs reporting.

[me]

Post by Robert Heller

Post by Peter Flynn
14.04 is getting a little long in the tooth but should still be stable.

I know, but I am not one to randomly upgrade machines to the "latest"
version on a whim, which often causes all sorts of problems, mostly
subtle.

Dead right. I keep sacrifical machines to test upgrades on.

Post by Robert Heller
These machines are being used by people who are not Linux experts and
who need the machines to "Just Work" and not randomly change in
non-trivial ways.

Stability was why my last job used CentOS for servers, but over time we
got fewer and fewer end-users and more and more properly-managed
processes that needed up-to-date software. Trying to run a modern web
server on an ancient LAMP stack is self-defeating.

///Peter

[Oliver Grawert]

hi,

Post by Robert Heller
 
In other words, the "error" popup was totally extranious, unnecessary
and 
quite anoying.  Is there any reason not to get rid of this
silliness?  Oh, and 
I don't really want the users of these machines to be randomly
reporting 
"bugs" in any case.  I'd rather they just tell me when something goes
wrong.

apport got a lot celeverer to not notify you about older/known issues
past 14.04 ... and given that 14.04 goes effectively EOL in april
chances are low it would get fixed even if you filed a bug about it ...
so my suggestion would be to simply disable it in /etc/default/apport
and be done ....

ciao
oli

[Liam Proven]

Post by Robert Heller
I'm getting this "The system detected a problem, do you want to report it?"
dialog. It does not say what the problem is. How do I find out what the
problem is? I am not interested in reporting it.

If you're not interested then just clear the Apport cache.

https://askubuntu.com/questions/133385/getting-system-program-problem-detected-pops-up-regularly-after-upgrade

or

https://www.binarytides.com/ubuntu-fix-system-program-problem-error/
--
Liam Proven - Profile: https://about.me/liamproven
Email: ***@cix.co.uk - Google Mail/Hangouts/Plus: ***@gmail.com
Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven
UK: [phone] - ČR (+ WhatsApp/Telegram/Signal): [phone]