Hello everybody,

I just wanted to ask if the current version 2.2.1 already includes all the fixes done since the release of 2.2.0. The reason I am asking this is because I downloaded a very recent version of 'base_w32_v22.zip' from the FreePascal FTP server
(ftp://ftp.freepascal.org/pub/fpc/snapshot/fixes/i386-win32/) and I am almost certain that an issue reported as fixed in 2.2.1 (http://bugs.freepascal.org/view.php?id=9275) is still present. Running 'fpc -i' reports version 2.2.1 (2008/04/12), but the 'readme.rev' file reports revision 8445, which is really old.

Thanks in advance,
Yiannis.

Yiannis Dondos wrote

I just wanted to ask if the current version 2.2.1 already includes all the fixes done since the release of 2.2.0.

No, it doesn't.

The reason I am asking this is because I downloaded a very recent version of 'base_w32_v22.zip' from the FreePascal FTP server (ftp://ftp.freepascal.org/pub/fpc/snapshot/fixes/i386-win32/ ) and I am almost certain that an issue reported as fixed in 2.2.1 (http://bugs.freepascal.org/view.php?id=9275 ) is still present.

The fix for that bug report has been merged back however, as mentioned in the bug report's history.

Running 'fpc -i' reports version 2.2.1 (2008/04/12), but the 'readme.rev' file reports revision 8445, which is really old.

I don't know what's up with the Windows snapshots. The 2.3.1 one hasn't been updated at all in ages, and apparently the 2.2.1 one isn't properly updated either. It is probably indeed revision 8445, which would explain why that fix isn't in the binary you downloaded.

Jonas

Yiannis, sorry about that - my fault. It's been a known problem for a while that will get fixed soon, we hope.

I've mentioned the problem recently to Tomas, who 'owns' (or at least has fixed in past) the scripts that generate the fpc.zips (a few weeks ago). The v22 fpc.zip (in snapshots/ source/v22) that I use for the v22 go32v2 and win32 snapshots (and for the base*.zip files which are just the compiler & RTL) is stuck at r8445 and not tracking the latest v22 release(s) as it should.

Not sure whether it's same or related issue with v2.3.1 not getting updated by my daily snapshot script, it builds fine here!

Regards John

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

Fixed.

Jonas

Jonas Maebe wrote

don't know what's up with the Windows snapshots. The 2.3.1 one hasn't been updated at all in ages,

Actually, it seems this has been fixed in the mean time and they are being updated again.

Jonas

Well, I can't check the FTP site right now, but last night (as of Seattle) there was a fresh ZIP file named as 2.3.1 snapshot for Win32 from John's machine, but it only contained a readme.rev file (but a freshly generated one ;-) ).

I built a snapshot myself as a temporary workaround and uploaded it with undescore at the end of the name to make sure it wouldn't get overwritten by another empty ZIP file from John's machine.

BTW, while doing this, I noticed that some units were misplaced (located in the root of the ZIP files); something to be checked in 2.2.x before the release.

Tomas

.
.

I checked it now and there's indeed a complete snapshot generated from John's machine now. It might be still worth having a look at error checking in scripts used for snapshot building and uploading to make sure proper snapshots cannot get overwritten with an incomplete ZIP file (as it obviously happened there, not sure why).

Tomas

.
.

BTW, while doing this, I noticed that some units were misplaced (located in the root of the ZIP files); something to be checked in 2.2.x before the release.

Sorry, not root of ZIP file but root of units/i386-win32. Anyway, this seems to be specific to 2.3.x (at least as of now, i.e. unless this bit gets merged), because these units apparently belong to the new fpcres. I guess that they shouldn't be distributed at all as they are probably just needed for building the binary, so it looks like the "units=" section in utils/fpcres/Makefile.fpc should be preceded with "[clean]" (see e.g. utils/fpcm/Makefile.fpc). However, I'll leave a decision (and testing) up to somebody else (Giulio?).

Tomas

There are checks in script (eg that there are no make errors or zip errors) to ensure that only 'good' snapshots are uploaded, but guess they don't work 100% eg if there is a network funny, or PC crash or something else odd during the upload - I use pscp & check its error code.

Let me know if this happens too often & I'll try to improve checks /check that checks are working...

John
--------------

Seattle)

there was a fresh ZIP file named as 2.3.1 snapshot for Win32 from

John's

machine, but it only contained a readme.rev file (but a freshly

generated

one ;-) ).

.
.

I checked it now and there's indeed a complete snapshot generated from John's machine now. It might be still worth having a look at error checking in scripts used for snapshot building and uploading to make sure
proper snapshots cannot get overwritten with an incomplete ZIP file (as it
obviously happened there, not sure why).

Tomas

Tomas Hajny ha scritto:

You're right, here is the patch.
Could someone apply it to trunk?

bye
Giulio

Applied.

Michael.

It shouldn't have been network problem or PC crash because the ZIP file was not broken technically, it "just" didn't contain anything apart the readme.rev file. I assume that you add this file in another ZIP run (since the basic ZIP file is created by the make process), so maybe you could just check whether the ZIP file already existed before you run the ZIP command for adding readme.rev?

Tomas