So here's another update, I been puttsing around with use flags and rebuilding things and just playing around with getting my dependencies as low as possible. But this problem still persists. I have no clue at all why simply clicking on a .desktop file won't start a windows app running with wine. I ...

Here's another update - If I right-click on any .desktop file and select "Create Launcher on the Panel", it opens an error dialog (which won't allow me to highlight text in it, fucking retarded)....

"Failed to add a plugin to the panel - GDbus.Error:org.Freedesktop.DBus.Error.ServiceUnknown: The ...

Pretty much as the title suggests. I think it has something to do with the doom3-data files. Any idea's?


uby229@TheBeast ~ $ dhewm3
dhewm3 1.5.1pre.1304 linux-x86_64 Apr 14 2019 18:42:32 using SDL v2.0.9
WARNING: terminal type 'xterm-256color' is unknown. terminal support may not work correctly ...

Just an an update - I got Steam installed last night and it is displaying the same symptoms with native games and games played with Proton. Native games start just fine by simply clicking on them, but games started with Proton only start in a terminal.

Pretty much as the title says, Native apps start fine from the desktop icon, but apps running from wine don't start the app. If I type out the full path name on a terminal though the app starts just fine. Any idea's why native apps start fine, but wine apps don't?

@duby2291: all is relative. No offence meant but you can't say it's better to not re-encode video without knowing the context. All is contextual. Always.

None taken. :D In the end we try and experiment and do what works the best. It's better to have done it and learned there's no visual ...

I'm only posting this because the op seems unaware of the new wine packaging. Check this out.
https://wiki.gentoo.org/wiki/Wine:_New_Packaging

You'll probably be better off using the new packaging.

I'm not sure if my thinking is actually sound or not, but it seems to me that every time you re-encode a video your gonna lose some quality. It's not gonna be lossless. In all honesty you'll probably be better off just leaving it alone.

I'm not sure if this is related, maybe not, but perhaps it is. I had to do this "echo >=dev-util/cargo-0.21.0-r1 >> /etc/portage/package.mask && emerge -1 =dev-util/cargo-0.21.0"

I don't understand why, but the build failure I experienced indicated that supported cargo versions are hardcoded. So ...

The true actual problem here is that the libressl work is being done on an overlay with outdated ebuilds. Would you please clarify what is outdated? I'd really like to understand why you believe that given that in the case of qtnetwork, it actually has changes to support libressl, and is therefor ...

If I'm interpreting it right, then -vo should be vdpau. I think all you need is something like "mpv -vo=vdpau video-file"

That is another option but it fails and gives even less error messages:

mpv -vo=vdpau video_file

[vo/vdpau] Error when calling vdp_device_create_x11: 1
Error opening ...

remove "bindist" in make.conf, cause of so many prerequisite problems. Had a similar problem with openssl and tor integration..... on a "vanilla" system

Actually I already got it resolved. The thing is, if you use openssl you can't use bindist, so in that sense it is a valid blocker. But here's ...

To see if I could get some better error output I tried the mpv video player:

mpv -hwdec=vdpau -vo=opengl video_file

...
[vo/opengl] Loading hwdec driver 'vdpau-glx'
[vo/opengl/vdpau-glx] Error when calling vdp_device_create_x11: 1
[vo/opengl] Loading failed.
[vo/opengl] Reported display depth: 8 ...

I may actually be misunderstanding, I'm not sure, but I was under the impression nvidia replaced vdpau with nvenc such that nvenc does everything vdpau can plus much more and so they removed vdpau from their proprietary driver. I don't think it's even been in the driver for a few years now.

You ...

emerge -va --oneshot =dev-qt/qtnetwork-5.7.1 is able to pull in that version just fine, but emerge -DNu world always tries to upgrade it. It will not allow me to install this version pf plasma with that version of qtnetwork. That is a version locked command, not a repository locked command like I ...

EDIT: The solution is actually just a work around, the ebuild is still broken. You have to copy the qtnetwork ebuild into a local overlay and remove "ssl? ( dev-libs/openssl:0=[bindist=] )" from the DEPEND= stage.

So it seems like qtnetwork -requires- openssl to be built with -bindist use flag -if ...

Well, I followed your guidance and unfortunately for me the mouse is still lagging. I guess I'll just stick with MDM but really like Qingy...

Here is my complete directfbrc, perhaps there is more you need to set?


system=fbdev
mode=1680x1050
directfbrc
no-banner
vt-switching
mouse-source=/dev ...

Does not build with USE="-truetype" either: CC fbcondecor_helper-image.o
CC fbcondecor_helper-effects.o
daemon_cmd.c: In function ‘cmd_log’:
daemon_cmd.c:367:3: warning: implicit declaration of function ‘list_ringadd’ [-Wimplicit-function-declaration]
list_ringadd(&theme->msglog, strndup(args[0 ...

I've demonstrated that the overlay works just fine in this example, so lets please move on from that.

I cannot answer the issue regarding available developer time, so you'd have to ask the Gentoo devs about that specifically. I believe they are listed on the project page.

As far as "current ...

Exactly what command did you run that should have pulled the ebuild from the libressl overlay instead of the main build? What does Portage do if you specifically request the ebuild from the overlay, rather than letting it guess which tree to use?

emerge -va --oneshot =dev-qt/qtnetwork-5.7.1 is ...

So then what is the correct "supported" way to do it then? Basically what you're saying is that building a distributable Plasma desktop with the bindist use flag enabled is "unsupported" That's exactly what happens when your statements are extrapolated to an end result. I'm saying no such thing ...

This is not a problem with migrating to libressl, This is a problem with a broken qtnetwork ebuild. It is a problem with migrating to libressl if you don't migrate properly. LibreSSL is not yet supported in the main Gentoo repository.

this very forum thread proves beyond any doubt the fault is at ...

Because in the libressl overlay it is masked. Adding that is the only thing I needed to do, but I've obviously done other things to set up the overlay in general. That's why I mentioned it as a "at least."

$ grep KEYW /var/lib/layman/libressl/dev-qt/qtnetwork/qtnetwork-5.7.1.ebuild
KEYWORDS ...

This is not a problem with migrating to libressl, This is a problem with a broken qtnetwork ebuild. The broken one is the one in the main tree, the one that everyone is going to have problems with. The one that caused all these forum threads suggesting the only solution is to build with -bindist ...

qtnetwork not force to have -bindist use flag
DEPEND="
~dev-qt/qtcore-${PV}
>=sys-libs/zlib-1.2.5
connman? ( ~dev-qt/qtdbus-${PV} )
libproxy? ( net-libs/libproxy )
networkmanager? ( ~dev-qt/qtdbus-${PV} )
ssl? ( dev-libs/openssl:0[bindist=] )
"
You can post full output of emerge?

That was ...