Directly starting the 0.9.5 Fritzing in the debug build folder from file explorer worked fine. However opening the Door Pi.fzz sketch from that also worked. The same sequence failed with 0.9.4. Both running on Fedora 31 Workstation, one a real system, the other a VM.
Doing environment differences research …
Found the problem. In my normal environment, my command line run of Fritzing is scripted, pointing to an alternate source for the parts library (so I could switch around for testing core part creation). Running from the GUI does not get that parts library redirect, and the parts pulled in by/with the flatpak version of Fritzing is OLD, (Jun 9 2016) and not being updated automatically locally. The Camdenboss parts do not exist in that library, so the error message is perfectly correct.
@CuriousJames check with your linux user friend about the version and age of the parts library they are using. If they are using Fritzing 0.9.3, it could be the same version I had. Or if they are running Fritzing via flatpak, then they have the same lack of library updates problem.
The library (git repo) was sitting on a
Detached HEAD branch for that date. Until I did a manual fetch, I could not even see any other branches. I could not convince git to get the repository into what seemed like a normal state. I ended up deleting that and manually cloning from github. After that, running from the GUI worked. The expected parts ARE in this copy of the parts library.
Just FYI, the path to that parts library folder (for flatpak and Fedora 31) is
Or some variations.
active are symbolic links that hide some version flatpak app updates.
The not updating issue is known. It is because of where Fritzing (the flatpak wrapper) stores the library. It is in the path for code, which is not allowed to be updated from inside the application. Which was one of the reasons for my script to use an alternate path, that I cloned from github manually. I seldom use the GUI to access Fritzing (except to open an occasion sketch from the forum), so had forgotten about the limitations. I should take some time, dig deeper, to see if I can automatically pass that library override when starting from the GUI. I think that is possible in the desktop file that the application uses. Have not has a real reason to go play there before.
A quick check shows the desktop file at
~.local/share/flatpak/app/org.fritzing.Fritzing/current/active/export/bin/org.fritzing.Fritzing. Adding the parameter there seems to have fixed the problem. At least until a flatpak update replaces it on me.
Long winded description to say the error messages are correct, because the local copy of the parts library was ancient.