The parts.db file is what regenerate should create. However, /usr/share/fritzing/ is a folder that normally needs to have root access to make any changes. A regular run of fritzing can not touch it. As mentioned in the previous comment.
From the reported message, I assume that while regenerating, Fritzing first attempts to make a backup copy of the db. Which fails, either because it does not exist yet, or because it can not write to that folder. If you want to get fritzing running using the library in /usr/share/fritzing/parts, there are options. The most functional way is probably to get write access to that folder for your normal user id (I have never tried that). An alternative is to use the command with the --parts options to run fritzing pointed to the cloned folder, do a regenerate there, then exit fritzing and copy (using root or sudo) the parts.db file from the cloned folder to /usr/share/fritzing/parts. That should get regular fritzing to work, but future parts library updates are still not going to work, because of write access failures. I just use the --parts option always. I created a 2 line script file that adds the option automatically. The desktop file can also be modified to add the arguments, but I normally run from the command line. A file with the executable property set, in the search path (before it find the real fritzing, I assume in /usr/bin), containing the following should handle the command line version.
#! /bin/sh
/usr/bin/fritzing --parts "/path/to/cloned/fritzing-parts" "$@" &
If you did the clone in your Documents folder, “$HOME/Documents/fritzing-parts” should work for the path.
EDIT:
That swapping message will probably go away once the parts library is working.