Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
Summary: Review Request: alliance - Alliance VLSI CAD Sytem Product: Fedora Version: devel Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: Package Review AssignedTo: nobody@fedoraproject.org ReportedBy: cgoorah@yahoo.com.au QAContact: extras-qa@fedoraproject.org CC: fedora-package-review@redhat.com,notting@redhat.com
Spec URL: http://tux.u-strasbg.fr/~chit/alliance/F-8/alliance.spec SRPM URL: http://tux.u-strasbg.fr/~chit/alliance/F-8/alliance-5.0-1.fc8.src.rpm Description: Alliance is a complete set of free CAD tools and portable libraries for VLSI design. It includes a VHDL compiler and simulator, logic synthesis tools, and automatic place and route tools.
A complete set of portable CMOS libraries is provided, including a RAM generator, a ROM generator and a data-path compiler.
Alliance is the result of more than ten years effort spent at ASIM department of LIP6 laboratory of the Pierre et Marie Curie University (Paris VI, France).
Alliance has been used for research projects such as the 875 000 transistors StaCS superscalar microprocessor and 400 000 transistors IEEE Gigabit HSL Router.
Alliance provides CAD tools covering most of all the digital design flow:
* VHDL Compilation and Simulation * Model checking and formal proof * RTL and Logic synthesis * Data-Path compilation * Macro-cells generation * Place and route * Layout edition * Netlist extraction and verification * Design rules checking
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: alliance - Alliance VLSI CAD Sytem
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
kwizart@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|nobody@fedoraproject.org |kwizart@gmail.com
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: alliance - Alliance VLSI CAD Sytem
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
kwizart@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag| |fedora-review?
------- Additional Comments From kwizart@gmail.com 2007-07-17 17:33 EST ------- Starting review...
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: alliance - Alliance VLSI CAD Sytem
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
------- Additional Comments From cgoorah@yahoo.com.au 2007-07-17 17:45 EST ------- Some notes about this package: #1: this is a Hardware Development CAD. The headers included in the main package are not an error or a mistake, but useful for some %_bindir/*. In other words, it is important for the working(normal) environment of the user. (note: don't get confuse with headers of a normal application and the hardware CAD)
#2: The design tools at %_bindir/* are used in a collectively way following the design flow. http://www-asim.lip6.fr/recherche/alliance//doc/design-flow/flow.html If one of the %_bindir/* is buggy it may affect the entire design flow.
#3: I wrote a simple tutorial for trial: http://chitlesh.googlepages.com/full_adder_alliance
#4: Alliance depends heavily on %{prefix} (careful not %{_prefix}). Most of the sources have hardcoded paths to %{prefix}. Patching the dozens of Makefiles isn't enough.
#5: Makefiles on the -doc Makefiles are present in alliance-examples/*. It is normal because * it gives the VLSI designer a template on how to create his own Makefile for alliance (VLSI designers normally don't know how to do so) * it is not part of the build, but part of the _working_ environment of the user
#6: on the build.log there are lines about : libtool: install: warning: `/builddir/build/BUILD/alliance-5.0/mbk/src/libMut.la' has not been installed in `/usr/lib' I have no idea what to do with it. Any suggestion is welcome. http://tux.u-strasbg.fr/~chit/alliance/F-8/build.log
I tried to comment as much as I can on the SPEC file.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: alliance - Alliance VLSI CAD Sytem
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
------- Additional Comments From kwizart@gmail.com 2007-07-17 21:53 EST ------- Ok so few comments to start: 1 / prefix seems problematic. But since no arch dependant files are installed in it, this could be fine if we can have configs files in /etc actually... Also no %config(no replace) seems to be used for users config files...
2 / evr problem The source has 20060509 but this do not appear in evr wheras this should appear inside the release tag (if release, then >= 1). Others sources have the same version (in OLD_RELEASES ). So this will need to add 20060509snap in the release field to make a difference.
3 / URL has changed to http://www-asim.lip6.fr/recherche/alliance/
4 / patches macros. - As the pacakge name is good why do you need to uses %{name}? this bring some confusion when looking for the patch instead of having the full name. - Some patches are backport from older version (+ is older than -) This mean that some patches could be usefull with later release ? I cannot see the aim of using %{version} in this case! Unless it will break patch historicy in cvs if no changes are made to the patch for later releases.
5 / desktop files * You missed Requires(post): desktop-file-utils Requires(postun): desktop-file-utils * I don't know if the shortcuts will be in the right category... * see scriplets - 11 /
6 / About the kindly requested https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00750.html Why do you choose not to show the "kindly requested" in %description ?
7 / %configure * This package do not conform to the standard paths and use a prefix with --with-alliance-top=%{prefix}. But, do you need to export it to make it work ? * --disable-static is avaible why don't you uses it ? Does it works ?
8 / # applying timestamps What do you mean by this ? This could go in %prep for Source7
9 / # documentation Why do you copy them it "." ? (you do not seems to use them after that...) It could be safer to copy all of them in a created __doc - This will need to be remove just before %install like: %{__rm} -rf %{buildroot} __doc
10 / #conflicts with man-pages and is a duplicate of log.1.gz This make rise the problem of too much generic names appear (Which I haven't checked yet). Maybe a renamed could be enought if the --program-prefix do not work if this apply.
11 / scriplets * %preun -p /sbin/ldconfig - This is unneeded * Recommand to have this if desktop file has a MimeType key. %post /sbin/ldconfig update-desktop-database &> /dev/null || :
%postun /sbin/ldconfig update-desktop-database &> /dev/null || :
12 / # duplicate and unstripped-binary-or-object %exclude %{_libdir}/debug * This is wrong on x86_64 and also uneeded (tested)
13 / %{_includedir}/* * header are presents in main but not in devel - Is it possible to sort those that should be used at runtime from those that are needed for developping alliance ?
14 / %{_mandir}/man?/* * Check if some of them shouldn't go in -devel
15 / #Makefiles are present in alliance-examples/* * Is it possible to have another sub-package for these examples (which will follow others rules of Requirement eventually ) * Having users to build them is %doc directory is not fair - Thoses can go in %{_datadir}/alliance/examples.
16 / build fails on x86_64 FC6: (i will give a retry ) /usr/bin/ld: cannot find -lMvg collect2: ld returned 1 exit status make[2]: *** [x2vy] Error 1 make[2]: *** Waiting for unfinished jobs....
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: alliance - Alliance VLSI CAD Sytem
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
------- Additional Comments From cgoorah@yahoo.com.au 2007-07-18 05:30 EST ------- (In reply to comment #3)
Ok so few comments to start: 1 / prefix seems problematic. But since no arch dependant files are
installed in
it, this could be fine if we can have configs files in /etc actually... Also no %config(no replace) seems to be used for users config files...
Would you like me to put configs files in /etc and just create a symbolic link to /usr/share/alliance/etc ? Note: without this link some %_bindir/* would be broken since this path is hardcoded into the sources.
#2 #3
Ok, will change appropriately.
4 / patches macros.
- As the pacakge name is good why do you need to uses %{name}? this bring
some
confusion when looking for the patch instead of having the full name.
- Some patches are backport from older version (+ is older than -) This mean
that some patches could be usefull with later release ? I cannot see the aim
of
using %{version} in this case! Unless it will break patch historicy in cvs
if no
changes are made to the patch for later releases.
They will break in cvs since upstream
Patch0: %{name}-%{version}-addphcon.patch
There are 2 bugs in this release: (on ocp and on boog) As for ocp, I've backported to the old release (20060218), till there is a fix. Concerning boog, upstream will be digging on it this week: https://www-asim.lip6.fr/wws/arc/alliance-users/2007-07/msg00017.html
Patch1: %{name}-%{version}-examples.patch (is for the documentation/alliance-examples folder) Patch2: %{name}-%{version}-run.patch (is for the documentation/alliance-run folder) Patch3: %{name}-%{version}-perms.patch (setting the proper permissions)
will be without %{version}.
5 / desktop files
- You missed
Requires(post): desktop-file-utils Requires(postun): desktop-file-utils
As agreed if MimeType key in desktop files is used, and will be using in the next release.
- I don't know if the shortcuts will be in the right category...
You mean in the menus ?
6 / About the kindly requested https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00750.html Why do you choose not to show the "kindly requested" in %description ?
There is no big reason behind it, except I had already agreed with upstream on a separate file before Tom proposed. The %description would be too long. I've included it into a separate file alliance.fedora. If you want me to change accordingly, I can do it.
7 / %configure
- This package do not conform to the standard paths and use a prefix with
--with-alliance-top=%{prefix}. But, do you need to export it to make it
work ?
You mean - export ALLIANCE_TOP=%{prefix} - %configure --prefix=%{prefix} --enable-alc-shared --disable-static + %configure --prefix=%{prefix} --enable-alc-shared \ --disable-static --with-alliance-top=%{prefix} ?
- --disable-static is avaible why don't you uses it ? Does it works ?
will use
8 / # applying timestamps What do you mean by this ? This could go in %prep for Source7
will move to %prep
9 / # documentation Why do you copy them it "." ? (you do not seems to use them after that...)
I need them in the -doc package.
10 / #conflicts with man-pages and is a duplicate of log.1.gz This make rise the problem of too much generic names appear (Which I haven't checked yet). Maybe a renamed could be enought if the --program-prefix do
not
work if this apply.
It is a duplicate of log.1.gz as well. I see no harm removing a duplicate.
11 / scriplets
- %preun -p /sbin/ldconfig - This is unneeded
- Recommand to have this if desktop file has a MimeType key.
%post /sbin/ldconfig update-desktop-database &> /dev/null || :
%postun /sbin/ldconfig update-desktop-database &> /dev/null || :
Will use MimeType key
12 / # duplicate and unstripped-binary-or-object %exclude %{_libdir}/debug
- This is wrong on x86_64 and also uneeded (tested)
On i386, I have debug files before the script /usr/lib/rpm/find-debuginfo.sh Is there a way to disable this thing and let /usr/lib/rpm/find-debuginfo.sh do the job ?
13 / %{_includedir}/*
- header are presents in main but not in devel - Is it possible to sort
those
that should be used at runtime from those that are needed for developping
alliance ?
will try
14 / %{_mandir}/man?/*
- Check if some of them shouldn't go in -devel
will try
15 / #Makefiles are present in alliance-examples/*
- Is it possible to have another sub-package for these examples (which
will
follow others rules of Requirement eventually )
- Having users to build them is %doc directory is not fair - Thoses can go
in
%{_datadir}/alliance/examples.
Ok, will be opting for a "alliance-examples" sub package.
16 / build fails on x86_64 FC6: (i will give a retry ) /usr/bin/ld: cannot find -lMvg collect2: ld returned 1 exit status make[2]: *** [x2vy] Error 1 make[2]: *** Waiting for unfinished jobs....
Are you using %{__make} %{?_smp_mflags} ?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: alliance - Alliance VLSI CAD Sytem
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
------- Additional Comments From cgoorah@yahoo.com.au 2007-07-18 05:37 EST ------- reply to comment #4)
(In reply to comment #3)
5 / desktop files
- You missed
Requires(post): desktop-file-utils Requires(postun): desktop-file-utils
As agreed if MimeType key in desktop files is used, and will be using in the next release.
Actually, I mean "will _not_ be using".
11 / scriplets
- %preun -p /sbin/ldconfig - This is unneeded
- Recommand to have this if desktop file has a MimeType key.
%post /sbin/ldconfig update-desktop-database &> /dev/null || :
%postun /sbin/ldconfig update-desktop-database &> /dev/null || :
Will use MimeType key
Again, will _not_ be using.
15 / #Makefiles are present in alliance-examples/*
- Is it possible to have another sub-package for these examples (which
will
follow others rules of Requirement eventually )
- Having users to build them is %doc directory is not fair - Thoses can
go
in
%{_datadir}/alliance/examples.
Ok, will be opting for a "alliance-examples" sub package.
After a second thought, does it make sense to have a sub package ? I'll be leaving it in -doc package
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: alliance - Alliance VLSI CAD Sytem
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
------- Additional Comments From cgoorah@yahoo.com.au 2007-07-18 15:53 EST ------- You will laugh at me, but the %{_libdir}/*.so is also required by the main package.
I was thinking about having 2 more sub-packages in order to comply with the packaging guidelines: - alliance-lib for %{_libdir}/*.so, and - alliance-headers for %{_includedir}/* both requiring alliance.
what do you think ?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: alliance - Alliance VLSI CAD Sytem
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
------- Additional Comments From kwizart@gmail.com 2007-07-18 16:48 EST ------- Whether both requiring alliance or both required by alliance, if you do so, there is no interest in splitting them... Actually -libs sub-packages are used to provide multibs compatibily on lib64 systems. This needed to have Requires %{main}-libs = %{evr} for -devel, but that's all. - If you uses Requires %{main}-libs on main, this only requires something that rpm would discover by itself... - If you uses Requires %{main} on -libs, then you will break multilibs compatibilty because you will bring i386 binaries into x86_64 repository (and binaries will share the same namespace in %{_bindir} which is wrong )
A good way to have multilibs compatibilty would be to have your prefix in %{_libdir}/alliance (with datadir shared in %{_datadir}/alliance if relevant)
About headers, If you can sort them, you can have %{_libdir}/alliance/include for runtime (with main ) and %{_includedir}/alliance for devel (or runtime headers in datadir - but i expect it will break some alliance_top prefix ?!)
That could be a good idea if you can uses relative path to find headers to have them in %{_datadir}/alliance/include if you have examples in %{_datadir}/alliance/examples , maybe...)
More Answears: 1 / leave this as is work for now... 4 / If upsteam change the name of the patches, you will need to import them into cvs 5 I mean the Menues indeed - I've experienced some problems whith packages that do not handle this in %post, so i don't know if this is mandatory or should. (depend if Minetype is present... anayway it seems not) 7 / indeed 9 / I still do not understand why you need to cp -pr them in "." since you do uses thoses files but thoses present in doc/* 10 / Can you see at which step this /usr/lib/debug directory is created in build.log ?
16 / alliance-examples would be fine as the content is really differents than -docs... (for example -docs may not requires main whereas examples will requires it - because examples may live in %{_datadir}/alliance )
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: alliance - Alliance VLSI CAD Sytem
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
------- Additional Comments From cgoorah@yahoo.com.au 2007-07-18 18:03 EST ------- (In reply to comment #7)
Whether both requiring alliance or both required by alliance, if you do so, there is no interest in splitting them...
I meant "both required by alliance. Ok, then I'll leave it as one package.
A good way to have multilibs compatibilty would be to have your prefix in %{_libdir}/alliance (with datadir shared in %{_datadir}/alliance if
relevant)
I guess you haven't understood the contents of %{_datadir}/alliance. It contains the what so called in electronics "libraries" of different electronic components. These "libraries" have nothing to do with the daily word 'libraries' you used in the fedora packaging. Those electronic components does not depend on any architecture ( i386 , x86_64, ppc ).
But however if I replace %{_datadir}/alliance by %{_libdir}/alliance, I fear I would break alliance further in terms of multilibs. We will have more bugs in alliance (which were not architecture ( i386 , x86_64, ppc ) dependent) which will vary from architecture to architecture. This is wrong and too risky!
more info: Those electronic components are provided by alliance as a startup. However when a VLSI designer will use alliance, he/she will eventually use other electronic components.
5 I mean the Menues indeed - I've experienced some problems whith packages
that
do not handle this in %post, so i don't know if this is mandatory or should. (depend if Minetype is present... anayway it seems not)
The desktop files are very simple and they should be pulled up in the menus. There is no need you use %post or %postun for these desktop files.
7 / indeed
well that's a choice. But the variable "ALLIANCE_TOP" will even be used by the user in his/her working environment (as in any other commercial equivalent to alliance). Exporting ALLIANCE_TOP in the spec makes it more oblivious for debugging purposes, not by me but those who will be using this spec file for troubleshooting. Upstream and I were thinking to use this spec file in other fedora derivatives. In other words, it makes life easier for troubleshooting (maintainance)and share bugfixes between distros!
9 / I still do not understand why you need to cp -pr them in "." since you
do
uses thoses files but thoses present in doc/*
those doc/* comes from %{__cp} -pr %{buildroot}%{prefix}/doc/ . Without %{__cp} -pr %{buildroot}%{prefix}/doc/, there is not doc/ directory. here the dot "." refers to the builddir, that is why it is in %files docs I specified only doc/* and not the absolute path.
Its mainly experience talking here: _Suppose_ I patch in the Makefiles so that during %install the contents of documentation would not be copied into the buildroot. Then remove %{__cp} -pr %{buildroot}%{prefix}/doc/ as you suggested. And pull the docs ony be one on %file docs.:
Each time upstream changes the makefiles or the contents of documentation/, I'll need to update my patch (eventually patches). Thus requiring me a lot of changes for each upstream release. And some contents are either not useful or duplicates (in terms of different format .pdf, .ps or .tex)
The contents of the docs (in this case) have already undergone a "make" in the tex/ directories. So right now the pdfs are simply copied to the %buildroot. But if upstream decides to make a "make" during %__make in the future to produce those pdfs from texs, I'll need to dig further and further. This is frustrating. It is simple to let %__make finish, then gather the bits.
You happend to see that I prefer everything being done in the SPEC file rather patching every single thing, in the end making life harder to debug or troubleshoot by me and others.
16 / alliance-examples would be fine as the content is really differents
than
-docs... (for example -docs may not requires main whereas examples will
requires
it - because examples may live in %{_datadir}/alliance )
hmm the release 1 might say so, because I missed some other directories in tutorials. In release 2, you will see that some docs come with its _own_ examples. :)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: alliance - Alliance VLSI CAD Sytem
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
------- Additional Comments From cgoorah@yahoo.com.au 2007-07-18 18:04 EST ------- Updated: SRPM: http://chitlesh.fedorapeople.org/alliance/alliance-5.0-2.20060509snap.src.rp... SPEC: http://chitlesh.fedorapeople.org/alliance/alliance.spec
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: alliance - Alliance VLSI CAD Sytem
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
------- Additional Comments From cgoorah@yahoo.com.au 2007-07-19 07:25 EST ------- New Upstream Release: SRPM: http://chitlesh.fedorapeople.org/alliance/alliance-5.0-3.20070718snap.src.rp... SPEC: http://chitlesh.fedorapeople.org/alliance/alliance.spec
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: alliance - Alliance VLSI CAD Sytem
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
------- Additional Comments From cgoorah@yahoo.com.au 2007-07-24 06:26 EST ------- Ping ?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: alliance - Alliance VLSI CAD Sytem
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
------- Additional Comments From kwizart@gmail.com 2007-07-24 12:23 EST ------- Review of version - release : 5.0-3.20070718snap * From Previous comments: - multilibs, As there is no more -devel package, the multilibs problems on repository is solved. This mean there is no headers to write plugins for alliance ? Then OK.
- 5 Ok for not using desktop-file-utils. But on my Gnome environnement, the menues are showed in Edutainment which is not a right name in my view (mostly because it is not translated) Also X-Desktop-File-Install-Version=0.10 in sources desktop files is wrong. This field is added at install time..Be carefull that desktop-file-install in F8 rawhide is no more permissive with theses littles errors. (not tested yet...)
- 7 / 9 / 16 : OK
- Still i don't understand why you used macro for name of patches. That might be better to have them in full name (as the name will not change)
* New comments: (now it builds in mock on x86_64) (rpmlint on rpm packages ) - Names are too generic. For headers in %{_includedir}/*.h and libraries in %{_libdir}/*.so, maybe you can at least uses a subdirectory with them (and put a path for in /etc/ld.so.conf.d ) When trying to install it: ----------- le fichier /usr/include/btr.h de l'installation de alliance-5.0-3.20070718snap.fc6 entre en conflit avec le fichier du paquetage mx-2.0.6-2.2.2 le fichier /usr/share/man/man3/log.3.gz de l'installation de alliance-5.0-3.20070718snap.fc6 entre en conflit avec le fichier du paquetage man-pages-2.39-7.fc6 ----------
- E: alliance non-executable-script /etc/alliance/attila.conf 0644 See why this is considered as script (may be safe to ignore... Also, maybe not all files in /etc/%{name} will need %config(no replace) This can be better to have only %{config} for some of them. For example if they are changing between release and need to be updated with no user choice... For files that depend on users choice , the better way could be to have files to be sourced in a sub-directory... (maybe not relevant, in this case...)
- W: alliance non-conffile-in-etc /etc/alliance/alc_env.csh Not sure it is the right place for it...?! why this have changed from profiles.d ?
(rpmlint on installed file : rpmlint alliance ) - Untested - (package cannot be installed becaue mx is in use)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: alliance - Alliance VLSI CAD Sytem
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
------- Additional Comments From cgoorah@yahoo.com.au 2007-07-24 15:47 EST ------- (In reply to comment #12)
Review of version - release : 5.0-3.20070718snap
- 5 Ok for not using desktop-file-utils. But on my Gnome environnement, the
menues are showed in Edutainment which is not a right name in my view
(mostly
because it is not translated)
All scientific apps of fedora are placed at that location: * ktechlab * geda/gaf * magic * xcircuit * qucs * labplot (to name a few)
Not sure it is the right place for it...?! why this have changed from
profiles.d ?
It has always been this way, i.e in all my releases there were 2 symbolic links on /etc/profile.d In my previous releases, the alc_env* scripts were at /usr/share/alliance/etc, in the release 3 they were moved to /etc/allliance.
I'll include your other comments in the release 4.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: alliance - Alliance VLSI CAD Sytem
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
------- Additional Comments From cgoorah@yahoo.com.au 2007-07-24 22:27 EST ------- Updated: SRPM: http://chitlesh.fedorapeople.org/alliance/alliance-5.0-4.20070718snap.fc8.sr... SPEC: http://chitlesh.fedorapeople.org/alliance/alliance.spec Build.log (i386): http://chitlesh.fedorapeople.org/alliance/build.log
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: alliance - Alliance VLSI CAD Sytem
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
------- Additional Comments From kwizart@gmail.com 2007-07-27 07:39 EST ------- * rpmlint on package: (only one of each) W: alliance devel-file-in-non-devel-package /usr/share/alliance/include/msl.h As taken as a compiler, this is acceptable, the path in acceptable also... W: alliance devel-file-in-non-devel-package /usr/share/alliance/lib/libCtp.so This one also, as this is not arch dependant...but this may lead to problem later...
But: E: alliance arch-dependent-file-in-usr-share /usr/share/alliance/lib/libBtr.so.1 .0.3 This one is wrong - This would be better to have them in libdir/alliance (with the previous symlink as i expect, it will be easier to have them in the same directory).
Also maybe this is related to our shlib problem we discussed on #IRC: "libtool: install: warning: `/builddir/build/BUILD/alliance-5.0/abt/src/libAbt.la' has not been installed in `/usr/share/alliance/lib'" Does the .la source file exist ?
Here are the output of "rpmlint alliance" on installed files: This is sometime the result of missing libraries LDFLAGS (see attachment)
Also i wonder if the binaries aren't subject to the same problem with generic names...(i have'nt checked this...)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: alliance - Alliance VLSI CAD Sytem
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
------- Additional Comments From kwizart@gmail.com 2007-07-27 07:45 EST ------- Created an attachment (id=160109) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=160109&action=vie...) rpmlint alliance (release 4) - problem with shlib
See if unused-direct-shlib-dependency and undefined-non-weak-symbol can be solved by adding the right links LDFLAGS for each library (or if this information have been lost during the prep of the build process...)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: alliance - Alliance VLSI CAD Sytem
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
------- Additional Comments From cgoorah@yahoo.com.au 2007-07-29 12:57 EST ------- Updated: SRPM: http://chitlesh.fedorapeople.org/alliance/alliance-5.0-5.20070718snap.fc8.sr... SPEC: http://chitlesh.fedorapeople.org/alliance/alliance.spec Build.log (i386): http://chitlesh.fedorapeople.org/alliance/build.log rpmlint: http://chitlesh.fedorapeople.org/alliance/rpmlint
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: alliance - Alliance VLSI CAD Sytem
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
------- Additional Comments From cgoorah@yahoo.com.au 2007-08-01 06:47 EST ------- ping ?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: alliance - Alliance VLSI CAD Sytem
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
------- Additional Comments From kwizart@gmail.com 2007-08-01 08:53 EST -------
Looking at build.log: This append in the %prep section * "/usr/share/texmf/web2c/mktexupd: /var/lib/texmf/ls-R unwritable." Maybe, there is something to change with this file in %post (%postun ), so the changes it tries to write, will be done in %post (if ever usefull...) * "Overfull \hbox (29.40456pt too wide) in paragraph at lines 258--260 []\T1/bch/b/n/10 GRAAL \T1/bch/m/n/10 uses the en-vi-ron-ment vari-able \T1/bch /b/n/10 GRAAL_TECHNO_NAME\T1/bch/m/n/10 . It must be set to \T1/bch/b/n/10 /al- liance/etc/cmos.graal\T1/bch/m/n/10 . " See if there is something to change with paths * "No file start.aux. / synthesis.aux."
* Files names are too generic: I still have a problem with theses files to be installed in _bindir as they are too generics... Is it possible to have prefixed named ? Another solution could be to uses bin in %{_libdir}/alliance/bin, then add the Path of the alliance binaries... (see the next comment about profile.d/alc_env.sh )
/usr/bin/a2def /usr/bin/a2lef /usr/bin/alcbanner /usr/bin/asimut /usr/bin/b2f /usr/bin/boog /usr/bin/boom /usr/bin/cougar /usr/bin/def2a /usr/bin/dreal /usr/bin/druc /usr/bin/exp /usr/bin/flatbeh /usr/bin/flatlo /usr/bin/flatph /usr/bin/flatrds /usr/bin/fmi /usr/bin/fsp /usr/bin/genlib /usr/bin/genpat /usr/bin/graal /usr/bin/k2f /usr/bin/l2p /usr/bin/loon /usr/bin/lvx /usr/bin/m2e /usr/bin/mips_asm /usr/bin/moka /usr/bin/nero /usr/bin/ocp /usr/bin/pat2spi /usr/bin/pdv /usr/bin/proof /usr/bin/ring /usr/bin/s2r /usr/bin/scapin /usr/bin/sea /usr/bin/seplace /usr/bin/seroute /usr/bin/sxlib2lef /usr/bin/syf /usr/bin/vasy /usr/bin/x2vy /usr/bin/x2y /usr/bin/xfsm /usr/bin/xpat /usr/bin/xsch /usr/bin/xvpn
* alc_env.csh and alc_env.sh should be marked as %config (no replace do not seems to usefull in this case) @DATE@ - this macro isn't expanded...
# System environment variables. PATH=$ALLIANCE_TOP/bin:$PATH export PATH * As previously talked with the prefix discution. $ALLIANCE_TOP is not arch independant from how upstream use it. So linking /usr/share/alliance/lib to /usr/lib64/alliance seems wrong (I expect it might be needed by the makefiles, is not, please remove this symlink). Thats because $ALLIANCE_TOP is not arch independant, that I would prefer to uses %{_libdir}/alliance (then using symlinks to /usr/share/alliance/$i from /usr/lib64/alliance/$i with $i as arch independant data - This seems more correct to me...)
* There might be some testing todo with selinux... (then ask the selinux-policy-maintainer to add special context if this is needed...)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: alliance - Alliance VLSI CAD Sytem
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
------- Additional Comments From cgoorah@yahoo.com.au 2007-08-01 09:35 EST ------- (In reply to comment #19)
Looking at build.log: This append in the %prep section
- "/usr/share/texmf/web2c/mktexupd: /var/lib/texmf/ls-R unwritable."
Maybe, there is something to change with this file in %post (%postun ), so
the
changes it tries to write, will be done in %post (if ever usefull...)
- "Overfull \hbox (29.40456pt too wide) in paragraph at lines 258--260
[]\T1/bch/b/n/10 GRAAL \T1/bch/m/n/10 uses the en-vi-ron-ment vari-able
\T1/bch
/b/n/10 GRAAL_TECHNO_NAME\T1/bch/m/n/10 . It must be set to
\T1/bch/b/n/10 /al-
liance/etc/cmos.graal\T1/bch/m/n/10 . " See if there is something to change with paths
- "No file start.aux. / synthesis.aux."
These are for pdf generation. That is for documentation.
The "unwritable" warning has no influence on the final pdf and also
chitlesh(~)[0]$rpm -qf /var/lib/texmf/ls-R tetex-fonts-3.0-34.fc6 chitlesh(~)[0]$rpm -qf /usr/share/texmf/web2c/mktexupd tetex-fonts-3.0-34.fc6
Documentation produced are used as tutorials and have nothing to do with modifying files from tetex-fonts.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: alliance - Alliance VLSI CAD Sytem
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
------- Additional Comments From cgoorah@yahoo.com.au 2007-08-01 12:09 EST ------- (In reply to comment #19)
- As previously talked with the prefix discution. $ALLIANCE_TOP is not arch
independant from how upstream use it.
chitlesh(~)[0]$ll /usr/share/alliance/ total 4 drwxr-xr-x 10 root root 4096 Jul 29 17:55 cells lrwxrwxrwx 1 root root 21 Jul 29 17:55 etc -> ../../../etc/alliance lrwxrwxrwx 1 root root 29 Jul 29 17:55 include -> ../../../usr/include/alliance lrwxrwxrwx 1 root root 25 Jul 29 17:55 lib -> ../../../usr/lib/alliance
The symbolic links are here to protect hardcorded bits of the codes that aren't dynamically set up during %configure. These symbolics links are here to meet _functionality_ when all the %{_bindir}/* are used at once( on a Makefile for example.)
Please take note that libraries are placed at %{_libdir}/%{name} during %configure --libdir=%{_libdir}/%{name}
As from the only "real" directory, cells which contains "technology files". Text files which specify the design rules of the respective technology.
The latter is _NOT_ a must in the alliance distribution. Since the user might want to use his/her technology. for example from: * http://www.vlsitechnology.org/ * commercial technologies
However the included cells are present so that one who doesn't have his/her own technology can use them for the first time.
I hope I clarified that this is not arch-dependent, and should not be %{_libdir} but %{_datadir}
Please also note, that once alliance is in the fedora collection, i'll start packaging the standard cells from http://www.vlsitechnology.org/, hence those will be placed in %{_datadir}, since there are only text files and images. Thus _not_ arch-dependent.
The way that upstream uses the $ALLIANCE_TOP variable is similar to most commercial vendors do.
But in my spec, these are split up in standard linux directories and made sure that users can still use $ALLIANCE_TOP. This variable IS NOT only for packagers or developers but users as well.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: alliance - Alliance VLSI CAD Sytem
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
------- Additional Comments From cgoorah@yahoo.com.au 2007-08-01 12:10 EST ------- (In reply to comment #19)
- There might be some testing todo with selinux... (then ask the
selinux-policy-maintainer to add special context if this is needed...)
Is there any reason why alliance might require selinux policies ?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: alliance - Alliance VLSI CAD Sytem
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
------- Additional Comments From cgoorah@yahoo.com.au 2007-08-07 10:18 EST ------- Updated: SRPM: http://chitlesh.fedorapeople.org/alliance/alliance-5.0-6.20070718snap.fc8.sr... SPEC: http://chitlesh.fedorapeople.org/alliance/alliance.spec Build.log (i386): http://chitlesh.fedorapeople.org/alliance/build.log rpmlint: http://chitlesh.fedorapeople.org/alliance/rpmlint
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: alliance - Alliance VLSI CAD Sytem
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
------- Additional Comments From kwizart@gmail.com 2007-08-12 09:54 EST ------- OK Exept for the cells (and all arch independant data) that should be in /usr/share/alliance, thoses directories seems rights... The aim is to sort arch dependant and arch-independant data.
But the remaining problems is about $alliance_top/{etc,cells,...}, Actually thoses directory are hardcoded in configure* and Makefile*, but that would be better to change them with autotools (to be set at configure step). So you will have something like @alliance_etc@ and @alliance_cells@
I think this would be better so upstream can merge thoses changes. I don't mean to re-run autotools but to have patches to that can be merged upstream...
About the desktop files (nices icons) Thoses links wasn't working has alliance_bin wasn't yet in the path... (I expect that it will be after a reboot)
I ever you wanted to make comment (and comment{fr] ) in you .desktop files, you have to follow : http://developer.gnome.org/projects/gup/hig/2.0/desktop-integration.html#men... And specially uses verbs in the comments line...
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: alliance - Alliance VLSI CAD Sytem
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
------- Additional Comments From cgoorah@yahoo.com.au 2007-08-12 10:30 EST ------- (In reply to comment #24)
The aim is to sort arch dependant and arch-independant data.
Ok, will do
But the remaining problems is about $alliance_top/{etc,cells,...}, Actually thoses directory are hardcoded in configure* and Makefile*, but that would
be
better to change them with autotools (to be set at configure step). So you
will
have something like @alliance_etc@ and @alliance_cells@
I think this would be better so upstream can merge thoses changes. I don't
mean
to re-run autotools but to have patches to that can be merged upstream...
should I do every upstream's job it as a packager? Would you block the review, if I don't ?
Thoses links wasn't working has alliance_bin wasn't yet in the path... (I expect that it will be after a reboot)
True
And specially uses verbs in the comments line...
Will do.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: alliance - Alliance VLSI CAD Sytem
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
------- Additional Comments From cgoorah@yahoo.com.au 2007-08-12 15:27 EST ------- Updated: SRPM: http://chitlesh.fedorapeople.org/alliance/alliance-5.0-7.20070718snap.fc8.sr... SPEC: http://chitlesh.fedorapeople.org/alliance/alliance.spec Build.log (i386): http://chitlesh.fedorapeople.org/alliance/build.log rpmlint: http://chitlesh.fedorapeople.org/alliance/rpmlint
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: alliance - Alliance VLSI CAD Sytem
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
kwizart@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|fedora-review? |fedora-review+
------- Additional Comments From kwizart@gmail.com 2007-08-13 09:15 EST ------- good!
* Works fine on installation/uninstallation (directory ownership is good) Beware that upgrading from previous reviewing packages it might leave from directory ownership problems (ie sprecially from the cells directory switch )
* Runtime test works
---------------------
This package ( alliance ) is APPROVED by me
---------------------
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: alliance - Alliance VLSI CAD Sytem
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
cgoorah@yahoo.com.au changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag| |fedora-cvs?
------- Additional Comments From cgoorah@yahoo.com.au 2007-08-13 11:16 EST ------- New Package CVS Request ======================= Package Name: alliance Short Description: Alliance VLSI CAD Sytem Owners: cgoorah@yahoo.com.au Branches: FC-6 F-7 devel
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: alliance - Alliance VLSI CAD Sytem
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
kevin@tummy.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|fedora-cvs? |fedora-cvs+
------- Additional Comments From kevin@tummy.com 2007-08-13 15:37 EST ------- cvs done. Note that the cvs template now should include your Fedora Account system name instead of email, and that there is a 'cvsextras can all commit' item.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: alliance - Alliance VLSI CAD Sytem
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248649
cgoorah@yahoo.com.au changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=248649
Chitlesh GOORAH cgoorah@yahoo.com.au changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|fedora-cvs+ |fedora-cvs?
--- Comment #30 from Chitlesh GOORAH cgoorah@yahoo.com.au 2008-11-10 10:11:15 EDT --- Package Change Request ======================= Package Name: alliance Short Description: Alliance VLSI CAD Sytem Owners: chitlesh Branches: EL-5
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=248649
Kevin Fenzi kevin@tummy.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|fedora-cvs? |fedora-cvs+
--- Comment #31 from Kevin Fenzi kevin@tummy.com 2008-11-10 11:56:32 EDT --- cvs done.
package-review@lists.fedoraproject.org