#wine-staging

Under what OS are the debian sid packages built?

jpleau: under debian sid

slackner: I'm getting this: https://gist.github.com/jpleau/06356b3091b8f320...

That's why I was asking, maybe I did somethign wrong to generate the files though

jpleau: the build dependencies are gcc-4.5 | gcc-4.7 | gcc-4.9 | gcc-5 (>= 5.3)

at least gcc-5.3 should be available -> https://packages.debian.org/sid/gcc-5

DarkPlayer: yup I looked at d/control, gcc-5 is definitely available. I think it is a bug with the dependency desolver

let me try another

jpleau: we use mk-build-deps -i -r -t "apt-get -y" debian/control to install the dependencies

DarkPlayer: Yea I would do that but I'm trying to build it from my build schroots

I'll do it manually if it fails though

with mk-build-deps like you mentionned

DarkPlayer: fyi, the fatal exception / access_violation I was getting the other day seems to be caused by http://source.winehq.org/git/wine.git/commit/3e... -- fixes the issue on wine-1.9.6, now trying it on staging

if all works i will file a regression on winehq

jpleau: current wine staging reverts this commit, ehoover also encountered a crash caused by this commit

jpleau: there is already a bug report on winehq.org

slackner: /o\ I spent all my evening on this, nooo

but I'm glad it's fixed :)

jpleau: its not fixed yet, but the issue is known ;)

well, reverted in staging ;-)

DarkPlayer: i wouldn't call that a fix, its really mysterious that this patch causes crashes

slackner: my issue was an app needs to inject a dll into a game (to be precise: tMorph with WoW). Reading the commit message made me scratch my head too, but it fixed it

https://github.com/ariscop/wine/commit/90b7fd74c4 would this be accepted upstream? not in its current state obviously, but using thread name exceptions in general

release version of steam uses them, could be useful for debugging

ariscop: what is the use for that? apparently the exception is for the debugger only

hackomatic, makes thread names visible in htop or similar, and some applications do use them

it's not supposed to be set when there is no debugger

when there's no debugger it's a caught exception

it is a debugging aid implemented by microsoft, but it has been implemented by many more since then

ariscop: despite the limitations (no support for not current thread) what's the use for that outside of wine?

none, since it is a windows mechanism?

context, tells you what a threads doing

learn_more: it's a windows debugger feature

ya?

so without wine, its of no use on linux

my feeling as well

i assumed hack meant on windows

with wine, its usefull

but it is not correct, since you can also set the name of another thread

learn_more: wine has nothing to do with it

since it's built on seh there's no meaningful use outside of win32

yes

and that's where wine comes in

it's just nice to have

"oh this threads misbehaving" *open htop* "something to do with [name]"

aww, my wine testbot account died

anyone online with a testbot account?

nevermind, mine apparently isn't dead

ariscop: for future reference, i have a testbot acct

but this channel is usually not on top, so a highlight speeds things up

What a rhyme!

ikr

Hi I'm using KDE PLasma there is an option to disable the compositor while playing games in fullscreen.

Does this also work if I use Wine virtual desktop resolution?

also it seems that playing Guild Wars 2 the game still gets slower over a period of playtime (texture unload too slow maybe?!)

If I use virtual desktop resolution it seems to be a bit better