Bug 226725 - Review Request: netgen - LVS netlist comparison tool
Review Request: netgen - LVS netlist comparison tool
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mamoru TASAKA
Fedora Package Reviews List
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-01 03:34 EST by Chitlesh GOORAH
Modified: 2008-12-28 14:23 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-23 21:10:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
mtasaka: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)
rpmbuild output (41.54 KB, text/plain)
2007-03-13 06:28 EDT, Trond Danielsen
no flags Details
install.log (2.62 KB, text/plain)
2007-03-23 08:48 EDT, Trond Danielsen
no flags Details
build.log from mock (41.64 KB, text/plain)
2007-03-29 08:14 EDT, Trond Danielsen
no flags Details

  None (edit)
Description Chitlesh GOORAH 2007-02-01 03:34:42 EST
Spec URL: http://tux.u-strasbg.fr/~chit/RPMS/netgen.spec
SRPM http://tux.u-strasbg.fr/~chit/RPMS/netgen-1.3.7-1.src.rpm
Description:
Netgen is a tool for comparing netlists, a process known as LVS,
which stands for "Layout vs. Schematic". This is an important step
in the integrated circuit design flow, ensuring that the geometry
that has been laid out matches the expected circuit.

The greatest need for LVS is in large analog or mixed-signal circuits
that cannot be simulated in reasonable time. Even for small circuits,
LVS can be done much faster than simulation, and provides feedback
that makes it easier to find an error than does a simulation.
Comment 2 Trond Danielsen 2007-03-12 18:35:09 EDT
Looks good to me! If you want I will go through the formal review tomorrow.
Comment 3 Chitlesh GOORAH 2007-03-12 18:43:58 EDT
Sure, go on :)
Comment 4 Trond Danielsen 2007-03-13 06:28:48 EDT
Created attachment 149914 [details]
rpmbuild output
Comment 5 Trond Danielsen 2007-03-13 06:29:45 EDT
Build fails on x86_64. Problem seems to be hardcoded library paths, but I
haven't figured out where this is done. See complete build log in #4
Comment 6 Trond Danielsen 2007-03-13 06:31:36 EDT
One more comment; does this make a difference?

%files
%defattr(-,root,root,-)
%doc README VERSION TO_DO Changes Copying netgen.doc
%{_bindir}/%{name}
-%{_libdir}/%{name}/
+%{_libdir}/%{name}
Comment 7 Chitlesh GOORAH 2007-03-17 17:35:32 EDT
(In reply to comment #5)
> Build fails on x86_64. Problem seems to be hardcoded library paths, but I
> haven't figured out where this is done. See complete build log in #4

Updated:
Spec URL: http://tux.u-strasbg.fr/~chit/RPMS/netgen.spec
SRPM http://tux.u-strasbg.fr/~chit/RPMS/netgen-1.3.7-3.src.rpm
Comment 8 Chitlesh GOORAH 2007-03-17 17:37:30 EDT
(In reply to comment #6)
> One more comment; does this make a difference?

no it doesn't.
the %{_libdir}/%{name}/ implies a folder. It's only for visual aspect only.
Comment 9 Trond Danielsen 2007-03-19 04:01:59 EDT
make install still fails for some reason, but I solved it by manually creating
%{_libdir}/%{name} in the build root before running make install in the %install
section.

There are also some unpackaged file in %{_bindir}:
- - - - - -
RPM build errors:
    Installed (but unpackaged) file(s) found:
   /usr/bin/inetcomp
   /usr/bin/netcomp
   /usr/bin/ntk2adl
   /usr/bin/ntk2xnf
- - - - - -
Comment 10 Chitlesh GOORAH 2007-03-22 13:59:16 EDT
(In reply to comment #9)
> make install still fails for some reason, but I solved it by manually 
creating
> %{_libdir}/%{name} in the build root before running make install in 
the %install
> section.

Can i have a look why it's failing on x86_64 arch?
Comment 12 Trond Danielsen 2007-03-23 07:06:04 EDT
(In reply to comment #10)
> (In reply to comment #9)
> > make install still fails for some reason, but I solved it by manually 
> creating
> > %{_libdir}/%{name} in the build root before running make install in 
> the %install
> > section.
> 
> Can i have a look why it's failing on x86_64 arch?

The problem is simply that the Makefile in lib/ does not check for the existence
of $prefix/%{_libdir}/%{name} before attempting to copy the file. I can create
an account on my x86_64 machine if you want to check for your self, but the
problem can easily be fixed either by adding the directory to the install-dirs
rule in the top level Makefile, or by manually running mkdir -p
%{buildroot}%{_libdir}/%{name} before running make install.

On the other hand, it seems kind of strange to me to install the scripts in
libdir in the first place. Wouldn't the correct location be libexec?

Comment 13 Trond Danielsen 2007-03-23 08:48:51 EDT
Created attachment 150746 [details]
install.log

make install fails on x86_64.
Comment 14 Chitlesh GOORAH 2007-03-28 18:18:17 EDT
can you post the build.log instead ?
Comment 15 Trond Danielsen 2007-03-29 08:14:21 EDT
Created attachment 151189 [details]
build.log from mock
Comment 16 Trond Danielsen 2007-04-03 09:16:49 EDT
Now I know why it fails on x86_64. I did not spot this configure warning at first:

- - - -
checking for tclConfig.sh... 
Can't find Tcl configuration script "tclConfig.sh"
Reverting to non-Tcl compilation
checking for X... libraries /usr/lib64, headers 
checking for gethostbyname... yes
checking for connect... yes
- - - -

The real problem is that the makefile in netgen/lib does not check if install
path exists before attempting to copy the file, but adding --with-tcl=%{_libdir}
 to %configure solves the problem.
Comment 18 Trond Danielsen 2007-04-21 03:32:55 EDT
Nope, still does not work on x86_64. Any particular reason why you write:

%configure \
   --with-tcl=%{_prefix}/lib$SUF     \
   --with-tk=%{_prefix}/lib$SUF      \
   --with-tcllibs=%{_prefix}/lib$SUF \
   --with-tklibs=%{_prefix}/lib$SUF

instead of just:

%configure --with-tcl=%{_libdir} --with-tk=%{_libdir}

I've tested it on both i386 and x86_64, and it works fine.
Comment 20 Trond Danielsen 2007-04-25 16:19:32 EDT
Ok, build on x86_64. Just one more issue and everything should be ok: netgen.doc
is installed in %{_libdir}/netgen/doc, should it not be in /usr/share/doc/netgen?
Comment 21 Ralf Corsepius 2007-04-26 03:22:54 EDT
(In reply to comment #20)
> ust one more issue and everything should be ok: netgen.doc
> is installed in %{_libdir}/netgen/doc, should it not be in 
> /usr/share/doc/netgen?
It depends:

- if a docfile is being accessed by the application at its runtime 
(e.g. as part of some interactive help system) /usr/share/<somewhere>,
/usr/lib/<somewhere> or %{_libdir}/<somewhere> can be OK.
What to use depends on a package's internals and working principles (e.g. are
these docs shared between several packages?) 

- if a docfile is not being accessed by the application at its runtime, but is
"optional user documentation" then it must be below /usr/share/doc/%name-%version

AFAIS in this case, netgen.doc is mere "user documentation" and already is in
/usr/share/doc/%name-%version. 
=> %{_libdir}/netgen/netgen.doc probably should not be shipped at all.

Comment 23 Trond Danielsen 2007-05-02 15:22:33 EDT
APPROVED by Trond Danielsen; package looks good to me!
Comment 24 Chitlesh GOORAH 2007-05-06 05:33:34 EDT
New Package CVS Request
=======================
Package Name: netgen
Short Description: LVS netlist comparison tool
Owners: cgoorah@yahoo.com.au
Branches: FC-6
Comment 25 Chitlesh GOORAH 2007-05-09 14:53:27 EDT
The build on x86_64 failed. I thought you tested it under x86_64?
http://buildsys.fedoraproject.org/logs/fedora-6-extras/33099-netgen-1.3.7-7.fc6/

however, I've some segmentation fault when using netgen with my netlists. So 
I'll be working on finding more why and what is failing to contact upstream. 
Though netgen is important for my daily work, I prefer not to have a broken 
netgen on fedora repositories. So I'll take my time before closing this bug.
Comment 26 Trond Danielsen 2007-05-10 05:10:08 EDT
(In reply to comment #25)
> The build on x86_64 failed. I thought you tested it under x86_64?
> http://buildsys.fedoraproject.org/logs/fedora-6-extras/33099-netgen-1.3.7-7.fc6/

I did test it on x86_64, but I am indeed the one to blame here. Yum installs
both tcl.i386 and tcl.x86_64, so when building the package, netgen would find
the i386 libraries. This, however, is not the case when building in mock. Then
only the x86_64 libs are installed. By adding --with=tcllibs=%{_libdir} and
--with-tklibs%{_libdir}, the package also builds in mock.

Sorry for my lack of attention to details, I hope my review skills will improve
over time!
Comment 27 Chitlesh GOORAH 2007-05-10 14:34:12 EDT
(In reply to comment #26)
> Sorry for my lack of attention to details, I hope my review skills will 
improve
> over time!

You have done a great review. Your contribution to Fedora Electronics' world
is admirable.
Comment 28 Jason Tibbitts 2007-06-21 16:42:17 EDT
Shouldn't this ticket be closed now?
Comment 29 Chitlesh GOORAH 2007-06-21 17:09:59 EDT
not now, i haven't still found why netgen is segmenting fault with my 
examples.

Upstream/their mailing list didn't respond to me yet.
Comment 30 Chitlesh GOORAH 2007-08-05 20:18:18 EDT
Package Change Request
======================
Package Name: netgen
[Removed Branches: FC-6 devel ]
[Removed Fedora Owners: cgoorah@yahoo.com.au ]

this package crashes (segmentation faults) during its main functionality. 
Upstream didn't reply to me and there is no reason to push it into the fedora 
collection nor maintaining it for the moment.

Please remove netgen's FC-6 and development branches. It was neither built nor 
released into the mirrors.
Comment 31 Chitlesh GOORAH 2007-08-06 13:56:24 EDT
I'm now closing this bug as WONTFIX!

If anyone happened to know an opensource LVS checker which can be used with 
other opensource tools such as magic and xcircuit, please, let me know:
chitlesh [AT] fedoraproject DOT org

http://clunixchit.blogspot.com/2007/08/loss-there-is-no-opensource-lvs-netlist.html
Comment 32 Chitlesh GOORAH 2007-08-14 11:05:50 EDT
Now, with Denis's patch we are back on track.

Updated:
SRPM: http://chitlesh.fedorapeople.org/netgen/netgen-1.3.7-8.src.rpm
SPEC: http://chitlesh.fedorapeople.org/netgen/netgen.spec

Changelog:
- added patch netgen-1.3.7-free.patch by Denis Leroy

Example
http://chitlesh.fedorapeople.org/netgen/NOR/
netgen &
readnet sim nor
readnet sim nor2
lvs nor nor2

"reinitialize", should be used to restart another LVS check


Trond Danielsen still interested in reviewing this application ?
Comment 34 Mamoru TASAKA 2007-08-17 11:57:45 EDT
Well,
* I only have i386
* I only tried to rebuild the srpm and I did not do anything else
but build fails at least on x86_64

http://koji.fedoraproject.org/koji/taskinfo?taskID=107147
Comment 35 Chitlesh GOORAH 2007-08-17 13:11:13 EDT
I'll look at it.

However how can you upload the srpm and build on koji ?
Can I do it too ?
Comment 36 Mamoru TASAKA 2007-08-17 13:22:27 EDT
(In reply to comment #35)
> However how can you upload the srpm and build on koji ?
> Can I do it too ?

Yes. Actually I was told from Jason Tibbitts that now we can
try to rebuild arbitrary srpm by scratch build:

koji build --scratch <target> <your srpm>

Currently target may be: dist-f8, dist-fc7-updates-candidate.

If the rebuild ends successfully, the result rpms are to be put on
http://koji.fedoraproject.org/scratch/<your FAS name>/task_<number>/
Comment 37 Chitlesh GOORAH 2007-08-17 20:10:39 EDT
(In reply to comment #12)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > make install still fails for some reason, but I solved it by manually 
> > creating
> > > %{_libdir}/%{name} in the build root before running make install in 
> > the %install
> > > section.
> > 
> > Can i have a look why it's failing on x86_64 arch?
> 
> The problem is simply that the Makefile in lib/ does not check for the 
existence
> of $prefix/%{_libdir}/%{name} before attempting to copy the file. I can 
create
> an account on my x86_64 machine if you want to check for your self, but the
> problem can easily be fixed either by adding the directory to the 
install-dirs
> rule in the top level Makefile, or by manually running mkdir -p
> %{buildroot}%{_libdir}/%{name} before running make install.
> 
> On the other hand, it seems kind of strange to me to install the scripts in
> libdir in the first place. Wouldn't the correct location be libexec?
> 
> 

Updated:
SRPM: http://chitlesh.fedorapeople.org/netgen/netgen-1.3.7-10.fc7.src.rpm
SPEC: http://chitlesh.fedorapeople.org/netgen/netgen.spec
logs: http://koji.fedoraproject.org/scratch/chitlesh/task_107798/
Comment 38 Mamoru TASAKA 2007-08-18 08:25:38 EDT
Well, still not good on 64 bits.

http://koji.fedoraproject.org/scratch/chitlesh/task_107798/logs/x86_64/build.log
says :

--------------------------------------------
checking for tkConfig.sh... /usr/lib64/tkConfig.sh
checking for wish executable... /usr/bin/wish
Can't find tcl library
Reverting to non-Tcl compile
checking for X... libraries , headers 
--------------------------------------------

Some detailed logs are found on:
http://koji.fedoraproject.org/koji/taskinfo?taskID=108275

I may try to check how to fix this after I finith commenting
on other review requests...
Comment 39 Chitlesh GOORAH 2007-08-21 06:54:13 EDT
Updated (without dumping the release):
SRPM: http://chitlesh.fedorapeople.org/netgen/netgen-1.3.7-10.fc7.src.rpm
SPEC: http://chitlesh.fedorapeople.org/netgen/netgen.spec
logs: http://koji.fedoraproject.org/scratch/chitlesh/task_111617/

changes:
%configure --with-tcl=%{_libdir}      --with-tk=%{_libdir} \
           --with-tcllibs=%{_libdir}  --with-tklibs=%{_libdir}
Comment 40 Mamoru TASAKA 2007-08-22 08:16:32 EDT
One question.

* Desktop file
  - This package does not contain any desktop file. However
    xcircuit is also Tcl/Tk application and xcircuit has desktop
    file

    So may it be that netgen should also have desktop file?
Comment 41 Chitlesh GOORAH 2007-08-22 11:20:05 EDT
(In reply to comment #40)
>     So may it be that netgen should also have desktop file?

Yes, true. Netgen should have a desktop file.
However, is this the only issue (meanwhile I'm searching for an appropriate 
icon )?
Comment 42 Mamoru TASAKA 2007-08-22 11:22:55 EDT
(In reply to comment #41)
> However, is this the only issue (meanwhile I'm searching for an appropriate 
> icon )?

Yes
Comment 43 Chitlesh GOORAH 2007-08-22 12:08:12 EDT
Updated:
SRPM: http://chitlesh.fedorapeople.org/netgen/netgen-1.3.7-11.fc7.src.rpm
SPEC: http://chitlesh.fedorapeople.org/netgen/netgen.spec

The png is a screenshot taken on adder4 (an alliance's example) by me.
Its license is GPL+.
Comment 44 Mamoru TASAKA 2007-08-23 00:07:35 EDT
At least desktop-file-utils is missing from BR.
http://koji.fedoraproject.org/koji/taskinfo?taskID=121359
Comment 45 Chitlesh GOORAH 2007-08-23 05:46:19 EDT
Updated: (without dumping the release)
SRPM: http://chitlesh.fedorapeople.org/netgen/netgen-1.3.7-11.fc7.src.rpm
SPEC: http://chitlesh.fedorapeople.org/netgen/netgen.spec
Comment 46 Chitlesh GOORAH 2007-08-23 07:22:12 EDT
Please hold on. I'll make a new release soon today.
Actually the desktop files of my applications point 
to "Education;Science;Engineering".

In fact this is wrong and should be changed to "Science;Engineering" 
or "Science;Electronics" as stated by 
http://standards.freedesktop.org/menu-spec/latest/apa.html

Additional Category - Description                        - Related Categories
Electronics  -  Electronics software, e.g. a circuit designer    - [ ]
Engineering  -  Engineering software, e.g. CAD programs    - [ ]

For "netgen", I'll use:

   [Desktop Entry]
   Categories=Science;Electronics;

I'll produce patches for other packages for electronic simulation and data 
computing (that others are packaging, such as qucs, octave, pikdev,..) and 
requests the changes on rawhide soon. At the same time, I'll be filing bugs 
for duplicate entries.

Since those packages are not meant for "Education" (but instead Engineering), 
the category "Education" is inappropriate.

Meanwhile your thoughts are welcome.
Comment 48 Mamoru TASAKA 2007-08-23 11:36:44 EDT
Okay,

--------------------------------------------------------
   This package (netgen) is APPROVED by me
--------------------------------------------------------
Comment 49 Chitlesh GOORAH 2007-08-23 11:43:33 EDT
New Package CVS Request
=======================
Package Name: netgen
Short Description: LVS netlist comparison tool
Owners: chitlesh
Branches: FC-6 F-7 devel
Comment 50 Kevin Fenzi 2007-08-23 16:24:27 EDT
cvs done.
Comment 51 Chitlesh GOORAH 2008-12-27 21:52:42 EST
Package Change Request
=======================
Package Name: netgen
Short Description: LVS netlist comparison tool
Owners: chitlesh
Branches: EL-5
Comment 52 Kevin Fenzi 2008-12-28 14:23:40 EST
cvs done.

Note You need to log in before you can comment on or make changes to this bug.