https://bugs.winehq.org/show_bug.cgi?id=6682
Artem S. Tashkinov <aros(a)gmx.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
URL|http://www.techspot.com/dow |https://web.archive.org/web
|nloads/299-irfanview.html#d |/20170711052934/https://www
|ownload_scroll |.irfanview.info/files/iview
| |444.zip
Resolution|--- |FIXED
--- Comment #74 from Artem S. Tashkinov <aros(a)gmx.com> ---
Can't reproduce in Wine 7.6, marking fixed.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=50629
Bug ID: 50629
Summary: Old links on https://www.winehq.org/forums
Product: WineHQ.org
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: www-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: jkfloris(a)dds.nl
Distribution: ---
Two old links on https://www.winehq.org/forums
1.
"Users might also want to visit the Wine area at Linux Forums"
has a link to http://www.linuxforums.org/forum/wine/linuxforums.org is offline since May 2020
2.
The wine-tests-results(a)winehq.org mailing list isn't used.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=39379
Bug ID: 39379
Summary: test.winehq.org: Show a specific test history for a
machine or platform
Product: WineHQ.org
Version: unspecified
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: www-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
Currently it's possible to see at a glance how specific test fared across Wine
commits and *all platforms*. For instance:
https://test.winehq.org/data/tests/advapi32:service.html
But if a platform has multiple test machines, one where the test has always
failed and another where it has just started failing, one cannot see when the
failures started on the above page.
So it would be nice to have a similar page on a per-platform basis; or one with
all the reports where that test failed regardless of platform.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=48164
Bug ID: 48164
Summary: test.winehq.org should provide an efficient way to
detect new failures
Product: WineHQ.org
Version: unspecified
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: www-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
Problem
-------
test.winehq.org does not allow performing the following tasks efficiently:
1. Detecting when a new failure slips past the TestBot.
One can detect new failures on the per test unit page when specific columns
turn red. But quite often the test unit already has failures so one has to look
at the specific number of failures. Furthermore many test units currently have
failures so this requires checking 80+ pages individually.
2. Detecting when the results on a VM degrade.
After upgrading a machine it's useful to compare it to its previous results.
But the results for each date are on separate pages. So again it's necessary
to check the per-test-unit result pages.
3. Comparing the results of two machines of different platforms.
For instance comparing the results of running Windows 8 to those of
Windows 10 on the same hardware.
Other things that got asked:
4. Sometimes it would be nice to have only the failures, and not all the lines
with skipped tests and todos.
5. In some cases it would also be nice to have pages with only the failures
that happen on TesBot VMs since these are usually easier to reproduce.
Jeremy's page
-------------
Jeremy's test summary page can help with some of that:
https://www.winehq.org/~jwhite/latest.html
But:
* It's not integrated with test.winehq.org which makes it hard to find.
* There are only two states: Success and Failed: So it does not help when a
test goes from having 2 failures to 4, or when it has a set of systematic
failures and a set of intermittent ones.
* The failed / success pattern is not per VM which masks some patterns and does
not help with point 2.
Proposal
--------
A modified version of Jeremy's page could be integrated with test.wnehq.org:
* It would actually be a pair of 'Failures' pages, one for TestBot VMs and one
for all test results. Both would be linked to from the top of the main index
page, for instance using the same type of 'prev | next' text links used on the
other pages.
* Jeremy's result matrix would be extended from three to four dimensions; test
units, test results, time, and number/type of failures.
* As before the results would be grouped per test unit in alphabetical order.
Only the test units having at least one error, recent or not, would be shown.
This could again be in the form of an array ('full report' pages on
test.winehq.org) or simply test unit titles (TestBot jobDetails page style)
with the information about each test unit inside. Clicking on the test unit
name would link to its 'test runs' page on test.winehq.org.
* For each test unit there would be one line per test result having errors. The
first part of the line would have one character per commit for the whole
history available on test.winehq.org. That character would indicate if the test
failed and more.
The second part of the line would be the test result platform and tag. They
would be sorted per platform and alphabetically.
* Each test result would get a one character code:
. Success
F Failure
C Crash
T Timeout
m Missing dll (foo=missing or other error code)
e Other dll error (foo=load error 1359 and equivalent)
_ No test (the test did not exist)
' ' No result (the machine did not run the tests that day)
* These codes would be shown using a monospace font so they would form a
pattern across time and test results:
.....F..F...F..F.mmm Win8 vm1
.....FFFFeFFFFFFeFFF Win8 vm1-ja
...TTCC Win8 vm2-new
......eF...F...F..F. Win10 vm3
* Each character would have a tooltip containing details like the meaning of
the letter, the number of failures, or the dll error message.
They would also link to the corresponding section of the test report.
* In addition to the character the background would be color coded to make
patterns more visible.
. Green
F Green to yellow to red gradient
C Dark red
T Purple/pink
m Cyan
e Dark blue
_ Light gray
' ' White
* The green-yellow-red gradient would be what allows detecting changes in the
number of test failures. That gradient must be consistent for all lines of a
given test unit's pattern.
Furthermore the gradient must not be computed based on the test result's
number of failures. That is, if a test unit has either 100 or 101 failures,
those must not have nearly indistinguishable colors. Instead the set of all
different failure counts for the test unit should be collected. Zero should be
added to that set. Then these values should be sorted and a color attributed
for each *index*. Then the background color is selected based on the index of
that result's failures count.
It is expected that each set will be relatively small so that the colors will
be reasonably far apart, making it easy to distinguish a shift from 4 to 6
failures even if there are 100 failures from time to time.
Also note hat adding zero to the set essentially reserves green for
successful results.
Implementation feasibility
--------------------------
* No changes in dissect.
* In gather, generate a new testunits.txt file containing one line per test
unit:
- The data source would be the per-report summary.txt files.
-> These don't indicate when a timeout has occurred so timeouts will appear
as F instead which is acceptable for a first implementation.
- The first line would contain a star followed by the tags of all the test
runs used to build the file:
- The other lines would contain the name of the test unit followed by
space-separated pairs of result code/failure count and result tag (including
the platform).
- A line would be put out even if the test unit had no failure.
For instance, the commit1 testunit.txt file could contain:
* win8_vm1 win8_vm1-ja win8_vm2-new win10_vm3
foo:bar 43 win8_vm1-ja C win8_vm2-new e win10_vm3
foo:bar2
- In the example above win8_vm1 only appears on the first line. This means
WineTest was run on that machine but had no failure at all.
- If the results for commit2 refer to a win8_vm4 machine, we will know that
the reason win8_vm4 does not appear in commit1 file is not because all the
tests succeeded, but because WineTest was not run on win8_vm4 for commit1. This
means that the result code for win8_vm4 for commit1 should be ' '. not '.' for
all test units.
- If commit2 has results for the foo:bar3 test unit, then we will know the
reason it is not present in the commit1 file is not because all the test runs
were successful, but because foo:bar3 did not exist yet. So its result code
would be '_', not '.'.
* Add a new build-failures script to generate both failures pages.
- This script will need to read the testunits.txt file for all the commits.
The simplest implementation will be to read all the data into memory before
generating the page. This will avoid having to deal with keeping the current
test unit synchronized between all of the testunits.txt files when a new test
unit has been added.
- The combined size of the testunits.txt files is expected to be reasonable,
within a factor of 3 of the summary.txt files. For reference, here is some data
about the sizes involved:
$ du -sh data
21G data
$ ls data/*/*/report | wc -l
2299
$ cat data/*/*/report | wc
34,087,987 231,694,407 2,104,860,095
$ cat data/*/*/report | egrep '(: Test failed:|: Test succeeded inside todo
block:|done [(]258)|Unhandled exception:)' | wc
567,158 6,275,504 53,202,999
$ cat data/*/summary.txt | wc
186,219 3,046,363 30,596,901
- Having a function to generate the page will allow calling it twice in a row
to generate both pages without having to load and parse the testunits.txt files
twice.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=51352
Bug ID: 51352
Summary: test.winehq.org should distinguish "too much data"
errors from others
Product: WineHQ.org
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: www-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
The new patterns page treats the "test printed too much data" failures like any
other. It would be better to use another symbol and color when there is no
other failure.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=52088
Bug ID: 52088
Summary: Update favicon to 32X32
Product: WineHQ.org
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: trivial
Priority: P2
Component: www-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: 2ndforwine(a)inmano.com
Distribution: ---
The 16x16 looks very blurry when compared to other web-sites.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=50630
Bug ID: 50630
Summary: Old link on https://www.winehq.org/news
Product: WineHQ.org
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: www-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: jkfloris(a)dds.nl
Distribution: ---
At the bottom of the page there is a link to
World Wine News Archive - https://www.winehq.org/wwn
The last "news" item is from 2017.
Maybe it is an idea to remove this link.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=50516
Bug ID: 50516
Summary: Broken link
'https://wiki.winehq.org/Useful_Registry_Keys'
Product: WineHQ.org
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: www-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: jose.relland(a)free.fr
Distribution: ---
Hi, thank you for your time.
I noted that the linnk:
"Wine Man Page" (at the bottom of the page) is broken.
Send to 404 page error.
Best 2021 year :)
José from France
--
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.