September 2011 - Wine-Devel

Re: Tests failing on OSX

by Stefan Dösinger

On Wednesday 21 September 2011 12:59:17 Francois Gouget wrote: > I guess there's no way to automatically authorize / sign the application? I think that would defeat the purpose of such a firewall.

Sept. 21, 2011

Re: IPv6 issue on TestBot?

by Francois Gouget

On Wed, 14 Sep 2011, Francois Gouget wrote: > > Connecting to https://testbot.winehq.org/ over IPv6 hangs for ages :-( > This makes accessing it from my desktop very annoying. Hmm, I guess I really have to use the feedback form on the website :-( -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.

Sept. 21, 2011

Re: Tests failing on OSX

by Francois Gouget

On Wed, 21 Sep 2011, Ken Thomases wrote: [...] > That sounds like Mac OS X's application firewall which is Apple's > primary firewall instead of a more traditional packet filtering > firewall. The application firewall is based around which local > applications and services are trusted to accept in-bound connections [...] > You can disable the application firewall in System Preferences > > Security > Firewall. Yes that's the one that brings up this dialog. For instance if I run ws2_32:sock with the firewall enabled I get asked whether I want to allow 'wineserver' (!) to accept incoming network connections. Interestingly if I don't answer and look into the firewall configuration after ws2_32_test.exe is done, I see that wineserver did got added with 'Block incomming connections'. So in the next run I am not asked that question again but then the connections are presumably really blocked. A related question is whether it is actually known to have an impact on the test results or not. Again, looking at the ws_32:sock results I saw no difference, even over multiple runs. Looking at the full results of a pair of runs on winetest.org the only difference I saw is an unrelated failure in d3d9:device. http://test.winehq.org/data/b6153354dd28c57fb1f92f85df1f1ba751794fc1/index_… Is what's saving us that the firewall always allows connections originating from the local IP address (e.g. 192.168.0.42 to 192.168.0.42)? Windows XP / Vista / 7 pop up similar dialogs and I don't know if they cause trouble either. I suspect not and this may be the reason why too. > Anyway, the application firewall is based on code-signing. The user's > permission to allow a program to accept incoming connections is tied > to the program's signature. [...] > Since regularly testing Wine entails constantly rebuilding it, the > signature never survives for long and the system asks for permission > with every new build. Exactly. So should the application firewall be causing trouble, the only solution would be to disable it :-( I guess there's no way to automatically authorize / sign the application? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ E-Voting: It's not the people who vote that count. It's the people who count the votes.

Sept. 21, 2011

Re: po: Update Russian translation

by Alexander Lakhin

I proposed such translation to replicate Windows xcopy behavior: Заменить C:\xcacls.exe [Yes (да)/No (нет)/All (все)]? IMO first way is not suitable for us (you have to input command with one keyboard layout (EN), and then switch to another (RU) just to answer the question). And I am afraid that "(да (Y)|нет (N))" is ambigous too, but if you prefer this way, I will make such corrections. I will add the indentation where you pointed, and if all the other my explications accepted, I'll make another patch. Best regards, Alexander 21.09.2011 13:47, Francois Gouget пишет: > On Wed, 21 Sep 2011, Nikolay Sivov wrote: > [...] >>> * "(Yes|No)" -> "(да|нет)" and "Y" -> "д" >>> This is used for languages where typing the translated strings >>> presents no special challenge. >>> >>> * "(Yes|No)" -> "(да (Y)|нет (N))" and "Y" -> "Y" >>> If typing the translated strings is cumbersome for some reason (but >>> I guess it's not the case here). >>> In truth this approach is mostly used for accelerators. I guess >>> that's because Alt cannot be combined with characters composed >>> through dead keys or special input methods, and also because it >>> avoids trouble with accelerator collisions in case two translations >>> start with the same letter (like if 'Yes' and 'No' both both >>> translated to words starting with 'C' for instance). >> I don't know what we use for other languages but I prefer second way. > They all went with the first way: > > po/sr_RS(a)cyrillic.po:msgid "%s? (Yes|No)\n" > po/sr_RS(a)cyrillic.po-msgstr "%s? (Да|Не)\n" > > po/da.po:msgid "%s? (Yes|No)\n" > po/da.po-msgstr "%s? (Ja|Nei)\n" > > po/de.po:msgid "%s? (Yes|No)\n" > po/de.po-msgstr "%s? (Ja|Nein)\n" > > po/fr.po:msgid "%s? (Yes|No)\n" > po/fr.po-msgstr "%s ? (Oui|Non)\n" > > po/it.po:msgid "%s? (Yes|No)\n" > po/it.po-msgstr "%s? (Sì|No)\n" > > po/ja.po:msgid "%s? (Yes|No)\n" > po/ja.po:msgstr "%s? (Yes|No)\n" !!! > > po/ko.po:msgid "%s? (Yes|No)\n" > po/ko.po-msgstr "%s? (예|아니오)\n" > > po/lt.po:msgid "%s? (Yes|No)\n" > po/lt.po-msgstr "%s? (Taip|Ne)\n" > > po/nb_NO.po:msgid "%s? (Yes|No)\n" > po/nb_NO.po-msgstr "%s? (Ja|Nei)\n" > > po/nl.po:msgid "%s? (Yes|No)\n" > po/nl.po-msgstr "%s? (Ja|Nee)\n" > > po/pl.po:msgid "%s? (Yes|No)\n" > po/pl.po-msgstr "%s? (Tak|Nie)\n" > > po/pt_BR.po:msgid "%s? (Yes|No)\n" > po/pt_BR.po-msgstr "%s? (Sim|Não)\n" > > po/sl.po:msgid "%s? (Yes|No)\n" > po/sl.po-msgstr "%s? (Da|Ne)\n" > > po/sr_RS(a)latin.po:msgid "%s? (Yes|No)\n" > po/sr_RS(a)latin.po-msgstr "%s? (Da|Ne)\n" > > po/sv.po:msgid "%s? (Yes|No)\n" > po/sv.po-msgstr "%s? (Ja|Nej)\n" > > >

Sept. 21, 2011

winetest: Missing test.avi and msrle.avi files

by Francois Gouget

Two Wine tests are skipping tests because they are missing avi test files: * quartz:avisplitter needs a test.avi file: http://source.winehq.org/git/wine.git/?a=history;f=dlls/quartz/tests/avispl… avisplitter.c:210: Tests skipped: Could not read test file "test.avi", skipping test * winmm:mmio needs an msrle.avi file: http://test.winehq.org/data/b6153354dd28c57fb1f92f85df1f1ba751794fc1/mac_fg… mmio.c:77: Tests skipped: msrle.avi file is missing, skipping the test Interestingly there is a test.avi file in the Wine source tree: dlls/qedit/tests/test.avi So where can one procure these test files? Should quartz:avisplitter automatically find qedit:test's test.avi file? Can the missing files be added to Wine? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.

Sept. 21, 2011

Re: po: Update Russian translation

by Francois Gouget

On Wed, 21 Sep 2011, Nikolay Sivov wrote: [...] > > * "(Yes|No)" -> "(да|нет)" and "Y" -> "д" > > This is used for languages where typing the translated strings > > presents no special challenge. > > > > * "(Yes|No)" -> "(да (Y)|нет (N))" and "Y" -> "Y" > > If typing the translated strings is cumbersome for some reason (but > > I guess it's not the case here). > > In truth this approach is mostly used for accelerators. I guess > > that's because Alt cannot be combined with characters composed > > through dead keys or special input methods, and also because it > > avoids trouble with accelerator collisions in case two translations > > start with the same letter (like if 'Yes' and 'No' both both > > translated to words starting with 'C' for instance). > I don't know what we use for other languages but I prefer second way. They all went with the first way: po/sr_RS(a)cyrillic.po:msgid "%s? (Yes|No)\n" po/sr_RS(a)cyrillic.po-msgstr "%s? (Да|Не)\n" po/da.po:msgid "%s? (Yes|No)\n" po/da.po-msgstr "%s? (Ja|Nei)\n" po/de.po:msgid "%s? (Yes|No)\n" po/de.po-msgstr "%s? (Ja|Nein)\n" po/fr.po:msgid "%s? (Yes|No)\n" po/fr.po-msgstr "%s ? (Oui|Non)\n" po/it.po:msgid "%s? (Yes|No)\n" po/it.po-msgstr "%s? (Sì|No)\n" po/ja.po:msgid "%s? (Yes|No)\n" po/ja.po:msgstr "%s? (Yes|No)\n" !!! po/ko.po:msgid "%s? (Yes|No)\n" po/ko.po-msgstr "%s? (예|아니오)\n" po/lt.po:msgid "%s? (Yes|No)\n" po/lt.po-msgstr "%s? (Taip|Ne)\n" po/nb_NO.po:msgid "%s? (Yes|No)\n" po/nb_NO.po-msgstr "%s? (Ja|Nei)\n" po/nl.po:msgid "%s? (Yes|No)\n" po/nl.po-msgstr "%s? (Ja|Nee)\n" po/pl.po:msgid "%s? (Yes|No)\n" po/pl.po-msgstr "%s? (Tak|Nie)\n" po/pt_BR.po:msgid "%s? (Yes|No)\n" po/pt_BR.po-msgstr "%s? (Sim|Não)\n" po/sl.po:msgid "%s? (Yes|No)\n" po/sl.po-msgstr "%s? (Da|Ne)\n" po/sr_RS(a)latin.po:msgid "%s? (Yes|No)\n" po/sr_RS(a)latin.po-msgstr "%s? (Da|Ne)\n" po/sv.po:msgid "%s? (Yes|No)\n" po/sv.po-msgstr "%s? (Ja|Nej)\n" -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.

Sept. 21, 2011

Remove the legalese from start.exe?

by Francois Gouget

Start has the following lines at the end of its usage message: "start.exe version 0.2 Copyright (C) 2003, Dan Kegel\n" "Start comes with ABSOLUTELY NO WARRANTY; for details run with /L option.\n" "This is free software, and you are welcome to redistribute it\n" "under certain conditions; run 'start /L' for details.\n" And also this resource: "start.exe version 0.2 Copyright (C) 2003, Dan Kegel\n" "This program is free software; you can redistribute it and/or\n" "modify it under the terms of the GNU Lesser Public License\n" "as published by the Free Software Foundation; either version 2.1\n" [...] "along with this program; if not, write to the Free Software\n" "Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.\n" "\n" "See the COPYING.LIB file for license information.\n" We also have another copy of this copyright notice in shell32 for the 'About Wine' dialog but without the 'start.exe' and 'COPYING.LIB' lines, and with 'This program' replaced with 'Wine'. One more copyright notice we have is this in msrle32.rc: "Wine MS-RLE video codec\n" "Copyright 2002 by Michael Guennewig" Now this is all legalese which is a pain to translate (weird vocabulary) and pretty scary too. And because of the small differences the copyright notice needs to be translated twice (though tools like Virtaal/Launchpad may notice the similarity and prefill a fuzzy translation). Also start.exe and msrle32.dll are the only ones to have these notices which seems pretty inconsistent. So what can we do to make this simpler? The simplest would be to remove all copyright notices from start.rc and msrle32.rc. (we would keep the ones in the source of course). I guess that would require Dan's and Michael's approval. The other options involve separating the strings that change from one tool to the next, from those that stay the same. This way the latter will only appear once in the PO file and thus need to be translated only once. The various parts can then trivially be concatenated when they are displayed. (unfortunately this does not help for the msrle32.rc case) For instance we could decide to only keep the 'COPYING.LIB' string and tack it to the end of the usage message. We could also make things more consistent by doing this in every tool. So in pseudo-code we would have something like this: /* Load the tool-specific usage message */ usage_message = load_string(IDS_USAGE); /* Load the generic copying.lib reference. This one is duplicated in * every tool but always the same. */ copying_reference = load_string(IDS_COPYING); /* Print both */ printf(usage_message); printf(copying_reference); Another option would be to reuse the exact same main copyright notice as in the About Wine dialog since we need to translate that anyway (I think it would work wrapping-wise). So the start.exe pseudo-code for showing the license would be something like this: /* Load the copyright notice header, that is: * start.exe version 0.2 Copyright (C) 2003, Dan Kegel * start.exe is part of Wine. */ notice_header = load_string(IDS_NOTICE_HEADER); /* Load the generic Wine copyright notice. Note that it * says 'Wine' like in the 'About Wine' dialog, not 'This program' * and would be the same in any other Wine tool: * Wine is free software; you can redistribute it and/or modify * ... */ notice_generic = load_string(IDS_NOTICE_GENERIC); /* Load the copyright notice trailer: * * See the COPYING.LIB file for license information. */ notice_trailer = load_string(IDS_NOTICE_TRAILER); /* Print all the parts together */ printf(notice_header); printf(notice_generic); printf(notice_trailer); -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY

Sept. 21, 2011

Re: po: Update Russian translation

by Nikolay Sivov

On 9/21/2011 12:39, Francois Gouget wrote: >> #: wordpad.rc:174 >> msgid "inch" >> msgstr "inch" > Based on your exchange with Nikolay Sivov it sounds like this could be > translated. Right, I just pointed out that used translation is reserved for decimetre in Russian, but I doubt it'll be much of confusion in this case because of dialogue function. Anyway I can't think of better one, commonly used way to mark inch is seconds sign like - 1/72", but it's not acceptable here. > #: xcopy.rc:35 > msgid "%s? (Yes|No)\n" > -msgstr "" > +msgstr "%s? (Yes (да)|No (нет))\n" > I believe this one is a bit ambiguous because it does not make it clear > whether to type 'Yes' or 'да' (only the first character counts as the > 'Yes key' anyway). My understanding is that the two standard ways to > deal with this are: > > * "(Yes|No)" -> "(да|нет)" and "Y" -> "д" > This is used for languages where typing the translated strings > presents no special challenge. > > * "(Yes|No)" -> "(да (Y)|нет (N))" and "Y" -> "Y" > If typing the translated strings is cumbersome for some reason (but > I guess it's not the case here). > In truth this approach is mostly used for accelerators. I guess > that's because Alt cannot be combined with characters composed > through dead keys or special input methods, and also because it > avoids trouble with accelerator collisions in case two translations > start with the same letter (like if 'Yes' and 'No' both both > translated to words starting with 'C' for instance). I don't know what we use for other languages but I prefer second way.

Sept. 21, 2011

Re: Tests failing on OSX

by Ken Thomases

On Sep 21, 2011, at 2:58 AM, Francois Gouget wrote: > Note also that the firewall will also ask whether to allow incoming > network access for some of the tests. I would really like information on > how to best deal with that. That sounds like Mac OS X's application firewall which is Apple's primary firewall instead of a more traditional packet filtering firewall. The application firewall is based around which local applications and services are trusted to accept in-bound connections rather than which external sources are trusted to deliver packets. From a security standpoint, I'm not sure that's a good approach, but it is what it is. For what it's worth, Mac OS X still has ipfw or, with Lion, PF, so you can enable/configure that and disable the application firewall, if you want. You can disable the application firewall in System Preferences > Security > Firewall. There's no built-in GUI for enabling or configuring the packet filtering firewall, so you have to use the command line or third-party tools. Anyway, the application firewall is based on code-signing. The user's permission to allow a program to accept incoming connections is tied to the program's signature. If a program wasn't code-signed by its vendor, then the system will ad-hoc sign it. If a program changes in a way that invalidates its signature, then the past permission is ignored and the system asks again. For ad-hoc-signed programs, just about any change will invalidate its signature. Since regularly testing Wine entails constantly rebuilding it, the signature never survives for long and the system asks for permission with every new build. Regards, Ken

Sept. 21, 2011

Re: po: Update Russian translation

by Francois Gouget

This email is likely to get mangled but the gist of it will hopefully survive. > -"Синтаксис:\tIF [NOT] EXIST файл команда\n" > +"Синтаксис: IF [NOT] EXIST файл команда\n" > "IF [NOT] \"строка1\"==\"строка2\" команда\n" > "IF [NOT] ERRORLEVEL число команда\n" I believe the last two lines should be indented. > +"[/I] Если конечный каталог отсутствует и копируется более одного файла,\n" > +"местом назначения считается каталог.\n" [...] > +"[/A] Копирует только файлы с атрибутом \"архивный\".\n" > +"[/M] Копирует только файлы с атрибутом \"архивный\",\n" > +"при этом очищает атрибут.\n" > +"[/D | /D:m-d-y] Копирует только новые файлы или файлы, измененные\n" > +"после указанной даты. Если дата не указана, заменяет все старые файлы\n" > +"существующими новыми.\n" This one too could use some extra indentation where the description wraps to the next line. Also it is missing an extra trailing '\n'. > #: wordpad.rc:174 > msgid "inch" > msgstr "inch" Based on your exchange with Nikolay Sivov it sounds like this could be translated. > #: cmd.rc:291 xcopy.rc:40 > msgctxt "Yes key" > msgid "Y" > msgstr "" [...same for 'No key'...] > #: xcopy.rc:35 > msgid "%s? (Yes|No)\n" > -msgstr "" > +msgstr "%s? (Yes (да)|No (нет))\n" I believe this one is a bit ambiguous because it does not make it clear whether to type 'Yes' or 'да' (only the first character counts as the 'Yes key' anyway). My understanding is that the two standard ways to deal with this are: * "(Yes|No)" -> "(да|нет)" and "Y" -> "д" This is used for languages where typing the translated strings presents no special challenge. * "(Yes|No)" -> "(да (Y)|нет (N))" and "Y" -> "Y" If typing the translated strings is cumbersome for some reason (but I guess it's not the case here). In truth this approach is mostly used for accelerators. I guess that's because Alt cannot be combined with characters composed through dead keys or special input methods, and also because it avoids trouble with accelerator collisions in case two translations start with the same letter (like if 'Yes' and 'No' both both translated to words starting with 'C' for instance). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Vote Electronique: Les gens qui votent ne décident rien. Ceux qui comptent les votes décident de tout.

Sept. 21, 2011

Re: [PATCH 1/9] cmd/tests: add tests for command line parsing

by Frédéric Delanoy

2011/9/20 Martin Wilck <mwilck(a)arcor.de>: > On 09/20/2011 01:24 AM, Frédéric Delanoy wrote: > >> You might want to do a single "@echo off" at the start of the .cmd file. >> Echoing every command in the .exp isn't very helpful: you don't want >> to replicate the .cmd contents in the .exp file. > > I did that on purpose. It makes figuring out problems *way* easier. I > hate counting lines in the .exp file just to see which test was failing. You don't need counting lines. Just put appropriate self-descriptive messages + short test (sub)sections Use echoing only for difficult cases. A shorter patch is easier to review and more auto-documenting. The .exp file is not there for replicating the .cmd file, otherwise the .cmd file wouldn't be needed in the first place... Ex: (testing echo command here, but valid for all other commands) (cmd) @echo off [this line is generally not needed, unless echo mode was previously activated] echo ... quoted strings ... echo 'single-quoted string' echo "double-quoted string" echo `backquoted string` echo ... another subsection ... ... (exp) ... quoted strings... 'single-quoted string' "double-quoted string" `backquoted string` ... another subsection ... > However, if that's a blocking point for getting the patches applied, it > will be no problem to change that. I'm not the one who commits patches, but they should be as concise as possible. See http://wiki.winehq.org/SubmittingPatches

Sept. 21, 2011

Re: [PATCH 2/9] cmd: use GetCommandline() rather than argv

by Frédéric Delanoy

On Tue, Sep 20, 2011 at 22:17, Martin Wilck <mwilck(a)arcor.de> wrote: > Hi Dan, > >> on my i7 machine, your patch series fails every time for me when run >> normally. Here's the log: > > Did you apply only this one, or also 3/9 which is supposed to fix the > test results? Frédéric already told me that I should have submitted the > patches in one. Not exactly. What I said it that you can't fix stuff in patch N and alter .exp in patch N+1, since that would make the test suite run with errors Ideally, what should be done is: Patch N .cmd add tests .exp expected results, potentially with some @todo_wine@ Patch N+1 Fix in .c/h files, and removal of @todo_wine@ in .exp Of course, test suite must run flawlessly after both patch N and N+1 This way you (read AJ) can be sure that there was a bug (patch N) and that patch N+1 fixed it Only if it's too difficult/not feasible to split into 2 patches (e.g. due to big deficiencies in the test runner, etc.) should you merge them, but that's generally not recommended Frédéric

Sept. 21, 2011

Re: Tests failing on OSX

by Francois Gouget

On Tue, 20 Sep 2011, Charles Davis wrote: > > On Sep 20, 2011, at 3:11 PM, Stefan Dösinger wrote: > >> gdi32/dc > >> user32/monitor > > No Xvidmode support, so Get/SetDeviceGammaRamp fail. There's a win_skip for > > that already. Should we change it to skip(), or ignore it until we have a > > quartz driver? > > User32/monitor also fails because it can't change the display mode. > Key words: "stock X11 server". XQuartz has much better support for > this. You should be using that. That's what I have been told too so I documented it there: http://wiki.winehq.org/ConformanceTests#MacOSX However XQuartz 2.6.3 (the latest) would systematically become 'non responsive' at some random point during the tests on my Leopard Mac Mini (GMA 950 graphics). So I downgraded to XQuartz 2.6.1 which at least lets me complete the WineTest run. [...] > >> mmdevapi/capture > > Various Set*Volume calls fail > I know that some CoreAudio devices actually don't have software volume > controls. Optical out, for example. For these devices, Set*Volume will > always fail. Not sure if that's what 's happening in your case, > though. My Mac Mini uses an optical audio connection and indeed I cannot set the volume on the Mac. Yet I have no failures in mmdevapi/capture (or in any other sound test for that matter). > >> ws2_32/sock > > A mixture of test failures and unexpected successes. > >From what I can tell, Wine's WinSock implementation seems to depend > >on several nuances of Linux's BSD sockets implementation that are > >different from the original 4.xBSD implementation (from which most > >others, including WinSock itself, are derived). That's my impression too given that it fails on Solaris and FreeBSD too (quite a paradox as that should be the original 'BSD sockets' <g>). Note also that the firewall will also ask whether to allow incoming network access for some of the tests. I would really like information on how to best deal with that. Also the OOB tests are not reliable at all, even on Windows, so this test won't be reliable anywhere until that's fixed: http://test.winehq.org/data/tests/ws2_32:sock.html -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ If you think the whole world revolves around you, quit staring at the GPS display while driving.

Sept. 21, 2011

Re: po: Update Russian translation

by Alexander Lakhin

Hello, Nikolay. 20.09.2011 23:00, Nikolay Sivov пишет: > On 9/20/2011 22:33, Alexander Lakhin wrote: >> English strings removed, partial translation fixed too. >> #: crypt32.rc:53 cryptdlg.rc:31 >> -#, fuzzy >> msgctxt "Certification Practice Statement" >> msgid "CPS" >> -msgstr "CPS" >> +msgstr "РУЦ" > What does that mean exactly? I didn't find such abbreviation anywhere. // // It means "Регламент Удостоверяющего центра" (http://www.infotrust.ru/data/Docs/InfoTrustCPS.pdf) >> #: jscript.rc:48 >> -#, fuzzy >> msgid "URI to be decoded is incorrect" >> msgstr "URI содержит неверные символы" > That's not a translation. Sorry, I haven't looked at jscript.rc and not seen that it contains two distinct strings IDS_URI_INVALID_CODING "URI to be decoded is incorrect" IDS_URI_INVALID_CHAR "URI to be encoded contains invalid characters" One for encodeURI and other for the decodeURI. So if it's needed to emphasize this, then I would translate both as: msgid "URI to be decoded is incorrect" msgstr "Декодируемый URI неверен" msgid "URI to be encoded contains invalid characters" msgstr "В кодируемом URI обнаружены неверные символы" In fact, this error occurs even when only one invalid character encountered, so maybe it's better to translate it as msgstr "В кодируемом URI обнаружен неверный символ" >> #: oleview.rc:114 >> msgid "Ask for an in-process handler when calling CoGetClassObject" >> msgstr "" >> +"Запросить использование обработчика \"в процессе\" при вызове " >> +"CoGetClassObject" > "Использовать" is better here IMO, you just don't say the way you > translated it. It seems that "Использовать обработчик" would be better if it doesn't substantially alter the original meaning. And now I think it doesn't. So I can shorten these strings. >> "\n" >> "Например:\n" >> " wineconsole cmd\n" >> -"Запустить командный процессор Wine в консоли Wine\n" >> +"Открывает командное приглашение Wine в консоли Wine.\n" >> "\n" > This was better before change. I just wanted to make the translation closer to the original: "Starts the Wine command prompt in a Wine console.\n" And I can't found any other mentions of "командный процессор" in the russian translation. > >> #: wordpad.rc:173 >> -#, fuzzy >> msgctxt "unit: inch" >> msgid "in" >> -msgstr "in" >> +msgstr "дм" > There's no common short name for inch AFAIK, "дм" is used for decimetre. I agree with you, but in this context it's used to parse size units, such as "12 pt", and I looked at the same function in Microsoft Wordpad (Формат, Абзац, Отступ). It accepts "пт" as points, and "дм" as inches. > >> #: wordpad.rc:175 >> -#, fuzzy >> msgctxt "unit: point" >> msgid "pt" >> -msgstr "pt" >> +msgstr "пт" > I'm not sure about this. > Best regards, Alexander

Sept. 21, 2011

Re: Tests failing on OSX

by Charles Davis

On Sep 20, 2011, at 3:11 PM, Stefan Dösinger wrote: >> gdi32/dc >> user32/monitor > No Xvidmode support, so Get/SetDeviceGammaRamp fail. There's a win_skip for > that already. Should we change it to skip(), or ignore it until we have a > quartz driver? > User32/monitor also fails because it can't change the display mode. Key words: "stock X11 server". XQuartz has much better support for this. You should be using that. > >> kernel32/change >> ntdll/change >> ntdll/directory > Lots of test failures. I'm not sure what those tests do tbh I wrote a message to the list about fixing those tests once. The problem is that the functionality they test (well, at least the */change tests) isn't implemented on Mac. And none of our options for implementing it look good (c.f. "Failing kernel32:change and ntdll:change tests on Mac OS"). > >> ntdll/exception > "Test failed: Execution of data memory succeeded." Do I have to do anything > special to enable NX support on OSX? No. It's just that the kernel for some reason only supports NX on stacks in 32-bit code. They fixed it in Mac OS 10.7. > >> mmdevapi/capture > Various Set*Volume calls fail I know that some CoreAudio devices actually don't have software volume controls. Optical out, for example. For these devices, Set*Volume will always fail. Not sure if that's what 's happening in your case, though. >> ws2_32/sock > A mixture of test failures and unexpected successes. >From what I can tell, Wine's WinSock implementation seems to depend on several nuances of Linux's BSD sockets implementation that are different from the original 4.xBSD implementation (from which most others, including WinSock itself, are derived). Hope that helps. Chip

Sept. 21, 2011

Re: [PATCH 2/9] cmd: use GetCommandline() rather than argv

by Martin Wilck

On 09/20/2011 09:52 PM, Dan Kegel wrote: > This happened even if I applied your whole series. But the log you posted can't be from the full series (tests are marked as @todo_wine@ which are solved after applying all patches). Could you please send me the output of wine cmd /c test_cmdline.cmd, with the whole series applied? > Oddly, everything was fine on my other machines, it was only the i7 > that detected a problem. What could that mean? My stuff is pretty elementary, how could that be CPU-dependent? What does warn+heap have to do with it? Martin

Sept. 20, 2011

Tests failing on OSX

by Stefan Dösinger

Hi, I'm attempting to set up a OSX testbot and I'm currently trying to get as many tests to work as possible. The following is a list of tests that fail currently. I'm hoping for comments if anybody knows more about them: (This is a 2006-era iMac, OSX 10.6, using the stock X server) > dinput8/device.c device.c:87: Test failed: We're not able to inject input into Windows dinput8 with events Fails sometimes, succeeds sometimes. > gdi32/dc > user32/monitor No Xvidmode support, so Get/SetDeviceGammaRamp fail. There's a win_skip for that already. Should we change it to skip(), or ignore it until we have a quartz driver? User32/monitor also fails because it can't change the display mode. > kernel32/change > ntdll/change > ntdll/directory Lots of test failures. I'm not sure what those tests do tbh > ntdll/exception "Test failed: Execution of data memory succeeded." Do I have to do anything special to enable NX support on OSX? > mmdevapi/capture Various Set*Volume calls fail > tests/shlexec Random failure: "shlexec.c:1023: test failed: Expected success (33), got failure (11), lpFile: C:\users\pts\Temp\wtb6bf.tmp\test file.shlexec" > urlmon/url > winmm/mci Test failed: mci resume waited Test failed: got 0001 instead of MCI_NOTIFY_xyz 0004 from command play (aborted by close) > ddraw/visual > d3d8/visual > d3d9/visual I'll investigate those. I bet they are GPU dependent. > ws2_32/sock A mixture of test failures and unexpected successes. > ddraw/d3d The window message test can't cope with the resolution change failure. I'll fix it. Using a virtual desktop works around the problem > ddraw/dsurface Crashes sometimes during cleanup in fbo-related GL calls. > d3dx9_36/math > d3dx9_36/texture I just sent patches for those. There was an issue with NaN sign bits and some GPU limitations the tests didn't account for.

Sept. 20, 2011

Re: [PATCH 1/9] cmd/tests: add tests for command line parsing

by Martin Wilck

On 09/20/2011 01:24 AM, Frédéric Delanoy wrote: > You might want to do a single "@echo off" at the start of the .cmd file. > Echoing every command in the .exp isn't very helpful: you don't want > to replicate the .cmd contents in the .exp file. I did that on purpose. It makes figuring out problems *way* easier. I hate counting lines in the .exp file just to see which test was failing. However, if that's a blocking point for getting the patches applied, it will be no problem to change that. Martin

Sept. 20, 2011

Re: [PATCH 2/9] cmd: use GetCommandline() rather than argv

by Martin Wilck

Hi Dan, > on my i7 machine, your patch series fails every time for me when run > normally. Here's the log: Did you apply only this one, or also 3/9 which is supposed to fix the test results? Frédéric already told me that I should have submitted the patches in one. Martin > > ]] ../../../tools/runtest -q -P wine -M cmd.exe -T ../../.. -p > cmd.exe_test.exe.so batch.c && touch batch.ok > ]] ... > ]] wine: cannot find L"C:\\windows\\system32\\tell;1;;2.exe" > ]] batch.c:301: Test succeeded inside todo block: unexpected char 0x0 > position -1 in line 50 (got '0 ', wanted '0(a)space@') > ]] batch.c:301: Test failed: unexpected char 0x65 position 0 in line > 53 (got 'error 9009', wanted '1(a)space@') > ]] batch.c:301: Test failed: unexpected char 0x65 position 0 in line > 59 (got 'error 9009', wanted '1(a)space@') > ]] batch.c:301: Test failed: unexpected char 0x65 position 0 in line > 62 (got 'error 9009', wanted '2(a)space@') > ]] batch.c:301: Test succeeded inside todo block: unexpected char 0x0 > position -1 in line 75 (got '"hi"', wanted '"hi"') > ]] batch.c:301: Test failed: unexpected char 0x65 position 0 in line > 78 (got 'error 9009', wanted '1(a)space@') > ]] batch.c:301: Test succeeded inside todo block: unexpected char 0x0 > position -1 in line 81 (got '"\"\\"\\\"\\\\" "\"\\"\\\"\\\\"', wanted > '"\"\\"\\\"\\\\"@space@"\"\\"\\\"\\\\"') > ]] batch.c:301: Test succeeded inside todo block: unexpected char 0x0 > position -1 in line 90 (got '1 ', wanted '1(a)space@') > ]] batch.c:301: Test succeeded inside todo block: unexpected char 0x0 > position -1 in line 93 (got '0 ', wanted '0(a)space@') > ]] batch.c:301: Test succeeded inside todo block: unexpected char 0x0 > position -1 in line 102 (got '3 ', wanted '3(a)space@') > ]] Command exited with non-zero status 10 > ]] make: *** [batch.ok] Error 10 > ]] make: Target `test' not remade because of errors. > > When run with WINEDEBUG=warn+heap, it passes. Not sure what to make of > that, but something's fishy, and the patch should not go in as is. > You might try valgrind to see if it turns anything up. > - Dan

Sept. 20, 2011

Re: [PATCH 1/2] include: add a generic class factory template

by Octavian Voicu

On Tue, Sep 20, 2011 at 4:05 PM, Bernhard Loos <bernhardloos(a)googlemail.com> wrote: > +# define __WINE_GENERIC_CF_DLL_MAIN_CONTENT \ > + return __WINE_PS_ENTRY(DllMain(hInstDll, fdwReason, lpv)); I think __WINE_PS_ENTRY needs only be applied to DllMain, not its argument, so second line should read: + return __WINE_PS_ENTRY(DllMain)(hInstDll, fdwReason, lpv); Octavian

Sept. 20, 2011

Re: [PATCH 2/9] cmd: use GetCommandline() rather than argv

by Dan Kegel

On Tue, Sep 20, 2011 at 1:17 PM, Martin Wilck <mwilck(a)arcor.de> wrote: >> on my i7 machine, your patch series fails every time for me when run >> normally. Here's the log: > > Did you apply only this one, or also 3/9 which is supposed to fix the > test results? Frédéric already told me that I should have submitted the > patches in one. This happened even if I applied your whole series. Oddly, everything was fine on my other machines, it was only the i7 that detected a problem. - Dan

Sept. 20, 2011

Re: Daily builds of latest Git now available as Ubuntu packages

by Qian Hong

On Wed, Sep 21, 2011 at 2:48 AM, Octavian Voicu <octavian.voicu(a)gmail.com> wrote: > > I'm guessing daily builds are done after daily commits, so you could > use the build id (which is just a prefix of the last commit id) from > here [1]. > > In your case, it's probably 9b729bb1b348 - 12-Sep-2011 15:45. > > Octavian > > [1] http://test.winehq.org/data/ > Thanks Octavian, this tip helps a lot. Thanks Austin all the same ;) -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/

Sept. 20, 2011

Re: po: Update Russian translation

by Nikolay Sivov

On 9/20/2011 22:33, Alexander Lakhin wrote: > English strings removed, partial translation fixed too. > #: crypt32.rc:53 cryptdlg.rc:31 > -#, fuzzy > msgctxt "Certification Practice Statement" > msgid "CPS" > -msgstr "CPS" > +msgstr "РУЦ" What does that mean exactly? I didn't find such abbreviation anywhere. > #: jscript.rc:48 > -#, fuzzy > msgid "URI to be decoded is incorrect" > msgstr "URI содержит неверные символы" That's not a translation. > #: oleview.rc:114 > msgid "Ask for an in-process handler when calling CoGetClassObject" > msgstr "" > +"Запросить использование обработчика \"в процессе\" при вызове " > +"CoGetClassObject" "Использовать" is better here IMO, you just don't say the way you translated it. > "\n" > "Например:\n" > " wineconsole cmd\n" > -"Запустить командный процессор Wine в консоли Wine\n" > +"Открывает командное приглашение Wine в консоли Wine.\n" > "\n" This was better before change. > #: wordpad.rc:173 > -#, fuzzy > msgctxt "unit: inch" > msgid "in" > -msgstr "in" > +msgstr "дм" There's no common short name for inch AFAIK, "дм" is used for decimetre. > #: wordpad.rc:175 > -#, fuzzy > msgctxt "unit: point" > msgid "pt" > -msgstr "pt" > +msgstr "пт" I'm not sure about this.

Sept. 20, 2011

Re: Daily builds of latest Git now available as Ubuntu packages

by Austin English

On Tue, Sep 20, 2011 at 11:48, Octavian Voicu <octavian.voicu(a)gmail.com> wrote: > On Tue, Sep 20, 2011 at 9:27 PM, Qian Hong <fracting(a)gmail.com> wrote: >> Is there any good ways to get the git-describe-like version number >> from the daily build ppa version number? >> That's useful while running a regression test. For example, I'd like >> to know exactly what is wine1.3_1.3.28+daily-20110912 >> in http://bugs.winehq.org/show_bug.cgi?id=28450 . > > I'm guessing daily builds are done after daily commits, so you could > use the build id (which is just a prefix of the last commit id) from > here [1]. > > In your case, it's probably 9b729bb1b348 - 12-Sep-2011 15:45. > > Octavian > > [1] http://test.winehq.org/data/ Or use 'git describe', which will also contain the wine version/number of commits since that version. E.g., today's is: wine-1.3.28-421-gb615335 and the sha1 hash is b6153354dd28c57fb1f92f85df1f1ba751794fc1. -- -Austin

Sept. 20, 2011

Re: Daily builds of latest Git now available as Ubuntu packages

by Octavian Voicu

On Tue, Sep 20, 2011 at 9:27 PM, Qian Hong <fracting(a)gmail.com> wrote: > Is there any good ways to get the git-describe-like version number > from the daily build ppa version number? > That's useful while running a regression test. For example, I'd like > to know exactly what is wine1.3_1.3.28+daily-20110912 > in http://bugs.winehq.org/show_bug.cgi?id=28450 . I'm guessing daily builds are done after daily commits, so you could use the build id (which is just a prefix of the last commit id) from here [1]. In your case, it's probably 9b729bb1b348 - 12-Sep-2011 15:45. Octavian [1] http://test.winehq.org/data/

Sept. 20, 2011