apport-collect should suppress STDERR

[Ted Gould]

Binary package hint: apport

I ran apport collect which called epiphany. Epiphany has a bunch of debug/error information on it's output, and that made it more difficult to run apport-collect as I didn't realize I needed to hit enter. Here's an example:

$ apport-collect computer-janitor
Logging into Launchpad...
The authorization page (https://edge.launchpad.net/+authorize-token?oauth_token=q288vdmzvBDCFZVR62Wt) should be opening in your browser. After you have authorized this program to access Launchpad on your behalf you should come back here and press <Enter> to finish the authentication process.
NOTE: Enabling gecko pango renderer; this may cause performance degradation.
You can set /apps/epiphany/web/enable_pango to "false" to disable it.

** (epiphany-browser:5804): WARNING **: Unknown widget
sys:1: GtkWarning: Attempting to add a widget with type GtkHBox to a GtkToggleButton, but as a GtkBin subclass a GtkToggleButton can only contain one widget at a time; it already contains a widget of type GtkLabel

** (epiphany-browser:5804): WARNING **: Unknown widget

[Martin Pitt (pitti)]

It could really be suppressed in python-launchpadlib.

However, I understand that using Launchpad.get_token_and_login() is not really recommended in production software. It's just utterly convenient and pretty much exactly what it needs to do.

[Leonard Richardson (leonardr)]

Actually get_token_and_login is fine to use in console applications, if you don't mind the generic 'hit enter' message.

I don't see a good solution here. launchpadlib uses the webbrowser module to launch Galeon. There's no way to tell Galeon anything but the URL to open and how to open it. Using anything other than the webbrowser module is a non-starter and a hackfest.

The webbrowser.Galeon module starts Galeon with ">/dev/null 2>&1", so standard error should be redirected to standard output, which should be redirected to /dev/null. So you shouldn't be having this problem in the first place. Check to see how Galeon is actually being started.

[Ted Gould (ted)]

On Mon, 2009-04-20 at 14:28 +0000, Leonard Richardson wrote:
> Actually get_token_and_login is fine to use in console applications, if
> you don't mind the generic 'hit enter' message.

Could it be changed to "Hit Enter" but only if the web browser doesn't
close with a valid exit value. So if someone did have the browser open,
did something, and then closed it, they wouldn't have to hit enter as
well.

> The webbrowser.Galeon module starts Galeon with ">/dev/null 2>&1", so
> standard error should be redirected to standard output, which should be
> redirected to /dev/null. So you shouldn't be having this problem in the
> first place. Check to see how Galeon is actually being started.

Okay, so they why don't you grab STDOUT as well. I don't see why any
text from the webbrowser should get to the user when using the console
based utility. It's never going to be very readable.

[Leonard Richardson (leonardr)]

> Could it be changed to "Hit Enter" but only if the web browser doesn't
> close with a valid exit value.

There's no way of knowing if or when the web browser closed. The webbrowser module spawns a background shell command, and never hears what happens to the command.

Besides which, the common case is that the user already has their browser open. I don't know how Galeon does it, but it's probably similar to how Firefox works: the webbrowser module starts up a new Firefox process, which tells the main Firefox process to open a URL in a new tab. The new process then exits, possibly before the page is even loaded. So even if we did know when the browser process exited, that information would be useless in the common case.

Right now after you grant permission, you see a web page that tells you "you should go back to the application window in which you started the process and inform it that you have done your part of the process." This is pretty generic, but it has to be, because it has to work for every conceivable client. Although now I see that it uses "process" in two different senses, which should be changed. Anyway, we could allow the client to specify some custom instructions here when it's setting up the token. For the get_token_and_login case, "go back and hit enter" would be better, though I suspect everyone would overlook it.

> Okay, so they why don't you grab STDOUT as well. I don't see why any
> text from the webbrowser should get to the user when using the console
> based utility. It's never going to be very readable.

I agree with you, but 1) that's not within my control, and 2) it should be doing that already. According to the source of the webbrowser module, both STDOUT and STDERR are redirected to /dev/null. That's why I'm interested in how Galeon is actually being started by the webbrowser module.

[Martin Pitt (pitti)]

Eventually I want to change apport to not use this function in the first place any more, since there's just one possible answer anyway (see bug 410205), and it is confusing. Therefore I'll mark this as a duplicate of bug 410205, since reworking the credentials acquisition will fix this as a side issue.

Thanks!