Bug 248649
Summary: | Review Request: alliance - Alliance VLSI CAD Sytem | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Chitlesh GOORAH <chitlesh> | ||||
Component: | Package Review | Assignee: | Nicolas Chauvet (kwizart) <kwizart> | ||||
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | rawhide | CC: | fedora-package-review, jean-paul.chaput, lxtnow, mtasaka, notting | ||||
Target Milestone: | --- | Flags: | kwizart:
fedora-review+
kevin: fedora-cvs+ |
||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2007-08-13 22:14:27 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Chitlesh GOORAH
2007-07-17 21:23:46 UTC
Starting review... 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. 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.... (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} ? 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 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 ? 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 ) (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. :) Updated: SRPM: http://chitlesh.fedorapeople.org/alliance/alliance-5.0-2.20060509snap.src.rpm SPEC: http://chitlesh.fedorapeople.org/alliance/alliance.spec New Upstream Release: SRPM: http://chitlesh.fedorapeople.org/alliance/alliance-5.0-3.20070718snap.src.rpm SPEC: http://chitlesh.fedorapeople.org/alliance/alliance.spec Ping ? 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) (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. Updated: SRPM: http://chitlesh.fedorapeople.org/alliance/alliance-5.0-4.20070718snap.fc8.src.rpm SPEC: http://chitlesh.fedorapeople.org/alliance/alliance.spec Build.log (i386): http://chitlesh.fedorapeople.org/alliance/build.log * 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...) Created attachment 160109 [details]
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...)
Updated: SRPM: http://chitlesh.fedorapeople.org/alliance/alliance-5.0-5.20070718snap.fc8.src.rpm 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 ping ? 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...) (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. (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. (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 ? Updated: SRPM: http://chitlesh.fedorapeople.org/alliance/alliance-5.0-6.20070718snap.fc8.src.rpm 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 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#menu-item-tooltips And specially uses verbs in the comments line... (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. Updated: SRPM: http://chitlesh.fedorapeople.org/alliance/alliance-5.0-7.20070718snap.fc8.src.rpm 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 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 --------------------- New Package CVS Request ======================= Package Name: alliance Short Description: Alliance VLSI CAD Sytem Owners: cgoorah.au Branches: FC-6 F-7 devel 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. Package Change Request ======================= Package Name: alliance Short Description: Alliance VLSI CAD Sytem Owners: chitlesh Branches: EL-5 cvs done. |