Hello MArk, On Fri, Apr 07, 2017 at 09:51:02AM +0000, Mark Morgan Lloyd wrote: > > You can change your local table ~/.config/kicad/fp-lib-table and add the > > correct names there > > I guess that's not too bad since there's only about 15 names involved. > > > or, if you haven't modified the table much, delete > > the file. KiCad will copy the default file with the new library names if > > you restart KiCad. > > Will that work, since the files in the /usr/share/kicad tree are what's > wrong?
please note the documentation about footprint management in KiCad. http://docs.kicad-pcb.org/stable/en/cvpcb.html#_footprint_libraries_management Especially chapter 5.2.3 is showing what is happen if the user specific configuration (~/.config/kicad/fp-lib-table) is not found. So you have two options if you can't delete the old file or you are not willing to do so. 1. Modify the fp-lib-table as shown in the picture in the introducing of the chapter 5.2. 2. Alternatively you can modify the file directly as it's a simple text file. > > In the end I wouldn't wait for a version 4.0.6 in the Stretch release. > > If the upload to NEW is going well we need to ask the release team if > > they would allow a upload to unstable and a unblock for migration to > > testing. > > > > After the release we could then make a upload to backports every time. > > Apologies if I'm speaking out of turn here but I don't think it should be > released in this state. The problem is not so much how it looks inside > Debian, but that KiCad itself is pointing to Debian as the definitive > location of a usable .deb built from their source repository. > > http://kicad-pcb.org/download/debian/ That's not fully correct, they point to the respective place within the Debian distribution. So KiCad can't be made responsible what Debian is then providing by the packages. > I'd suggest that either it should be fixed inside Debian, or that KiCad > should be asked to temporarily remove that link since what's being shipped > doesn't correspond to their sources. Debian is taking what upstream is providing and it's obviously that the footprint management is work in process in all times. We can try to work around about such defects by handling the names consitent over a main version. For this a powerfull testing and feedback is needed. And basically a bug report upstream about the problem would also be not the badest. Also some autopkgtests which detects such things would be good, for the footprints it should be that difficult as we simply need to check if the names inside the package pointing to something valid. As written, I've prepared a new version 4.0.6 but this is depending on possible going through NEW. Or we drop the new -doc package and ask the release team if they would accept the new version in the Stretch release also. I can somehow upload the packages somethere if you are willing to test. Regards Carsten
