Pre 5.1 Windows Nightlies


downloaded from:
Download Manager: FDM

I should try download again?, but the installer size :frowning_face: @GyrosGeier


I installed that build and got Simon Richter as the signer
Windows 10 sees the file size as 918,367KB


Thank you very much for the confirmation.
never happened like this with FDM, I will try again tomorrow.


Upload looks good to me. With the old server I’d have understood partial downloads while the upload was still going, but OpenStack only publishes files that have been completely transferred.


When was the changeover, I saw a runt file of the 686 build alone two days ago, which was replaced by the full sized pair later.
I have learned to do a sanity check on the file size before wasting a lot of bandwidth.

I will take a screenshot if I see it happen again.


Both servers get updated.

The old download server is often full, in which case the upload fails. If I notice (shows up in Jenkins) I might restart the upload stage, but that is a manual process.

Upload to the CERN service is a separate job so it is usually a few minutes later there, but OpenStack transfers files atomically, so any file that shows up on the CERN download server is complete.


A screenshot of a runt file today. The r12343 build is half sized:


You probably took the screenshot when the file was uploading to the repository.

Both versions (32 and 64 bit) are now available

kicad-r12343.ea84020b1-i686.exe 12-Feb-2019 23:18 942511624
kicad-r12343.ea84020b1-x86_64.exe 12-Feb-2019 23:20 940771816


Correct, that is what seems to have happened, but @GyrosGeier comment that any file showing on the server is complete is not always true


That is the old server, which shows files while they’re being scp’d, and even if they are incompletely transferred. :confused:

The link @Sujith posted is on CERN infrastructure, and that one has atomic transfers.


Thanks, I had not noticed that Firefox Top Sites was giving me the old server URL


Some new code was pushed in which affects the graphics in GAL. The purpose is to make graphics look good with antialiasing and in different zoom levels, for example so that in eeschema each line of the same width would have the same width in display, too. This affected pcbnew, too, so that at least one bug was found after the code was pushed. It would be good to test all possible graphics in KiCad’s editors before 5.1. (I found the mentioned bug by switching to “Show tracks in outline mode”.)


I finally got a chance to play around with win64 5.1.0-rc1-81-g27b4f2fbe (dated 2019-02-17 on the Cern server). I have to say the schematic looks good, I haven’t seen any uneven lines yet using Supersampling (2x). Trying the other antialiasing settings I noticed something interesting near junction dots at zoom 2.46. The antialiasing is confused by the green line coming from a green dot giving the line a tapered appearance. I’m not convinced that this is a big issue which is why I mention it here instead of on the bug tracker.

Here is the same region of a schematic with different antialiasing settings:

No Antialiasing

Subpixel Antialiasing (High quality):

Subpixel Antialiasing (Ultra quality):

Supersampling (2x):

Supersampling (4x):

My graphics processor is NVIDIA Quadro K2100M driver version

P.S. While checking my driver version in Device Manager I decided to click on update driver. Seems I got an update from wherever Windows automatically downloads drivers from. New version is I checked EESchema and see no difference to the above screenshots.


Wayne is going to tag 5.1 soon (this week):

As usual, the packages will be ready a bit later.


5.1 release was tagged in source repo. Libs/translation/docs will soon follow, we should hopefully see release packages appear in next week or two.


This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.