Spec URL: http://rishi.fedorapeople.org/autogen.spec SRPM URL: http://rishi.fedorapeople.org/autogen-5.9.4-1.fc8.src.rpm Description: AutoGen is a tool designed to simplify the creation and maintenance of programs that contain large amounts of repetitious text. It is especially valuable in programs that have several blocks of text that must be kept synchronised.
Koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=419598 I inherited this package from Paul F. Johnson few days back. Since this was last updated a year ago, I would like to pass this through a review. Important changes: + Package split into autogen, libopts, and libopts-devel to avoid multiple licensing scenario -- AutoOpts (or libopts) is BSD or LGPLv3+; while the rest of AutoGen is GPLv3+ with some portions being GPLv2+. AutoGen's GPLv2+ portions are being redistributed as GPLv3+. Debian also has a similar breakup. + Dropped 'Obsoletes: libopts ...' because the libopts source package was retired and superseded by autogen during FC-5 and according to the Naming Guidelines they should not be carried any further. What should be done to smoothen the change caused by the splitting of autogen as stated above?
Bumping priority because: + This was never built on PPC64 for no particular reason, it seems. + Prevents packages like Anjuta from getting built for PPC64.
(In reply to comment #2) > Bumping priority because: > > + This was never built on PPC64 for no particular reason, it seems. There was a bug on ppc64 (not sure if it is really resolved: bug 249138)
>> + This was never built on PPC64 for no particular reason, it seems. > There was a bug on ppc64 (not sure if it is really resolved: > bug 249138) Looks like that was due to a build failure. However that was quite a few releases back with autogen-5.8.9, and the latest release builds fine on PPC64. Strangely there is no ExcludeArch in the Spec for PPC64.
Well, first of all, the version of bundled autoopts seems 31.0.6. Is it possible to submit a seperated autoopts review request?
Back in the days of FC-5 and FC-6 Fedora's libopts (or autoopts) package was retired: http://cvs.fedoraproject.org/viewcvs/rpms/libopts/ Strangely the latest libopts tarball from upstream is versioned 27.6: http://gnu.glug-nith.org/libopts/rel27.6/ At the same time, Debian ships a libopts package that bears the same EVRA as autogen: http://packages.debian.org/experimental/libopts25 I took this option. Remember due to the multiple licensing scenario we have to separate the libopts (or autoopts) portion from the rest of autogen. What do you suggest?
There was also a autogen-manuals package according to the Spec in CVS. According to the %changelog, which is quite old, it was created to prevent some sort of conflict on F-7. The reason for this conflict is unclear to me. Therefore, I dropped it. It looks to me that the *.autogen suffix is not required because no other package seems to provide binaries of the same name. If that is so, we can drop the dependency on %{_sbindir}/alternatives. What do you think?
(In reply to comment #6) > Strangely the latest libopts tarball from upstream is versioned 27.6: > http://gnu.glug-nith.org/libopts/rel27.6/ > > At the same time, Debian ships a libopts package that bears the same EVRA as > autogen: http://packages.debian.org/experimental/libopts25 I took this option. > Remember due to the multiple licensing scenario we have to separate the libopts > (or autoopts) portion from the rest of autogen. > > What do you suggest? This is *only my opinion* I think that if you want to name the libopts related subrpm as "libopts" the version should be 31.0.6 (as autoopts-config --version surely returns this value) texlive maintainers use this method (i.e. they allow different versions for subpackage), however I really don't want this. _IMO_ it is better that libopts related packages are named to show explicitly that they are subpackages of autogen, i.e. they should be autogen-libopts-devel, for example (as we actually did so in tetex age) with the same EVR as autogen main package. (In reply to comment #7) > It looks to me that the *.autogen suffix is not required because no other > package seems to provide binaries of the same name. If that is so, we can drop > the dependency on %{_sbindir}/alternatives. If you don't know why alternatives is used here (note that I don't know either) it should just be dropped.
> _IMO_ it is better that libopts related packages are named to show explicitly > that they are subpackages of autogen I like this. > If you don't know why alternatives is used here (note that I > don't know either) it should just be dropped. Alright.
Spec: http://rishi.fedorapeople.org/autogen.spec SRPM: http://rishi.fedorapeople.org/autogen-5.9.4-2.fc8.src.rpm
For 5.9.4-2: * autogen-manuals - new autogen package should "obsolete" this package. ? BR: chrpath - Well, would you try to remove rpath by not using chrpath? ("Removing Rpath" of http://fedoraproject.org/wiki/Packaging/Guidelines ) Using chrpath should be considered as a last resort.. Usually modifying libtool (or make LIBTOOL=%{_bindir}/libtool) removes rpath. * License tag (See License-check.log) - Actually as %{_includedir}/autoopts/options.h (and so on) is LGPLv3+, "BSD or" part must be deleted. * defattr - We now recommend %defattr(-,root,root,-) * pkgconfig file - Well, autoopts.pc file contains ------------------------------------------------------------- 11 ldopts="-Wl,-R" 25 Libs: -Wl,-R/usr/lib -L/usr/lib -lopts ------------------------------------------------------------- "-Wl,-R" sets rpath and this must be deleted. ! multilib conflict - autoopts/autoopts-config.in contains ------------------------------------------------------------- 20 libdir="@libdir@" ------------------------------------------------------------- or so, which differs between on 32bit arch and on 64bit arch. So this causes multilib conflict. Please try to resolve this conflict. http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks * Undefined non weak symbols - libguileopts.so has undefined non-weak symbols From rpmlint (on i386): ------------------------------------------------------------- autogen-libopts.i386: W: undefined-non-weak-symbol /usr/lib/libguileopts.so.0.0.1 scm_i_master_freelist autogen-libopts.i386: W: undefined-non-weak-symbol /usr/lib/libguileopts.so.0.0.1 scm_i_master_freelist2 autogen-libopts.i386: W: undefined-non-weak-symbol /usr/lib/libguileopts.so.0.0.1 scm_cells_allocated autogen-libopts.i386: W: undefined-non-weak-symbol /usr/lib/libguileopts.so.0.0.1 scm_i_freelist autogen-libopts.i386: W: undefined-non-weak-symbol /usr/lib/libguileopts.so.0.0.1 scm_i_freelist2 autogen-libopts.i386: W: undefined-non-weak-symbol /usr/lib/libguileopts.so.0.0.1 scm_gc_for_newcell autogen-libopts.i386: W: undefined-non-weak-symbol /usr/lib/libguileopts.so.0.0.1 gh_eval_str ------------------------------------------------------------- ( you can check this also by "ldd -r /usr/lib/libguileopts.so") libguileopts.so is in -devel package, i.e. used for linkage so leaving these symbols is not allowed because this causes linkage failure. * scriptlets - For /sbin/install-info, for some reason Fedora requests to use -------------------------------------------------------------- /sbin/install-info %{_infodir}/%{name}.info %{_infodir}/dir || : ^^^^ -------------------------------------------------------------- http://fedoraproject.org/wiki/Packaging/ScriptletSnippets
(In reply to comment #11) > * autogen-manuals > - new autogen package should "obsolete" this package. Fixed. > ? BR: chrpath > - Well, would you try to remove rpath by not using chrpath? > ("Removing Rpath" of > http://fedoraproject.org/wiki/Packaging/Guidelines ) > Using chrpath should be considered as a last resort.. + there is no --disable-rpath option in configure + using sed to modify libtool as shown in Wiki causes build failure Is it worth trying to modify the code/Makefiles as mentioned in the Wiki? I did not try it because they say it is "not always easy or sane to do". > * License tag > (See License-check.log) > - Actually as %{_includedir}/autoopts/options.h (and so on) > is LGPLv3+, "BSD or" part must be deleted. Changed dual licensing of autogen-libopts-devel by dropping BSD. > * defattr > - We now recommend %defattr(-,root,root,-) Fixed. > * pkgconfig file > - Well, autoopts.pc file contains > ------------------------------------------------------------- > 11 ldopts="-Wl,-R" > 25 Libs: -Wl,-R/usr/lib -L/usr/lib -lopts > ------------------------------------------------------------- > "-Wl,-R" sets rpath and this must be deleted. Fixed. > ! multilib conflict > - autoopts/autoopts-config.in contains > ------------------------------------------------------------- > 20 libdir="@libdir@" > ------------------------------------------------------------- > or so, which differs between on 32bit arch and on 64bit arch. > So this causes multilib conflict. Please try to resolve this > conflict. > http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks Ok. However, some pkgconfig files (eg., cairo.pc) have: [...] libdir=/usr/lib64 [...] Libs: -L${libdir} -lcairo [...] Since the above write-up is a draft, I just want to confirm from you. > * Undefined non weak symbols > - libguileopts.so has undefined non-weak symbols Fixed. > * scriptlets > - For /sbin/install-info, for some reason Fedora requests > to use Fixed. Spec: http://rishi.fedorapeople.org/autogen.spec SRPM: http://rishi.fedorapeople.org/autogen-5.9.4-3.fc8.src.rpm Koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=466283
I have not checked this yet, however I just write some comments (In reply to comment #12) > > ? BR: chrpath > > - Well, would you try to remove rpath by not using chrpath? > > ("Removing Rpath" of > > http://fedoraproject.org/wiki/Packaging/Guidelines ) > > Using chrpath should be considered as a last resort.. > > + there is no --disable-rpath option in configure > + using sed to modify libtool as shown in Wiki causes build failure > > Is it worth trying to modify the code/Makefiles as mentioned in the Wiki? I did > not try it because they say it is "not always easy or sane to do". - Actually ------------------------------------------------------------------ make %{__smp_mflags} LIBTOOL=%{_bindir}/libtool ------------------------------------------------------------------ removed rpath as expected (please check the result of http://koji.fedoraproject.org/koji/taskinfo?taskID=466340 http://koji.fedoraproject.org/koji/taskinfo?taskID=466331 ) > > > * License tag > > (See License-check.log) > > - Actually as %{_includedir}/autoopts/options.h (and so on) > > is LGPLv3+, "BSD or" part must be deleted. > > Changed dual licensing of autogen-libopts-devel by dropping BSD. - Also the license of autogen-libopts should be changed to just LGPLv3+ as the libraries in -libopts uses the header files in issue. > > ! multilib conflict > > - autoopts/autoopts-config.in contains > > ------------------------------------------------------------- > > 20 libdir="@libdir@" > > ------------------------------------------------------------- > > or so, which differs between on 32bit arch and on 64bit arch. > > So this causes multilib conflict. Please try to resolve this > > conflict. > > http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks > > Ok. However, some pkgconfig files (eg., cairo.pc) have: > [...] > libdir=/usr/lib64 > [...] > Libs: -L${libdir} -lcairo > [...] > > Since the above write-up is a draft, I just want to confirm from you. - pkgconfig files are no problems because they uses different directories between 32 bits <-> 64 bits (%{_libdir}/pkgconfig, not /usr/lib/pkgconfig). On the other hand it must be checked that 64 bits pkgconfig file does not use /usr/lib but uses /usr/lib64 correctly.
(In reply to comment #13) > ------------------------------------------------------------------ > make %{__smp_mflags} LIBTOOL=%{_bindir}/libtool The Wiki does not mention this method, although I have seen it before. :-) Is this preferred above using chrpath? I am asking because if it is so, then I need to fix some of my existing packages.
I can say that using LIBTOOL=%{_bindir}/libtool is more preferable way to fix rpath issues than to using Fedora specific chrpath binary and I saw several people are actually using this method.
Spec: http://rishi.fedorapeople.org/autogen.spec SRPM: http://rishi.fedorapeople.org/autogen-5.9.4-4.fc8.src.rpm To omit unused direct shared library dependencies, I copied /usr/bin/libtool and modified it as before.
(In reply to comment #11) > For 5.9.4-2: > > * autogen-manuals > - new autogen package should "obsolete" this package. Well, I wrote so, however also now autogen can "provide" autogen-manuals (= %{name}-%{version}). Other things are okay. ------------------------------------------------------------------------ This package (autogen) is APPROVED by me ------------------------------------------------------------------------
Package Change Request ====================== Package Name: autogen Updated Fedora Owners: rishi Updated Description: Automated text file generator Updated Cvsextras Commits: yes I inherited this from Paul F. Johnson and everything should already be in place, but just in case...
Yeah, everything seems in place to me... feel free to reset the flag if you need anything.
(In reply to comment #17) > > * autogen-manuals > > - new autogen package should "obsolete" this package. > > Well, I wrote so, however also now autogen can "provide" > autogen-manuals (= %{name}-%{version}). Fixed.
Package Change Request ====================== Package Name: autogen New Branches: el6 Owners: green InitialCC: Please branch this for el6. Thanks, AG
Git done (by process-git-requests).