KDE related log message in Octave's console

[kupiqu]

I frequently see the following warning message in Octave's console:

trying to load "/usr/lib/plugins/kf5/kio/file.so" from "/usr/lib/plugins/kf5/kio/file.so"

This is a very minor thing, but is there a way to silence it?

[kupiqu]

But beyond the fact that the kdenlive issue seems to be fixed in a previous version of flatpak (0.11 vs. 1.01), there's IMO an important difference between this issue and that one. In kdenlive the logs are only visible in its sh environment, but not in the application itself. The errors I refer to, appear in Octave's console, not just in its environment.

How or why are sh logs reported in Octave's console? Isn't there a way to avoid this behavior? That may be a useful feature when debugging Octave's interactions with its dependencies, but not in production.

Said that, it might be that this is an issue in Octave itself (perhaps not fixable in the flatpak package).

[mtmiller]

1. I believe Octave intentionally moves all of its stderr to its own command window output, instead of the controlling terminal device. So yes, while most GUI programs can spew warning messages on stderr and no one will ever see them, Octave has an interactive terminal emulator that the user can see all of these messages on. This is an upstream Octave issue that can be discussed elsewhere, especially if the command window moves away from being a full terminal emulator at some point in the future.

2. Is this specific diagnostic message a flatpak portal issue, do we know the cause, does it need to be fixed?

[kupiqu]

Thanks for the info about 1.

Regarding 2., I have no idea. If you can reproduce it in flatpak (just call uigetfile in Octave's console and see if it's triggered), which I would expect so, then we could also try to see if it happens as well elsewhere, e.g. when usng ubuntu packages (although that would be a different Octave version).

[kupiqu]

Actually, there is a very easy way to silence this out: using uigetfile; instead of uigetfile. Note the semicolon (how silly!). This would workaround (1). Should we check if there is sth wrong about (2). I can easily test this in Ubuntu's Octave 4.2.2

[kupiqu]

I can confirm that this is not happening in Ubuntu's Octave 4.2.2

[mtmiller]

I don't have any KDE environment available, so I can't help reproduce any KDE-specific interactions like this. But I can report that there is no output from either uigetfile or uigetfile; in a GNOME session.

[kupiqu]

I think it's most likely flatpak related as it doesn't happen either with deb packages (unless this was introduced between 4.2.2 and 4.4.1)

[kupiqu]

Not related to issue #6 either. Same behavior in flatpak 0.11.8.3 and 1.0.1

[mtmiller]

This diagnostic message comes from the kio library, see https://github.com/KDE/kio/blob/master/src/kioslave/kioslave.cpp#L82

This is using the qDebug() recommended approach for debug output. Described some here.

I don't know enough about QDebug to know whether this debug feature is enabled at compile-time or run-time. Is there a way we can test this? Is there some option that is being set by Octave, or is it how Octave or the flatpak KDE runtime itself is being built?

[kupiqu]

Not sure this is it, but I see this salient difference between metadata for octave and kdenlive:

[Application]
name=org.octave.Octave
runtime=org.kde.Sdk/x86_64/5.11
sdk=org.kde.Sdk/x86_64/5.11
command=octave

[Application]
name=org.kde.kdenlive
runtime=org.kde.Platform/x86_64/5.11
sdk=org.kde.Sdk/x86_64/5.11
tags=nightly;
command=kdenlive

So while Octave uses org.kde.Sdk/x86_64/5.11 as sdk and runtime, kde apps seem to use org.kde.Platform/x86_64/5.11 for the runtime

[kupiqu]

I see, thank you. Does the following enlighten something?

https://community.kde.org/Guidelines_and_HOWTOs/Flatpak#Debugging_portals

[kupiqu]

I asked Aleix Pol (@aleixpol) from KDE. He is going to look into it...

[mtmiller]

It's also worth noting that Octave installs its own null message handler when the GUI first starts, unless the environment variable OCTAVE_SHOW_GUI_MESSAGES is set. You don't have that in your environment do you?

So by default, all diagnostics, whether they are errors, warnings, info, or debug, are supposed to be discarded, unless the user opts in. Somehow something is overriding that or undoing that and allowing this qDebug message from kio to appear in your command window output.

[kupiqu]

I don't have any particular setting other than default.

@Alexander-Wilms, could you please assignsubscribe this issue to @aleixpol as he asked me to? He is not in front of the computer but will take a look soon...

[mtmiller]

Or maybe this kio library is spawning a separate child process to do some work, and that's where the debug output is being printed to the terminal.

If that's the case, it makes sense, but doesn't help explain why it's only the flatpak environment that is affected, or why the semicolon suppresses the output.

[aleixpol]

Hi octavers,
Yes, that wasn't very useful, I submitted a patch that removes this actual output.
https://phabricator.kde.org/D15258

As for your case, you can actually disable it by passing --env=QT_LOGGING_RULES=*=false.

In the long run, it could be interesting if Octave implemented qInstallMessageHandler (http://doc.qt.io/qt-5/qtglobal.html#qInstallMessageHandler) to properly treat Qt output.

[mtmiller]

In the long run, it could be interesting if Octave implemented qInstallMessageHandler

Octave does. Do you have any insight as to why that isn't working in this particular case?

[aleixpol]

Octave does. Do you have any insight as to why that isn't working in this particular case?

That does make sense, the msg handler is redirecting the output to the central view and since the dialog is emitting a qDebug then it's being shown.

In general it shouldn't be a big problem. We don't do any non-categorised logs in the libraries. That's why I sent the patch to the framework in the first place.

Please test the environment variable I suggested to make sure it doesn't regress.

[mtmiller]

That does make sense, the msg handler is redirecting the output to the central view

No, by default Octave's message handler discards all messages (see octave-gui.cc). Only this message is appearing on the terminal view for some reason. Possibly because this is happening in a separate process spawned by the kio library?

Only when the environment variable OCTAVE_SHOW_GUI_MESSAGES is set, Octave does not install a message handler, allowing all diagnostics to be shown in the terminal view.

But anyway, if your patch removing the qDebug output completely is merged, then this will be resolved in a future flatpak runtime update.

[kupiqu]

But anyway, if your patch removing the qDebug output completely is merged, then this will be resolved in a future flatpak runtime update.

@aleixpol, do you know when your commit will be part of the flatpak kde runtime?

In any case, I think we can close this issue.

Thank you all!