Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 787263 - >=sci-electronics/ngspice-34 no longer needs to depend on sci-visualization/xgraph
Summary: >=sci-electronics/ngspice-34 no longer needs to depend on sci-visualization/x...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: The Soldering-Iron Brotherhood
URL: https://sourceforge.net/p/ngspice/ngs...
Whiteboard:
Keywords: EBUILD
Depends on:
Blocks:
 
Reported: 2021-05-01 02:06 UTC by Gabriel Marcano
Modified: 2021-09-05 19:17 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
ngspice-34.ebuild (ngspice-34.ebuild,4.37 KB, text/plain)
2021-05-01 02:24 UTC, Gabriel Marcano
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gabriel Marcano 2021-05-01 02:06:25 UTC
I think it's actually around at least sci-electronics/ngspice-32, but definitely by sci-electronics/ngspice-34 xgraph is no longer used by ngspice. Specifically, commit 8d986e50c upstream tears out xgraph support from ngspice, with some additional commits happening later to prune some other parts of the build system (for Windows).

The solution is simple, dropping xgraph from the dependencies for ngspice.

Reproducible: Always

Steps to Reproduce:
1. equery g =sci-electronics/ngspice-34
Actual Results:  
$ equery g =sci-electronics/ngspice-34
 * Searching for ngspice34 in sci-electronics ...

 * dependency graph for sci-electronics/ngspice-34
 `--  sci-electronics/ngspice-34  ~amd64 
   `--  sys-libs/ncurses-6.2_p20210123  (sys-libs/ncurses) ~amd64 
   `--  x11-libs/libXaw-1.0.14  (x11-libs/libXaw) ~amd64 
   `--  x11-libs/libXt-1.2.1  (x11-libs/libXt) amd64 
   `--  x11-libs/libX11-1.7.0  (x11-libs/libX11) amd64 
   `--  sci-libs/fftw-3.3.9  (sci-libs/fftw) amd64 
   `--  sys-libs/readline-8.1  (sys-libs/readline) ~amd64 
   `--  dev-lang/tcl-8.6.11  (dev-lang/tcl) ~amd64 
   `--  dev-tcltk/blt-2.5.3-r1  (dev-tcltk/blt) amd64 
   `--  sci-visualization/xgraph-12.1-r4  (sci-visualization/xgraph) xgraph license(s) 
   `--  sys-devel/gnuconfig-20210107  (sys-devel/gnuconfig) ~amd64 
   `--  app-portage/elt-patches-20201205  (>=app-portage/elt-patches-20170815) ~amd64 
   `--  sys-devel/automake-1.16.3-r1  (>=sys-devel/automake-1.16.2-r1) ~amd64 
   `--  sys-devel/autoconf-2.69-r5  (>=sys-devel/autoconf-2.69) amd64 
   `--  sys-devel/libtool-2.4.6-r6  (>=sys-devel/libtool-2.4) amd64 
   `--  x11-base/xorg-server-1.20.11  (x11-base/xorg-server) amd64  [xvfb]
   `--  x11-apps/xhost-1.0.8  (x11-apps/xhost) amd64 
[ sci-electronics/ngspice-34 stats: packages (17), max depth (1) ]

Expected Results:  
$ equery g =sci-electronics/ngspice-34
 * Searching for ngspice34 in sci-electronics ...

 * dependency graph for sci-electronics/ngspice-34
 `--  sci-electronics/ngspice-34  ~amd64 
   `--  sys-libs/ncurses-6.2_p20210123  (sys-libs/ncurses) ~amd64 
   `--  x11-libs/libXaw-1.0.14  (x11-libs/libXaw) ~amd64 
   `--  x11-libs/libXt-1.2.1  (x11-libs/libXt) amd64 
   `--  x11-libs/libX11-1.7.0  (x11-libs/libX11) amd64 
   `--  sci-libs/fftw-3.3.9  (sci-libs/fftw) amd64 
   `--  sys-libs/readline-8.1  (sys-libs/readline) ~amd64 
   `--  dev-lang/tcl-8.6.11  (dev-lang/tcl) ~amd64 
   `--  dev-tcltk/blt-2.5.3-r1  (dev-tcltk/blt) amd64 
   `--  sys-devel/gnuconfig-20210107  (sys-devel/gnuconfig) ~amd64 
   `--  app-portage/elt-patches-20201205  (>=app-portage/elt-patches-20170815) ~amd64 
   `--  sys-devel/automake-1.16.3-r1  (>=sys-devel/automake-1.16.2-r1) ~amd64 
   `--  sys-devel/autoconf-2.69-r5  (>=sys-devel/autoconf-2.69) amd64 
   `--  sys-devel/libtool-2.4.6-r6  (>=sys-devel/libtool-2.4) amd64 
   `--  x11-base/xorg-server-1.20.11  (x11-base/xorg-server) amd64  [xvfb]
   `--  x11-apps/xhost-1.0.8  (x11-apps/xhost) amd64 
[ sci-electronics/ngspice-34 stats: packages (17), max depth (1) ]

What prompted me looking into this is the weird xgraph license of the xgraph package that was getting pulled in by ngspice[X].
Comment 1 Gabriel Marcano 2021-05-01 02:24:45 UTC
Created attachment 704778 [details]
ngspice-34.ebuild

This is the patched/fixed ebuild. I've built it on my system without xgraph, and it appears to function properly. I don't see any references to xgraph on ldd or even in strings in the generated binaries (so the application isn't called manually).

Let me know if you need anything else from me.
Comment 2 Gabriel Marcano 2021-05-01 02:55:51 UTC
From a glance, it looks like ngspice is the last application in the tree that depends on xgraph. Once ngspice-31 is dropped from the tree and once >=ngspice-34 is made to not depend on xgraph, nothing will depend on it. I know we're not the same, but for reference Debian has already removed xgraph from their packages (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870973). I guess that might be a case of opening a new bug report once that's the case, assuming we want to drop the package completely. I think I just really dislike the custom license xgraph uses.
Comment 3 Larry the Git Cow gentoo-dev 2021-09-05 19:17:31 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ab622819ea56352cb14695f0a4eab537856b15a0

commit ab622819ea56352cb14695f0a4eab537856b15a0
Author:     Jason Zaman <perfinion@gentoo.org>
AuthorDate: 2021-09-05 18:12:08 +0000
Commit:     Jason Zaman <perfinion@gentoo.org>
CommitDate: 2021-09-05 19:17:20 +0000

    sci-electronics/ngspice: Bump 35
    
    Closes: https://bugs.gentoo.org/730548
    Closes: https://bugs.gentoo.org/787263
    Package-Manager: Portage-3.0.20, Repoman-3.0.3
    Signed-off-by: Jason Zaman <perfinion@gentoo.org>

 sci-electronics/ngspice/Manifest          |   2 +
 sci-electronics/ngspice/ngspice-35.ebuild | 198 ++++++++++++++++++++++++++++++
 2 files changed, 200 insertions(+)