January 2022 - Wine-Bugs - list.winehq.org

[Bug 16875] New: .NET 3.0: WIC installer fails due to bug(s) in setupapi.SetupGetTargetPathW
by wine-bugs＠winehq.org Oct. 12, 2022

Oct. 12, 2022

http://bugs.winehq.org/show_bug.cgi?id=16875 Summary: .NET 3.0: WIC installer fails due to bug(s) in setupapi.SetupGetTargetPathW Product: Wine Version: 1.1.12 Platform: Other URL: http://www.microsoft.com/downloads/details.aspx?FamilyID =10cc340b-f857-4a14-83f5-25634c3bf043 OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: setupapi AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, prerequisite: 1. clean WINEPREFIX 2. download .NET 3.0 Framework installer from: http://download.microsoft.com /download/4/d/a/4da3a5fa-ee6a-42b8-8bfa-ea5c4a458a7d/dotnetfx3setup.exe (sha1sum: a566bcd2ffffc3842a95adc57f7df3f8cd11577f) 3. export _SFX_CAB_SHUTDOWN_REQUEST=1 (workaround, see bug 9158) 4. wine ./dotnetfx3setup.exe It might take a while until all required packages are downloaded using BITS. Note: If you need to redo steps, backup the directory "dotnetfx304506.30" from "c:\\windows\\temp" to a different location, remove ~/.wine, copy "dotnetfx304506.30" again to "c:\\windows\\temp" to prevent BITS from downloading over and over again. After accepting EULA, the installer will exit due to error. "c:\\windows\\temp\\dd_dotnetfx3error.txt": --- snip --- ... [01/11/09,09:51:04] WIC Installer: [2] Error code 1603 for this component means "ERROR_INSTALL_FAILURE " [01/11/09,09:51:04] WIC Installer: [2] Setup Failed on component WIC Installer [01/11/09,09:51:12] WapUI: [2] DepCheck indicates WIC Installer is not installed. --- snip --- "c:\\windows\\temp\\dd_WIC.txt": --- snip --- [dd_WIC.txt] 0.082: ================================================================================ 0.084: 2009/01/11 09:51:04.229 (local) 0.084: C:\f93da2af7072de7f1485\update\update.exe (version 6.3.4.0) 0.085: Hotfix started with following command line: /quiet /norestart /log:C:\windows\temp\dd_WIC.txt 0.085: GetKernelType: GetInternalFilename failed 0.085: In Function GetBuildType, line 1170, RegOpenKeyEx failed with error 0x2 0.098: Unexpected Error While Executing Line 1 ( Test.WindowsCodecsVer.Section ) of PreRequisite 0.098: WIC Setup canceled. 0.098: Update.exe extended error code = 0xf00d 0.098: Update.exe return code was masked to 0x643 for MSI custom action compliance. --- snip --- Relevant trace log from WIC installer, run manually: --- snip --- ... 0023:Call setupapi.SetupFindFirstLineW(00148740,0033ba3c L"Test.WindowsCodecsVer.Section",00000000,0033b5e0) ret=0107ee9e 0023:trace:setupapi:SetupFindFirstLineW (0x148740,L"Test.WindowsCodecsVer.Section",(null)): returning 12/0 0023:Ret setupapi.SetupFindFirstLineW() retval=00000001 ret=0107ee9e 0023:Call setupapi.SetupFindNextLine(0033b5e0,0033b5d0) ret=0107eeb0 0023:Call KERNEL32.SetLastError(00000000) ret=6ead0fab 0023:Ret KERNEL32.SetLastError() retval=00000000 ret=6ead0fab 0023:Ret setupapi.SetupFindNextLine() retval=00000001 ret=0107eeb0 0023:Call setupapi.SetupGetStringFieldW(0033b5e0,00000000,0033b3a8,00000104,0033b190) ret=0107eaec 0023:Call KERNEL32.SetLastError(00000000) ret=6ead1ad4 0023:Ret KERNEL32.SetLastError() retval=00000000 ret=6ead1ad4 0023:trace:setupapi:SetupGetStringFieldW context 0x148740/0x148740/12/0 index 0 returning L"NotPresentOp" 0023:Ret setupapi.SetupGetStringFieldW() retval=00000001 ret=0107eaec .. 0023:Call setupapi.SetupGetStringFieldW(0033b5e0,00000001,0033b1a0,00000104,0033b190) ret=0107ec3b 0023:Call KERNEL32.SetLastError(00000000) ret=6ead1ad4 0023:Ret KERNEL32.SetLastError() retval=00000000 ret=6ead1ad4 0023:trace:setupapi:SetupGetStringFieldW context 0x148740/0x148740/12/0 index 1 returning L"CheckFilever" 0023:Ret setupapi.SetupGetStringFieldW() retval=00000001 ret=0107ec3b ... 0023:Call setupapi.SetupGetStringFieldW(0033b5e0,00000002,0033ae4c,00000104,0033a72c) ret=0107d377 0023:Call KERNEL32.SetLastError(00000000) ret=6ead1ad4 0023:Ret KERNEL32.SetLastError() retval=00000000 ret=6ead1ad4 0023:trace:setupapi:SetupGetStringFieldW context 0x148740/0x148740/12/0 index 2 returning L"CopyAlways.System32.Files" 0023:Ret setupapi.SetupGetStringFieldW() retval=00000001 ret=0107d377 0023:Call setupapi.SetupGetTargetPathW(00148740,00000000,0033ae4c L"CopyAlways.System32.Files",0033a730,00000104,0033a72c) ret=0107d3a9 0023:trace:setupapi:SetupGetTargetPathW 0x148740, (nil), L"CopyAlways.System32.Files", 0x33a730, 0x00000104, 0x33a72c 0023:Call KERNEL32.SetLastError(00000000) ret=6ead0de6 0023:Ret KERNEL32.SetLastError() retval=00000000 ret=6ead0de6 0023:trace:setupapi:SetupFindFirstLineW (0x148740,L"CopyAlways.System32.Files",(null)): returning 8/0 0023:trace:setupapi:SetupFindNextMatchLineW (0x148740,L"DestinationDirs",L"DefaultDestDir"): not found 0023:Call KERNEL32.SetLastError(e0000102) ret=6ead14bb 0023:Ret KERNEL32.SetLastError() retval=e0000102 ret=6ead14bb 0023:Ret setupapi.SetupGetTargetPathW() retval=00000000 ret=0107d3a9 0023:Call KERNEL32.GetLastError() ret=010701ae 0023:Ret KERNEL32.GetLastError() retval=e0000102 ret=010701ae --- snip --- Relevant snippet from: "update_winxp.inf" --- snip --- [Test.WindowsCodecsVer.Section] NotPresentOp=CheckFilever,CopyAlways.System32.Files,WindowsCodecs.dll ... [DestinationDirs] CopyAlways.System32.files=11 ; %windir%\system32 (don't delay until reboot) --- snip --- If you override updspapi.dll to native, you see the target path resolution working: --- snip --- 001b:CALL UPDSPAPI.UpdSpGetTargetPathW(0014e450,00000000,0033ae4c,0033a730,00000104,0033a72c) ret=0107d3a9 001b:Call ntdll.wcslen(0033ae4c L"CopyAlways.System32.Files") ret=0046a14c 001b:Ret ntdll.wcslen() retval=00000019 ret=0046a14c 001b:Call ntdll.RtlAllocateHeap(00110000,00000000,00000034) ret=0046a07b 001b:Ret ntdll.RtlAllocateHeap() retval=00151148 ret=0046a07b 001b:Call ntdll.wcscpy(00151148,0033ae4c L"CopyAlways.System32.Files") ret=0046a16b 001b:Ret ntdll.wcscpy() retval=00151148 ret=0046a16b 001b:Call msvcrt._abnormal_termination() ret=0046a186 001b:fixme:seh:_abnormal_termination (void)stub 001b:Ret msvcrt._abnormal_termination() retval=00000000 ret=0046a186 001b:Call KERNEL32.WaitForMultipleObjects(00000002,0014e6c4,00000000,ffffffff) ret=00457d36 001b:Ret KERNEL32.WaitForMultipleObjects() retval=00000001 ret=00457d36 001b:Call KERNEL32.lstrcpynW(0033a21c,00452804 L"DestinationDirs",000000ff) ret=00460f5b 001b:Ret KERNEL32.lstrcpynW() retval=0033a21c ret=00460f5b 001b:Call user32.CharLowerW(0033a21c L"DestinationDirs") ret=0046995a 001b:Ret user32.CharLowerW() retval=0033a21c ret=0046995a 001b:Call KERNEL32.CompareStringW(00000409,00000001,0033a21c L"destinationdirs",ffffffff,006516f0 L"destinationdirs",ffffffff) ret=00469a4b 001b:Ret KERNEL32.CompareStringW() retval=00000002 ret=00469a4b 001b:Call KERNEL32.lstrcpynW(0033a014,00151148 L"CopyAlways.System32.Files",000001ff) ret=00461002 001b:Ret KERNEL32.lstrcpynW() retval=0033a014 ret=00461002 001b:Call user32.CharLowerW(0033a014 L"CopyAlways.System32.Files") ret=0046995a 001b:Ret user32.CharLowerW() retval=0033a014 ret=0046995a 001b:Call KERNEL32.CompareStringW(00000409,00000001,0033a014 L"copyalways.system32.files",ffffffff,0066bd34 L"CLSID\\{22C21F93-7DDB-411C-9B17-C5B7BD064ABC}\\Containers",ffffffff) ret=00469a4b 001b:Ret KERNEL32.CompareStringW() retval=00000003 ret=00469a4b 001b:Call KERNEL32.CompareStringW(00000409,00000001,0033a014 L"copyalways.system32.files",ffffffff,00651714 L"copyalways.system32.files",ffffffff) ret=00469a4b 001b:Ret KERNEL32.CompareStringW() retval=00000002 ret=00469a4b 001b:Call ntdll.wcstoul(0065174c L"11",0033a1d4,0000000a) ret=0045d673 001b:Ret ntdll.wcstoul() retval=0000000b ret=0045d673 ... 001b:Call KERNEL32.lstrcpyW(0033a730,0033a4c8 L"C:\\windows\\system32") ret=0045e8e1 001b:Ret KERNEL32.lstrcpyW() retval=0033a730 ret=0045e8e1 001b:Call ntdll.RtlFreeHeap(00110000,00000000,00151148) ret=0046a0fd 001b:Ret ntdll.RtlFreeHeap() retval=00000001 ret=0046a0fd 001b:Call KERNEL32.SetLastError(00000000) ret=0045e909 001b:Ret KERNEL32.SetLastError() retval=00000000 ret=0045e909 001b:RET UPDSPAPI.UpdSpGetTargetPathW() retval=00000001 ret=0107d3a9 --- snip --- Well, actually there are more bugs in this API than this specific case. For instance the IE7 installer suffers from another bug in SetupGetTargetPathW API if you don't use Hans Leidekkers "iecustom" fake dll patch (http://bugs.winehq.org/show_bug.cgi?id=12690#c17) which just short-circuits/skips/hides various setupapi/updspapi deficencies (string tables, dynamic strings/replacements, target path resolution). Hint: "CheckFileVer" op with directory target (ex: "System32.Files") which is not present in "DestinationDirs" section and no default destination dir (-> fallback must be used). You can find many examples of such .inf files. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

2 11

[Bug 16328] New: GTA4 does not work under Wine
by wine-bugs＠winehq.org Oct. 12, 2022

Oct. 12, 2022

http://bugs.winehq.org/show_bug.cgi?id=16328 Summary: GTA4 does not work under Wine Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: advapi32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: zapolnov(a)gmail.com Created an attachment (id=17631) --> (http://bugs.winehq.org/attachment.cgi?id=17631) Wine Log When running GTA4 it calls some unimplemented function in advapi32.dll and crashes. Wine log is attached. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

2 225

[Bug 13656] New: Testout navigator does not dispaly menus or vodeo correctly
by wine-bugs＠winehq.org Oct. 12, 2022

Oct. 12, 2022

http://bugs.winehq.org/show_bug.cgi?id=13656 Summary: Testout navigator does not dispaly menus or vodeo correctly Product: Wine Version: 1.0-rc2 Platform: Other OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P3 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: keith_kw_muir(a)blueyonder.co.uk Testout navigator Starts but grey pane where the course video would play and the menu bar is empty. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

2 11

[Bug 48668] New: rFactor2 - Physics thread slower on multiplayer mode
by WineHQ Bugzilla Oct. 11, 2022

Oct. 11, 2022

https://bugs.winehq.org/show_bug.cgi?id=48668 Bug ID: 48668 Summary: rFactor2 - Physics thread slower on multiplayer mode Product: Wine Version: 5.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: alex.brrsclnt(a)gmail.com Distribution: Ubuntu Created attachment 66525 --> https://bugs.winehq.org/attachment.cgi?id=66525 Steam rfactor2 proton log This bug is created after the one that exists in the Proton github issue tracker https://github.com/ValveSoftware/Proton/issues/245 The game runs fine in single player mode since version 4.11 to the newest versions of Proton, but there is a problem in multiplayer mode that makes the game run slower. We have asked to the game devs in their discord server for some info, try to get some logs of the multiplayer execution, and finally, one dev told us that despite the graphics thread was fine, there is something wrong affecting to the physics thread in the game, and this only happens in online races, so the issue may be in the network code of Proton/Wine. (@leillo1975 tried to run the game in vanilla Wine, and the problem was also there). Is there any way to trace the network execution to find what could be the problem? I added a log file in the proton issue tracker generated running the game with the "PROTON_LOG=1 %command%" but don't know if that contains enough information. Let me know if I can add any other info. Thanks! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 38409] New: Wine Task Tray does is not in the taskbar KDE 5
by wine-bugs＠winehq.org Oct. 9, 2022

Oct. 9, 2022

https://bugs.winehq.org/show_bug.cgi?id=38409 Bug ID: 38409 Summary: Wine Task Tray does is not in the taskbar KDE 5 Product: Wine Version: 1.7.40 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: jack(a)emoss.org Distribution: --- The wine System Tray is not linked to the KDE desktop at all in KDE 5 but it worked fine in KDE 4. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 99

[Bug 17638] New: NOLF GotY: Sluggish mouse reaction when in zoom mode
by wine-bugs＠winehq.org Oct. 8, 2022

Oct. 8, 2022

http://bugs.winehq.org/show_bug.cgi?id=17638 Summary: NOLF GotY: Sluggish mouse reaction when in zoom mode Product: Wine Version: 1.1.16 Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: liquid.acid(a)gmx.net CC: jb.faq(a)gmx.de Mouse input in NOLF is generally a bit "inprecise", but one thing is broken for sure. Some weapons feature a zoom mode, but when this zoom mode is switched on it's almost impossible to accurately use it since the mouse input becomes very sluggish then. Turn zoom off again and mouse input stabilizes again. I suppose that's a dinput problem, but I'm not sure about that. The wine-0.9.46 testresult here (http://appdb.winehq.org/objectManager.php?sClass=version&iId=305&iTestingId…) mentions a "weird mouse problem", but I'm not sure if that's what I'm encountering. Haven't tried any native DLLs though. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

2 20

[Bug 31157] New: Filemaker Pro 12 Trial crashes
by wine-bugs＠winehq.org Oct. 7, 2022

Oct. 7, 2022

http://bugs.winehq.org/show_bug.cgi?id=31157 Bug #: 31157 Summary: Filemaker Pro 12 Trial crashes Product: Wine Version: 1.2.3 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: maikwagner(a)yahoo.com Classification: Unclassified Created attachment 40903 --> http://bugs.winehq.org/attachment.cgi?id=40903 Crash Output on Filemaker 12 I would like to report some issues with Filemaker 12 Trial which can be downloaded from Filemaker.com. The application installs okay and I can start "Filemaker 12" from the command line. When opening a sample solution (I selected "Invoices") the application crashes. I have attached my console output. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

2 36

[Bug 30666] New: MPEG movie does not play in Capitalism 2 demo
by wine-bugs＠winehq.org Oct. 7, 2022

Oct. 7, 2022

http://bugs.winehq.org/show_bug.cgi?id=30666 Bug #: 30666 Summary: MPEG movie does not play in Capitalism 2 demo Product: Wine Version: 1.5.4 Platform: x86 URL: http://www.cnwcentral.com/capitalism-2/demo.shtml OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winegstreamer AssignedTo: wine-bugs(a)winehq.org ReportedBy: jeremielapuree(a)yahoo.fr Classification: Unclassified Created attachment 40144 --> http://bugs.winehq.org/attachment.cgi?id=40144 console output While playing intro movie of Capitalism 2 demo, one can hear the sound, but video is playing. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

2 11

[Bug 48912] New: Allow blacklisting unreliable and always new failures
by WineHQ Bugzilla Oct. 6, 2022

Oct. 6, 2022

https://bugs.winehq.org/show_bug.cgi?id=48912 Bug ID: 48912 Summary: Allow blacklisting unreliable and always new failures Product: Wine-Testbot Version: unspecified Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: unknown Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- A number of tests produce false positives because: * Either the failure message contains a value that changes with each run (e.g. an HWND). In some cases these values are really necessary for diagnosis and moving them to a separate line would make the code quite a bit more complex. * Or the test fails intermittently and is hard to fix. Sometimes the cause of the failures may also come from external factors such as bugs in QEmu (for instance long execution delays causing timeouts). * Sometimes the intermittent failure is the product of a new Windows version or configuration, which requires investigating before a fix is found. In all cases the tests should be fixed eventually, but a solution is needed for the interim so these tests to not make the TestBot so unreliable that its results are ignored. So the goal is to provide a way to blacklist some test failures so they do not cause a patch to be rejected. Some safeguards are needed to ensure that: * Failures are not blacklisted lightly. The preference should always be to fix the test. * The blacklist does not get so large that it becomes hard to maintain. * Once a test is fixed the corresponding blacklist entries are removed in a timely fashion. * There is still an incentive to fix the tests. So here is a proposal for implementing this blacklist: * Each blacklist entry should be associated with a Wine bug describing the issue. That bug should provide some minimal diagnosis: whether it's a new Windows behavior, a race condition or some issue that was reported to QEmu. That would ensure we know why the blacklist entry was added. One could also check the status of the bug when reviewing the blacklist entries. A closed bug would be a strong hint that the blacklist entry is no longer needed. * Rather than blacklisting whole test units, blacklist entries should target specific test failures via a regular expression. Besides being finer grained this would be useful for cases like user32:win which has different issues depending on the locale and where each should be linked to a different bug (bugs 48815, 48819 and 48820). * The TestBot should record when each blacklist entry was last used. This relies on having the above regular expression since without it the TestBot would not know anything beyond 'the test unit was run and had failures'. Also the regular expression would only be used against *new* failures. So this would really record the last time the blacklist entry was actually useful. An entry that was unused for a long time would be a prime candidate for reviewing the corresponding bug and for removal. (Note: The blacklist would also be used on WineTest reports so it would get a chance of matching its target at least 5 days / week). * The blacklist entries would only be needed for 'base' test configurations since they are the only ones wine-devel patches run on. * There should be a page listing the blacklist entries so developers have a good starting point to work on them. * Ideally the blacklist page would also point to the tasks where the blacklist was last used. Since most of the blacklisted failures are either intermittent or specific to a given test configuration this would make it easier for developers to find reports where the failure did happen. Note that Wine VMs often test multiple configurations per task (e.g. wow32 and wow64, different locales), each producing its own test report. So pointing at just the task would leave the developer guessing which report should be looked at. But that may be sufficient guidance. * (test:unit, testbot-vm) tuples make it impossible to target a specific Wine test configuration such as a specific locale since they all run on the same VM. Similarly it would make blacklisting bitness-blind on Windows VMs. If necessary the tuple could be extended either with the specific mission the blacklist applies to, or with the basename of the corresponding report (the latter being easier to use in comparisons). Whether that's practical and worth the effort remains to be determined. One complication for instance is that this would lead to more blacklist entries: many 64 bit VMs would need two entries, one for 32 bit tests and one for 64 bit tests. * Pseudo database schema and sample use: FailureBlacklists ----------------- PK Bug 48815 PK TestModule user32 PK TestUnit win Name 0x738 message FailureRegExp Test failed: hwnd [0-9A-F]{8,16} message 0738 LastUse 2020-03-27 FailureBlacklistVMs ------------------- PK Bug 48815 PK TestModule user32 PK TestUnit win PK VMName Entries for w1064v1709, w1064v1809, etc. (48815, user32, win, w1064v1709) (48815, user32, win, w1064v1809) (48815, user32, win, w1064v1809_2scr) ... FailureBlacklistUses (optionally) --------------------------------- PK Bug PK TestModule PK TestUnit PK JobId PK StepNo PK TaskNo (48815, user32, win, 68507, 1, 7) (48815, user32, win, 68508, 1, 7) ... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 48209] New: Ignore random parts of test failure messages
by WineHQ Bugzilla Oct. 6, 2022

Oct. 6, 2022

https://bugs.winehq.org/show_bug.cgi?id=48209 Bug ID: 48209 Summary: Ignore random parts of test failure messages Product: Wine-Testbot Version: unspecified Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: unknown Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- The TestBot needs to detect if a patch introduces NEW test failures. To do so it compares the failure messages with those from reference WineTest runs. But in some cases part of the message changes from one run to the next, causing the failure to look new. Of course in all cases the ideal solution is to fix the test so it does not fail. Barring that there are also cases where the varying value is not really useful (e.g. handle or pointer values) and in that case it should just be removed from the message. But there may be cases where knowing the value is still useful. So one solution would be to tag such values so the TestBot knows it can ignore them when comparing failure messages. For instance they could be enclosed in double braces, curly braces, or other. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 5