KiCad 9 status

[nguyen-v]

Hi @set-soft, I'm just wondering what the status is with KiCad 9. Is it already mostly supported? Does it need to be modified according to the new IPC API? I'm currently making a workflow video tutorial with KiBot, so I'm wondering if I should wait for a bit longer for KiCad 9 to be fully supported before releasing it.

Thanks for your work!

[set-soft]

The dev branch is quite advanced.
I'm trying to run all tests, in the last run I detected two new KiCad issues:

• pcbnew print layers selection not memorized the File | Print dialog is always starting with all layers selected, so we always get all layers. This isn't important as the pcb_print output is the recommended method.
• Can't check schematic parity from command line (kicad-cli), always says "Schematic parity tests require a fully annotated schematic.". We can't check for PCB/SCH parity. Might be fixed, but I doubt it.

In addition to this we have the usual SCH problem: new format is NEVER documented. I catched a few changes, but more will pop-up as we test it. Lamentably was the same for all major the releases since v6.

We don't have support for the new features, I found you can now mark a whole hierarchy as "Do not fit" or similar. Things like that will take some time to be supported.

I think the above mentioned bugs will be fixed soon, as the previous 9 bugs that I reported.

[set-soft]

Does it need to be modified according to the new IPC API

This will be a very big (huge) issue, but for KiCad 10.
Currently is hard to test (you need the whole KiCad running) and I'm focusing on KiCad 9 release.
We'll need to push for a lot of additions in kicad-cli and the IPC API to keep the functionality.

[nguyen-v]

Great! Is there already a KiCad 9 docker available to test with?

[set-soft]

The following image contains the nightly KiCad snapshot:

ghcr.io/inti-cmnb/kicad_auto_test:nightly

These images contains 1.8.2, so you need to add the current dev code. Note that KiBot can be run "in-place", you can just checkout the repo and execute the src/kibot script, no need to install.

[set-soft]

Now we have dev images to test KiCad 9:

https://github.com/INTI-CMNB/kicad_auto_test/pkgs/container/kicad9_auto_full

The two bugs mentioned above are already fixed.

[nguyen-v]

Now we have dev images to test KiCad 9:

INTI-CMNB/kicad_auto_test/pkgs/container/kicad9_auto_full

The two bugs mentioned above are already fixed.

Thanks! Would using INTI-CMNB/KiBot@v2_dk9 work in CI/CD? I don't see it mentioned in the KiBot repo

[set-soft]

Nope, no GitHub Actions tags yet

[nguyen-v]

Thank you for the amazing work the past few days. Do you know when it will be available for testing?

[set-soft]

I tagged v2_dk9 and tried it using: https://github.com/set-soft/kibot_variants_arduprog_test
Which generates: https://set-soft.github.io/kibot_variants_arduprog_site/Browse/t1-navigate.html
Seems to be working ok, please report glitches

[nguyen-v]

Great, thanks! I'll test it and report any issue

[nguyen-v]

Otherwise I've tried running the KiCad 9 docker locally, it works great but I've encountered a small issue where mirror_text is not applied in PCB Print for some layers, might have to do with _get_user() in layer.py (I don't currently have time to investigate/try a minimal example so just a heads up). I think it needs to be set as UserMask && UserDefinedLayersMask

[set-soft]

You are right, the user defined layers (User.N) are not included in the UserMask (I wonder why).
To make things worst applying UserDefinedLayersMask doesn't work (you get all the possible layers upto User.45)
So I had to implement it in two steps, should work now.

[set-soft]

Now the images are using KiCad 9.0.0 release

[set-soft]

Now we have a stable release with basic KiCad 9 support, I know it generates some bogus warnings, but works

[montirafa]

Hi @set-soft, do we have more updates planned? I saw the last update was to 9.0.1, and KiCad is already at 9.0.3.

[set-soft]

I'll consider it. What is important in 9.0.3?

BTW: Debian currently has only 9.0.2.

[jorg-stor]

It would be nice to have the fix for lib_footprint_mismatch from 9.0.3, the issue came with 8.0.8.
"Do not trigger footprint does not match library errors when footprint has rule area on inner layers"
Seems 9.0.4 is about to be released now also.

[set-soft]

I recommend just disabling footprint comparison.

I'm testing 9.0.3, which seems to introduce some bugs.

9.0.4 isn't available for Debian, will take time before it gets ported.

[set-soft]

KiCad 9.0.3 and 9.0.4 has a major bug in the plotter:

https://gitlab.com/kicad/code/kicad/-/issues/21474

I won't bother in releasing images with it

[set-soft]

KiBot 1.8.5 was released and the docker images are using KiCad 9.0.6.

[nguyen-v]

Hi @set-soft, I'm just wondering what the status is with KiCad 9. Is it already mostly supported? Does it need to be modified according to the new IPC API? I'm currently making a workflow video tutorial with KiBot, so I'm wondering if I should wait for a bit longer for KiCad 9 to be fully supported before releasing it.

Thanks for your work!

I've uploaded the video for those that are interested
https://youtu.be/63R6Wnx44uY

[set-soft]

Hi @nguyen-v !
Did you try adding execute attribute to the bash scripts and then commit them? This should work and avoid the need to do it after checkout

[set-soft]

Looking at the scripts and workflows: I see one detail you are dealing with, that is not covered by KiBot, is the CHANGELOG.md maintained as a "keep-a-changelog" file.
You have two scripts:

• kibot_resources/scripts/get_changelog.py
• kibot_resources/scripts/get_changelog_version.py

And you invoke a couple of actions:

• ffurrer2/extract-release-notes@v2 (really used?)
• thomaseizinger/keep-a-changelog-new-release@v2

I think all of them could be benefited be: keepachangelog

This is around 30 kB of Python code without extra dependencies.

I mention this because I would like to evaluate if your project could also support GitLab CI/CD, so reducing the use of actions might help.

[nguyen-v]

Hi @nguyen-v ! Did you try adding execute attribute to the bash scripts and then commit them? This should work and avoid the need to do it after checkout

Thanks! Just added that.

Looking at the scripts and workflows: I see one detail you are dealing with, that is not covered by KiBot, is the CHANGELOG.md maintained as a "keep-a-changelog" file. You have two scripts:

* kibot_resources/scripts/get_changelog.py

* kibot_resources/scripts/get_changelog_version.py

And you invoke a couple of actions:

* ffurrer2/extract-release-notes@v2  (really used?)

* thomaseizinger/keep-a-changelog-new-release@v2

I think all of them could be benefited be: keepachangelog

This is around 30 kB of Python code without extra dependencies.

I mention this because I would like to evaluate if your project could also support GitLab CI/CD, so reducing the use of actions might help.

The python package looks interesting, but I dont know how easy or hard it would be to replace the actions and scripts with it

[set-soft]

Is very easy, I made it work, but I also patched the CLI tool, so it can be used directly.
While playing with it I saw your workflow can be simplified.
One complex thing is the need to switch to main for a release.
And I also see a problem: the tag and the actual release are different.
What about this:

1. The user always commits to dev, never to main
2. When the user wants a release s/he tags dev using semantic version
3. The workflow checkouts main, merges changes from dev, generates the final release files, commits to main, creates a tag release_VERSION and generates an actual release

So you don't need to change to main, or create pull requests, or even go back to dev, you always work on dev and the workflow will keep main clean and contain the release state.

[set-soft]

KiCad 9 images now uses 9.0.7