September 2015 - Wine-Devel

Re: Migrating away from Sourceforge

by Aaryaman Vasishta

+1. That's great news :D It would be a great silver lining if the bandwidth does get over once we start providing binary packages ;) Cheers, Aaryaman On Tue, Sep 29, 2015 at 2:32 AM, Austin English <austinenglish(a)gmail.com> wrote: > On Mon, Sep 28, 2015 at 3:58 PM, Jeremy White <jwhite(a)codeweavers.com> > wrote: > >>> As an update, I did email the Conservancy. They've gotten this same > >> question from a number of member projects, and are doing some > >> research/thinking about this. > >>> > >>> So it's not forgotten, but in progress. > > > > Just in case folks have missed it, we are getting sponsorship from > > Fastly. Jeremy Newman is working out the details now. > > > > It's not clear how much bandwidth we'll need vs how much they are > > donating. It looks like we'll be getting at least 8.5 TB/month, which > > should be enough to cover the move away from Sourceforge. > > > > But we were also hoping to provide binary downloads; we may need to do > > some wiggling to cover that as well. Of course, that depends on how > > much demand there is for the binary downloads; if the demand is modest, > > it won't be an issue. > > > > Cheers, > > > > Jeremy > > Huzzah! Thanks Jeremy. > > -- > -Austin > > >

Sept. 29, 2015

Re: Migrating away from Sourceforge

by Austin English

On Mon, Sep 28, 2015 at 3:58 PM, Jeremy White <jwhite(a)codeweavers.com> wrote: >>> As an update, I did email the Conservancy. They've gotten this same >> question from a number of member projects, and are doing some >> research/thinking about this. >>> >>> So it's not forgotten, but in progress. > > Just in case folks have missed it, we are getting sponsorship from > Fastly. Jeremy Newman is working out the details now. > > It's not clear how much bandwidth we'll need vs how much they are > donating. It looks like we'll be getting at least 8.5 TB/month, which > should be enough to cover the move away from Sourceforge. > > But we were also hoping to provide binary downloads; we may need to do > some wiggling to cover that as well. Of course, that depends on how > much demand there is for the binary downloads; if the demand is modest, > it won't be an issue. > > Cheers, > > Jeremy Huzzah! Thanks Jeremy. -- -Austin

Sept. 28, 2015

Re: Migrating away from Sourceforge

by Jeremy White

>> As an update, I did email the Conservancy. They've gotten this same > question from a number of member projects, and are doing some > research/thinking about this. >> >> So it's not forgotten, but in progress. Just in case folks have missed it, we are getting sponsorship from Fastly. Jeremy Newman is working out the details now. It's not clear how much bandwidth we'll need vs how much they are donating. It looks like we'll be getting at least 8.5 TB/month, which should be enough to cover the move away from Sourceforge. But we were also hoping to provide binary downloads; we may need to do some wiggling to cover that as well. Of course, that depends on how much demand there is for the binary downloads; if the demand is modest, it won't be an issue. Cheers, Jeremy

Sept. 28, 2015

Re: [PATCH 1/2] d3d8: Accept D3DSWAPEFFECT_COPY_VSYNC.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=16895 Your paranoid android. === w1064 (32 bit device) === device.c:2612: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2617: Test failed: The focus window is active. device.c:2625: Test failed: Got unexpected hr 0x88760869. device.c:2631: Test failed: Got unexpect screen size 1152x870. device.c:2646: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=2. device.c:2655: Test failed: Got unexpect screen size 1152x870. device.c:2668: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2676: Test failed: Got unexpect width 1152. device.c:2677: Test failed: Got unexpect height 864.

Sept. 28, 2015

Re: Bugzilla changes

by Sebastian Lackner

On 28.09.2015 19:02, Theodore Dubois wrote: >> * New wine-staging product: This should be used for bugs caused by >> patches that are in wine-staging, but that do not occur in >> wine-development (i.e., wine-staging patch regressions) > > There should also be a place for bugs that only show up in wine > staging, but can't be considered regressions because the program > wouldn't even run in wine. For example, Life is Strange (I've tested > episode 1) doesn't work at all in wine. In wine staging, though, it > does run, but after a few minutes the performance drops to about 2 > FPS. I have no idea if the bug is in wine staging, or it's in wine > and you can only notice it when the wine staging patches are applied > and the game actually runs. > > ~Theodore > There is no need to keep them separate, Bugzilla already supports a way to mark bugs as "blocked by a different bug". You would just mention this information, then the Staging patchset can be bisected to find out which other fixes are required, and the bug dependencies can be set accordingly.

Sept. 28, 2015

Re: Bugzilla changes

by Austin English

On Mon, Sep 28, 2015 at 12:02 PM, Theodore Dubois <tblodt(a)icloud.com> wrote: >> * New wine-staging product: This should be used for bugs caused by >> patches that are in wine-staging, but that do not occur in >> wine-development (i.e., wine-staging patch regressions) > > There should also be a place for bugs that only show up in wine staging, but can't be considered regressions because the program wouldn't even run in wine. For example, Life is Strange (I've tested episode 1) doesn't work at all in wine. In wine staging, though, it does run, but after a few minutes the performance drops to about 2 FPS. I have no idea if the bug is in wine staging, or it's in wine and you can only notice it when the wine staging patches are applied and the game actually runs. > > ~Theodore File it as a bug in wine. -- -Austin

Sept. 28, 2015

Re: Bugzilla changes

by Theodore Dubois

> * New wine-staging product: This should be used for bugs caused by > patches that are in wine-staging, but that do not occur in > wine-development (i.e., wine-staging patch regressions) There should also be a place for bugs that only show up in wine staging, but can't be considered regressions because the program wouldn't even run in wine. For example, Life is Strange (I've tested episode 1) doesn't work at all in wine. In wine staging, though, it does run, but after a few minutes the performance drops to about 2 FPS. I have no idea if the bug is in wine staging, or it's in wine and you can only notice it when the wine staging patches are applied and the game actually runs. ~Theodore

Sept. 28, 2015

Re: Bugzilla changes

by Austin English

On Mon, Sep 28, 2015 at 7:00 AM, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > On 28.09.2015 08:56, Austin English wrote: >> Howdy all, >> >> As Alexandre mentioned [1], at WineConf we made several decisions to >> modify bugzilla in a few ways. I've now implemented those changes, >> which are outlined below: > > Hi Austin, > > thanks for doing these changes. :) > >> >> * New wine-staging product: This should be used for bugs caused by >> patches that are in wine-staging, but that do not occur in >> wine-development (i.e., wine-staging patch regressions) > > As far as I know there were some concerns to call it "wine-staging", and > it was preferred to call it just "staging". Did you use the original name > to avoid ordering problems? Yes, and consistency. >> * New STAGED resolution: This is to differentiate bugs that are FIXED >> (in wine-development) from bugs that are not present in wine-staging >> because of one or more patches. The anticipated workflow is: >> UNCONFIRMED > bug confirmed, NEW > patch written and sent to >> wine-patches, if it's accepted, FIXED. If not, and the patch is >> integrated into wine-staging, then the bug is STAGED. When the patch >> is revised and eventually integrated into wine-development, the bug >> should move to FIXED. > > Wasn't the idea to add it as a non-RESOLVED status? I personally do not > care that much about the difference, but we should probably decide before > we use it everywhere. Also it would be nice to have a field to keep track > of the staged patchset, without writing it in a comment. What about an > additional field which is only present when this status is selected? > (similar to the Regression SHA field for example) I wasn't aware that distinction was made, but I think that makes sense, I've changed NEEDINFO / STAGED to be statuses rather than resolutions. I've also added a 'Staged patchset' field to Bugzilla. >> >> * New NEEDINFO resolution: There's a lot of confusion and different >> handling by triagers for what to do with bug reports that are >> incomplete (i.e., leaving it open versus closing invalid). To mitigate >> this, I've added a NEEDINFO resolution. If a bug report lacks needed >> information, set it to this status. Bug that have been open NEEDINFO >> for more than 1 year can be closed. > > Similar to the staging status, why is this a RESOLVED status? Its not > really a final status, so a non-RESOLVED status would make more sense maybe. Changed. >> >> * Renamed UPSTREAM to NOTOURBUG: This is more in line with what other >> projects do, and eliminates confusion about the upstream/downstream >> distinction. >> >> Please let me know if there are any questions or ideas for further enhancements. >> >> [1] https://www.winehq.org/pipermail/wine-devel/2015-September/109392.html >> > > Regards, > Sebastian -- -Austin

Sept. 28, 2015

Re: ieframe: add a better toolbar bitmap

by Joel Holdsworth

On 28/09/15 12:58, Jacek Caban wrote: > Hi Jared, > > On 09/26/15 20:02, Jared Smudde wrote: >> --- >> dlls/ieframe/ietoolbar.bmp | Bin 24698 -> 24630 bytes >> 1 files changed, 0 insertions(+), 0 deletions(-) > Also - what's "better" about this toolbar image? I applied the patch and for me it appears identical to the old one. Joel

Sept. 28, 2015

Re: ntdll: Reduce stack usage of virtual memory functions by storing sigset in static memory.

by Grazvydas Ignotas

On Sun, Sep 27, 2015 at 6:05 PM, Michael Müller <michael(a)fds-team.de> wrote: > Am 27.09.2015 um 00:07 schrieb Sebastian Lackner: >> From: Michael Müller <michael(a)fds-team.de> >> >> For https://bugs.winehq.org/show_bug.cgi?id=34558 >> >> Depending on the compiler optimization flags there is still no guarantee that >> everything will fit into the available stack space, no matter if its declared >> as static or not. > > As suspected the idea does not work for all optimization levels. At > least GCC merges the content of the functions when using -O2 and > therefore reintroduces the problem - even __attribute__ ((noinline)) is > not sufficient. Try __attribute__ ((noclone,noinline)) Gražvydas

Sept. 28, 2015