#wine-staging

i see several versions, that is one of them - when it finishes i'll know if it picked the right one ;)

slackner: had some time to look at the patch, and it looks good to me. maybe a nit pick or two, but ... :) building a new executable so will give it a test run too.

JackWinter: ^^ congrats on the merge :)

the if (sched_setscheduler(thread->unix_tid, policy | SCHED_RESET_ON_FORK, &param) == -1 && sched_setscheduler(thread->unix_tid, policy, &param) == -1) is really elegant! don't think i'd thought of that, had to think two times before i understood it :)

ehoover: thanks, just happy if more people will use it, and it turns up useful.

until now it's been a very obscure patch

JackWinter: i'm sure it will be very useful, there's a lot of people that care about performance

hmm, we may want to think about giving the wineserver executable the necessary set_cap permissions

otherwise they will get reset on every update

think slackner said that some simple progs were twice as fast with the wineserver running rt. that ought to please a few :)

slackner used the small program i wrote to measure the performance of wineserver calls

cause imo the server really is a bottle neck, and i'm really looking forwards to staging removing them in the future

ah, still something :)

i really don't expect all programs to run twice as fast just from that patch

DarkPlayer: somewhere i have some code for giving wineserver set_cap while protecting everything else from getting it on fork

ehoover: i didn't take a closer look at the patch, but the flags seem to prevent this already:

sched_setscheduler(thread->unix_tid, policy | SCHED_RESET_ON_FORK, &param)

you don't want the user to need to allow users the rt privs?

the problem is that the file attributes get lost on every update

therefore the user needs to set the capability every 2 weeks

so it would be good to set it directly inside of the package

traditionally the user has been given rt caps through pam so far. think that is how most linux software does it. no idea about osx or others

DarkPlayer: correct winetricks installed

JackWinter: well, you maybe don't wont to give the permission to all programs

DarkPlayer: yeah there is that side to it too

DarkPlayer: don't most packaging systems have some kind of post install script?

JackWinter, DarkPlayer: we can do that, i'm not sure that's a good idea though

ehoover: it still won't get active by default, you need to set the environment variable

fyi, acl regression: https://bugs.winehq.org/show_bug.cgi?id=38341

04Bug 38341: normal, P2, ---, wine-bugs, UNCONFIRMED , Photoshop CS6 crash at startup

but it seems to me that on linux the traditional way is to add a realtime group and then give its users realtime and memlock privs through PAM

austin_laptop: bwahahahahaha

JackWinter: this is not easy to setup for everyone

on many distros the audio group, but i think that's kinda wrong, especially with systemd around :)

austin_laptop: pretty sure it will not be the only one - i think wine implemented file ACLs completely wrong

austin_laptop: unfortunately i can't even get my tests upstream fast enough because AJ doesn't want to add them, when they result in a corrupted wineprefix :(

slackner: corrupted prefix? wha?

but that reminds me, slackner. i have it through other patches, but we really ought to add a mlockall(), especially/only? for the server.

JackWinter: setcap wineserver CAP_SYS_NICE is still much easier ;-)

nice levels kinda suck, and seem to me to be an anachronism :)

ehoover: yes, some of the tests i wanted to add result in undeleteable directory objects

ehoover: (only on wine of course, on windows it works fine)

slackner, yeah, I saw that

it's kinda basic to realtime to memlock the code, because if it gets swapped your determinism is fscked

slackner: just generate random names for the directories

ehoover: thats what i did -> reject

seriously? ugg, it's a legitimate test

would've been nice to have written the tests first ;)

but still, glad you're working on it :)

austin_laptop: exactly, our plan was to add stored ACLs first

you need stored ACLs to do this right

slackner, sure, I see that

it doesn't work properly without stored ACLs

and there's still tons of issues with ACL handling even so

though once you have stored ACLs in your tree, you could've written the tests there as well

like bad defaults :/

not blaming anyone, it's a bad predicament to be in :/

austin_laptop: we kinda gave up putting energy into it when he said he wouldn't accept them

the original plan was to get stored ACLs in (already understood good enough and i think there are also existing tests), then upstream all the tests for inheritance

and afterwards implement inheritance properly in the wineserver

ehoover, ahh, that explains it

JackWinter: as already mentioned earlier, i don't think its a good idea to keep the whole wineserver process locked in memory

JackWinter: the code itself maybe, that should be harmless

slackner, austin_laptop: the secondary plan was to upstream DOS attributes and then stored ACLs, then the tests, then inheritance

(since stored ACLs uses the same infrastructure)

(and DOS attributes are easier)

JackWinter: but i really don't want to have any crashes because it just receives a large wineserver message ^^ there should be a solution for that

mm

slackner: what would crash? the wineserver?

JackWinter: the wineserver, when the kernel limits the amount of locked pages

ah, i see. up to the admin to configure the system just as realtime caps?

well in anycase everything goes to sh*t on linux when it starts swapping :) and personally i have it from other code so probably not a biggie

JackWinter: realtime caps is "relatively" harmless - the worst case is that it freezes the system

JackWinter: whereas such a feature might lead to unexpected crashes, and i doubt that anyone wants to track them down

well default since a long time is that it get 95% runtime max, so it won't really freeze the system

so indeed it's quite harmless. linux' vm system is much more of a pita

JackWinter: yep, but mlockall() isn't that harmless ^^ it might be useful in some situations, but its a bit dangerous when people just enable it without thinking

JackWinter: i am also not sure if its really required - this somehow reminds me of a winehq bug report

JackWinter: where a user wanted to run a lot of game servers in parallel

JackWinter: and wanted to enable kernel page deduplication for wine ;)

reaper keeps playing audio with no probs when i hit a swapstorm :)

JackWinter: in some situations page deduplication might be useful, but for the "average user" it will decrease the performance

but just wanted to point out that memlock is standard when it comes to realtime apps, that's all

think there is a way that you can memlock just the code too, but i'll have to look it up

JackWinter: yep, but i am pretty sure that most apps support some kind of fallback - for example only try to lock the code, and don't fail on error

slackner: btw, have you seen these patches, maybe something interesting in there: http://museupdates.com/wine-1.3.24-muse14.fc15.... from http://www.museresearch.com/

JackWinter: no, haven't seen them yet ^^ anything interesting in there?

sound stuff

popular stuff that runs with wine

if you're into audio stuff

it appareard to me that the named pipe stuff might be interesting, but a long time since i looked at them

but I'm not

i know i looked at it for my Wine presentation from last years LinuxTag

but I forgot

iirc it's a set of patches they developed but didn't have anyone to go through the wine submitting hoops :)

wine-1.3.24

kinda old

wanted to say, they developed to fix issues and make improvements they needed for their product

afair the new stuff has just tuning tips for Linux

and some configuration stuff

but afair no Wine patches anymore

can be that it's completely irrelevant nowadays

"Vendor wiki pages with HowTos"

no links

in my presentation that is

but the name rings a bell

didn't someone mention that there are wine-staging builds for osx? I need some binary wine that I can invoke from the command line, if anyone knows of something

wineskin/winebottler seem geared toward UI stuff, and I don't see an easy way to get a working wine (winebottler's gives freetype issues)

austin_laptop: I would assume that the patch for wine <1.7.20 would work for you regarding bottler (though idk anything about it, if it source or binary)

austin_laptop: ehoover has a Mac

NP-Hardass, what patch?

no clue if he has a Mac build

austin_laptop: let me dig it up

austin_laptop: you can try whether the POL builds of wine staging can directly be called on osx

I realllllly don't want to set up a build env for wine on osx; every time I've had to, it was a nightmare

DarkPlayer, I was hoping for vanilla wine, but that may work, thanks

austin_laptop: err, excuse me, 1.7.0-1.7.7

austin_laptop: they also provide vanilla builds

NP-Hardass: [06wine](00http://is.gd/lVVBhi) 02Alexandre Julliard: configure: Update FreeType configure checks for the changed headers location.

DarkPlayer, ah, excellent

austin_laptop: not sure if that applies to you

NP-Hardass, I think it's more likely a configuration issue; I tried setting LD_LIBRARY_PATH, but that didn't help.

OSX users tend to use GUIs, so it makes sense that it targets that, but I just want to test winetricks, not actually build on osx

though maybe valgrind + wine on osx would be interesting...

austin_laptop: okie dokie :) Just figured I'd point you to that, just in case

no time for it now

NP-Hardass, sure, thanks

slackner: does the server really allocate a lot of memory? don't think i've seen it allocate a lot, but was so long ago that i really looked at the server code...

puk: i test on mac on occasion, but i don't make a distributable build

happy easter weekend!

[06staging/master][05bd6e9c6](00http://is.gd/fHvjhS) 02Sebastian Lackner: Rebase against upstream changes.