Re: wintrust(2/3): Remove a couple tests that fail on a variety of systems (try 2)
Juan Lang wrote:
This removes the unused variables in the last version. --Juan
------------------------------------------------------------------------
I think that these failures are also because of "not enough rights" (people running winetest as a normal user). So just removing them is probably not the best approach? -- Cheers, Paul.
Paul Vriens wrote:
Juan Lang wrote:
This removes the unused variables in the last version. --Juan
------------------------------------------------------------------------
I think that these failures are also because of "not enough rights" (people running winetest as a normal user). So just removing them is probably not the best approach?
Maybe it's not that there are not enough rights. The common denominator that I see is that all reports/boxes that produce these failures seems to be coming from one person (Ge). Maybe worthwhile checking with him before just removing the tests? -- Cheers, Paul.
I think that these failures are also because of "not enough rights" (people running winetest as a normal user). So just removing them is probably not the best approach?
Maybe it's not that there are not enough rights. The common denominator that I see is that all reports/boxes that produce these failures seems to be coming from one person (Ge). Maybe worthwhile checking with him before just removing the tests?
Perhaps. The last error didn't change in any of these tests, so I'm discinclined to believe it's a permissions issue. The only change was that on some systems the return value is FALSE, whereas on others it's TRUE. I don't think a test that says ok(ret == TRUE || ret == FALSE) is worth much, so I removed it. In general, I treat this Windows boxes as oracles: if they behave a certain way, then by definition that's allowed behavior. The only exception is when the behavior differs and is clearly broken on older machines. Since in this case, the failures are on relatively new machines as well, the tests appear to be flawed. Of course, if it's a misconfiguration, I'll reconsider. --Juan
Juan Lang wrote:
I think that these failures are also because of "not enough rights" (people running winetest as a normal user). So just removing them is probably not the best approach?
Maybe it's not that there are not enough rights. The common denominator that I see is that all reports/boxes that produce these failures seems to be coming from one person (Ge). Maybe worthwhile checking with him before just removing the tests?
Perhaps. The last error didn't change in any of these tests, so I'm discinclined to believe it's a permissions issue. The only change was that on some systems the return value is FALSE, whereas on others it's TRUE. I don't think a test that says ok(ret == TRUE || ret == FALSE) is worth much, so I removed it.
In general, I treat this Windows boxes as oracles: if they behave a certain way, then by definition that's allowed behavior. The only exception is when the behavior differs and is clearly broken on older machines. Since in this case, the failures are on relatively new machines as well, the tests appear to be flawed.
Of course, if it's a misconfiguration, I'll reconsider. --Juan
What we maybe need in the header of the report is more information: - The locale - The screen dimensions - Do we have admin rights (just brainstorming here). That would make it easier to decide if it's a misconfiguration or a real acceptable configuration. -- Cheers, Paul.
What we maybe need in the header of the report is more information:
- The locale - The screen dimensions - Do we have admin rights
(just brainstorming here).
That would make it easier to decide if it's a misconfiguration or a real acceptable configuration.
Maybe you're right. To that list I'd add the video driver, as the DirectX folks appear to have black-balled most video cards. --Juan
Juan Lang wrote:
What we maybe need in the header of the report is more information:
- The locale - The screen dimensions - Do we have admin rights
(just brainstorming here).
That would make it easier to decide if it's a misconfiguration or a real acceptable configuration.
Maybe you're right. To that list I'd add the video driver, as the DirectX folks appear to have black-balled most video cards. --Juan
Well all cards are fine as long as it's a NVIDIA :) -- Cheers, Paul.
2009/2/12 Paul Vriens <paul.vriens.wine(a)gmail.com>:
Juan Lang wrote:
I think that these failures are also because of "not enough rights" (people running winetest as a normal user). So just removing them is probably not the best approach?
Maybe it's not that there are not enough rights. The common denominator that I see is that all reports/boxes that produce these failures seems to be coming from one person (Ge). Maybe worthwhile checking with him before just removing the tests?
Perhaps. The last error didn't change in any of these tests, so I'm discinclined to believe it's a permissions issue. The only change was that on some systems the return value is FALSE, whereas on others it's TRUE. I don't think a test that says ok(ret == TRUE || ret == FALSE) is worth much, so I removed it.
In general, I treat this Windows boxes as oracles: if they behave a certain way, then by definition that's allowed behavior. The only exception is when the behavior differs and is clearly broken on older machines. Since in this case, the failures are on relatively new machines as well, the tests appear to be flawed.
Of course, if it's a misconfiguration, I'll reconsider. --Juan
What we maybe need in the header of the report is more information:
- The locale - The screen dimensions - Do we have admin rights
+1 - DPI setting - Installed theme (if any) - system metrics (font name & size, etc) -- this would be useful for those tests - installed versions of system components -- MSI; IE; .NET -- I know that these could probably be implied from DLL versions, but it can be difficult to find out what version of a DLL corresponds to IE6SP1 or whatever - Reece
Juan Lang wrote:
I think that these failures are also because of "not enough rights" (people running winetest as a normal user). So just removing them is probably not the best approach?
Maybe it's not that there are not enough rights. The common denominator that I see is that all reports/boxes that produce these failures seems to be coming from one person (Ge). Maybe worthwhile checking with him before just removing the tests?
Perhaps. The last error didn't change in any of these tests, so I'm discinclined to believe it's a permissions issue. The only change was that on some systems the return value is FALSE, whereas on others it's TRUE. I don't think a test that says ok(ret == TRUE || ret == FALSE) is worth much, so I removed it.
In general, I treat this Windows boxes as oracles: if they behave a certain way, then by definition that's allowed behavior. The only exception is when the behavior differs and is clearly broken on older machines. Since in this case, the failures are on relatively new machines as well, the tests appear to be flawed.
Of course, if it's a misconfiguration, I'll reconsider. --Juan
Ge confirmed that it's a non-administrator issue on all those boxes. I'll do some testing in the nearby future and will probably reintroduce those tests but with proper guarding for non-administrators. -- Cheers, Paul.
From: Paul Vriens [mailto:paul.vriens.wine(a)gmail.com]
Paul Vriens wrote:
Juan Lang wrote:
This removes the unused variables in the last version. --Juan
---
I think that these failures are also because of "not enough rights" (people running winetest as a normal user). So just removing them is probably not the best approach?
Maybe it's not that there are not enough rights. The common denominator that I see is that all reports/boxes that produce these failures seems to be coming from one person (Ge). Maybe worthwhile checking with him before just removing the tests?
All the failure cases on my machines are when running as non-Administrator. I've set up a number of boxes deliberately that way, but I'm starting to wonder if that is a good idea? For a whole bunch of tests (MSI comes to mind) the only sensible approach is to skip the test when running as non-Administrator, so it seems that I'm not actually adding new test runs in a different environment as I originally wanted to do. Gé.
participants (4)
-
Ge van Geldorp -
Juan Lang -
Paul Vriens -
Reece Dunn