Bug 521458 - Review Request: vrq - Verilog tool framework with plugins for manipulating source code
Summary: Review Request: vrq - Verilog tool framework with plugins for manipulating so...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Chitlesh GOORAH
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-06 06:05 UTC by Shakthi Kannan
Modified: 2009-10-10 22:19 UTC (History)
3 users (show)

Fixed In Version: 1.0.58-3.el5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-09-15 07:42:42 UTC
chitlesh: fedora-review+
kevin: fedora-cvs+


Attachments (Terms of Use)

Description Shakthi Kannan 2009-09-06 06:05:07 UTC
Spec URL: http://shakthimaan.fedorapeople.org/SPECS/vrq.spec
SRPM URL: http://shakthimaan.fedorapeople.org/SRPMS/vrq-1.0.56-1.fc11.src.rpm

Description: VRQ is modular verilog parser that supports plugin tools to process verilog. Multiple tools may be invoked in a pipeline fashion within a single execution of vrq. It is a generic front-end parser with support for plugin backend customizable tools.

Comment 2 Shakthi Kannan 2009-09-08 17:12:38 UTC
- Added Requires for -devel section as it is a MUST requirement.
- Added post, postun for -devel package as well.
- Cleaned up .la files in the shipped package.
- Replaced rm with __rm usage.

Spec URL: http://shakthimaan.fedorapeople.org/SPECS/vrq.spec
SRPM URL: http://shakthimaan.fedorapeople.org/SRPMS/vrq-1.0.56-2.fc11.src.rpm

Successful Koji builds for F-10, F-11 and EL-5 at:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1662808
http://koji.fedoraproject.org/koji/taskinfo?taskID=1662881
http://koji.fedoraproject.org/koji/taskinfo?taskID=1662913

Comment 3 Chitlesh GOORAH 2009-09-08 19:11:52 UTC
#001 ExclusiveArch:  %{ix86} x86_64
Add a comment to the spec file explaining the reason for this line.

#002: Remove perl from BR
Your http://koji.fedoraproject.org/koji/getfile?taskID=1662810&name=root.log shows that perl was installed as part of the build system minimal package set, then afterwards koji reads what you have listed as BR.

#003: Add a check section before %clean:

------------------
# Fedora Electronic Lab: Package Self Check
%check
%{__make} check
------------------

make check fails. Please notify upstream for correction. Since he is quite responsive maybe he can dump a new release. Please invite him to add himself as CC: or comaintainer of this package.

running 'builder-search' test...
  subtest: case1...diff: regression/builder-search/case1.v: No such file or directory
 fail 
FAIL: builder3.pl



#004: Preserve timestamps during make install
add the following to your make install : INSTALL="%{_bindir}/install -p"

#005: use make macro everything %{__make}


#006: No need to package the %docs twice.
Both main package and subpackage should not own
%doc README COPYING doc/html/ doc/latex/

#007: replace your %make install process :
--------------------------
make prefix=%{buildroot}%{_prefix} \
     bindir=%{buildroot}%{_bindir} \
     libdir=%{buildroot}%{_libdir} \
     includedir=%{buildroot}%{_includedir} \
     mandir=%{buildroot}%{_mandir}  \
install 
-------------------
by

%{__make} INSTALL="%{_bindir}/install -p" install DESTDIR=%{buildroot}

after you have added the following in %prep
%{__sed} -i "s|^MYDOCDIR = |MYDOCDIR = \$(DESTDIR)|" doc/Makefile*

#008: Both doc/html/ and doc/latex/ seem to be outputs of doxygen. Should not we just take doc/html (-devel package)?

#009: doc/faq.html should be added to %doc of the main package

#010: contents of %{_datadir}/%{name}-%{version}/ should be in %doc of the main package

Comment 4 Shakthi Kannan 2009-09-10 16:58:24 UTC
#001 Done
#002 Done
#003 Done. New upstream package released, vrq-1.0.58.
#004 Done
#005 Done
#006 Done
#007 Done
#008 Done. Now using only doc/html in -devel
#009 Done
#010 Upstream has moved everything to %doc, and I have moved examples* to -devel.

Upstream was notified of necessary changes, and vrq-1.0.58 was released. Now packaged:

Spec URL: http://shakthimaan.fedorapeople.org/SPECS/vrq.spec
SRPM URL: http://shakthimaan.fedorapeople.org/SRPMS/vrq-1.0.58-1.fc11.src.rpm

Successful Koji builds for F-10, F-11 and EL-5 at:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1668521
http://koji.fedoraproject.org/koji/taskinfo?taskID=1668543
http://koji.fedoraproject.org/koji/taskinfo?taskID=1668565

Comment 5 Chitlesh GOORAH 2009-09-12 17:16:28 UTC
the devel subpackage should not contain these scriptlets as it does not contain any shared libraries

%post devel -p /sbin/ldconfig
%postun devel -p /sbin/ldconfig

---------------------------------------------------------------------------
- MUST: The package is named according to the Package Naming Guidelines.
- MUST: The spec file name matches the base package %{name}
- MUST: The package meets the Packaging Guidelines.
- MUST: The package is licensed with an open-source compatible license
and meet other legal requirements as defined in the legal section of Packaging
Guidelines.
- MUST: The License field in the package spec file matches the actual license.
- MUST: the source package includes the text of the license(s) in its own file,
then that file, containing the text of the license(s) for the package is
included in %doc.
- MUST: The spec file must be written in American English.
- MUST: The spec file for the package is be legible. 
- MUST: The sources used to build the package must matches the upstream source,
as provided in the spec URL.
- MUST: The package successfully compiles and builds into binary rpms on at
least i386.
- MUST: All build dependencies is listed in BuildRequires.
- MUST: The spec file handles locales properly.
- MUST: If the package does not contain shared library files located in the
dynamic linker's default paths
- MUST: the package is not designed to be relocatable
- MUST: the package owns all directories that it creates.
- MUST: the package does not contain any duplicate files in the %files listing.
- MUST: Permissions on files are set properly.
- MUST: The package has a %clean section, which contains rm -rf %{buildroot}
(or $RPM_BUILD_ROOT).
- MUST: The package consistently uses macros, as described in the macros
section
of Packaging Guidelines.
- MUST: The package contains code, or permissable content. This is described in
detail in the code vs. content section of Packaging Guidelines.
- MUST: There are no Large documentation files
- MUST: %doc does not affect the runtime of the application. To summarize: If
it is in %doc, the program must run properly if it is not present.
- MUST: There are no Header files or static libraries 
- MUST: The package does not contain library files with a suffix 
- MUST: Package does NOT contain any .la libtool archives
- MUST: Package containing GUI applications includes a %{name}.desktop file,
and that file must be properly installed with desktop-file-install in the %install
section.
- MUST: Package does not own files or directories already owned by other
packages. 

SHOULD Items:

 - SHOULD: The source package does include license text(s) as COPYING
 - SHOULD: mock builds succcessfully in i386.
 - SHOULD: The reviewer tested that the package functions as described. A
package should not segfault instead of running, for example.


Please update the spec accordingly for approval

Comment 7 Chitlesh GOORAH 2009-09-12 19:25:57 UTC
Approved.

Comment 8 Mamoru TASAKA 2009-09-12 19:52:10 UTC
Well, 
- actually even "%post{,un} -p /sbin/ldconfig" is also unneeded
  for this package because no libraries are installed under default
  library search paths (some binaries are installed under
  %_libdir/%name but not %_libdir)

- By the way build.log shows lots of warnings like
-------------------------------------------------------------
Generating annotated compound ish: epstopdf: command not found
Error: Problems running epstopdf. Check your TeX installation!
sh: epstopdf: command not found
Error: Problems running epstopdf. Check your TeX installation!
-------------------------------------------------------------
  Would you check if BRs are correct?

Comment 9 Shakthi Kannan 2009-09-13 12:17:16 UTC
@Mamoru Tasaka (Comment #8):

---
| some binaries are installed under
| %_libdir/%name but not %_libdir
\--

In 'man ld-linux', it states that the dynamic linker/loader also searches /usr/lib if it doesn't find the library in /lib. Isn't it not recursive?

---
| Error: Problems running epstopdf. Check your TeX installation!
\--

Upstream has reported that the .tex files have been generated with doyxgen, and thus has no control over it. We are not packaging .tex files in the RPM.

Comment 10 Mamoru TASAKA 2009-09-13 16:03:55 UTC
(In reply to comment #9)
> @Mamoru Tasaka (Comment #8):
> ---
> | some binaries are installed under
> | %_libdir/%name but not %_libdir
> \--
> 
> In 'man ld-linux', it states that the dynamic linker/loader also searches
> /usr/lib if it doesn't find the library in /lib. Isn't it not recursive?

- No, it is not recursive.

> ---
> | Error: Problems running epstopdf. Check your TeX installation!
> \--
> 
> Upstream has reported that the .tex files have been generated with doyxgen, and
> thus has no control over it. We are not packaging .tex files in the RPM.

- What I am saying is it is needed to check if "BuildRequires: texlive-utils"
 is needed or not (as epstopdf is in texlive-utils)

Comment 11 Chitlesh GOORAH 2009-09-13 16:19:27 UTC
Shakthi remove the
%post{,un} -p /sbin/ldconfig"

Mamoru, no need to add texlive-utils as BR as there is no use of adding both html and latex outputs of doxygen. They provide the same information. Hence vrq opted for html only. Then it makes no sense compiling the latex files into a pdf.

Comment 13 Shakthi Kannan 2009-09-13 18:51:35 UTC
New Package CVS Request
=======================
Package Name: vrq
Short Description: Verilog tool framework with plugins for manipulating source code
Owners: shakthimaan chitlesh
Branches: F-10 F-11 EL-5

Comment 14 Kevin Fenzi 2009-09-14 04:53:09 UTC
cvs done.

Comment 15 Fedora Update System 2009-09-14 16:04:34 UTC
vrq-1.0.58-3.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/vrq-1.0.58-3.fc11

Comment 16 Fedora Update System 2009-09-14 16:04:40 UTC
vrq-1.0.58-3.el5 has been submitted as an update for Fedora EPEL 5.
http://admin.fedoraproject.org/updates/vrq-1.0.58-3.el5

Comment 17 Fedora Update System 2009-09-14 16:04:45 UTC
vrq-1.0.58-3.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/vrq-1.0.58-3.fc10

Comment 18 Fedora Update System 2009-09-15 07:42:37 UTC
vrq-1.0.58-3.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 19 Fedora Update System 2009-09-15 07:51:07 UTC
vrq-1.0.58-3.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 20 Shakthi Kannan 2009-10-10 12:51:21 UTC
Successful Koji F-12 build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1739353

Package Change Request
=======================
Package Name: vrq
Short Description: Verilog tool framework with plugins for manipulating source
code
Owners: shakthimaan chitlesh
New Branches: F-12

Comment 21 Chitlesh GOORAH 2009-10-10 13:38:07 UTC
Please don't forget to file a ticket to the release engineers as well asking them to tag vrq for F-12

https://fedorahosted.org/rel-eng

Comment 22 Fedora Update System 2009-10-10 20:26:18 UTC
vrq-1.0.58-3.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 23 Kevin Fenzi 2009-10-10 22:19:51 UTC
All packages have been mass branched for f12 already. 

do a 'cvs update -d' to make sure you pick up the new directory.


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