On 2019-11-30 04:56-0000 Alistair Leslie-Hughes wrote:
Binary packages for various distributions will be available from: https://www.winehq.org/download
Summary since last release
- Rebased to current wine 4.21 (833 patches are applied to wine vanilla)
Upstreamed (Either directly from staging or fixed with a similar patch).
- none
Added:
- [47668] kernelbase: Improve stub for ReOpenFile and add small test
- [48138] League of Legends 9.23: Crash after champ select
- [47970] Legends of Runeterra crashes at launch
- [40334] AION - Wine /Unhandled exception: page fault on read access to
0x00000000 in 64-bit code (0x0000000000000000).
- [48175] AION (64 bit) - crashes in crysystem.dll.CryFree() due to high
memory pointers allocated
- [46568] 64-bit msxml6.dll from Microsoft Core XML Services 6.0 redist
package fails to load (Wine doesn't respect 44-bit user-mode VA limitation from Windows < 8.1)
Updated:
- d3d9-Direct3DShaderValidatorCreate9
- winecfg-Staging
[...]
Hi Alistair:
Could you explain how these patch numbers in your report are related with each other? For example, my initial assumption was the rebased patch number should be equal to the corresponding number in the last report plus the added patches in this report less the upstreamed patches in this report, i.e.,
r = r_old + a - u
where r and r_old are the current and last reported rebased patch numbers and a and u are the current added and upstreamed patch numbers.
But looking at the last several reports that formula predicts incorrect results with the rebased patch number changing in what looks like a completely arbitrary way from report to report compared to the prediction. So it appears the above formula is incorrect and/or incomplete.
Could you let me know what the correct formula is for predicting the rebased patch number from report to report (which helps to evaluate the reliability of the staging patch number statistics that you present), and if that formula depends on information (my guess is it is the number of patches in staging that have just been deleted by the staging maintainers because they judge those patches to not be worthwhile) that you currently do not include in your reports, could you include that important information in your following reports?
TIA.
Alan __________________________ Alan W. Irwin
Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________
Linux-powered Science __________________________
Le mercredi 04 décembre 2019 à 14:56 -0800, Alan W. Irwin a écrit :
On 2019-11-30 04:56-0000 Alistair Leslie-Hughes wrote:
Added:
- [47668] kernelbase: Improve stub for ReOpenFile and add small
test
- [48138] League of Legends 9.23: Crash after champ select
- [47970] Legends of Runeterra crashes at launch
- [40334] AION - Wine /Unhandled exception: page fault on read
access to 0x00000000 in 64-bit code (0x0000000000000000).
- [48175] AION (64 bit) - crashes in crysystem.dll.CryFree() due to
high memory pointers allocated
- [46568] 64-bit msxml6.dll from Microsoft Core XML Services 6.0
redist package fails to load (Wine doesn't respect 44-bit user-mode VA limitation from Windows < 8.1)
[...]
Could you explain how these patch numbers in your report are related with each other?
Hello,
The numbers between brackets are winehq.org bugzilla bug numbers.
For example, in "[47668] kernelbase: Improve stub for ReOpenFile and add small test", "47668" is the bug number that the patch "kernelbase: Improve stub for ReOpenFile" is accommodating. The referenced bug can be found at the URL: https://bugs.winehq.org/show_bug.cgi?id=47668
Regards.
On 2019-12-05 14:03+0100 Olivier F. R. Dierick wrote:
Le mercredi 04 décembre 2019 à 14:56 -0800, Alan W. Irwin a écrit :
On 2019-11-30 04:56-0000 Alistair Leslie-Hughes wrote:
Added:
- [47668] kernelbase: Improve stub for ReOpenFile and add small
[...]
Could you explain how these patch numbers in your report are related with each other?
Hello,
The numbers between brackets are winehq.org bugzilla bug numbers.
Hi Olivier:
Thanks for trying to be helpful, but your answer did not respond to the question which was about how to account for the total number of patches in each category mentioned in these reports.
To explain further, my curiosity about this question was stimulated by these staging "accounting" numbers from recent reports:
Version rebased upstreamed added updated predicted predicted-rebased T U A u P D
4.17 855 5 9 7 n/a n/a 4.18 850 1 1 3 855 5 4.19 840 8 1 1 843 3 4.20 832 8 1 3 833 1 4.21 833 0 6 2 838 5
I assume the "T" column is the total number of patches in staging, i.e., the report is only sent out when the rebasing work is completed, but could someone confirm that? I also assume U reduces the total number in staging by that number, A increases the total number in staging by that number, and u leaves the total number in staging unchanged. And I have used
P = T' - U - A
to calculate the predicted number of patches from one report to the next
and
D = P - T
to calculate the discrepancy between predicted and actual values where T' is taken from the previous report and T, U and A are taken from the current report.
In every case D is positive (P always greater than T) so I hypothesize there is another kind of patch category not currently mentioned in the report that explains this discrepancy (e.g., patches which the staging developers have removed from staging). Could someone please describe the true reason why D is always positive?
Furthermore, my view is it would be helpful if patch categories (deletions from staging or whatever) that are currently not mentioned in these reports should be mentioned in future reports.
Alan __________________________ Alan W. Irwin
Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________
Linux-powered Science __________________________
Hi Alan,
On 7/12/19 7:48 pm, Alan W. Irwin wrote:
On 2019-12-05 14:03+0100 Olivier F. R. Dierick wrote:
Version rebased upstreamed added updated predicted predicted-rebased T U A u P D
4.17 855 5 9 7 n/a n/a 4.18 850 1 1 3 855 5 4.19 840 8 1 1 843 3 4.20 832 8 1 3 833 1 4.21 833 0 6 2 838 5
These rebased number is the total number of patches applied to the current wine. The numbers aren't always going to add up as you expect, For example: we might disable a patchset from one version to another while we workout a regression or drop a patch(s) because they aren't correct or add patches to a patchset to increase functionally.
This release will have two patches listed as upstreamed but were actually part of the previous release since I initial disabled the patchset until I could verify that these patches were no longer required. Likewise we might drop/disable the remaining wusa patch since we are unable to verify whether is actually required anymore, which wont be listed in the release notes.
Regards Alistair.
On 2019-12-07 09:52-0000 Alistair Leslie-Hughes wrote:
Hi Alan,
On 7/12/19 7:48 pm, Alan W. Irwin wrote:
On 2019-12-05 14:03+0100 Olivier F. R. Dierick wrote:
Version rebased upstreamed added updated predicted predicted-rebased T U A u P D
4.17 855 5 9 7 n/a n/a 4.18 850 1 1 3 855 5 4.19 840 8 1 1 843 3 4.20 832 8 1 3 833 1 4.21 833 0 6 2 838 5
These rebased number is the total number of patches applied to the current wine. The numbers aren't always going to add up as you expect, For example: we might disable a patchset from one version to another while we workout a regression or drop a patch(s) because they aren't correct or add patches to a patchset to increase functionally.
This release will have two patches listed as upstreamed but were actually part of the previous release since I initial disabled the patchset until I could verify that these patches were no longer required. Likewise we might drop/disable the remaining wusa patch since we are unable to verify whether is actually required anymore, which wont be listed in the release notes.
Hi Alistair:
Thanks for answering my curiosity about these numbers in your reports.
Best wishes to you and the rest of the staging team with continuing your useful work.
Alan __________________________ Alan W. Irwin
Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________
Linux-powered Science __________________________
Le samedi 07 décembre 2019 à 00:48 -0800, Alan W. Irwin a écrit :
On 2019-12-05 14:03+0100 Olivier F. R. Dierick wrote:
Le mercredi 04 décembre 2019 à 14:56 -0800, Alan W. Irwin a écrit :
On 2019-11-30 04:56-0000 Alistair Leslie-Hughes wrote:
Added:
- [47668] kernelbase: Improve stub for ReOpenFile and add small
[...]
Could you explain how these patch numbers in your report are related with each other?
Hello,
The numbers between brackets are winehq.org bugzilla bug numbers.
Hi Olivier:
Thanks for trying to be helpful, but your answer did not respond to the question which was about how to account for the total number of patches in each category mentioned in these reports.
Hello,
Yes it did. The whole point is that you assume patch numbers where it is in fact patch sets referred to with bug numbers. That's why they don't account for the total number of patches.
That is enough information for you to know that your assumptions are wrong and do a bit of research.
You could have found that yourself had you put more effort into looking at the wine-staging code than into thinking out an over-complicated pointless formula.
Could you let me know what the correct formula is for predicting the rebased patch number from report to report (which helps to evaluate the reliability of the staging patch number statistics that you present), and if that formula depends on information (my guess is it is the number of patches in staging that have just been deleted by thestaging maintainers because they judge those patches to not be worthwhile) that you currently do not include in your reports, could you include that important information in your following reports?
What makes you think that the information in the report is not reliable? Have you anything against the staging maintainers?
You're the only one that want to make a formula out of the reports. We don't have to provide you the formula you seek or provide the "important" (to you; What makes it important?) information that formula would need.
Your whole 'predicting to evaluate the reliability of the report' thing is nonsense. Predicting the future number of patch from report statistics is pointless as the number of patches is determined by specific issues and development and there is no way to predict what will be done next, and it certainly doesn't depend on the previous changes.
To me, you're just making ground for an argument in a convoluted way.
Regards.
I think you are overcomplicating something that does not need to be.
The "Report" is somewhat trunkated. So are you kinda saying you would want a more detailed report on what patches and things that are changed? And that the report posted does not meet a proper standard? Probably a fair request, but i don't know what the real benefit would be unless you miss some important patchset that gets removed and breaks something the staging devs are not aware of - which do happen from time to time.
I guess the "best" way for you personally if you really want to get into stuff like that is to pay attention to the commit messages on GIT. None of us live in a perfect world, and i do not think it is overly easy (or informative for everyone) to make the report too detailed.
Sveinar
On 07.12.2019 09:48, Alan W. Irwin wrote:
On 2019-12-05 14:03+0100 Olivier F. R. Dierick wrote:
Le mercredi 04 décembre 2019 à 14:56 -0800, Alan W. Irwin a écrit :
On 2019-11-30 04:56-0000 Alistair Leslie-Hughes wrote:
Added:
- [47668] kernelbase: Improve stub for ReOpenFile and add small
[...]
Could you explain how these patch numbers in your report are related with each other?
Hello,
The numbers between brackets are winehq.org bugzilla bug numbers.
Hi Olivier:
Thanks for trying to be helpful, but your answer did not respond to the question which was about how to account for the total number of patches in each category mentioned in these reports.
To explain further, my curiosity about this question was stimulated by these staging "accounting" numbers from recent reports:
Version rebased upstreamed added updated predicted predicted-rebased T U A u P D
4.17 855 5 9 7 n/a n/a 4.18 850 1 1 3 855 5 4.19 840 8 1 1 843 3 4.20 832 8 1 3 833 1 4.21 833 0 6 2 838 5
I assume the "T" column is the total number of patches in staging, i.e., the report is only sent out when the rebasing work is completed, but could someone confirm that? I also assume U reduces the total number in staging by that number, A increases the total number in staging by that number, and u leaves the total number in staging unchanged. And I have used
P = T' - U - A
to calculate the predicted number of patches from one report to the next
and
D = P - T
to calculate the discrepancy between predicted and actual values where T' is taken from the previous report and T, U and A are taken from the current report.
In every case D is positive (P always greater than T) so I hypothesize there is another kind of patch category not currently mentioned in the report that explains this discrepancy (e.g., patches which the staging developers have removed from staging). Could someone please describe the true reason why D is always positive?
Furthermore, my view is it would be helpful if patch categories (deletions from staging or whatever) that are currently not mentioned in these reports should be mentioned in future reports.
Alan __________________________ Alan W. Irwin
Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________
Linux-powered Science __________________________
On 2019-12-07 19:36+0100 Sveinar Søpler wrote:
I think you are overcomplicating something that does not need to be.
Your statement is probably true, and thanks to you (and Alistair previously) for responding to my curiousity in a polite way. :-)
Alan __________________________ Alan W. Irwin
Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________
Linux-powered Science __________________________
On 12/4/19 4:56 PM, Alan W. Irwin wrote:
On 2019-11-30 04:56-0000 Alistair Leslie-Hughes wrote:
Binary packages for various distributions will be available from: https://www.winehq.org/download
Summary since last release
- Rebased to current wine 4.21 (833 patches are applied to wine vanilla)
Upstreamed (Either directly from staging or fixed with a similar patch).
- none
Added:
- [47668] kernelbase: Improve stub for ReOpenFile and add small test
- [48138] League of Legends 9.23: Crash after champ select
- [47970] Legends of Runeterra crashes at launch
- [40334] AION - Wine /Unhandled exception: page fault on read access to
0x00000000 in 64-bit code (0x0000000000000000).
- [48175] AION (64 bit) - crashes in crysystem.dll.CryFree() due to high
memory pointers allocated
- [46568] 64-bit msxml6.dll from Microsoft Core XML Services 6.0 redist
package fails to load (Wine doesn't respect 44-bit user-mode VA limitation from Windows < 8.1)
Updated:
- d3d9-Direct3DShaderValidatorCreate9
- winecfg-Staging
[...]
Hi Alistair:
Could you explain how these patch numbers in your report are related with each other? For example, my initial assumption was the rebased patch number should be equal to the corresponding number in the last report plus the added patches in this report less the upstreamed patches in this report, i.e.,
r = r_old + a - u
where r and r_old are the current and last reported rebased patch numbers and a and u are the current added and upstreamed patch numbers.
But looking at the last several reports that formula predicts incorrect results with the rebased patch number changing in what looks like a completely arbitrary way from report to report compared to the prediction. So it appears the above formula is incorrect and/or incomplete.
Could you let me know what the correct formula is for predicting the rebased patch number from report to report (which helps to evaluate the reliability of the staging patch number statistics that you present), and if that formula depends on information (my guess is it is the number of patches in staging that have just been deleted by the staging maintainers because they judge those patches to not be worthwhile) that you currently do not include in your reports, could you include that important information in your following reports?
In this case, I guess the confusion is caused by the fact that bugs 48175 and 46568 are addressed by the same patch set (viz. ntdll-ForceBottomUpAlloc). I suspect it may be better (or at least more consistent) to list the patch name first, followed by the bug(s) it addresses. We could also list the relevant bugs under the "updated" and "removed" sections.
TIA.
Alan __________________________ Alan W. Irwin
Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________
Linux-powered Science __________________________
On 12/5/19 9:57 AM, Zebediah Figura wrote:
On 12/4/19 4:56 PM, Alan W. Irwin wrote:
On 2019-11-30 04:56-0000 Alistair Leslie-Hughes wrote:
Binary packages for various distributions will be available from: https://www.winehq.org/download
Summary since last release
- Rebased to current wine 4.21 (833 patches are applied to wine vanilla)
Upstreamed (Either directly from staging or fixed with a similar patch).
- none
Added:
- [47668] kernelbase: Improve stub for ReOpenFile and add small test
- [48138] League of Legends 9.23: Crash after champ select
- [47970] Legends of Runeterra crashes at launch
- [40334] AION - Wine /Unhandled exception: page fault on read access to
0x00000000 in 64-bit code (0x0000000000000000).
- [48175] AION (64 bit) - crashes in crysystem.dll.CryFree() due to high
memory pointers allocated
- [46568] 64-bit msxml6.dll from Microsoft Core XML Services 6.0 redist
package fails to load (Wine doesn't respect 44-bit user-mode VA limitation from Windows < 8.1)
Updated:
- d3d9-Direct3DShaderValidatorCreate9
- winecfg-Staging
[...]
Hi Alistair:
Could you explain how these patch numbers in your report are related with each other? For example, my initial assumption was the rebased patch number should be equal to the corresponding number in the last report plus the added patches in this report less the upstreamed patches in this report, i.e.,
r = r_old + a - u
where r and r_old are the current and last reported rebased patch numbers and a and u are the current added and upstreamed patch numbers.
But looking at the last several reports that formula predicts incorrect results with the rebased patch number changing in what looks like a completely arbitrary way from report to report compared to the prediction. So it appears the above formula is incorrect and/or incomplete.
Could you let me know what the correct formula is for predicting the rebased patch number from report to report (which helps to evaluate the reliability of the staging patch number statistics that you present), and if that formula depends on information (my guess is it is the number of patches in staging that have just been deleted by the staging maintainers because they judge those patches to not be worthwhile) that you currently do not include in your reports, could you include that important information in your following reports?
In this case, I guess the confusion is caused by the fact that bugs 48175 and 46568 are addressed by the same patch set (viz. ntdll-ForceBottomUpAlloc). I suspect it may be better (or at least more consistent) to list the patch name first, followed by the bug(s) it addresses. We could also list the relevant bugs under the "updated" and "removed" sections.
The other cause for confusion, it occurs, is that 833 is the number of individual patches, but these are organized into series, and the latter are what are given symbolic names.
TIA.
Alan __________________________ Alan W. Irwin
Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________
Linux-powered Science __________________________
-
Alan W. Irwin -
Alistair Leslie-Hughes -
Olivier F. R. Dierick -
Sveinar Søpler -
Zebediah Figura