106496 2005-09-19 02:31 0000 sci-electronics/ng-spice-rework-17 (version bump) 2006-04-10 12:33:42 0000 1 1 1 Unclassified Gentoo Linux Ebuilds unspecified All Linux RESOLVED FIXED http://ngspice.sourceforge.net/ P2 enhancement --- 1 calchan@gentoo.org plasmaroo@gentoo.org info@maestroprogramador.com ludek.stepan@gmail.com sascha-gentoo-bugzilla@silbe.org sci@gentoo.org calchan@gentoo.org 2005-09-19 02:31:51 0000 Version rework-17 of ngspice was released on august 30th. Here is an ebuild for it. Changelog compared to previous ebuild: * revbumped to rework-17 * download location changed to sourceforge mirrors * added sensitivity to 'debug' and 'readline' USE flags * keyword ppc changed to ~ppc (so that it's unstable for all archictures until it's confirmed OK) * patch for gcc 3.4 no more needed calchan@gentoo.org 2005-09-19 02:35:07 0000 Created an attachment (id=68798) ng-spice-rework-17.ebuild plasmaroo@gentoo.org 2005-12-28 04:33:09 0000 *** Bug 109851 has been marked as a duplicate of this bug. *** plasmaroo@gentoo.org 2006-01-01 14:08:06 0000 debug and readline USE flags now in the -17 ebuild; thanks! ludek.stepan@gmail.com 2006-03-17 10:57:49 0000 (In reply to comment #3) > debug and readline USE flags now in the -17 ebuild; thanks! > Hello, could anyone be so kind to add --enable-xspice config directive to the ebuild, please? I suggest adding USE flag for this. The xspice is important feature in my opinion and I believe users should be given an option whether they use xspice or not. There was also a discusion in ng-spice mailing list about enabling this feature as default. While many manufacturers provide only spice2 models (which use spice3-incompatible POLY() function) for their parts, the user needs to enable this feature if he is to use these models. I offer this modification for the existing ebuild: --- ng-spice-rework-17.ebuild.old 2006-03-17 19:55:06.000000000 +0100 +++ ng-spice-rework-17.ebuild 2006-03-17 19:37:53.000000000 +0100 @@ -10,13 +10,14 @@ LICENSE="BSD GPL-2" SLOT="0" -IUSE="readline debug" +IUSE="readline debug xspice" KEYWORDS="~amd64 ~ppc ~x86" DEPEND="readline? ( >=sys-libs/readline-5.0 )" src_compile() { econf \ + $(use_enable xspice) \ $(use_with debug) \ $(use_with readline) || die "econf failed" emake || die "emake failed" plasmaroo@gentoo.org 2006-03-17 11:53:38 0000 Hi Ludek, 1) Does it need a USE flag? I have tclspice just enable xspice support by default; doesn't seem to cause problems. Does the xspice support cause conflicts with existing spice2? 2) If so, use.local.desc needs updating, does this sound reasonable: --- use.local.desc 17 Mar 2006 16:04:55 -0000 1.1786 +++ use.local.desc 17 Mar 2006 19:51:33 -0000 @@ -1211,6 +1211,7 @@ sci-chemistry/caver:pymol - Install the PyMol plugin sci-chemistry/eden:double-precision - more precise calculations at the expense of speed sci-chemistry/ghemical:mpqc - Use the MPQC package for quantum-mechanical calculations +sci-electronics/ng-spice-rework:xspice - Enable extended SPICE3 features for code modelling and digital components sci-geosciences/gmt:gmtfull - Full resolution bathymetry database sci-geosciences/gmt:gmthigh - Adds high resolution bathymetry database sci-geosciences/gmt:gmtsuppl - Supplement functions for GMT 3) Ideally you should file a new bug or reopen, comments get lost sometimes on resolved bugs. ludek.stepan@gmail.com 2006-03-17 12:56:17 0000 (In reply to comment #5) > 1) Does it need a USE flag? I have tclspice just enable xspice support by > default; doesn't seem to cause problems. Does the xspice support cause > conflicts with existing spice2? Well, it doesn't need USE flag as long as it's enabled by default, but at this moment it's not. Anyway, following the "gentoo's all about options" philosophy, I think USE flag is ok for this. I don't know about any conflicts, but I did no checks. Perhaps somebody else can verify it. I can't install tclspice on amd64 (emerge error) :( and spice doesn't work for me (bug #84034 ) calchan@gentoo.org 2006-03-17 13:31:07 0000 (In reply to comment #6) > Well, it doesn't need USE flag as long as it's enabled by default, but at this > moment it's not. Anyway, following the "gentoo's all about options" philosophy, If you really want xspice, you can always activate it like this : EXTRA_ECONF="--enable-xspice" emerge ng-spice-rework Now, about having xpsice as a default is another story. I've had bad experiences with it, but your mileage may (will) vary. plasmaroo@gentoo.org 2006-03-18 14:24:23 0000 Hrm, I noticed enabling xspice dumps a lot of debug output when starting ngspice, so the feature looks rather experimental... calchan@gentoo.org 2006-03-18 14:43:20 0000 (In reply to comment #8) > Hrm, I noticed enabling xspice dumps a lot of debug output when starting > ngspice, so the feature looks rather experimental... True, plus doing a './configure --help' shows --enable-xspice as being "officially" experimental. Another feature that I can confirm breaks ng-spice under certain conditions is numparam. I tried to fix it, but gave up (you should just have a look at the code, for a good laugh). There were some allusions on the mailing list about rewriting it totally. ludek.stepan@gmail.com 2006-03-19 02:01:30 0000 Ok, you are right. The xspice feature *is* quite experimental, but doesn't the whole package taste bit experimental? Although xspice can break things, it is important part and feature of the ngspice package and I believe it's useful for many people. At least for those who would like to use spice2 macromodels released by manufacturers, as these models often contain polynomial sources. I don't claim it should be enabled by default, but I think an USE flag is appropriate for this. EXTRA_ECONF="--enable-xspice" does the job, but I wouldn't call it "efficient". Aren't the USE flags designed for this? Oh come on, it can't be that hard to add it... --- use.local.desc 17 Mar 2006 16:04:55 -0000 1.1786 +++ use.local.desc 17 Mar 2006 19:51:33 -0000 @@ -1211,6 +1211,7 @@ sci-chemistry/caver:pymol - Install the PyMol plugin sci-chemistry/eden:double-precision - more precise calculations at the expense of speed sci-chemistry/ghemical:mpqc - Use the MPQC package for quantum-mechanical calculations +sci-electronics/ng-spice-rework:xspice - Enable extended SPICE3 features for code modelling and digital components (bug #106496) sci-geosciences/gmt:gmtfull - Full resolution bathymetry database sci-geosciences/gmt:gmthigh - Adds high resolution bathymetry database sci-geosciences/gmt:gmtsuppl - Supplement functions for GMT calchan@gentoo.org 2006-04-07 14:44:58 0000 (In reply to comment #10) > Ok, you are right. The xspice feature *is* quite experimental, but doesn't the > whole package taste bit experimental? Although xspice can break things, it is > important part and feature of the ngspice package and I believe it's useful for > many people. At least for those who would like to use spice2 macromodels > released by manufacturers, as these models often contain polynomial sources. I > don't claim it should be enabled by default, but I think an USE flag is > appropriate for this. EXTRA_ECONF="--enable-xspice" does the job, but I > wouldn't call it "efficient". Aren't the USE flags designed for this? Oh come > on, it can't be that hard to add it... > > --- use.local.desc 17 Mar 2006 16:04:55 -0000 1.1786 > +++ use.local.desc 17 Mar 2006 19:51:33 -0000 > @@ -1211,6 +1211,7 @@ > sci-chemistry/caver:pymol - Install the PyMol plugin > sci-chemistry/eden:double-precision - more precise calculations at the expense > of speed > sci-chemistry/ghemical:mpqc - Use the MPQC package for quantum-mechanical > calculations > +sci-electronics/ng-spice-rework:xspice - Enable extended SPICE3 features for > code modelling and digital components (bug #106496) > sci-geosciences/gmt:gmtfull - Full resolution bathymetry database > sci-geosciences/gmt:gmthigh - Adds high resolution bathymetry database > sci-geosciences/gmt:gmtsuppl - Supplement functions for GMT > When I wrote 'experimental' about xspice above, it meant it is actually broken, only in mild language. You can find hints of this on the ng-spice mailing lists, and I have personnally experienced it (and with fairly simple models, even). So, since it is broken for at least a few of us, it means it isn't ready for prime time yet. However, feel free to compile it in, and report bugs upstream if you find any. ludek.stepan@gmail.com 2006-04-09 08:07:43 0000 (In reply to comment #11) > When I wrote 'experimental' about xspice above, it meant it is actually broken, > only in mild language. You can find hints of this on the ng-spice mailing > lists, and I have personnally experienced it (and with fairly simple models, > even). So, since it is broken for at least a few of us, it means it isn't ready > for prime time yet. > > However, feel free to compile it in, and report bugs upstream if you find any. > Ok, no problem for me :) So this bug shell be marked WON'T or CLOSED respectively? Yours Ludek plasmaroo@gentoo.org 2006-04-10 12:33:42 0000 (In reply to comment #12) > Ok, no problem for me :) So this bug shell be marked WON'T or CLOSED > respectively? Guess so. If you think the situation has changed in future releases and it feels stable enough please let us know. Thanks! 68798 2005-09-19 02:35 0000 ng-spice-rework-17.ebuild ng-spice-rework-17.ebuild text/plain IyBDb3B5cmlnaHQgMTk5OS0yMDA1IEdlbnRvbyBGb3VuZGF0aW9uCiMgRGlzdHJpYnV0ZWQgdW5k ZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2MgojICRIZWFk ZXI6ICQKCmluaGVyaXQgZXV0aWxzCgpERVNDUklQVElPTj0iTkdTcGljZSAtIFRoZSBOZXh0IEdl bmVyYXRpb24gU3BpY2UgKENpcmN1aXQgRW11bGF0b3IpIgpTUkNfVVJJPSJtaXJyb3I6Ly9zb3Vy Y2Vmb3JnZS9uZ3NwaWNlLyR7UH0udGFyLmd6IgpIT01FUEFHRT0iaHR0cDovL25nc3BpY2Uuc291 cmNlZm9yZ2UubmV0IgoKU0xPVD0iMCIKSVVTRT0iZGVidWcgcmVhZGxpbmUiCkxJQ0VOU0U9IkJT RCBHUEwtMiIKS0VZV09SRFM9In5hbWQ2NCB+cHBjIH54ODYiCgpERVBFTkQ9Ij49c3lzLWxpYnMv Z2xpYmMtMi4xLjMKCXJlYWRsaW5lPyAoID49c3lzLWxpYnMvcmVhZGxpbmUtNS4wICkiCgpzcmNf Y29tcGlsZSgpIHsKCWVjb25mIFwKCQkkKHVzZV93aXRoIGRlYnVnKSBcCgkJJCh1c2Vfd2l0aCBy ZWFkbGluZSkgXAoJCXx8IGRpZQoJZW1ha2UgfHwgZGllCn0KCnNyY19pbnN0YWxsICgpIHsKCWxv Y2FsIGluZm9GaWxlCglmb3IgaW5mb0ZpbGUgaW4gZG9jL25nc3BpY2UuaW5mbyo7IGRvCgkJZWNo byAnSU5GTy1ESVItU0VDVElPTiBFREEnID4+ICR7aW5mb0ZpbGV9CgkJZWNobyAnU1RBUlQtSU5G Ty1ESVItRU5UUlknID4+ICR7aW5mb0ZpbGV9CgkJZWNobyAnKiBOR1NQSUNFOiAobmdzcGljZSku IEVsZWN0cm9uaWMgQ2lyY3VpdCBTaW11bGF0b3IuJyA+PiAke2luZm9GaWxlfQoJCWVjaG8gJ0VO RC1JTkZPLURJUi1FTlRSWScgPj4gJHtpbmZvRmlsZX0KCWRvbmUKCgltYWtlIERFU1RESVI9JHtE fSBpbnN0YWxsIHx8IGRpZQoJZG9kb2MgQ09QWUlORyBDT1BZUklHSFQgQ1JFRElUUyBDaGFuZ2VM b2cgUkVBRE1FCn0K