[Fedora] Beta testers wanted - new nightly build packages

[aimylios]

Fedora provides the latest stable release of KiCad to its users, and updates are typically published within a couple of days after a new version has been released. But 5.1.x was branched off in March 2019, and since then a lot of new features have been merged to the KiCad development code base. This makes it more and more interesting to try out nightly builds.

The KiCad project already maintains a Copr repository for nightly builds. But the way the applications are packaged makes it impossible to install them in parallel to the stable KiCad release from the official Fedora repository. Users have to decide which one they want to use.

To make it easier for Fedora users to help testing the development version of KiCad, we are currently working on a new set of packaging scripts. It will allow to install the nightly build in parallel to the stable release and even to run both versions at the same time. As Fedora does not provide an easy mechanism to achieve this, we have to apply a couple of tricks similar to the ones used by the kicad-dev-nightly PPA for Ubuntu (which already supports this since quite some time).

To make sure that everything works as expected and we do not introduce any regressions, a lot of testing needs to be done. Therefore we are looking for volunteers who want to try out the new packages and give us feedback.

For the time being, I have set up a dedicated Copr repository. It is x86_64-only, but I can enable other architectures upon request.
https://copr.fedorainfracloud.org/coprs/aimylios/kicad-nightly-test/

If you have never used Copr before, you may first have to install the required dnf plugin:
dnf install dnf-plugins-core

Then the new repository must be enabled:
dnf copr enable aimylios/kicad-nightly-test

And the application can be installed:
dnf install kicad-nightly

Please note that this package does not bundle any of the libraries. But they are available as separate packages (kicad-nightly-templates, kicad-nightly-symbols, kicad-nightly-footprints, and kicad-nightly-packages3d), in case you need them.

Please leave your feedback here in this thread. We would like to hear if you are experiencing any issues installing the new package, and if all of the applications work as expected w/ and w/o having the stable KiCad package installed in parallel.

Disclaimer

Nightly development builds are untested, might be affected by serious bugs and/or produce files that are incompatible with the latest stable release. This can potentially lead to a corruption or even loss of data. Always take a backup of your projects before opening them with the applications from this package. I strongly recommend to take a look at this FAQ article before installing and using a nightly build:

Is it a good idea to use a nightly build version?

Short answer: If you have to ask, you should probably stick to the stable release. What are nightly builds? As the name implies, nightly builds are generated every night from the current master branch of the source repository. They are meant to allow a wider audience to more easily test new features. What are the dangers when using nightly builds? Nightly builds like all software have bugs. Because they have new not yet widely tested features you must expect a higher number of bugs. This inclu…

Known limitations

• File type associations

The nightly and the release package register the same file extensions. If you have both of them installed in parallel, your file manager will therefore not know which application to use to open KiCad files (*.pro, *.sch, *.kicad_pcb), and it may arbitrarily choose the one or the other. To be sure to always open a project with the desired version, I would recommend to directly launch the correct application and then use the File -> Open… menu entry.

• Python scripting

The Pcbnew Python scripting functionality works from within Pcbnew (i.e., Scripting Console and Action Plugins). It does not work out-of-the-box when launching a standalone Python interpreter. Executing “import pcbnew” will most likely lead to one of the following error messages:

ModuleNotFoundError: No module named ‘pcbnew’

ImportError: libkicad_3dsg.so.2.0.0: cannot open shared object file: No such file or directory

This can be worked around by setting the LD_LIBRARY_PATH and PYTHONPATH environment variables before launching the Python interpreter (or by applying some tricks from within your script before importing the pcbnew module). E.g., on Fedora 32:
export LD_LIBRARY_PATH=/usr/lib/kicad-nightly/lib64/:/usr/lib/kicad-nightly/lib/
export PYTHONPATH=/usr/lib/kicad-nightly/lib/python3.8/site-packages/

When the stable release is installed in parallel, “import pcbnew” will import the 5.1.x version of the Python bindings (because they are installed to the default path).

• Debugging

The commands to launch the nightly versions of the KiCad applications are kicad-nightly, eeschema-nightly, pcbnew-nightly, etc. But the binaries themselves are installed in a non-standard location (/usr/lib/kicad-nightly/bin/). So if you want to debug the applications or get a backtrace for a bug report, you will have to point the debugger to the binaries, e.g., “gdb /usr/lib/kicad-nightly/bin/kicad” instead of “gdb kicad-nightly”.

[hackvana]

10/10 for doing this.

I have been using the nightly builds from group_kicad-kicad. At nickoe’s suggestion, I just switched to aimylios:kicad-nightly-test. On loading my schematic, KiCad tells me that it must save it in a new format which is not backwards compatible. I see new .kicad_sch files instead of my old .sch files.

I think the need to go with the new format should be listed in the Known Limitations. It certainly means the stable release can’t be used side-by-side with the new nightly.

[craftyjon]

@hackvana

I think the need to go with the new format should be listed in the Known Limitations. It certainly means the stable release can’t be used side-by-side with the new nightly.

It is generally the case that the stable release and nightlies should not be used side-by-side on the same design files. This is independent of platform-specific packaging concerns. The goal of these packaging efforts is to make it possible to have both stable and nightly KiCad on the same system, and the fact that the nightlies may make incompatible changes to your files is not a limitation of Fedora (or any other distribution) packaing.

For anyone who plans on installing nightlies (on any operating system) and testing them, make sure to test them on copies you have made of your files. If you test them on the original files with no backup or version control, do not expect that you will be able to switch back and forth between nightly and stable on the same design files.

[hackvana]

I agree with what you’re saying, I just think we should let people know about it. Principle of least surprise!

[Rene_Poschl]

@hackvana

I think the need to go with the new format should be listed in the Known Limitations.

This was always the case see: Is it a good idea to use a nightly build version? (Long before the new file format there were differences in the pcb file format that made it impossible to open in current stable) Plus the new file format was announced here on the forum, on the mailing list and as a blog post. What else do you expect?

[eelik]

@Rene_Poschl

What else do you expect?

It wouldn’t of course hurt to have a disclaimer in the package description. It wouldn’t require anything from KiCad or KiCad project. The packager just adds some text.

[craftyjon]

A disclaimer is fine. Just wanted to clarify that it’s not a “known limitation” of Fedora packaging. In fact it’s not a limitation at all, but it is something to be cautious of.

[aimylios]

Thank you for testing, @hackvana. As far as I understand, you did not experience any packaging-related problems. This is a first valuable data point. In case you decide to keep the packages from my repository installed, please consider to report back again after some time.

Regarding the general problem of nightly development builds not being compatible with the latest stable release: The RPM itself includes a warning in its description, you just don’t get to see it when installing from command line as described above. And my initial post already included a link to @Rene_Poschl’s FAQ article about nightly builds, which I thought would be sufficient, but I’ve now added some explicit warnings here and in the description of the Copr repository. This should hopefully help to avoid any further confusion about the consequences of using the stable release and a development build in parallel.