Error: connection identifier wrong.

[RolandHughes]

All,

[0701/190012:WARNING:resource_bundle.cc(286)] locale_file_path.empty()
Error: connection identifier wrong.

Yes, there is some kind of packaging issue when building a .deb for deployment. No the target machine is not connected to a network so it cannot go find dependencies. I don't care so much about the one kicking out of resource_bundle, but the second one is really honking me off for numerous reasons. I believe I have found the only place where Qt issues the message.

https://github.com/adobe/webkit/blob/master/Source/WebKit2/WebProcess/qt/WebProcessMainQt.cpp

line 177

This infuriates me for numerous reasons, not the least of which is we are using WebEngine, not WebKit. It appears to be looking for a connection number. Has anyone seen this error before? There is nothing in syslog() to indicate some kind of serious issue and nothing dumped to the terminal.

Built and run inside the IDE it is perfect. Deployed it doesn't work and isn't polite enough to register/log any kind of library linkage issue.

Thanks,

[ChrisW67]

If your program does not use Qt WebKit then why have you deployed the Qt WebKit library?
If you have not deployed the QtWebKit library then how is that code emitting that message?

Want to know what libraries are directly linked to your program executable, or to other libraries, look at ldd (http://linux-man-pages.info/man1/ldd.1.html).

[RolandHughes]

If your program does not use Qt WebKit then why have you deployed the Qt WebKit library?
If you have not deployed the QtWebKit library then how is that code emitting that message?

Want to know what libraries are directly linked to your program executable, or to other libraries, look at ldd (http://linux-man-pages.info/man1/ldd.1.html).

That was my question exactly.

We are already using ldd. Should not be seeing that message at all, but that is the only place I could find it. I guess I need to pull down the full source tree for 5.4 and see if that message isn't replicated in some other module and the Web search is a Red Herring.

[wysota]

So what does ldd report for your program?

[RolandHughes]

So what does ldd report for your program?

linux-gate.so.1 => (0xb7704000)
libQt5WebEngineWidgets.so.5 => /home/developer/Qt5.4.2/5.4/gcc/lib/libQt5WebEngineWidgets.so.5 (0xb76e2000)
libQt5Widgets.so.5 => /home/developer/Qt5.4.2/5.4/gcc/lib/libQt5Widgets.so.5 (0xb7068000)
libQt5X11Extras.so.5 => /home/developer/Qt5.4.2/5.4/gcc/lib/libQt5X11Extras.so.5 (0xb7063000)
libQt5WebChannel.so.5 => /home/developer/Qt5.4.2/5.4/gcc/lib/libQt5WebChannel.so.5 (0xb7046000)
libQt5WebSockets.so.5 => /home/developer/Qt5.4.2/5.4/gcc/lib/libQt5WebSockets.so.5 (0xb701d000)
libQt5Network.so.5 => /home/developer/Qt5.4.2/5.4/gcc/lib/libQt5Network.so.5 (0xb6eb5000)
libQt5DBus.so.5 => /home/developer/Qt5.4.2/5.4/gcc/lib/libQt5DBus.so.5 (0xb6e2e000)
libQt5Core.so.5 => /home/developer/Qt5.4.2/5.4/gcc/lib/libQt5Core.so.5 (0xb68e6000)
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb67db000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb67be000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb6603000)
libQt5WebEngine.so.5 => /home/developer/Qt5.4.2/5.4/gcc/lib/libQt5WebEngine.so.5 (0xb65d9000)
libQt5Quick.so.5 => /home/developer/Qt5.4.2/5.4/gcc/lib/libQt5Quick.so.5 (0xb6216000)
libQt5Gui.so.5 => /home/developer/Qt5.4.2/5.4/gcc/lib/libQt5Gui.so.5 (0xb5c34000)
libQt5WebEngineCore.so.5 => /home/developer/Qt5.4.2/5.4/gcc/lib/libQt5WebEngineCore.so.5 (0xb1c15000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb1bf8000)
libgobject-2.0.so.0 => /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 (0xb1b9b000)
libglib-2.0.so.0 => /lib/i386-linux-gnu/libglib-2.0.so.0 (0xb1a72000)
libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xb1927000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb18da000)
libQt5Qml.so.5 => /home/developer/Qt5.4.2/5.4/gcc/lib/libQt5Qml.so.5 (0xb14c4000)
libicui18n.so.53 => /home/developer/Qt5.4.2/5.4/gcc/lib/libicui18n.so.53 (0xb126d000)
libicuuc.so.53 => /home/developer/Qt5.4.2/5.4/gcc/lib/libicuuc.so.53 (0xb10ed000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb10e8000)
libgthread-2.0.so.0 => /usr/lib/i386-linux-gnu/libgthread-2.0.so.0 (0xb10e5000)
librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb10dc000)
/lib/ld-linux.so.2 (0xb7705000)
libGL.so.1 => /usr/lib/i386-linux-gnu/mesa/libGL.so.1 (0xb102e000)
libnss3.so => /usr/lib/i386-linux-gnu/libnss3.so (0xb0eb5000)
libnssutil3.so => /usr/lib/i386-linux-gnu/libnssutil3.so (0xb0e8e000)
libsmime3.so => /usr/lib/i386-linux-gnu/libsmime3.so (0xb0e5e000)
libplc4.so => /usr/lib/i386-linux-gnu/libplc4.so (0xb0e58000)
libnspr4.so => /usr/lib/i386-linux-gnu/libnspr4.so (0xb0e15000)
libfontconfig.so.1 => /usr/lib/i386-linux-gnu/libfontconfig.so.1 (0xb0dd1000)
libfreetype.so.6 => /usr/lib/i386-linux-gnu/libfreetype.so.6 (0xb0d21000)
libexpat.so.1 => /lib/i386-linux-gnu/libexpat.so.1 (0xb0cf8000)
libXi.so.6 => /usr/lib/i386-linux-gnu/libXi.so.6 (0xb0ce6000)
libXcursor.so.1 => /usr/lib/i386-linux-gnu/libXcursor.so.1 (0xb0cdb000)
libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xb0cc5000)
libXfixes.so.3 => /usr/lib/i386-linux-gnu/libXfixes.so.3 (0xb0cbe000)
libXrender.so.1 => /usr/lib/i386-linux-gnu/libXrender.so.1 (0xb0cb2000)
libXcomposite.so.1 => /usr/lib/i386-linux-gnu/libXcomposite.so.1 (0xb0cae000)
libasound.so.2 => /usr/lib/i386-linux-gnu/libasound.so.2 (0xb0bb8000)
libXdamage.so.1 => /usr/lib/i386-linux-gnu/libXdamage.so.1 (0xb0bb3000)
libXtst.so.6 => /usr/lib/i386-linux-gnu/libXtst.so.6 (0xb0bac000)
libXrandr.so.2 => /usr/lib/i386-linux-gnu/libXrandr.so.2 (0xb0ba1000)
libcap.so.2 => /lib/i386-linux-gnu/libcap.so.2 (0xb0b9b000)
libdbus-1.so.3 => /lib/i386-linux-gnu/libdbus-1.so.3 (0xb0b44000)
libffi.so.6 => /usr/lib/i386-linux-gnu/libffi.so.6 (0xb0b39000)
libpcre.so.3 => /lib/i386-linux-gnu/libpcre.so.3 (0xb0ac7000)
libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xb0aa5000)
libicudata.so.53 => /home/developer/Qt5.4.2/5.4/gcc/lib/libicudata.so.53 (0xaf61c000)
libglapi.so.0 => /usr/lib/i386-linux-gnu/libglapi.so.0 (0xaf603000)
libX11-xcb.so.1 => /usr/lib/i386-linux-gnu/libX11-xcb.so.1 (0xaf5ff000)
libxcb-glx.so.0 => /usr/lib/i386-linux-gnu/libxcb-glx.so.0 (0xaf5e7000)
libxcb-dri2.so.0 => /usr/lib/i386-linux-gnu/libxcb-dri2.so.0 (0xaf5e1000)
libxcb-dri3.so.0 => /usr/lib/i386-linux-gnu/libxcb-dri3.so.0 (0xaf5dd000)
libxcb-present.so.0 => /usr/lib/i386-linux-gnu/libxcb-present.so.0 (0xaf5d9000)
libxcb-sync.so.1 => /usr/lib/i386-linux-gnu/libxcb-sync.so.1 (0xaf5d1000)
libxshmfence.so.1 => /usr/lib/i386-linux-gnu/libxshmfence.so.1 (0xaf5ce000)
libXxf86vm.so.1 => /usr/lib/i386-linux-gnu/libXxf86vm.so.1 (0xaf5c8000)
libdrm.so.2 => /usr/lib/i386-linux-gnu/libdrm.so.2 (0xaf5b9000)
libplds4.so => /usr/lib/i386-linux-gnu/libplds4.so (0xaf5b4000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xaf598000)
libpng12.so.0 => /lib/i386-linux-gnu/libpng12.so.0 (0xaf56c000)
libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xaf568000)
libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xaf561000)


Since WebKit is not listed I "assume" that exact error string got re-used some place else in Qt. I will do some searching later on, have other things to deliver first. Just wondered if anyone doing deployments had encountered this issue.

Thank everyone for their time.

[wysota]

I don't think it is safe to assume things like that :) You should now check each of Qt libs to see if any of them depends on WebKit. Nevertheless, it would be best if you clarified when the problem occurs. The thread description seems to indicate this is related to the process of packaging an application yet you post some code which obviously is not executed during packaging. The piece of code you quoted is related to a child process of WebKit being passed incorrect parameters. It is hard for me to believe this has got anything to do with packaging. Could you provide more details about the problem?

[RolandHughes]

I don't think it is safe to assume things like that :) You should now check each of Qt libs to see if any of them depends on WebKit. Nevertheless, it would be best if you clarified when the problem occurs. The thread description seems to indicate this is related to the process of packaging an application yet you post some code which obviously is not executed during packaging. The piece of code you quoted is related to a child process of WebKit being passed incorrect parameters. It is hard for me to believe this has got anything to do with packaging. Could you provide more details about the problem?

It is a packaging problem. The .deb being created and installed on a bare Ubuntu install is missing something and it is something subtle like a dependency of a dependency of a dependency. Everything works perfectly in development on multiple development machines even when built on multiple versions of Ubuntu. The problem is in packaging this into a .deb which installs on machines that have zero network connection.

Boiling it down, there is a library or background/hidden executable used by WebEngine which isn't being packaged up and failed invocation of it does not log an error anywhere. Not to the terminal, syslog, no place I can find. If it would just stack dump or something it would be a 10 minute task to track down. Whatever this is has a "quietly hidden" failure and one doesn't see the result until that "main" module in webkit exits due to a missing connection number.

The self contained universe is both incomplete and ashamed of its inadequacies.

That's not good for a developer.

[stampede]

(...) something subtle like a dependency of a dependency of a dependency.
Maybe try running 'lddtree' ('apt-get install pax-utils') on your executable instead of "regular" ldd, maybe you can spot something related to webkit.

[wysota]

It is a packaging problem. The .deb being created and installed on a bare Ubuntu install is missing something and it is something subtle like a dependency of a dependency of a dependency. Everything works perfectly in development on multiple development machines even when built on multiple versions of Ubuntu. The problem is in packaging this into a .deb which installs on machines that have zero network connection.

Boiling it down, there is a library or background/hidden executable used by WebEngine which isn't being packaged up and failed invocation of it does not log an error anywhere. Not to the terminal, syslog, no place I can find. If it would just stack dump or something it would be a 10 minute task to track down. Whatever this is has a "quietly hidden" failure and one doesn't see the result until that "main" module in webkit exits due to a missing connection number.

Does the same happen if you copy all your executables and libraries to a bare ubuntu VM/chroot (you can create one quickly with debootstrap)? Does it change anything if you install Qt on that VM?

Edit:
QtWebKit doesn't spawn any foreign executables (pstree -p `pidof a`):

a(9252)─┬─{QXcbEventReader}(92 53)
├─{Qt HTTP thread}(9262)
├─{Qt bearer threa}(9261)
├─{a}(9254)
├─{a}(9255)
├─{a}(9256)
├─{a}(9257)
├─{a}(9258)
├─{a}(9259)
└─{a}(9260)


#include <QWebView>
#include <QApplication>

int main(int argc, char **argv) {
QApplication app(argc, argv);
QWebView view;
view.show();
view.setUrl(QUrl("http://www.google.com"));
return app.exec();
}

[RolandHughes]

Maybe try running 'lddtree' ('apt-get install pax-utils') on your executable instead of "regular" ldd, maybe you can spot something related to webkit.

Will look at the documentation for this over the weekend while cleaning up other things.

Thanks

Added after 13 minutes:


Does the same happen if you copy all your executables and libraries to a bare ubuntu VM/chroot (you can create one quickly with debootstrap)? Does it change anything if you install Qt on that VM?

Edit:
QtWebKit doesn't spawn any foreign executables (pstree -p `pidof a`):

a(9252)─┬─{QXcbEventReader}(92 53)
├─{Qt HTTP thread}(9262)
├─{Qt bearer threa}(9261)
├─{a}(9254)
├─{a}(9255)
├─{a}(9256)
├─{a}(9257)
├─{a}(9258)
├─{a}(9259)
└─{a}(9260)


#include <QWebView>
#include <QApplication>

int main(int argc, char **argv) {
QApplication app(argc, argv);
QWebView view;
view.show();
view.setUrl(QUrl("http://www.google.com"));
return app.exec();
}

Unknown. The deliverable must install on bare Ubuntu distro so, unless I'm going to try to DIFF two VMs completely, one bare and one with Qt installed, I don't know how much it would help.

Yes, webkit doesn't have the external executables...in theory. Webkit is its own train wreck. I originally developed the thing with webkit trying to keep things small. Webkit uses external plug-ins so when you launch the full screen app you don't exactly know why the sound or video isn't playing until you exit the full screen app then see a dialog saying something along the lines of "you need to install gstream blah blah blah -bad, do you want to install?" I've never been pleased with the results of installing anything from any package ending in -bad. Perhaps your mileage is different. Now we have an even bigger set of unknowns making sure we have all possible gstream plugins for all possible platforms for all possible 32-bit and 64-bit installations.

WebEngine is a massive improvement over WebKit but it is still lacking from the planning/architecture standpoint. Deployment shouldn't be a PITA with a bunch of not well documented executables that have to tag along and be put in specific places __and__ add yet another layer of dependencies. Good architecture means a deployment process which is consistently repeatable.

I have yet to find a documentation page which states: To deploy an application using QtWebEngine with QtWebChannel you need to include X,Y,Z

Perhaps I'm either blind or really sucky at using search engines, but I have __not__ found that. I'm guessing people are simply listing a bunch of Qt packages in their control manifest and holding their breath hoping it gets installed on a computer with Internet access.

[ChrisW67]

Does the same happen if you copy all your executables and libraries to a bare ubuntu VM ...?



Unknown. The deliverable must install on bare Ubuntu distro so, unless I'm going to try to DIFF two VMs completely, one bare and one with Qt installed, I don't know how much it would help.

It will quickly determine whether the missing dependency, if there is one, is a Qt component or an external component. The first is fixed by getting your deployment package's minimal Qt content right, the second by bundling external dependencies that are missing on your vanilla target.

If you want to know what the QtWebEngine library is directly dependent on then run ldd (or lddtree) against the .so file. Here is the example for your other library:


$ ldd libQt5WebChannel.so
linux-vdso.so.1 (0x00007ffc9a5c4000)
libQt5Qml.so.5 => /home/chrisw/Qt/5.4/gcc_64/lib/./libQt5Qml.so.5 (0x00007fb20c786000)
libQt5Core.so.5 => /home/chrisw/Qt/5.4/gcc_64/lib/./libQt5Core.so.5 (0x00007fb20c047000)
libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.4/libstdc++.so.6 (0x00007fb20bd43000)
libc.so.6 => /lib64/libc.so.6 (0x00007fb20b9ab000)
libQt5Network.so.5 => /home/chrisw/Qt/5.4/gcc_64/lib/./libQt5Network.so.5 (0x00007fb20b645000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb20b42a000)
libm.so.6 => /lib64/libm.so.6 (0x00007fb20b129000)
libicui18n.so.53 => /home/chrisw/Qt/5.4/gcc_64/lib/./libicui18n.so.53 (0x00007fb20acdd000)
libicuuc.so.53 => /home/chrisw/Qt/5.4/gcc_64/lib/./libicuuc.so.53 (0x00007fb20a952000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fb20a74e000)
libgthread-2.0.so.0 => /usr/lib64/libgthread-2.0.so.0 (0x00007fb20a54c000)
librt.so.1 => /lib64/librt.so.1 (0x00007fb20a344000)
libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007fb20a00e000)
libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.4/libgcc_s.so.1 (0x00007fb209df8000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb20cfb8000)
libicudata.so.53 => /home/chrisw/Qt/5.4/gcc_64/lib/./libicudata.so.53 (0x00007fb208770000)

If you want to know what is loaded in a running process you might like to try pldd (if it is available).

[wysota]

Yes, webkit doesn't have the external executables...in theory.
There is no "theory" here, it's a printout from a running program. You can see some subprocesses being created and running the same executable. Any foreign executable would be visible in pstree. If you want, you can strace your program to see the exact series of fork/exec calls. Then you will exactly know what your program is trying to execute and what exactly it depends on.


I've never been pleased with the results of installing anything from any package ending in -bad.
Maybe if you read GStreamer docs or the , you'd know why the package was called that way. Complaining will not get you anywhere.


GStreamer Bad Plug-ins is a set of plug-ins that aren't up to par compared to the rest. They might be close to being good quality, but they're missing something - be it a good code review, some documentation, a set of tests, a real live maintainer, or some actual wide use.
So you can see the plugins in the set are not broken, they might be just missing documentation or tests.

Similar with plugins-ugly:

GStreamer Ugly Plug-ins is a set of plug-ins that have good quality and correct functionality, but distributing them might pose problems. The license on either the plug-ins or the supporting libraries might not be how we'd like. The code might be widely known to present patent problems.

Don't judge a book by its cover.

[RolandHughes]

There is no "theory" here, it's a printout from a running program. You can see some subprocesses being created and running the same executable. Any foreign executable would be visible in pstree. If you want, you can strace your program to see the exact series of fork/exec calls. Then you will exactly know what your program is trying to execute and what exactly it depends on.


It is a theory. It requires external plug-ins which will be different on each platform. Requires each plug-in be identified and bundled with the package. Requires legal to research each of the licenses, etc. Even once all of that is done, since we don't control the rest of the target content someone could already have a plug-in installed which makes our bundled set of plug-ins non-functional (Ran into that one many times before.)

[wysota]

It is a theory. It requires external plug-ins which will be different on each platform. Requires each plug-in be identified and bundled with the package.
QtWebKit does not require any plugins.

As for Qt requiring plugins, it's explained in the docs and even if it weren't, it's quite easy to logically decide which plugins you will require. First you will obviously need a platform plugin for your app to run. If you want to show images in your application in formats other than the built-in png, bmp and xpm support then you will need image plugins. If you want multimedia to work then you will need a multimedia backend plugin as well. If you are in doubt, just deploy all plugins or compile them statically in your application.


Even once all of that is done, since we don't control the rest of the target content someone could already have a plug-in installed which makes our bundled set of plug-ins non-functional
No, that's not true. If something didn't work for you then you are responsible for it, not the user's system. You have mechanisms such as LD_LIBRARY_PATH and R(UN)PATH at your disposal which you can use to contain your application, you can build Qt with a custom discriminant, name or namespace to avoid the linker picking up the default Qt installation on one's system.

[RolandHughes]

QtWebKit does not require any plugins.

No, that's not true. If something didn't work for you then you are responsible for it, not the user's system. You have mechanisms such as LD_LIBRARY_PATH and R(UN)PATH at your disposal which you can use to contain your application, you can build Qt with a custom discriminant, name or namespace to avoid the linker picking up the default Qt installation on one's system.

Wysota,

I like you. I find you to be highly technical and you remind me of myself when I was young. (Of course, that was when commercial C compilers were first hitting the market for DOS and OpenVMS.) That answer is _exactly_ something I would have, and most like did, say back then, sans the mention of Qt.

There are situations where, no matter how you build/protect/enhance a Qt program using WebKit with plugins for sound and video will be broken by the user's or connonical's configuration. It is Sunday, so, before I start work at my client site, let me point to a few scars and speak about the size of the shark which left them.

Way back when Connical made the ill-timed poorly thought out decision to push Pulse Audio into its distro, it wasn't tested with streaming video. Admittedly, there wasn't any You-tube, Hulu, or Netflix streaming then. In truth anyone watching streaming video via any means was most likely watching porn, but, given the volume of bug reports, it must have been a very large pass time. Pulse Audio broke every browser on the platform. This wasn't a fault of any browser or plug-in. The underlying service provider for the system was broken. It then went through a bipolar state where updates pushed out to the release would alternately fix then break Pulse Audio. It may seem impossible to fathom now, but there was a time when you could not, with any certainty, assume that a video of any kind would play with sound or appear as anything other than a black rectangle. This time lasted for at least 6 months.

The KDE desktop went through a similar phase with some other package but the name of that escapes me now.

Today we have what many developers refer to as "Linux's built in virus" but you probably know by the name of compiz. There have been reports that it was to be purged from the Ubuntu based distros, but it is still here in 15. We will skip over the fact that if one starts a desktop application from a .desktop file in the .config/autostart folder that it couldn't find its backside with both hands and a seeing eye dog. Only a user with some kind of error log monitor installed would notice stuff like this in syslog:

I/O warning : failed to load external entity "/home/developer/.compiz/session/10e4dc3d6e9c85c701143611821760456600000011760001"

If a user has configured 3D, there are a good number of plug-ins, both for regular browsers and webkit, which either do not work or do not work correctly. Again, the only defense an application developer could present would be to do something virus-like, reaching out into the system from the application and thumping off 3D, which, correctly, would result in a rash of bug/field reports all saying "Hey, after I installed package z my 3D went away." Once again, this problem is not a result of how a Qt application is compiled, linked, or designed. I have heard of but not experienced the flip-side problem where plug-ins which work with 3D don't work with 2D.

It was due to all of these facts my client opted for WebEngine. For all of its faults, it was "contained" because there were no plug-ins. Yes, we could still be clocked by some update/sweeping change to Pulse Audio, or Connonical choosing some other package not ready for prime time, but we can achieve a 90% certainty that what we develop will function on all of the required hardware combinations.

Packaging this into the type of .DEB ultimately required is proving to be difficult, but we should have someone who normally does packaging starting this week.

[wysota]

Hi,


Way back when Connical made the ill-timed poorly thought out decision to push Pulse Audio into its distro, it wasn't tested with streaming video.
PulseAudio doesn't care about the source of the sound whether it is streamed from network or generated on the fly using GStreamer's audiotestsrc element. So if sound wasn't playing for streamed videos, it is the software that streamed it which is to be blamed, not PulseAudio. The latter is (or was) hard to configure and that difficulty indeed "broke" many installations (including mine) but that has little or nothing to do with streaming videos.


Today we have what many developers refer to as "Linux's built in virus" but you probably know by the name of compiz.
Compiz is long outdated and you should probably have stopped using it around 3 years ago at least. Besides that's a desktop compositor so it cares nothing about what is going on in your application.

By the way, googling for "Linux's built in virus" doesn't return anything related to compiz (adding "compiz" to the query doesn't help) so who are these many developers who refer to it as such?


It was due to all of these facts my client opted for WebEngine. For all of its faults, it was "contained" because there were no plug-ins.
Huh? What plugins? Qt WebEngine runs Blink (aka Chromium) under the hood so it does (or at least should, haven't tested that) work with PPAPI plugins. I don't know if you are referring to these kinds of plugins.

By the way, what are these "faults" of Blink/Chromium/WebEngine?


Yes, we could still be clocked by some update/sweeping change to Pulse Audio, or Connonical choosing some other package not ready for prime time, but we can achieve a 90% certainty that what we develop will function on all of the required hardware combinations.
I really got lost here. I have no idea what PulseAudio or Cannonical has anything to do with... anything related to the problem you are facing. Did you test your app on some other distro than Ubuntu? Did it work? What didn't?

Don't feel offended but reading your posts I often have an impression that you are assuming some things to be true just because you performed some logical conduct that didn't prove them to be false (or at least I hope you did). Unfortunately that is not enough to state them to be true. I have argued with you a lot in the past giving you arguments against your claims. You never tried rejecting any of them, instead you were pulling outanother bunch of completely unrelated arguments (e.g. PulseAudio in this thread) like a rabbit from a hat.

So please let's stick to the topic, if you say there is some dependency executable missing for your application, please back it up with any proof or logical conduct you went through to come to this conclusion. If I (or someone else) am able to replicate your problem maybe we will be able to help you. So far there is no evidence of any missing dependency, you were suggested a number of tools (lddtree, pldd, pstree, strace) to use to help you identify the problem. Please, make use of them. Don't assume things to be -- give us facts and let us reach our own conclusions. If you have problems employing the tools, please state the exact problem and I'm sure the author of a particular suggestion will be glad to offer a helping hand.

I can start with my suggestion of using strace:

strace yourapp 2>&1 | awk 'match($0, /^open\("([^"]*)\".*=\s(.*)*/, a) { if(a[2] > 0) a[2] = "OK"; print "OPEN", a[1], "=>", a[2] }'

strace will tell you which files your app tried to open and whether it worked or not (and why).

[RolandHughes]

Hi,

PulseAudio doesn't care about the source of the sound whether it is streamed from network or generated on the fly using GStreamer's audiotestsrc element. So if sound wasn't playing for streamed videos, it is the software that streamed it which is to be blamed, not PulseAudio. The latter is (or was) hard to configure and that difficulty indeed "broke" many installations (including mine) but that has little or nothing to do with streaming videos.


hello,

http://ubuntuforums.org/showthread.php?t=789578

There were many others, but I want to leave for supper tonight.



Compiz is long outdated and you should probably have stopped using it around 3 years ago at least. Besides that's a desktop compositor so it cares nothing about what is going on in your application.

By the way, googling for "Linux's built in virus" doesn't return anything related to compiz (adding "compiz" to the query doesn't help) so who are these many developers who refer to it as such?


I'm not. Ubuntu still is.

You would be the first Linux developer I've spoken with who doesn't. Every software engineer I've spoken with had that opinion before I met them.




Huh? What plugins? Qt WebEngine runs Blink (aka Chromium) under the hood so it does (or at least should, haven't tested that) work with PPAPI plugins. I don't know if you are referring to these kinds of plugins.

By the way, what are these "faults" of Blink/Chromium/WebEngine?


I'm guessing you read that really fast or just need some sleep. We went with WebEngine because WebKit had too many faults. Hence the wording

"It was due to all of these facts my client opted for WebEngine. For all of its faults, it was "contained" because there were no plug-ins. "





I really got lost here. I have no idea what PulseAudio or Cannonical has anything to do with... anything related to the problem you are facing. Did you test your app on some other distro than Ubuntu? Did it work? What didn't?

Don't feel offended but reading your posts I often have an impression that you are assuming some things to be true just because you performed some logical conduct that didn't prove them to be false (or at least I hope you did). Unfortunately that is not enough to state them to be true. I have argued with you a lot in the past giving you arguments against your claims. You never tried rejecting any of them, instead you were pulling outanother bunch of completely unrelated arguments (e.g. PulseAudio in this thread) like a rabbit from a hat.


No offense. I don't know how you missed it, but that entire response was both rejecting the false claim below and providing evidence as to why it was false.



No, that's not true. If something didn't work for you then you are responsible for it, not the user's system. You have mechanisms such as LD_LIBRARY_PATH and R(UN)PATH at your disposal which you can use to contain your application, you can build Qt with a custom discriminant, name or namespace to avoid the linker picking up the default Qt installation on one's system.


I no longer have to solve the packaging issue. We have a packaging person that used to work at the Linux Group who I've worked with before and have a great amount of respect for, showing up in the next couple of days. I am not a packaging person, that is a different skill set from software engineering.

Hmm... odd that you thought I've never refuted your claims though. I've done that more than once, but I would hate to word it as "often" as that makes it sound like we do nothing but fight. Perhaps I need to word posts here more like my novels and less like the stuff I send to the other software engineers?

At any rate. Nice chatting with you.

[wysota]

http://ubuntuforums.org/showthread.php?t=789578
This has nothing to do with "video streaming". I just skeemed through the thread but it looks like it is about getting pulseudio to work with alsa.


I'm not. Ubuntu still is.
Ubuntu's desktop used Metacity and now uses something called Mutter. As far as I can tell compiz (nor Beryl) was never the default window manager in Ubuntu. People indeed did install it to replace Metacity because they wanted to have these useless wobbly window effects compiz was the only one to have back then. These times are now long gone.

If by saying "compiz" you meant "a compositing window manager" then I have bad news for you. Windows and Mac desktops are both by default composited. In the Unix world the trend is to go towards replacing X11 with Wayland which is designed to be a composited environment. Most if not all modern desktop environments (including the largest two -- KDE and Unity) already use compositing window managers. Thus to rephrase a common meme: "Brace yourselves, compositing desktops are coming!".


You would be the first Linux developer I've spoken with who doesn't. Every software engineer I've spoken with had that opinion before I met them.
No comment. I have to be biting my tongue to stay polite.


I'm guessing you read that really fast or just need some sleep. We went with WebEngine because WebKit had too many faults. Hence the wording

"It was due to all of these facts my client opted for WebEngine. For all of its faults, it was "contained" because there were no plug-ins. "
There is no "WebKit" string in your last post, I don't know which are "these facts" you speak about. Besides, Blink/Chromium/WebEngine still has large parts of WebKit inside. Just that you know "these facts" still apply :) The main difference between WebKit and Chromium is that the latter does out of process rendering and I think since some time also does out of process handling of plugins. That's one of the reasons NPAPI plugins are disabled but at least until recently you could enable them back.


No offense. I don't know how you missed it, but that entire response was both rejecting the false claim below and providing evidence as to why it was false.
Sure, as usual.


I no longer have to solve the packaging issue. We have a packaging person that used to work at the Linux Group who I've worked with before and have a great amount of respect for, showing up in the next couple of days. I am not a packaging person, that is a different skill set from software engineering.
No comment. Biting my tongue again.


Hmm... odd that you thought I've never refuted your claims though. I've done that more than once
No, not once. Not even in this post. Maybe you thought you did. You quietly removed all the technical fragments and focused only on the least important of the soft parts. Nothing relevant about PulseAudio, nothing about the "faults" of Chromium, just nothing...


Perhaps I need to word posts here more like my novels and less like the stuff I send to the other software engineers?
I will ignore your offense. It is your problem that someone needs to get your job done for you, not mine. If you are really interested in phrasing your posts better, spend 15 minutes of your time reading this article, if you already haven't, it really pays off: http://www.catb.org/esr/faqs/smart-questions.html

[anda_skoa]

Ubuntu's desktop used Metacity and now uses something called Mutter. As far as I can tell compiz (nor Beryl) was never the default window manager in Ubuntu.

Interesting, I always thought that Unity was indeed built on the code base that originated as Compiz. And only the future version, which is incidentally using Qt, does not.
But I am not following Ubuntu, so I could very well be wrong.
Mutter, on the other hand, is used at least by GNOME and, as an extension, by Cinnamon and MATE.

Cheers,
_

[RolandHughes]

Interesting, I always thought that Unity was indeed built on the code base that originated as Compiz. And only the future version, which is incidentally using Qt, does not.
But I am not following Ubuntu, so I could very well be wrong.
Mutter, on the other hand, is used at least by GNOME and, as an extension, by Cinnamon and MATE.

Cheers,
_

You would be correct, at least as far as Unity. The previous syslog message listing .compiz in the path came directly from a default 32-bit installation of Ubuntu with the Unity desktop.

Added after 47 minutes:


This has nothing to do with "video streaming". I just skeemed through the thread but it looks like it is about getting pulseudio to work with alsa.


Ubuntu's desktop used Metacity and now uses something called Mutter. As far as I can tell compiz (nor Beryl) was never the default window manager in Ubuntu. People indeed did install it to replace Metacity because they wanted to have these useless wobbly window effects compiz was the only one to have back then. These times are now long gone.


That syslog message came from a default 32-bit install of Ubuntu with Unity desktop. As far as I know Unity never used anything other than compiz.




No comment. I have to be biting my tongue to stay polite.

:)



There is no "WebKit" string in your last post, I don't know which are "these facts" you speak about. Besides, Blink/Chromium/WebEngine still has large parts of WebKit inside. Just that you know "these facts" still apply :) The main difference between WebKit and Chromium is that the latter does out of process rendering and I think since some time also does out of process handling of plugins. That's one of the reasons NPAPI plugins are disabled but at least until recently you could enable them back.


I was not claiming faults of WebEngine, but faults of WebKit.



No, not once. Not even in this post. Maybe you thought you did. You quietly removed all the technical fragments and focused only on the least important of the soft parts. Nothing relevant about PulseAudio, nothing about the "faults" of Chromium, just nothing...


Yes, even in that post. ;)

We went with WebEngine because of the faults of WebKit and the fact WebKit is now depricated and will not be enhanced or actively developed after 5.4 according to an official post.




I will ignore your offense.


I meant no offense and hope you took none. It was all part of my journey. Not that you or anyone should care, but I will thumbnail it for you.

Many decades ago I started out with a degree in Business Oriented Computer Programming. While working in IT I went on to obtain a Computer Information Systems degree (they were two different tracks back then for some reason) then worked on a masters of computer science. At the same time I was working on an international parts routing/order management system (pre-internet) which was planned to take 7 years and we delivered in 5. I also worked on the trading floor system for a major stock exchange where we were directly liable for any trading errors. I really thought I knew something.

Then I had the good fortune of working with actual trained software engineers. Not the kind who crank out a planned 10 year life satelite which barely lasts 5, but the ones who are tasked with putting up a planned 10 year life bird which is still functioning perfectly 30 years later because they simply cannot design in failure. These men and women routinely built nuclear control systems, steel plant controls, and a rash of other such things, a few of which I was honored to work on. In short, I learned I knew nothing.

When I moved into the medical device area under full FDA regulation I wondered why some of these people were so relaxed when most of the team was so stressed. One day I finally asked one of them. Their response was life altering. "For the first time in my career only one life is riding on my code. It is still important, but this time it is only one."

At first blush such a statement sounded horrible until I looked into the systems they had done before where hundreds and in some cases thousands of lives relied on every line of their code being bug free. I learned what I could from them. Most importantly I learned that all of the degrees and projects I had worked on previously, even though I was proud of them, were nothing. At some point in the very near future I will most likely be back in the medical device field since that client has another product in design. I learned enough software engineering principles that the engineering team asked to have me back.

Sorry for the long winded off-topic response. My only defense is the trains woke me up at 3:30 this morning.

Back to the PulseAudio thing. It has been my experience that a regular user only knows they played a video and it didn't have sound. They don't really care who or what is at fault.

I wish you well and hope you have a super-fabulous day.

You need not worry about offending me. I'm old. Those buttons are hard to press.