Syslinux - Oct 2010 - Syslinux 4.03-pre4 - Release Candidate

Trying to get at least my backlog of bug fixes out... I'm hoping to do a
4.03 next week.  Please help by:

a) giving it a whirl;
b) letting me know if I have missed any low-risk bugfixes.

Gene: I did not include your UI branch in this release, because it made
me a bit nervous... poke me on IRC when you have a chance.

	-hpa

On 10/08/2010 06:31 PM, H. Peter Anvin wrote:
> b) letting me know if I have missed any low-risk bugfixes.
Missing fix for isohybrid about seek error. [#1]
[#1] http://syslinux.zytor.com/archives/2010-September/015319.html

-- 
Gerardo Exequiel Pozzi
\cos^2\alpha + \sin^2\alpha = 1

Op 20101008 om 14:31 schreef H. Peter Anvin:
> Trying to get at least my backlog of bug fixes out... I'm hoping to do
a
> 4.03 next week.  Please help by:
> 
> a) giving it a whirl;
> b) letting me know if I have missed any low-risk bugfixes.
14 september did send P J P <pj.pandit at yahoo.co.in>  a patch
against isohybrid.c, it is something about 64bit file offset
and "ftruncate()". I haven't seen that patch in commit patch list.



Stappers

On 10-10-08 23:31, H. Peter Anvin wrote:
> Trying to get at least my backlog of bug fixes out... I'm hoping to do
a
> 4.03 next week.  Please help by:
>
> a) giving it a whirl;
> b) letting me know if I have missed any low-risk bugfixes.
>
Hmmm, from small things in chain.c, in functions reading/writing 
sectors, two highest bits of the cylinder seem to not be set properly 
(during lba->chs conversion), basically:

-       inreg.ecx.b[0] = s + (c >> 6);
+       inreg.ecx.b[0] = ((c >> 2) & 0xc0u) | s;

git://git.hasevolq.net/syslinux.git masterdev

(I have this inside disklibdev branch too, although with other changes 
and stuff).

uOn Fri, Oct 8, 2010 at 17:31, H. Peter Anvin <hpa at zytor.com>
wrote:
> Trying to get at least my backlog of bug fixes out... I'm hoping to do
a
> 4.03 next week. ?Please help by:
>
> a) giving it a whirl;
> b) letting me know if I have missed any low-risk bugfixes.
>
> Gene: I did not include your UI branch in this release, because it made
> me a bit nervous... poke me on IRC when you have a chance.
I can understand being nervous about this considering the criticality
of the context.

The only thing I didn't consider immediately but thought of later is
creating a PM function to at least switch to using UI or DEFAULT and
possibly setting/correcting and then a COM32 module to use this
function.

(for reminder: my UI branch stored both UI and DEFAULT but would
switch from using UI to DEFAULT on certain guaranteed failure
conditions.  current behavior only uses UI if present, regardless of
failures).

-- 
-Gene