June 2015 - Wine-Devel - list.winehq.org

Re: [wine-tools] patches: Add a "Staging" status.

by Austin English

On Fri, Jun 5, 2015 at 11:30 AM, Michael Stefaniuc <mstefani(a)redhat.de> wrote: > --- > patches/expire | 1 + > patches/patches.css | 1 + > patches/update | 2 ++ > 3 files changed, 4 insertions(+) > > diff --git a/patches/expire b/patches/expire > index f143ab1..3cf75e6 100755 > --- a/patches/expire > +++ b/patches/expire > @@ -37,6 +37,7 @@ my %status_expiry = > "split" => 7, > "depend" => 7, > "sequence" => 7, > + "staging" => 30, > "superseded" => 1, > "testcase" => 7, > "testfail" => 7, > diff --git a/patches/patches.css b/patches/patches.css > index 745ec75..5746057 100644 > --- a/patches/patches.css > +++ b/patches/patches.css > @@ -154,6 +154,7 @@ tr.odd { background-color: #f8e8e8; } > .sequence, .sequence :link, .sequence :visited { color: #e08000; } > .deferred, .deferred :link, .deferred :visited { color: #e08000; } > .testcase, .testcase :link, .testcase :visited { color: #e08000; } > +.staging, .staging :link, .staging :visited { color: #e08000; } > .other, .other :link, .other :visited { color: #e08000; } > .applyfail, .applyfail :link, .applyfail :visited { color: red; } > .buildfail, .buildfail :link, .buildfail :visited { color: red; } > diff --git a/patches/update b/patches/update > index 4ccc910..335af0b 100755 > --- a/patches/update > +++ b/patches/update > @@ -40,6 +40,7 @@ my %status_descr = > "depend" => "Dependency", > "superseded" => "Superseded", > "sequence" => "Bad sequence", > + "staging" => "Staging", > "testcase" => "Needs tests", > "testfail" => "Test failure", > ); > @@ -57,6 +58,7 @@ my @legend = > "<li>Someone else fixed the problem already.</li></ul>" ], > [ "testcase", "<ul><li>You need to write some test cases demonstrating that the patch is correct.</li></ul>" ], > [ "deferred", "<ul><li>The patch is deferred because of code freeze for an upcoming release. Either resend after the release, make the patch less intrusive, or make a convincing argument that it needs to be included in the release.</li></ul>" ], > + [ "staging", "<ul><li>The patch needs more work or wider testing. Please get it in over Wine Staging.</li></ul>" ], > [ "other", "<ul><li>The patch belongs to another WineHQ project (website, appdb, etc.) and will be applied by the respective maintainer.</li></ul>" ], > [ "applyfail", "<ul><li>The patch got mangled in transit.</li>" . > "<li>It's not relative to the latest git.</li>" . > -- > 2.4.2 I'm not sure we want to encourage wine-stating from Upstream (I'm not convinced either way), but in any case, the grammar seems wrong to me as a native speaker, how about: "The patch needs more work or wider testing. Please try to get into Wine-Staging." or something similar? -- -Austin

June 5, 2015

Re: Migrating away from Sourceforge

by Jeremy White

On 06/04/2015 11:57 PM, Michael Cronenworth wrote: > On 06/04/2015 11:55 PM, Michael Cronenworth wrote: >> >> There is always the github route. All the cool kids are doing it these >> days. >> >> They don't have any expressed bandwidth or disk space limits on open >> source software repos. It would be completely free. > > It looks like this is already setup? > > https://github.com/wine-mirror/wine > > Any release tarballs are handled via: > > https://github.com/wine-mirror/wine/archive/wine-1.7.44.tar.gz Yeah, that certainly seems like a reasonable alternate to try. GitHub has essentially displaced SourceForge in the eco system. Note, though, while there are not explicit bandwidth caps, their terms of service does say: > If your bandwidth usage significantly exceeds the average bandwidth usage (as determined solely by GitHub) of other GitHub customers, we reserve the right to immediately disable your account or throttle your file hosting until you can reduce your bandwidth consumption. I do have a request in to the SFC and want to hear their wisdom as well. Cheers, Jeremy

June 5, 2015

Re: mciqtz32: Guarantees that CoInitialize and CoUninitialize run on the same thread.

by Akihiro Sagawa

Hi Jörg, On Tue, 2 Jun 2015 14:04:48 +0200, Joerg-Cyril.Hoehle wrote: > >However, recent Windows systems don't allow to call MCI commands from another thread. > Could you please elaborate? I understand the Co/UnCo issue, but what about other commands? > Wouldn't the thread invoking Co/UnCo remain strictly internal to winmm? > > At the MCI string command level, all you see are "device" numbers and aliases, so > why shouldn't an app be allowed to send "status x position" from any thread in > the app's address space? Essentially, it should. But, please see https://testbot.winehq.org/JobDetails.pl?Key=13867 and its patch. In the test, it opens tempfile.wav with alias mysound in mci_open_thread and plays mysound in mci_another_thread. It also expects the latter attempt is failed with MCIERR_INVALID_DEVICE_NAME. In the main thread, mciGetDeviceID's return value is zero which means an error. This indicates the device doesn't exist in winmm level. Finally, it succeeds to open a file with the same alias in main thread. The result shows there are no errors at these points. To wrap up, "device" and alias is not visible between threads. Among testbot, this is true. Additionally, my test shows it's true for Windows NT 4, but false for Windows 98. I'll continue investigating old Windows behavior. Regards, Akihiro Sagawa

June 5, 2015

Re: odbccp32: Add a trace message to functions

by Nikolay Sivov

> @@ -281,7 +281,7 @@ BOOL WINAPI SQLGetAvailableDriversW(LPCWSTR lpszInfFile, LPWSTR lpszBuf, > WORD cbBufMax, WORD *pcbBufOut) > { > clear_errors(); > - FIXME("\n"); > + FIXME("%s %s %d %p\n", debugstr_w(lpszInfFile), debugstr_w(lpszBuf), cbBufMax, pcbBufOut); This is wrong, because lpszBuf is out parameter. > @@ -370,6 +374,9 @@ BOOL WINAPI SQLGetInstalledDrivers(LPSTR lpszBuf, WORD cbBufMax, > int size_wbuf = cbBufMax; > LPWSTR wbuf; > WORD size_used; > + > + TRACE("%s %d %p\n", debugstr_a(lpszBuf), cbBufMax, pcbBufOut); > + Same here. > @@ -397,7 +404,9 @@ int WINAPI SQLGetPrivateProfileStringW(LPCWSTR lpszSection, LPCWSTR lpszEntry, > LPCWSTR lpszFilename) > { > clear_errors(); > - FIXME("\n"); > + FIXME("%s %s %s %p %d %s\n", debugstr_w(lpszSection), debugstr_w(lpszEntry), > + debugstr_w(lpszDefault), RetBuffer, cbRetBuffer, > + debugstr_w(lpszFilename)); > SetLastError(ERROR_CALL_NOT_IMPLEMENTED); And here.

June 5, 2015

Re: Wine 64 bit

by Charles Davis

> On Jun 5, 2015, at 12:04 AM, Ken Thomases <ken(a)codeweavers.com> wrote: > > Hi Chip, > > I saw your patch for 64-bit debug registers. Thanks! > > It made me wonder if you've got anything else in-progress related to 64-bit on OS X? In particular, are you still working on support for __builtin_ms_va_list in Clang Yeah, but I’ve had to rethink that patch because they’re doing something to the way the compiler represents pointers internally. Hopefully I’ll have it in by the time 3.7 is released in about a month or so. > or the problems you mentioned previously about code generation when switching calling conventions? I just recently fixed a really nasty bug with sibling-call optimization that basically just caused Wine to jump to NULL instead of the program’s entry point when it started up. (Specifically, it stuffed the target address into a callee-save register, then tried to use it *after restoring it from the stack*.) There might be other codegen bugs still lurking, though—my informal testing shows such odd problems as text being a little bigger than it should be and random problems accessing the registry, and I haven’t figured out why yet. (Maybe the first is caused by the second?) > > I noticed that a bug with DWARF unwind info got fixed in the Clang/LLVM trunk sometime after 3.6. Was that your doing? Nope. I haven’t had much time to work on this until recently. > (You mentioned something like this in your April 29th email.) I thought it might have been broken (and it may very well have been; I recall tracing Wine’s unwinder through the debugger early on and finding that what it was doing didn’t make sense, but it doesn’t seem as broken now, though I still got a stack overflow on the first guard page of the stack in one case), but now the thought has crossed my mind (especially since you sent those patches to use libunwind; it must have occurred to you, too!) that some functions just don’t have traditional DWARF CFI because the linker (and in many cases, Clang directly) emits compact unwind data. Naturally, this doesn’t matter to Apple’s unwinder, because it understands compact unwind and knows it should fall back to CFI if the function it’s trying to unwind doesn’t have it. I thought they emitted (or used to emit) compact unwind side-by-side with CFI, but they might have stopped doing that lately (or they only do it if the compiler puts out CFI, and the linker can produce matching compact unwind data out of it). > I was thinking of tackling the dbghelp support for 64-bit Mach-O images (although not DWARF debugging info) sometime soon, but maybe you're already working on that. Are you? Nope. Feel free to go ahead with that. I might still have some more codegen bugs to mercilessly hunt down by groveling over arcane runes. Chip

June 5, 2015

Re: Wine 64 bit

by Ken Thomases

Hi Chip, I saw your patch for 64-bit debug registers. Thanks! It made me wonder if you've got anything else in-progress related to 64-bit on OS X? In particular, are you still working on support for __builtin_ms_va_list in Clang or the problems you mentioned previously about code generation when switching calling conventions? I noticed that a bug with DWARF unwind info got fixed in the Clang/LLVM trunk sometime after 3.6. Was that your doing? (You mentioned something like this in your April 29th email.) If so, thanks! I was thinking of tackling the dbghelp support for 64-bit Mach-O images (although not DWARF debugging info) sometime soon, but maybe you're already working on that. Are you? If so, I'll leave it to you. Cheers, Ken

June 5, 2015

Re: Migrating away from Sourceforge

by Michael Cronenworth

On 06/04/2015 11:55 PM, Michael Cronenworth wrote: > > There is always the github route. All the cool kids are doing it these days. > > They don't have any expressed bandwidth or disk space limits on open source > software repos. It would be completely free. It looks like this is already setup? https://github.com/wine-mirror/wine Any release tarballs are handled via: https://github.com/wine-mirror/wine/archive/wine-1.7.44.tar.gz

June 5, 2015

Re: Migrating away from Sourceforge

by Michael Cronenworth

On 06/04/2015 11:22 PM, Jeremy White wrote: > [snip] > There may be a CDN willing to give Wine a deal, as we're a non profit. I'll shoot > a note of to SFC to see if they have a CDN they deal with. There is always the github route. All the cool kids are doing it these days. They don't have any expressed bandwidth or disk space limits on open source software repos. It would be completely free. Michael

June 5, 2015

Re: Migrating away from Sourceforge

by Jeremy White

On 06/04/2015 05:22 PM, Scott Ritchie wrote: > Do cloud providers like Amazon S3 count as a CDN here? It's very low > barrier to entry, just make an account. As far as automation goes, you > could just mirror whatever ftp structure you were going to build into s3 > with something like s3fs. Generally a CDN has several advantages; first, it mirrors across the world, so folks get to download from a more local source. Second, it tends to price more favorably. I've done some further research, and I think we may be looking at more of a cost than we might like. Google's pricing for network traffic is 12 cents / Gig. That's about $500/month for these downloads. Looks like other CDNs will get you down as low as 6 cents / Gig, which is still fairly pricey for us. Digital Ocean essentially advertises $0.02/Gig, but they don't make promises on rate, and I saw some concerns about their overall stability (e.g. indications that there were uptime issues). Note that Amazon's free tier lets you have 15G of data before they cap you. Sadly, I think CodeWeavers does not have enough head room; we're using about 30 Mbps (95th percentile) on our CDN, and if I read the numbers right, these downloads would push us over our 50 Mbps limit. CodeWeavers could probably negotiate a modest price for a bump on that cap to make room for the Wine downloads; I think we're overpaying now, so I suspect I have some leverage <grin>. There may be a CDN willing to give Wine a deal, as we're a non profit. I'll shoot a note of to SFC to see if they have a CDN they deal with. Bottom line: whatever other complaints we have about SourceForge, they've been providing an incredible value all these years. Cheers, Jeremy

June 5, 2015

Re: [PATCH 2/5] d3d9/tests: Add more tests for point size. (v3)

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=13876 Your paranoid android. === w8 (32 bit visual) === visual.c:10525: Test failed: Got unexpected color 0x00ff0000 (case 5, 3, size 0). visual.c:10525: Test failed: Got unexpected color 0x00ff0000 (case 7, 3, size 0). visual.c:10525: Test failed: Got unexpected color 0x00ff0000 (case 9, 3, size 0).

June 4, 2015