Spec URL: http://trac.assembla.com/bash-modules/export/107/bash-modules/branches/bash-modules-1.0.8/bash-modules/spec/bash-modules.spec SRPM URL: http://trac.assembla.com/bash-modules/attachment/wiki/WikiStart/bash-modules-1.0.8.83-1.fc14.noarch.rpm Description: Optional modules to use with bash, like log, argument parsing, etc. All modules are designed to work in strict mode (set -u -e) and well covered by test cases. PS. Home page: http://trac.assembla.com/bash-modules
Some quick comments: - Are you already a packager? I couldn't find you in fas... - When you use a svn checkout, you need to promote it differently in %{version}: https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Non-Numeric_Version_in_Release - use global instead of define: https://fedoraproject.org/wiki/Packaging:Guidelines#.25global_preferred_over_.25define - How did you generate the source? Either give a URL or add a comment, how you did the checkout. - What version of LGPL is this? LGPLv2+? (Didn't download sources because of the last issue above). - defattr looks odd and is not needed in Fedora (in el5 and below, if you want to branch for it) - The %changelog is missing. Please add a changelog everytime you change something and bump the release
I am new to Fedora project. My page: https://admin.fedoraproject.org/accounts/user/view/vlisivka . Spec file updated and package is rebuilt using Koji, see: https://trac.assembla.com/bash-modules/attachment/wiki/WikiStart/bash-modules.spec https://trac.assembla.com/bash-modules/attachment/wiki/WikiStart/bash-modules-1.0.8-3.fc15.src.rpm http://koji.fedoraproject.org/koji/taskinfo?taskID=3494475 > - use global instead of define: I eliminated %define completely in current version. I use my own versioning scheme to automate package versioning (SVN_RELEASE-RPM_RELEASE) on large projects with hundreds of packages developed by tens of developers. It uses maximum value of all file revisions in package directory in Subversion repository, thus version automatically bumps up when (and only when) a file is modified in this package source directory. This allows to automatically and determinately increase version every time when underlying file of package is changed, including it spec file. Can I use this versioning schema for packages in Fedora or I will need to change it to fit Fedora? > - How did you generate the source? I use my own build system for my projects, which builds binary packages using "rpmbuid -tb" or "rpmbuild -ts" and mock. Older packages on http://trac.assembla.com/bash-modules were generated by my build system on my home notebook with F14. Source package in koji was regenerated manually on my work computer with F15. > - What version of LGPL is this? LGPLv2+? I put COPYING.GPLv2 and COPYING.LGPL-2.1 license files into sources tarball. I also put following notice at top of each source file: bash-modules is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, either version 2.1 of the License, or (at your option) any later version. I hope this mean that these files are available under terms of LGPLv2.1+. > - defattr looks odd and is not needed in Fedora (in el5 and below, if you want to branch for it) I want to promote my package to EPEL5+ and Fedora14+. Should I remove %defattr and state attribute of each file explicitly? > The %changelog is missing. Please add a changelog everytime you change something OK, I will use rpmdev-bumpspec in future. Just discovered it. :-) However, rpmdev-bumpspec eats "%" in "Release: 3%{?dist}" in my case, so rpbuild cannot build spec file modified by rpmdev-bumpspec. :-/
> However, rpmdev-bumpspec eats "%" in "Release: 3%{?dist}" in my case, so rpbuild cannot build spec file modified by rpmdev-bumpspec. :-/ Ignore that - it was glitch of my editor.
Ping.
Adding FE-NEEDSPONSOR.
Hello Volodymyr , are you still interested to package this? In case you are you will have to update SPEC removing deprecated stuff like buildroot. Let me know if you are and we will try to get some attention here. VM
Yes, I am still interested to package this. However, I am author of that code, so I am unsure is I should be packager for it too. Latest version of bash-modules package is on github now: https://github.com/vlisivka/bash-modules . I am preparing for 2.0 release.
Built packages are here: https://build.opensuse.org/project/show/home%3Avlisivka%3Abash-modules .
Hello , let me know if you will have time to rewrite the specfile. If not i can try to do it for you and package this one. VM
Yes, I have time to rewrite the specfile. Latest version of specfile is here: https://raw.github.com/vlisivka/bash-modules/master/main/bash-modules/spec/bash-modules.spec . I see no major problems with spec file and bash-modules in RHEL5+, CentOS 5+, Fedora 17+, Mandriva 2009+, SLE11+, OpenSuse 12+. Can you suggest me what should be fixed in spec file?
Hello Volodymyr There have been lot's of changes in Fedora :) >%clean >rm -rf "$RPM_BUILD_ROOT" http://fedoraproject.org/wiki/Packaging:Guidelines#Group_tag %clean The %clean section is not required for F-13 and above. Each package for F-12 and below (or EPEL 5) MUST have a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT). >BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) http://fedoraproject.org/wiki/How_to_create_an_RPM_package#SPEC_file_overview BuildRoot: This is where files will be "installed" during the %install process (after the %build process). This is now redundant in Fedora and is only needed for EPEL5. By default, the build root is placed in "%{_topdir}/BUILDROOT/".
The same applies here >%install >rm -rf "$RPM_BUILD_ROOT" http://fedoraproject.org/wiki/How_to_create_an_RPM_package#.25install_section Removal of %{buildroot} is no longer necessary, except for EPEL 5. >%install >rm -rf "$RPM_BUILD_ROOT" > >install -D src/import.sh "$RPM_BUILD_ROOT%_bindir/import.sh" > >mkdir -p "$RPM_BUILD_ROOT%homedir/" >cp -a src/bash-modules/* "$RPM_BUILD_ROOT%homedir/" http://fedoraproject.org/wiki/Packaging:Guidelines#Statically_Linking_Executables Static linkage is a special exception and should be decided on a case-by-case basis. The packager must provide rationale for linking statically, including precedences where available, to FESCO for approval. If you link statically against a library, add yourself to the initialcc list for the library so you can watch for any security issues or bug fixes for which you'd want to rebuild your package against a new version of the library. Here are instructions for making that request.
from spec file >Group: Development/Libraries/Bash this group is not an valid one Also it is a good habit to run rpmlint on your specfile, this will detected majority of problems. If used with "-i" flag will give more detailed output [root@localhost tmp]# rpmlint bash-modules.spec bash-modules.spec:7: W: non-standard-group Development/Libraries/Bash bash-modules.spec: W: invalid-url Source0: bash-modules.tar.gz 0 packages and 1 specfiles checked; 0 errors, 2 warnings. [root@localhost tmp]# [root@localhost tmp]# rpmlint -i bash-modules.spec bash-modules.spec:7: W: non-standard-group Development/Libraries/Bash The value of the Group tag in the package is not valid. Valid groups are: "Amusements/Games", "Amusements/Graphics", "Applications/Archiving", "Applications/Communications", "Applications/Databases", "Applications/Editors", "Applications/Emulators", "Applications/Engineering", "Applications/File", "Applications/Internet", "Applications/Multimedia", "Applications/Productivity", "Applications/Publishing", "Applications/System", "Applications/Text", "Development/Debug", "Development/Debuggers", "Development/Languages", "Development/Libraries", "Development/System", "Development/Tools", "Documentation", "System Environment/Base", "System Environment/Daemons", "System Environment/Kernel", "System Environment/Libraries", "System Environment/Shells", "Unspecified", "User Interface/Desktops", "User Interface/X", "User Interface/X Hardware Support". bash-modules.spec: W: invalid-url Source0: bash-modules.tar.gz The value should be a valid, public HTTP, HTTPS, or FTP URL. 0 packages and 1 specfiles checked; 0 errors, 2 warnings. [root@localhost tmp]#
I advise you to drop the group tag, useless. Notes, 1. Said by Veaceslav, please remove relevant lines. 2. You don't need to add requires for bash, because we default have it in all Fedora system. 3. Veaceslav and you need sponsor, please find a proper sponsor ASAP. We hope less stalled tickets.