KiCad5.1.9 on Debian buster (10)

Hello All

It appears the testing (Debian 11) distribution has frozen KiCad to 5.1.8.

What is the easiest way to get 5.1.9 for Debian buster (10.x)? I have been using testing backports up to now. I am open to compiling the source code, but I’d rather not if there is an easier way.

Maybe try sid (unstable) or wait for buster-backports to update? The maintainers are probably waiting on sid anyway.

https://packages.debian.org/sid/kicad

APT automatically (using #apt-get update && apt-get upgrade) updated my Kicad to 5.1.8 on Nov. 8th and to 5.1.9 on Jan. 5th. I am running Debian buster stable version.

BTW you can substitute apt for most uses of apt-get now.

How did that happen, Russ?

My sources.list:

deb http://ftp.debian.org/debian/ buster main contrib non-free
deb-src http://ftp.debian.org/debian/ buster main contrib non-free

buster-updates, previously known as ‘volatile’
deb http://ftp.debian.org/debian/ buster-updates main contrib non-free
deb-src http://ftp.debian.org/debian/ buster-updates main contrib non-free
deb http://security.debian.org/ buster/updates main contrib non-free
deb-src http://security.debian.org/ buster/updates main contrib non-free

In sources.list.d/buster-backports.list:

/etc/apt/sources.list.d/buster-backports.list
deb http://deb.debian.org/debian buster-backports main contrib non-free

Comment delimiters '#" have been removed.

I tried installing from sid, but received an error message relating to breaking one of the CC libraries.

No, john3, I was wrong about kicad binary updating on Jan 5th. That was kicad-symbols.
Leading # removed:
Jan. 5, 2021

 apt-get update && apt-get upgrade
Hit:1 http://deb.debian.org/debian buster InRelease
Get:2 http://security.debian.org buster/updates InRelease [65.4 kB]
Get:3 http://deb.debian.org/debian buster-updates InRelease [51.9 kB]
Get:4 http://deb.debian.org/debian buster-backports InRelease [46.7 kB]
Get:5 http://deb.debian.org/debian buster-backports/main amd64 Packages.diff/Index [27.8 kB]
Get:6 http://deb.debian.org/debian buster-backports/main i386 Packages.diff/Index [27.8 kB]
Get:7 http://deb.debian.org/debian buster-backports/contrib amd64 Packages.diff/Index [27.8 kB]
Get:8 http://deb.debian.org/debian buster-backports/contrib i386 Packages.diff/Index [27.8 kB]
Get:9 http://deb.debian.org/debian buster-backports/main amd64 Packages 2021-01-04-2001.00.pdiff [490 B]
Get:10 http://deb.debian.org/debian buster-backports/main amd64 Packages 2021-01-05-0200.55.pdiff [680 B]
Get:10 http://deb.debian.org/debian buster-backports/main amd64 Packages 2021-01-05-0200.55.pdiff [680 B]
Get:11 https://repository.solydxk.com solydxk-10 InRelease [19.8 kB] 
Get:12 http://deb.debian.org/debian buster-backports/main i386 Packages 2021-01-04-2001.00.pdiff [489 B]
Get:13 http://deb.debian.org/debian buster-backports/main i386 Packages 2021-01-05-0200.55.pdiff [681 B]
Get:14 http://deb.debian.org/debian buster-backports/contrib amd64 Packages 2021-01-04-2001.00.pdiff [176 B]
Get:13 http://deb.debian.org/debian buster-backports/main i386 Packages 2021-01-05-0200.55.pdiff [681 B]
Get:14 http://deb.debian.org/debian buster-backports/contrib amd64 Packages 2021-01-04-2001.00.pdiff [176 B]
Get:15 http://deb.debian.org/debian buster-backports/contrib i386 Packages 2021-01-04-2001.00.pdiff [174 B]
Get:15 http://deb.debian.org/debian buster-backports/contrib i386 Packages 2021-01-04-2001.00.pdiff [174 B]
Fetched 298 kB in 1s (212 kB/s)
Reading package lists... Done
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  gir1.2-javascriptcoregtk-4.0 gir1.2-webkit2-4.0 libjavascriptcoregtk-4.0-18 libwebkit2gtk-4.0-37 lightning
  linux-headers-amd64 linux-image-amd64 solydxk-keyring thunderbird
The following packages will be upgraded:
  kicad-symbols
1 upgraded, 0 newly installed, 0 to remove and 9 not upgraded.
Need to get 1,169 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://deb.debian.org/debian buster-backports/main amd64 kicad-symbols all 5.1.9-1~bpo10+1 [1,169 kB]
Fetched 1,169 kB in 0s (2,947 kB/s) 
(Reading database ... 296911 files and directories currently installed.)
Preparing to unpack .../kicad-symbols_5.1.9-1~bpo10+1_all.deb ...
Unpacking kicad-symbols (5.1.9-1~bpo10+1) over (5.1.7-1~bpo10+1) ...
Setting up kicad-symbols (5.1.9-1~bpo10+1) ...

My kicad executable is still 5.1.8.
My /etc/apt/sources.list:

deb https://repository.solydxk.com solydxk-10 main upstream import
deb http://deb.debian.org/debian buster main contrib non-free
deb http://security.debian.org buster/updates main contrib non-free
deb http://deb.debian.org/debian buster-updates main contrib non-free

My /etc/apt/sources.list.d/buster-backports.list

deb http://deb.debian.org/debian buster-backports main contrib non-free

I got the symbols update but nothing else, Russ. That’s why I wondered.

I guess I’m stuck with compiling the code.

If you succeed at compiling the code, I will want to know exactly how you did it.

One way would be to download the. SRC deb from Sid and build that on Buster which should tell you which dev packages to install to make the build work. But I haven’t done this or the analogous RPM build process for years.

Due problems while the migration to testing of the depending package opencascade KiCad 5.1.9 can’t migrate to testing since weeks for now. And as 5.1.9 isn’t in testing version 5.1.9 can’t get uploaded to buster-backports. That’s the long story short.

Providing 5.1.9 for backports is a simple merge of the packaging branch debian/sid into debian/buster with a final build within a buster chroot if someone want’s to do the built itself.

The reason why opencascade isn’t migrating to testing is related to issues on the OpenMPI package. So yes, these are effects of the freeze from Debian Bullseye that has started a few days ago.

OK Russ, It looks to be worth a try, but given what tijuca said (below) it might have to wait for some bug(s) in OpenMPI to be fixed. Nevertheless, it will be a good exercise.

After reviewing Chapter 1 of [this document],(https://www.mpi-forum.org/docs/mpi-3.1/mpi31-report.pdf) I still don’t understand why this higher level of abstraction called MPI is used in kicad. It seems to be a mechanism for standardizing state information among concurrently running processes. Unix has had a robust set of function calls for interprocess communications (IPC) since the days of Bell Labs. I thought these had been rewritten in linux. Perhaps kicad developers need a set of IPC function calls that are standardized among all three major operating systems, and this MPI 3.1 provides such a standard ? Or does it have to do with multiple cores on modern CPUs?

“Perhaps kicad developers need a set of IPC function calls that are standardized among all three major operating systems, and this MPI 3.1 provides such a standard ?”

While it is not my intention to speak for the development team, I suspect this is the issue.

You are overthinking it. Kicad uses OpenCascade for 3d stuff, it doesn’t use mpi directly. In fact kicad doesn’t do any IPC calls to my knowledge.

And Debian policy is Debian centralized packages must be used. KiCad cannot have its own opencascade build. This is both a pro and a con of using Debian.

Now if you want to escape the con here. There is a flatpak package available that will run on Debian https://kicad.org/download/flatpak/

Well, you can use own embedded software within Debian packages, but the general rule is to avoid such code copies if ever possible because from a security POV this is really something we don’t want to do. And integrate also opencascade within the KiCad package isn’t something I’d do.

The problem with the openmpi packages is not related to a direct or indirect dependency from KiCad. But other packages which depend on opencacade are also depending on openmpi and updating openmpi and opencascade would cause broken packages in testing.

If I install kicad 5.1.9 using that flatpak method, will it overwrite my kicad 5.1.8 from APT or install kicad under a different name ?
Would installing this flatpak cause any problemswith my Debian stable OS ? I ask because I know nothing about flatpak.

I do not have much love for “flatpak”, “appimage” and those other container like application boxes, but I also realize we’re living in a non ideal word which sometimes calls for compromises.

Flatpak should create it’s own environment, and therefore not influence other applications so it should do what you expect (concerning this).

However, I’m always wary for any application that circumvents normal package management.

Just for the record, KiCad 5.1.9-1 did migrate to testing right now. I’ll upload preparations fur a buster-backports version once I’m home again.

1 Like

On a new machine (x86-64) I installed Kicad from Buster-backports, which was 5.1.9 and it was slow on eeschema and pcbnew. Graphical lag often when dragging objects, or moving around the screen. Sometimes it would take 5-10 seconds to catch up. It was molasses. I uninstalled and went to buster stable (5.0.2) which works without any slowdown.

1 Like