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 __________________________