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.
Successful Koji builds for F-10, F-11 and EL-5 at: http://koji.fedoraproject.org/koji/taskinfo?taskID=1658001 http://koji.fedoraproject.org/koji/taskinfo?taskID=1658004 http://koji.fedoraproject.org/koji/taskinfo?taskID=1658007
- 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
#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
#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
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
Removed ldconfig post, postun for -devel package. Updated: Spec URL: http://shakthimaan.fedorapeople.org/SPECS/vrq.spec SRPM URL: http://shakthimaan.fedorapeople.org/SRPMS/vrq-1.0.58-2.fc11.src.rpm Successful Koji builds for F-10, F-11 and EL-5 at: http://koji.fedoraproject.org/koji/taskinfo?taskID=1673764 http://koji.fedoraproject.org/koji/taskinfo?taskID=1673831 http://koji.fedoraproject.org/koji/taskinfo?taskID=1673844
Approved.
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?
@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.
(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)
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.
Removed %post{,un} -p /sbin/ldconfig. Updated: SPEC: http://shakthimaan.fedorapeople.org/SPECS/vrq.spec SRPM: http://shakthimaan.fedorapeople.org/SRPMS/vrq-1.0.58-3.fc11.src.rpm Successful Koji builds for F10, F11 and EL-5: http://koji.fedoraproject.org/koji/taskinfo?taskID=1675377 http://koji.fedoraproject.org/koji/taskinfo?taskID=1675394 http://koji.fedoraproject.org/koji/taskinfo?taskID=1675397
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
cvs done.
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
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
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
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.
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.
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
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
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.
All packages have been mass branched for f12 already. do a 'cvs update -d' to make sure you pick up the new directory.