Some footprint libraries not found anymore

[sietseachterop]

Since a few days about half of the footprint libraries (e.g. in the standard location /usr/share/kicad/modules) are not found anymore!
E.g. the directory Package_DFN_QFN.pretty is there, and IS filled with the libraries, as always.
But in the footprint editor the directory entry is there, but it seems empty.

I am using Kicad 5.1.9+dfsg1-1 from the Debian testing x86_64 distribution.
It could be something in testing, but I doubt it.
Why are half of the directories seem empty all of a sudden?

Thanks in advance,
Sietse

[sietseachterop]

Very weird!
If I remove/rename the Package_DFN_QFN.pretty directory and start the footprint editor, it complains about it,
but ALL other directories are accessible again!
If I then put that directory back and start the footprint editor again (from within the Kicad session) it also is available,
so everything works!

But, if I exit Kicad, and start it again, the problem comes back!!
So with the above hack I can work, but what’s up?

Sietse

[paulvdh]

KiCad V5.1.9 is the normal stable KiCad version. That it is in “debian testing” is nothing remarkable. For a long time (years) development in KiCad is done in version V5.99 (soon to become V6.0-rc1) and incremental changes in V5.1.x are just bug fixes.

Is your problem related to that specific library, or does it also happen if you change one of the other directories?

Just to be sure: Have you run an integrity check on your file system, just to exclude possible problems on that side?

[sietseachterop]

Thanks for the reply.
No, removing any (standard) directory (working or not) gets me this result.

But I found a solution. I removed ~/.config/kicad and started with a clean slate on my account.
Everything is working again.
I used kicad on this PC for a few years, starting with a Kicad-4 design, but nothing special.

Sietse

[paulvdh]

Removing the common configuration is indeed a trick that can solve a bunch of install issues.

For the next time:
Don’t just delete such directories, but just rename them. I usually add a date prefix in ISO_8601 format.

This has a few advantages:

1. You can simply put it back if you made an error.
2. You can use source code programs such as Meld Merge to check for differences & debugging.
3. If you’ve personalized it in some way, then Meld can also quickly show the differences.

[sietseachterop]

Regrettably the problem returned after a few days working:(

[paulvdh]

The thread below may have related info about problems with paths and issues with environment variables (and a link to a gitlab issue about this).

It’s just a guess from my part though, I do not know if it’s related to your problem.

[Nightly] configured paths (for symbols / footprints / templates) do not point to /usr/share

Looks like some environment variables visible under 'preferences-> configure paths are fixed to values starting /usr/lib while the symbols / footprints / templates dirs in the current nightly are actually located at /usr/share/kicad-nightly/… i located kicad_common.json where the paths are defined, but had to understand that these settings are not taken into consideration by kicad. any hint on how to solve this problem? my settings: Ubuntu 20.04 (up-to-date) kicad-nightly (just checked if t…

[b3422]

@paulvdh

The thread below may have related info about problems with paths and issues with environment variables (and a link to a gitlab issue about this).

My post to which you referred to is around the nightly build. I do not run any stable version of KiCad alongsideth nightly build. @sietseachterop is mentioning a stable version only. That’s why I think my post might not lead up to a solution for him.

[sietseachterop]

I did that. So every time I need to restart Kicad (not often) I do a “mv package_dir new_name” and when I then start the footprint editor again, somehow a"reload" of packages (taking 6 seconds or so) occurs and all is well.
Currently a small inconvenience for me, nothing more.
But maybe the lengthy reload is a hint?

Sietse