[wine-devel] Wine staging 4.21 release
z.figura12 at gmail.com
Thu Dec 5 09:57:24 CST 2019
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:
>> 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
>> *  kernelbase: Improve stub for ReOpenFile and add small test
>> *  League of Legends 9.23: Crash after champ select
>> *  Legends of Runeterra crashes at launch
>> *  AION - Wine /Unhandled exception: page fault on read access to
>> 0x00000000 in 64-bit code (0x0000000000000000).
>> *  AION (64 bit) - crashes in crysystem.dll.CryFree() due to high
>> memory pointers allocated
>> *  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)
>> * 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
> 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
> 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
More information about the wine-devel