Hi Georges > many people are eager to have a package of the so long awaited stable > version of Kicad in Debian. I am currently the maintainer of this > package. > > unfortunately, this event happens when I have an increase of business: I > work as a teacher in France, and now is a tought period: colleagues have > to organize many details for the school year to roll smoothly, and we > are making our best to welcome students... many success or failure can > depend on those few weeks; some students are difficult, and become much > better if we can quickly find how to adapt ourselves.
That's too bad, but you gotta do what you gotta do. :) I was in a bit of a hurry myself to get KiCAD updated, as I just switched to testing last weekend and ended up with a bunch of missing packages. KiCAD is one of them. > So, if you already began to create a working package structure, I shall > upload it quickly. If alone, I can probably promise that in two weeks I > shall have more free time to work on Kicad packaging. I'm still working on proper packaging, but it's looking good so far. There's a few other changes that need to be accounted for, like fetching the libraries from github instead of launchpad (there seems to be a script automating the task), and some issues with the documentation. Also, I'd prefer getting a second opinion on certain matters. Here's a status report: - The template path still needs to be hardcoded after all. As it turned out, the code to determine the executable path uses a compiled-in prefix and not runtime path information. I brought back the old patch and updated it. - Libraries were moved from Launchpad to Github. There is a script in scripts/library-repos-install.sh that will clone the git repository and its subrepos. Alternatively, KiCAD now contains a plugin to update/load libraries directly from Github. I think it's better to install them locally via kicad-common (or a new kicad-libraries) package though. - Documentation packages are currently empty. I still need to figure out proper paths etc. - cvpcb had a major overhaul and doesn't currently work for me, as it simply doesn't work with the legacy libraries. I'll check again when I've updated the libraries from Github. - Everything else seems to be working great. There a lot of nice improvements to the user interface. (new toolbar icons! yay!) Some questions: - UI plugins (_cvpcb.kiface, _eeschema.kiface, _gerbview.kifacem _pcb_calculator.kiface, _pcbnew.kifacem _pl_editor.kiface) are currently installed to /usr/bin. Should I report this upstream and request they be installed to /usr/lib/kicad instead? Or write a patch specifically for Debian? They are dynamically loaded libraries and not executables, so in my opinion, they should definitely not live in /usr/bin. - Would it be better to pass -DCMAKE_INSTALL_PREFIX=/usr to cmake, so all built binaries use /usr/* for their data paths by default? - Should the libraries be moved to a new package, like kicad-libraries instead of kicad-common? They have become quite large, and the Github repository seems to be updated regularly. This also begs the question if such a package should be built separately from kicad. - The KiCAD developers have designated their new stable release as 4.0. Debian currently uses a date+revision version scheme. Should the Debian versioning be changed to reflect this? What is the proper way to do so? 4.0+bzrnnnn is what I currently use. Good/bad idea? Once I've figured the libraries and documentation issues out, I'll post the debian/ (or a patch for better review) here. Thanks for your input, Greg