August 2012 - Wine-Devel - list.winehq.org

Re: [1/16] po: Update Russian translation

by Francois Gouget

On Sat, 25 Aug 2012, Oleg Yarigin wrote: > >> I translated so because, I hope, "floppy disc" term is obsolete > >> nowadays (nobody has it). > >> > > This is not up to translator to alter a meaning of original text just > > cause some words in it are not > > used frequently enough these days than they used to. Note however that if a translator finds something wrong in the English string he is welcome to either send a patch to fix it (in the RC file and if pretty sure of the change), or raise the issue on wine-devel (if the change is more questionable). By doing so you not only improve your translation, but also the English version and all the other translations. And really, only the translators, by force, make a complete and thorough review of Wine's messages. So if they don't contribute fixes to the English version, nobody will. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ There are 10 types of people in the world... those who understand binary and those who don't.

Aug. 31, 2012

Re: kernel32: Return correct drive type for empty drives

by Erich E. Hoover

On Fri, Aug 31, 2012 at 9:59 AM, Francois Gouget <fgouget(a)codeweavers.com> wrote: > ... > I'm pretty sure others have things they'd like to see in the new > WineTestBot. Where can we keep track of those? If you're collecting a wish list then multiple network interfaces would be awesome, though I recognize that there is only a small number of tests that would be affected by it. Erich Hoover ehoover(a)mines.edu

Aug. 31, 2012

Re: kernel32: Return correct drive type for empty drives

by Francois Gouget

On Fri, 31 Aug 2012, GOUJON Alexandre wrote: [...] > Except the fact that I wasn't testing my patch the right way (I'm not very > proud of it), this also proved the TestBot is not very efficient regarding > volume tests. > So, I am proposing to add several virtual drives to some virtual machines. Is > it possible ? I can work on it if needed. > With genisomage and mkudffs, it's very easy to generate ISO files of different > kinds. > It won't be the same as with real discs and real drives but at least, it would > prevent some regressions.. > Any comment on this ? The existing WineTestBot infrastructure is going to be replaced soonish... hopefully. So it's unlikely that we'll change the VMs now. However we can certainly add some drives or even ISOs as we build the VMs of the new WineTestBot. You'd need to detail which configurations you're interested in. One thing to keep in mind is we should strive to test as much as possible in as few configurations as possible, especially for the base VMs (those that run every single test patch). But at the same time it should be possible to isolate the effect of one configuration change. I'm pretty sure others have things they'd like to see in the new WineTestBot. Where can we keep track of those? Should we add a WineTestBot product to Bugzilla? Should the WineHQ.org product be coopted? -- Francois Gouget <fgouget(a)codeweavers.com>

Aug. 31, 2012

Wine Gecko 1.8-beta1

by Jacek Caban

Hi all, It's time for another Gecko update. I've uploaded to SourceForge [1] new Gecko builds. These are based on Firefox 16 beta. Other than tons of changes inherited from Firefox and usual fixes to keep it working well for us, it brings a few visible fixes: - Proper <noscript> tag handling - Synchronous ActiveX loading - Possibility to properly call APIs requiring JSContext - Possibility to implement HTMLStyleElement::styleSheet property As usually, to test it you need the attached patch and Gecko build placed in the right place [2]. Any help with testing is appreciated! On related note, I seriously consider dropping debug builds and replace them by unstripped release build or even just a separated package containing only debug symbols for the release build. Here are my thoughts about reasoning (in random order): - People use debug build mostly to retrieve better backtraces. Unstripped builds also give that ability. - If someone really needs debug build, it's easy enough to build it himself (and that's usually a good idea anyway) - Debug builds are seriously different than release build, so it occasionally exposes different set of problems, leading to invalid assumptions. This is really something for developers rather than users. - It costs my time spent builds and tests. And I consider it a serious matter. Amount of work needed to keep Gecko relevant is constantly growing. I try to mitigate it by doing long-term improvements upstream, automating the process and improving my hardware, but that has its limits. And the time spent on Gecko maintenance (as in pure maintenance, not real improvements) costs Wine in terms of improvements I could make in this time. If someone has a reason to keep debug builds, let me know. Any comments are welcomed. Thanks, Jacek [1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/1.8-beta1/ [2] http://wiki.winehq.org/Gecko

Aug. 31, 2012

Re: kernel32: Return correct drive type for empty drives

by GOUJON Alexandre

On 08/29/2012 09:35 PM, Alexandre Julliard wrote: > Alexandre Goujon <ale.goujon(a)gmail.com> writes: > >> Should fix bug #17037 >> I followed your advice and now, I only ask the mountmgr when needed. >> --- >> dlls/kernel32/volume.c | 10 +++++++++- >> 1 file changed, 9 insertions(+), 1 deletion(-) > This is failing here when the drive is empty: > > ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so volume.c && touch volume.ok > volume.c:132: Tests skipped: can't test removing fake drive > volume.c:785: Test failed: IOCTL_DVD_READ_STRUCTURE (DvdPhysicalDescriptor) failed, last error = 87 > make: *** [volume.ok] Error 1 > > If I put a DVD in I get: > > volume.c:813: Test failed: IOCTL_DVD_READ_STRUCTURE should have failed > > Probably the tests need some fixing. > I worked on these issues and found that : + "make volume.ok" is different than "wine kernel32_test.exe.so volume" (WINETEST_PLATFORM=wine is set in the first command) + the error "volume.c:813: Test failed: IOCTL_DVD_READ_STRUCTURE should have failed" comes from a missing check. I fixed it with http://source.winehq.org/patches/data/89457. + the error "volume.c:785: Test failed: IOCTL_DVD_READ_STRUCTURE (DvdPhysicalDescriptor) failed, last error = 87" comes from ioctl() failing (errno = ENOMEDIUM), returning STATUS_INVALID_PARAMETER hence last error = 87 (ERROR_INVALID_PARAMETER). I fixed that with http://source.winehq.org/patches/data/89458. Except the fact that I wasn't testing my patch the right way (I'm not very proud of it), this also proved the TestBot is not very efficient regarding volume tests. So, I am proposing to add several virtual drives to some virtual machines. Is it possible ? I can work on it if needed. With genisomage and mkudffs, it's very easy to generate ISO files of different kinds. It won't be the same as with real discs and real drives but at least, it would prevent some regressions.. Any comment on this ?

Aug. 31, 2012

Wine Gecko 1.8-beta1

by Jacek Caban

Hi all, It's time for another Gecko update. I've uploaded to SourceForge [1] new Gecko builds. These are based on Firefox 16 beta. Other than tons of changes inherited from Firefox and usual fixes to keep it working well for us, it brings a few visible fixes: - Proper <noscript> tag handling - Synchronous ActiveX loading - Possibility to properly call APIs requiring JSContext - Possibility to implement HTMLStyleElement::styleSheet property As usually, to test it you need the attached patch and Gecko build placed in the right place [2]. Any help with testing is appreciated! On related note, I seriously consider dropping debug builds and replace them by unstripped release build or even just a separated package containing only debug symbols for the release build. Here are my thoughts about reasoning (in random order): - People use debug build mostly to retrieve better backtraces. Unstripped builds also give that ability. - If someone really needs debug build, it's easy enough to build it himself (and that's usually a good idea anyway) - Debug builds are seriously different than release build, so it occasionally exposes different set of problems, leading to invalid assumptions. This is really something for developers rather than users. - It costs my time spent builds and tests. And I consider it a serious matter. Amount of work needed to keep Gecko relevant is constantly growing. I try to mitigate it by doing long-term improvements upstream, automating the process and improving my hardware, but that has its limits. And the time spent on Gecko maintenance (as in pure maintenance, not real improvements) costs Wine in terms of improvements I could make in this time. If someone has a reason to keep debug builds, let me know. Any comments are welcomed. Thanks, Jacek [1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/1.8-beta1/ [2] http://wiki.winehq.org/Gecko

Aug. 31, 2012

Re: kernel32: Add UTF-7 support. (try 5)

by Alexandre Julliard

Alex Henrie <alexhenrie24(a)gmail.com> writes: > Try 5 adds two tests for the case where srclen < -1 and passes them both. You are still overflowing the source. You need to spend more time on this. You also need to split the patch, and write some sort of table-driven tests so you can test a lot more cases, the ones you have are clearly not sufficient. -- Alexandre Julliard julliard(a)winehq.org

Aug. 31, 2012

Re: Moving pages to/from wiki

by Alexandre Julliard

Michael Stefaniuc <mstefani(a)redhat.com> writes: > On 08/30/2012 06:05 PM, Jeremy Newman wrote: >> On 08/29/2012 09:32 PM, Kyle Auble wrote: >>> just checked http://cvs.winehq.org and sure enough, there is still a >>> very outdated CVS repository there, but I can't find a template or a PHP >>> applet for it, just the same links you found (most in WWN issues). I've >>> CCed Jeremy Newman because I'm guessing the site admin would have to >>> remove it. >> >> I am not opposed to removing it. We had left it up as a historical >> archive, or for people that were not ready to switch to GIT yet. If >> there is consensus then I can certainly take it down. > According to Alexandre it is used by http://source.winehq.org/ for the > "Wine Cross Reference". Actually that doesn't use CVS, it's using a static copy. It should really use git instead, but that's a different issue. -- Alexandre Julliard julliard(a)winehq.org

Aug. 31, 2012

Re: Moving pages to/from wiki

by Kyle Auble

Thu, Aug 30, 2012 12:23, Michael Stefaniuc wrote: > On 08/30/2012 06:05 PM, Jeremy Newman wrote: >> On 08/29/2012 09:32 PM, Kyle Auble wrote: >>> just checked http://cvs.winehq.org and sure enough, there is still a >>> very outdated CVS repository there, but I can't find a template or a PHP >>> applet for it, just the same links you found (most in WWN issues). I've >>> CCed Jeremy Newman because I'm guessing the site admin would have to >>> remove it. >> >> I am not opposed to removing it. We had left it up as a historical >> archive, or for people that were not ready to switch to GIT yet. If >> there is consensus then I can certainly take it down. > According to Alexandre it is used by http://source.winehq.org/ for the > "Wine Cross Reference". Ahhh, that certainly changes things. Does the server have to run a CVS instance to generate the web interface? If so, and if it's possible to somehow store the CVS data somewhere else, it might not hurt to consolidate it someday. That's really distant, low-priority stuff though. I'll remove the line from the WineHQ Todo list and make a note on the wiki SourceCode page so no one gets confused. - Kyle

Aug. 30, 2012

Re: Moving pages to/from wiki

by Kyle Auble

Thu, Aug 30, 2012 11:55, André Hentschel wrote: > Am 30.08.2012 04:32, schrieb Kyle Auble: >> As for redirecting to http://www.winehq.org/cvs, since that was designed >> as a notice page for people trying to browse the source code, I was >> picturing just redirecting the links to http://source.winehq.org/git and >> deleting http://www.winehq.org/cvs as only WWN issues and news would >> still have dangling links. I don't want to remove it if there's another >> reason for keeping it though. > please don't remove it. there's still much linking to it on the web, or hiding links, like in sourcecodes somewhere OK, sounds good. I'll leave the CVS notice pages but update the links. - Kyle

Aug. 30, 2012