5.1.4 coming soon (5.1.3 got skipped because of a bug)


Wayne tagged 5.1.3 in the source code: https://lists.launchpad.net/kicad-developers/msg41661.html

Packages will come later; some Linux packages in PPA might be ready already.


Someone mentioned they couldn’t run 5.1.2 after upgrading Debian. A search came up empty. I’ve put off upgrading because of that. I seem to remember the issue was solved in 5.1.3. That ring a bell with anyone? I might want to do the Debian upgrade fight first before I try building and upgrading to 5.1.3.


I run Debian Buster, as does Wayne (on occasion). KiCad works fine under this OS.

I believe that the issue you are referencing is compiling KiCad under Debian Buster, which requires either using Clang or downgrading the libglm package. This requirement will be lifted soon as we move to C++14 that is required by the new libglm package.


Packages for Buster will be prepared once KiCad 5.1.3 has entered testing, as these packages will be new in the backports repo for Buster it will need to go through the NEW queue anyway first.
The same is true for the other additional packages (footprints, packages3d, symbols and templates) with an view on Buster.

As kicad-doc and -i18n isn’t tagged yet, I can’t fully prepare any KiCad upload into Debian currently.

And after that all I might have a look at stretch-backports. So nothing will recently happen. Some of the additional packages are uploaded to unstable just right now.


There has not been a pre 5.1.3 Windows build to test since 14th July, so the Windows release has the possibility of being broken.


Yeah. This was what I was thinking. I initially had to compile because the official version was ancient. I’ll probably run into some grief if I try and switch back to the packaged version. I always do. :wink:


There is a 5.1.3 tag in the git repo dated 23 Jul 2019, so I guess that means there should be some binaries available soon, yes ??

Where can I find the 5.1.3 release candidates? There’s nothing in the testing area.


Well, there is some nightly builds in the osx testing area - not sure why they are in testing - shouldn’t they just be in the nightly area?

Anyway, I will download a nightly build I guess. Hopefully a real 5.1.3 release will be available in the stable area soon :slight_smile:


Please see https://lists.launchpad.net/kicad-developers/msg41701.html


5.1.3 for ubuntu is already out. windows will need to wait till nick is back from vacation and has time to look at the documentation and translation stuff. (windows does package everything into one thing so everything must be ready to go before anything can be released. Linux or more precisely ubuntu has everything separate allowing for more freedom here.)


That is not fully correct, you mean the PPA from Jean-Samuel for sure here. The official Ubuntu packages for KiCad are pulled from Debian. Currently all additional packages except kicad and kicad-packages3d have already pulled into Ubuntu. But this all only for the current active development release.

The other part is correct, the PPA from Jean-Samuel and also the official KiCad packages are split into various packages for more flexibility. Also the versions from the PPA are always greater than the official packages so an upgrade path is always given.


The download page of kicad (for ubuntu) kind of implies that the ppa is the way to go. (I agree with that because waiting for debian is simply not worth it. They are just way too conservative for my taste. There is a reason i am normally under fedora.)


Well, the PPAs are still not official Ubuntu and also PPAs are “just” useful if people want something more actual than the latest tagged official version of Kicad. Clearly something for users that are really experienced and have the time to work between the various versions if needed.
For Debian I wont package any daily builds as this is the work not worth in my eyes and not the intention of Debian.

Debian isn’t more conservative than other distributions here, there are plans for something similar to PPAs for years. As some additional core infrastructure is needed to provide such an service and also some more work on DAK needs to b done this all wont happen in the next time.


That would assume the official distribution is the latest version. According to the kicad download page debian is on 5.0.2! (and that seems to be the ppa or do I read this wrong. The official is on 4.0.5 not even 4.0.7. Using debian seems like using stoneage tech.)

And the ubuntu page does not even mention any official repo. (so either the download page is out of date, the official package is so far behind as to not even deserve to be mentioned or it does not exist.)


Well, upgraded to Buster and my 5.1.2 refuses to run. sigh… I compiled it myself so I’ll just follow the instructions above to get a working copy back.

kicad: /usr/lib/x86_64-linux-gnu/libcurl.so.4: version CURL_OPENSSL_3' not found (required by kicad)>



The download page is manually written so it will always be lacking the current version as long nobody cares about that!. But for this there are package managers existing, they query the most recent versions from the archive. Nothing new and by the way the same technique Ubuntu has taken from Debian long ago. :smile:

Sorry but this is for me just trolling, if you don’t do any research on that before please don’t spread out such things into the world. I really would not expect to read such an posting from you! Thats not the culture of FOSS I expect here.

There is a tool called rmadison that will query all the available versions from archive.>

$ rmadison kicad
kicad | 0.20140622+bzr4027-3 | oldoldstable | source, amd64, armel, armhf, i386
kicad | 4.0.5+dfsg1-4 | oldstable | source, amd64, arm64, armel, armhf, i386, mips, mipsel, ppc64el
kicad | 4.0.7+dfsg1-1~bpo9+1 | stretch-backports | source, armel, mips, mipsel, ppc64el
kicad | 4.0.7+dfsg1-1~bpo9+1 | stretch-backports-debug | source
kicad | 5.0.2+dfsg1-1~bpo9+1 | stretch-backports | source, amd64, arm64, armhf, i386
kicad | 5.0.2+dfsg1-1~bpo9+1 | stretch-backports-debug | source
kicad | 5.0.2+dfsg1-1 | stable | source, amd64, arm64, armhf, i386
kicad | 5.0.2+dfsg1-1 | unstable | source
kicad | 5.1.2+dfsg1-1 | testing | source, amd64, arm64, armhf, i386
kicad | 5.1.2+dfsg1-1 | unstable | source, amd64, arm64, armhf, i386
kicad | 5.1.2+dfsg1-1 | unstable-debug | source

Seems to me your statement above isn’t true.

There is version 5.0.2 available for Stretch and also for Buster, yes that’s not the newest version. You might remember Debian has released Burster just a few weeks ago. Before the release can happen there is a freeze period and no newer versions are allowed into the targeted release at this time. So 5.1.2 has simply not made it into the Buster release, my question of uploading 5.1.2 into the Burster release was answered with a denying. As Testing did get also no 5.1.2 due this rule Stretch is currently also on version 5.0.2.

That’s simple is it.

Btw, I’m waiting for the tagging of -doc and -i18n for 5.1.3, all things are prepared so far on my side.


The JS PPAs are as official as it gets directly from the KiCad team, the bundled Linux packages in the Ubuntu etc repositories are usually WAY out of date


Only in backports repo which is not default and majority of users probably don’t know about. They just do apt-get show and that spits out 4.0.5, or at least it did on latest stable until Buster released. So Rene’s post is not inaccurate, just a bit outdated.


Pretty much agree. I just had to learn to use clang today (so far Kidad 5.1.3 is 55% built) because downgrading a package in Debian seems like an extremely bizarre concept. Having been a Mandrake user for years I wanted something stable so I ended up with Debian. Having done that I’m reminded why I went from Redhat to Mandrake. Then it was a tad different though. It was more about hardware support in those days and lagging might have been OK for server support but new hardware was a daily occurrence.


It looks like it won’t even build on Windows, see https://lists.launchpad.net/kicad-developers/msg41703.html


If you only need libglm then it’s as simple as downloading .deb from repo and dpkg -i libglm-dev_xx.deb.