Problem in running second time after installation in debian stretch


#1

I am using debian in a chroot environment & access GUI apps over VNC.

I installed fritzing using :: apt install fritzing fritzing-parts .
After successful installation , it ran without any problem for the first time. But running it again , showed these errors ::
Sorry, we have a problem with the swapping mechanism. Fritzing still works, but you won't be able to change parts properties.

Cannot read file screw_terminal_2_3.5mm.fzp: No such file or directory.


Unable to find the following 143 part(s):

Then Fritzing window opens , but without any parts in parts bar.

So , I uninstalled fritzing and installed again . Launched it , ran without any problem for the first time after installation, but on launching second time, it started showing those errors again.
Please guide me . what is the issue.


#2

Interesting! I assume you are using version 0.9.3.B? The only place I have seen this is on Ubuntu on a build from source. As far as I know no one yet knows why this is happening (and it doesn’t happen on the same system from the 0.9.3.B version from the download page, installed on the same machine, that works fine). The first thing Fritzing does is check the parts repository on github and updates it if the repository has changed. From the source version I think that process is where this is coming from but I don’t know yet. If you are willing to bypass your app manager you might try downloading the tar ball from the download page and try a standard install (that’s what works correctly on the Ubuntu machine).

Peter


#3

I am running on arm 64 bit system. Yes, the version is version 0.9.3.B.

So instead of installing from debian stretch repo , Should I build from source ? Would this fix the issue ?


#4

I don’t think so, at the moment source is broken the same way (and head has a problem in gerber generation as well), even building the 0.9.3.B release code acts the same way. I have some suspicion that the problem is the libgit2 library version. I’m currently using version 0.23.4 which is the latest of the 0.23 series (an api change at 0.24 breaks Fritzing and the library is currently at something like .29) and I’m wondering if even that is too new as some of the fixes were backported to that version They used something (but I don’t know what exactly) from the 0.23 series to build the release version so something in there should work I just haven’t it yet (for the bugs I’m chasing, not having the core parts doesn’t matter, so I haven’t pushed at fixing this yet). I’d be tempted to try an earlier version of the 0.23 series and see if that helps. I don’t know how easy it will be to substitute an older copy under your app manager though and the prebuilts won’t work for you because they are only x86, so you may have to try a build from source.

Edit: I forgot one thing, if you build from source and then do the package for release stuff (even though you aren’t doing a release) apparently 0.23.4 works properly from the tar ball the release script generates so a source build from the 0.9.3.B source may in fact work for you. There is a thread on this in the developers forum in here.

Peter


#5

From what you have said it sounds like the repo you used installs directly from source but it never creates a final release. And for some reason the current development version has this issue and the only way to get it running every time is to package a release and then run that release directly.

Have you tried simply downloading the release from Fritzing.org http://fritzing.org/download/0.9.3b/linux-64bit/fritzing-0.9.3b.linux.AMD64.tar.bz2 and running it? It looks like arm has been included for the last few releases.

If the release does’t work I would suggest finding the folder that apt has installed Fritzing in and see if you can compile a release. https://github.com/fritzing/fritzing-app/wiki/4.-Publishing-a-Release


#6

I am seeing the same problem with stretch x64 0.93b

I have tried installing from
http://fritzing.org/download/0.9.3b/linux-64bit/fritzing-0.9.3b.linux.AMD64.tar.bz2
I assume “running it” means executing the “install_fritzing.sh” in the tarball ?
I have tried that too.
I have also tried pulling the git repository and installing from there.
but there are a number of problems trying to do that.
There are hardcoded paths to /home/andre and unclear dependencies, such as for old versions of boost.


#7

Nope. Just Fritzing not install_fritzing.sh . The file called Fritzing is a binary file not a shell script.


#8

The head code has an updated set of install scripts (although I think still hard coded paths). I think they may be intended for the machine that creates releases rather than the general public but I’m not sure. I’m not aware of any documentation on the install scripts that may tell us.

Peter


#9

How can a git repository for multiple architectures have a binary that works for mine ?

I can understand how that might be true of the architecture specific downloads


#10

It doesn’t. The binary is from the download you get at Fritzing,org which is the one you linked to in your post.

If you want to run the development version then you download the files on Github and follow the build instructions which takes a long time and has multiple errors currently. To build it you would really have to read through the recent build discussions here on the forum for the latest information and undocumented changes to the build instructions.


#11

Specifically this post which builds head for me on Ubuntu 16.04lts linux and Windows7pro (although I think windows can be simplified somewhat, this works for me).

Peter