We have a custom library of components and it’s conflicting with the existing kicad libraries of 4.0.7. I won’t be able to explain it in short. In conclusion, I need to install 4.0.4 to verify whether the problem I’m facing is consistent with all versions of kicad or there’s an error on my end.
Welcome to the club, I wasn’t aware that nightly built is represents as 6. Regardless, I’ll post the link soon
You know that you can use 4.0.7 without the official libs right? You can even install any version of the official lib. (Not with an installer but by downloading said lib from github and putting it somewhere on your system. Then point kicad to that place instead of the system directory version of the libs.)
I’m unable to delete the path /usr/share/kicad/library
https://launchpad.net/~js-reynaud/+archive/ubuntu/kicad-4/packages
This is the link where I downloaded the .deb files from
Command used was sudo dpkg -i kicad_4.0.4+e1-6308~48~ubuntu15.10.1_amd64.deb
I realise I’m using 16.04 and the deb file was for 15.10 but I believe it should be compatible. Correct me if I’m wrong.
This is because that is a system path. You need root access for it. (In other words: Do not touch this if you are not 100% certain you know what you are doing.)
Your personal libs should not be in this path!! (These libs will be managed by the kicad package.)
Running kicad without libs is done by removing footprint libs from the fp lib table (library manager in pcb_new). For symbols such an option does not exist in version 4. Symbol libs are assigned to the project. So you can only influence what libs are assigned to new projects (My suggestion: Do not start new projects with version 4. Switch to version 5 for new stuff.)
But if you insist on creating new projects with version 4 then you might need to edit the system template project to remove symbol libs for new projects.
Or you simply take care of library preiorities and make sure your personal symbol libs have higher priority than the system ones: Any conflict with names of modules and libraries? This should remove any conflict between your personal libs and the system libs as your lib takes precedence in the case of a conflict.
install gdebi via terminal & then try & install .deb via gdebi (right click deb & select open with)
it’ll show if any dependency/version is not matching…
easier alternative is try 4.0.7 windows version via wine… so your current ubuntu installation won’t be disturbed…
1 Like
Thanks Apurv.
This worked.
Hey Rene, thanks for all your help. I modified the installation script and I am removing the conflicting kicad libraries before installation. The component selection was conflicting due to library priority like you had suggested. Also I will stick to 4.0.7 as it has fewer bugs.
You are not along 
. But I keep switching to 5.x back and for.
For Pcbnew - I can use vim for search and replace to fix the “at” (in m) vs. “offset” (in inch) easily.
For eeschematic - I just stay edit with 4.0.7, and view only on 5.x because it is too much of search and replace I have to do since they introduce a MUST library name in front of every symbol !
Transferring from v4 to v5 should not be done with a text editor! Kicad has a tool for that (the remap dialog) Converting KiCad version 4 projects to version 5 (Remap a project)
The moment you use the remap. There is no going back. It only useful when your intent is remove 4.0.7 out of your design history.
The same is true if you use search and replace with a text editor to add the lib names.
That why I said, 5.x for read only on schematic, 4.x will do the modify. I were hoping the 5.x feature was extend in this manner instead of enforce to incompatibility. Like accept both styles of specify lib name, or not.
PS: I know by now the hope is hopeless.
Please note that the developers are not aware of these bugs. And if they are not reported to https://bugs.launchpad.net/kicad they may never get fixed. We’re pretty friendly over there. Please take a moment to record bugs in 5.x that you experience to the tracker. We would greatly appreciate your help in making KiCad better!
But but reporting bugs sounds like work 
I would think most of the bug are actually already reported by one way or the other on launchpad. A lot of them are overlap too. So I would think, you will never end of with a launch pad with bug free for sure… It is because so many people love KiCad.
Find the ones that apply to you and help the devs find the reason behind them. Add further info if necessary and mark them as “affects me as well” while giving your kicad version info (if different from the everyone else who reported)
I can’t (nor would I want to) force you to report the issues you reference in your posts. But to my knowledge, there are no remaining bugs in 5.x that did not exist in 4.0.7. And I’ll re-iterate: If you decide not to report the bugs, they may never be fixed.
1 Like
It is understandable the bug never got fix if not reported. But however, I would hope developer them self actively seek for the bug/way automatically test for bugs. I don’t even’t hear bug report for very very old versions of KiCad, but somehow they are still usable for doing boards. So I would think bug report is a good system but not the only path.