Each time updating footprints from library the pcb file changes

The pcb file always changes when this menu is commanded. It looks like there are a lot of uuid changes. This is not good for git to tracking real changes. The same problem on both kicad 9 and 9.99. Thanks

Here is the version info:

Application: KiCad x86_64 on x86_64

Version: 9.99.0-unknown-1.20251231gitcaa5a27.fc42, release build

Libraries:
wxWidgets 3.2.8
FreeType 2.13.3
HarfBuzz 10.4.0
FontConfig 2.16.0
libcurl/8.11.1 OpenSSL/3.2.6 zlib/1.3.1.zlib-ng brotli/1.2.0 libidn2/2.3.8 libpsl/0.21.5 libssh/0.11.3/openssl/zlib nghttp2/1.64.0 OpenLDAP/2.6.10

Platform: Fedora Linux 42 (Workstation Edition), 64 bit, Little endian, wxGTK, X11, gnome, wayland
OpenGL: AMD, AMD Radeon Graphics (radeonsi, rembrandt, LLVM 20.1.8, DRM 3.64, 6.17.13-200.fc42.x86_64), 4.6 (Compatibility Profile) Mesa 25.1.9

Build Info:
Date: Dec 31 2025 18:16:25
wxWidgets: 3.2.8 (wchar_t,wx containers) GTK+ 3.24
Boost: 1.83.0
OCC: 7.8.1
Curl: 8.11.1
ngspice: 45.2
Compiler: GCC 15.2.1 with C++ ABI 1020
KICAD_IPC_API=ON
KICAD_USE_PCH=OFF

Locale:
Lang: en_US
Enc: UTF-8
Num: 1,234.5
Encoded кΩ丈: D0BACEA9E4B888 (sys), D0BACEA9E4B888 (utf8)

It looks like you are using the nightly (9.99) build, which does change a lot. Even the testing (9.0) builds are updated frequently, although less than the nightlies.

I think that is why you see the UUIDs change. Probably the best way to guard against this is if you take control of the libraries. In other words, if you use the packaged libraries, and if those libraries are updated, then the UUIDs might change. But if you have a private copy of the libraries and you don’t update them, then the UUIDs should be stable.

That is slightly more work for you, but if you don’t want the libraries changing, then you have to freeze them by making private copies, and updating the fp-lib-table and sym-lib-table to point to your copies rather than the system ones.

You can attach an example project and tell what you would expect when doing the update. Otherwise I can only say that if you do an update you should expect your PCB to change, and it would of course affect the git diff. If you don’t want anything to change, don’t do an update.

This is a bug, nothing to do with the libraries changing. The first time pressing “update footprints from libraries” could be the libraries changing, but the 2nd, 3rd, ….could not be the libraries. It always changes the pcb file.

This similar “update symbols from library” menu in the schematic does not have this issue.

This issue can be reproduced like this:

  1. cd to the attached project
  2. git log and git status, you can see only one commit and the worktree is clean
  3. open the project with kicad9.99, open the pcb editor, press “tools/update footprints from library”
  4. git status, you can see some changes there with the pcb file.
  5. git add .
  6. press “tools/update footprints from library"
  7. git status, you can see changes again
  8. repeat 5-7 to see the issue.

test_prj.zip (1.4 MB)

I think the best thing would be to file a bug report here: Issues · KiCad / KiCad Source Code / kicad · GitLab

That way, the upstream developers will have an opportunity to take a look at the issue and determine what is going on.

I want to but my account was deleted by gitlab just because I’m from China.

Well that sucks. I’ve gone ahead and created an issue for you: Each time updating footprints from library the pcb file changes (#22625) · Issues · KiCad / KiCad Source Code / kicad · GitLab

1 Like

Thank you so much for doing this and for bringing kicad to fedora!

The fix still has some problem. PCB file depends on both the schematic and the footprints. So actions ‘update pcb from schematic F8’ and ‘update footprints from library’ should be mixed to see if there are some problem.

When ‘update pcb from schematic’ is commanded on the example project, it will add 3 units blocks to the pcb file:

(units
(unit
(name “A”)
(pins “1” “2”)
)
)

But when ‘update footprints from library’ is commanded, these three units blocks will be removed.

Thanks