January 2016 - Wine-Devel - list.winehq.org

Re: Fedora source packages

by Jeffrey Smith

Fedora 21 was EOL'd a month ago, and I don't believe the yum-builddep commands work without the source rpms either. So the Old Fedora section probably could go away. If a patch of mine to the dnf project is approved, and if a source repo is added along-side the winehq binary repo, then perhaps the dnf builddep command can eventually replace that lengthy dnf install command. One more question: where is the Fedora spec file used for creating the winehq binary packages. That should be available somewhere, but I haven't found it. On Sat, Jan 2, 2016 at 9:36 AM, Rosanne DiMesio <dimesio(a)earthlink.net> wrote: > On Sat, 2 Jan 2016 01:49:40 -0600 > Jeffrey Smith <whydoubt(a)gmail.com> wrote: > > > For the builddep commands in http://wiki.winehq.org/Fedora to work as > > intended, there needs to be a repository containing the source rpms. The > > binary rpms do NOT provide the _build_ dependency information needed for > > the builddep commands to do their job. > > > > Otherwise, the instructions need to be redone, as the builddep commands > are > > not really doing anything useful as things stand. > > > > I assume you mean the line about using dnf builddep to install the build > dependencies on Fedora 22 and later. I've removed that. I've left the > command from Zhenbo Li, because AFAIK it should install everything listed, > and all those things are needed, but I'm not sure the list includes > everything needed. The original wording on that page suggested that it was > needed in addition to running dnf builddep. Hence the "This section is > incomplete" note I've also added; someone who uses Fedora will need to > expand that section, or tell me what to add. > > Is there any point in keeping the Old Fedora section on that page? > > > -- > Rosanne DiMesio > dimesio(a)earthlink.net > >

Jan. 2, 2016

Re: [PATCH] d3drm/tests: Add tests for IDirect3DRM*::LoadTexture (try 6).

by Aaryaman Vasishta

On Sat, Jan 2, 2016 at 12:41 AM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Am 2016-01-01 um 18:15 schrieb Aaryaman Vasishta: > > + expected = (info_header.biWidth + 3) & ~3; > > + ok(expected == img->bytes_per_line, "Expected bytes per line == > %d, got %d.\n", expected, img->bytes_per_line); > > + if (depth == 8) > > + { > > + for (i = 0; i < h; i++) > > + { > > + offset = upside_down ? (img->bytes_per_line * (h - i - > 1)) : (img->bytes_per_line * i); > > + for (j = 0; j < img->bytes_per_line; j++) > > + { > > + if (buffer1[k++] != buffer2[offset++]) > > + return FALSE; > > + } > You want j < img->width here, otherwise you compare the padded bytes > against the next line of the input image. (You'll then also compare the > follow-up lines incorrectly and read past the input buffer). It works > here because you pass an image with a width that's a multiple of 4 when > this codepath is used. > > So iterate over width pixels, but advance the read offset / pointer by > bytes_per_line bytes after processing one line. > It seems for any 8bpp image loaded by d3drm, the bytes_per_line is always == width regardless of whether the width is a multiple of 4 or not. So there's essentially no padding between lines. Hence, using bytes_per_line instead of width here doesn't really make a difference. I've sent a try 7 with the other changes we discussed on IRC, but if you want me to change this to use img->width instead of bytes_per_line I don't mind that either.

Jan. 2, 2016

Re: Mac OS X beta packages!

by Michael Müller

Am 02.01.2016 um 16:49 schrieb Rosanne DiMesio: > On Fri, 1 Jan 2016 02:54:48 +0100 > Michael Müller <michael(a)fds-team.de> wrote: > >> >> we are happy to announce an initial version of our Mac OS X >= 10.8 >> builds. So far the packages have not yet received that much testing, so >> please give them a try, and report any issues you encounter. >> > > This is probably a dumb question, but since I know nothing about Macs but have to support Mac users, I have to ask it. I noticed that, unlike your instructions for the Linux packages, you didn't mention anything about being able to install both the development and staging packages on the same machine. Does that mean it's not possible to have both packages installed on Mac OS X, or that it is possible, but nothing special needs to be done? Also, are there potential conflicts with previously installed versions of Wine that users need to be warned about? I'm thinking of Wine installed via Macports, Fink, or Homebrew in particular. > > The Wine Devel and Wine Staging packages can be installed in parallel. When started correctly (using Launchpad or the Dock), they will work no matter which other Wine versions are on the same system. Technically this is implemented by prepending the $PATH environment variable with the installation directory of our Wine version. Please note that it is very important here that users use the Launcher, typing "wine" in a regular terminal will either not work, or run a Wine version installed via other sources like Macports/Fink/Homebrew. At least Homebrew installs to /usr/local, which means that "wine" typed in a regular terminal has a different meaning than "wine" typed in a terminal spawned by clicking on "Wine Devel" or "Wine Staging". Only in the second case, the WineHQ packages will be used. In order to start WineHQ from a terminal without going through our Launcher, the user either has to: * Prepend $PATH himself with the installation directory. For an installation into the home directory, the following command should work: export PATH="$HOME/Applications/Wine Devel.app/Contents/Resources/wine/bin:$PATH" export PATH="$HOME/Applications/Wine Staging.app/Contents/Resources/wine/bin:$PATH" * Use the Mac OS X specific "open" command, which will search for the executable by program name. open -a "Wine Devel" program.exe open -a "Wine Devel" --args winecfg open -a "Wine Staging" program.exe [...] The only (non-critical) "conflict" is that the Devel and Staging packages (and also Play On Mac) register themselves for .exe files. The first installed application is then the default application to open .exe files. But like on all other systems, you can do a right click on such a file and use the "Open With" menu entry to select the application you want to use. The user can also change the default application for the .exe extension, if they want to always use Wine Devel or Wine Staging. Regards, Michael

Jan. 2, 2016

Re: Mac OS X beta packages!

by Rosanne DiMesio

On Fri, 1 Jan 2016 02:54:48 +0100 Michael Müller <michael(a)fds-team.de> wrote: > > we are happy to announce an initial version of our Mac OS X >= 10.8 > builds. So far the packages have not yet received that much testing, so > please give them a try, and report any issues you encounter. > This is probably a dumb question, but since I know nothing about Macs but have to support Mac users, I have to ask it. I noticed that, unlike your instructions for the Linux packages, you didn't mention anything about being able to install both the development and staging packages on the same machine. Does that mean it's not possible to have both packages installed on Mac OS X, or that it is possible, but nothing special needs to be done? Also, are there potential conflicts with previously installed versions of Wine that users need to be warned about? I'm thinking of Wine installed via Macports, Fink, or Homebrew in particular. -- Rosanne DiMesio dimesio(a)earthlink.net

Jan. 2, 2016

Re: Fedora source packages

by Rosanne DiMesio

On Sat, 2 Jan 2016 01:49:40 -0600 Jeffrey Smith <whydoubt(a)gmail.com> wrote: > For the builddep commands in http://wiki.winehq.org/Fedora to work as > intended, there needs to be a repository containing the source rpms. The > binary rpms do NOT provide the _build_ dependency information needed for > the builddep commands to do their job. > > Otherwise, the instructions need to be redone, as the builddep commands are > not really doing anything useful as things stand. > I assume you mean the line about using dnf builddep to install the build dependencies on Fedora 22 and later. I've removed that. I've left the command from Zhenbo Li, because AFAIK it should install everything listed, and all those things are needed, but I'm not sure the list includes everything needed. The original wording on that page suggested that it was needed in addition to running dnf builddep. Hence the "This section is incomplete" note I've also added; someone who uses Fedora will need to expand that section, or tell me what to add. Is there any point in keeping the Old Fedora section on that page? -- Rosanne DiMesio dimesio(a)earthlink.net

Jan. 2, 2016

Re: user32/tests: Add message tests for EM_SETSEL when getting/losing focus in combo boxes (v2)

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=19336 Your paranoid android. === w7u (32 bit msg) === msg.c:4644: Test failed: ShowWindow(SW_RESTORE):overlapped: 18: the msg sequence is not complete: expected 0000 - actual 0088 === w1064 (32 bit msg) === msg.c:6290: Test failed: Update region shouldn't be empty msg.c:6524: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6526: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different

Jan. 2, 2016

Re: [PATCH] shell32/tests: Explicitly compare to HRESULT values

by Nikolay Sivov

On 02.01.2016 14:15, Marvin wrote: > 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=19335 > > Your paranoid android. > > > === w1064 (32 bit shlfolder) === > shlfolder.c:1578: Test failed: IShellFolder_GetDisplayNameOf(NULL) failed! hr = 80070057 > > Existing failure, happens on Win10 only.

Jan. 2, 2016

Re: [PATCH] shell32/tests: Explicitly compare to HRESULT values

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=19335 Your paranoid android. === w1064 (32 bit shlfolder) === shlfolder.c:1578: Test failed: IShellFolder_GetDisplayNameOf(NULL) failed! hr = 80070057

Jan. 2, 2016

Re: Fedora source packages

by Zhenbo Li

2016-01-02 15:49 GMT+08:00 Jeffrey Smith <whydoubt(a)gmail.com>: > For the builddep commands in http://wiki.winehq.org/Fedora to work as > intended, there needs to be a repository containing the source rpms. The > binary rpms do NOT provide the _build_ dependency information needed for the > builddep commands to do their job. > > Otherwise, the instructions need to be redone, as the builddep commands are > not really doing anything useful as things stand. Hi Jeffery, Thank you for caring it. I added builddep commands before we provide official builds on https://dl.winehq.org/wine-builds/ And I haven't tested it if the repo is added. Should we add the build dependency information in src.rpm ? -- Have a nice day! Zhenbo Li

Jan. 2, 2016

Fedora source packages

by Jeffrey Smith

For the builddep commands in http://wiki.winehq.org/Fedora to work as intended, there needs to be a repository containing the source rpms. The binary rpms do NOT provide the _build_ dependency information needed for the builddep commands to do their job. Otherwise, the instructions need to be redone, as the builddep commands are not really doing anything useful as things stand. Jeff

Jan. 2, 2016