kicad-developers team mailing list archive

[Carsten Schoenert <c.schoenert@xxxxxxxxxxx>]

Hello Wayne,

Am 02.01.2018 um 15:33 schrieb Wayne Stambaugh:
> Would one of our Debian developers please prod the Debian ngspice
> package[1] maintainer(s) to enable building ngspice with a shared
> library and a -dev package.  A bug report[2] for this was filed almost a
> 1 1/2 years ago (aug 2016) and it still has not be resolved.  Carsten
> was kind enough to even provide patches to resolve the issue.
> Unfortunately, they were ignored and no long apply cleanly.  It appears
> that the package build files have be updated and none of Carsten's
> patches were accepted.  I checked the latest version of Ubuntu and their
> ngspice package isn't build with a shared library.  I'm guessing all of
> the Debian derivatives are the same in this respect.  It would be a
> shame to not be able to provide spice support to users of Debian it's
> derivatives.  I would really appreciate it if someone would be kind
> enough to provide a patch against the current Debian source package so
> myself and other developers could build and test KiCad with spice
> enabled on Debian.

the recently uploaded new version of ngspice into Debian unstable is
still non-free. By this I can't use it for building KiCad in Debian main.

I started over a half year ago to evaluate the options for bringing
ngspice into main and have also asked the current maintainer of ngspice
about my plans.

The good news is, I can mostly build all parts of ngspice for main which
are needed for the KiCad build, unless this would be "only" the
libngspice0.so itself and the one header file ngspice/sharedspice.h.

But from a Debian POV this is a new source package which needs to go
through NEW and also need to respect the existing package from non-free
to not collide with users systems which already use this package. Thus I
need to also take care of this which is also time consuming. Most of the
packaging is done. But I need to review the existing tree more in deep
so a upload to NEW wouldn't be rejected due still existing license
issues or other Debian compliance issues. Some more review is really
appreciated.
The controlling inside the (new) packages to give people a migration
path from the old ngspice package needs to be designed and integrated.
Which is mostly a decision of package names which users will be given.
The old ngspice packages should be ideally called *-nonfree so a
transition would be mostly easier. But it's not that simple as it looks
like from a first view and some interaction with the people from the
archive will also be needed.

My current Debian WIP tree can be found on my GitHub site [1]. Some more
emails are written to the Debian Electronics team [2].
If someone can do some testing of the libngspice0-dev package against
the current development of KiCad I'd like to hear if still something
isn't working. Unfortunately ngspice isn't creating a pkg-config file so
right now there isn't one. Note also the installation path for the
header files has also changed against version 26 but so far the cmake
snippet should find it in the default path for header files
/usr/inlcude. I plan to work later on a pkg-config file and bring this
upstream.

[1] https://github.com/tijuca/ngspice-dfsg
[2]
https://lists.alioth.debian.org/pipermail/pkg-electronics-devel/2017-September/004472.html

https://lists.alioth.debian.org/pipermail/pkg-electronics-devel/2017-December/004624.html

-- 
Regards
Carsten Schoenert