http://bugzilla.rpmfusion.org/show_bug.cgi?id=440 Conrad Meyer <konrad(a)tylerc.org&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |konrad(a)tylerc.org --- Comment #2 from Conrad Meyer <konrad(a)tylerc.org&gt; 2009-03-15 21:55:58 --- *** Bug 177 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=440 --- Comment #4 from Andrea Musuruane <musuruan(a)gmail.com&gt; 2009-03-16 16:43:44 --- Some comments: * You should specify a version to checkout from upstream VCS. Otherwise the reviewer cannot be sure to compare/recreate the same exact version you used. Place this details above the Source tag. https://fedoraproject.org/wiki/Packaging/SourceURL#Using_Revision_Control * Some BR are not required: https://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions_2 * Do not strip binaries! Otherwise the debuginfo package is useless: https://fedoraproject.org/wiki/Packaging/Debuginfo * Avoid using dos2unix. Use sed instead: https://fedoraproject.org/wiki/Packaging:Guidelines#Rpmlint_Errors * I see that you use the %{__xxx} macro style. Even though this is not a bug and it is not required that you change it, I suggest you not to use this style because it is not very readable. I cannot think of a good reason to use it instead of just using "xxx". A complete discussion about these case has been discussed in fedora-devel-list: http://www.redhat.com/archives/fedora-devel-list/2008-December/msg01855.html * The icon cache scriptlets are not the same used by the Fedora guidelines: http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#Icon_Cache I haven't checked every requirements but the spec file is quite good as a first release from a rookie :) Unluckily I'm not a sponsor and therefore I cannot sponsor you. I suggest you to do "informal" reviews of other packages to show your understanding of Fedora guidelines to potential sponsors. -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=440 --- Comment #6 from Andrea Musuruane <musuruan(a)gmail.com&gt; 2009-03-16 21:01:52 --- (In reply to comment #5) I suggest you to use the same versioning in the tarball (i.e. %{name}-%{version}-%{releasetag}.tar.gz), instead of using %{name}.tar.gz. Yes, you must remove them. You also must remove duplicate BR: glibmm24-devel (by gtkmm24-devel), gtkmm24-devel (by gtkglextmm-devel) SRPM is 0 bytes. -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=440 --- Comment #8 from Andrea Musuruane <musuruan(a)gmail.com&gt; 2009-03-16 21:30:48 --- (In reply to comment #7) Now it works. Thanks. -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=440 --- Comment #10 from Dave Straub <dave(a)is1337.net&gt; 2009-03-23 23:50:10 --- Minor update: I included the man page in the Debian directory in the spec. I also updated the source tar to the newest upstream revision while I was at it which just removes some Win32 code, so at least it is a smaller SRPM. Spec: http://dave.is1337.net/sources/vbam.spec SRPM: http://dave.is1337.net/sources/vbam-1.8.0-0.4.20090323svn866.fc10.src.rpm (rpmlint is silent) By the way, I still need a sponsor and official review for this package, but any other suggestions/corrections are welcome. Thanks. -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=440 --- Comment #12 from Dave Straub <dave(a)is1337.net&gt; 2009-04-03 21:57:58 --- (In reply to comment #11) Thanks for the response. I updated the spec at the same URL, but I will have a proper SRPM after I patch it. Responses below: Thanks for pointing this out, I will use GPLv2 and LGPLv2+ since both binary files are built from GPLv2 solo and GPLv2 and above source files. (Unless this does not apply for some reason: https://fedoraproject.org/wiki/Licensing/FAQ#Multiple_licensing_situations ) As far as I can see, assembly files are not touched with the default settings, and I am not specifying to include them. This means that file's license is not important to the binary package, correct? Performance seems good enough using the C++ alternatives, and they should keep it portable. However if you think it would be better, I will could pass the needed flags on the respective architectures to use the assembly files (and ask the author or some Fedora list about that license). Okay, I didn't know it will compress man pages on its own. Nifty. I will do this over the weekend. It seems the project is called "VBA-M" in discussions, but the SourceForge project name and all built files are "vbam". I think this makes more sense for the RPM name. Using %cmake generates a verbose Makefile. Removed. Done. I don't see very many occurrences of "vbam" other than the file list. I'd rather not use macros in comment commands as I think they should be copy-and-paste-able. I have used the name macro where applicable in the file list. Is it appropriate to write out the GTK binary's file name "gvbam", or should it have the macro as well ("g%{name}")? I attempted to use %cmake at first, but it wouldn't link properly with BUILD_SHARED_LIBS enabled. This flag is switched on in /etc/rpm/macros.cmake without an option to disable it. I'm no expert in RPM macros; is there a clean syntax for replacing a substring like for shell variables? (I have no luck in searching for this kind of thing.) For the uploaded spec, I used an ugly hack to remove that flag so it can at least make use of the other options in the macro. Is the proper action here to patch the source so that flag works correctly? I used what you suggested, but from Andrea's link, the only given reason for not using dos2unix is that it might break FC3. There is a single flag for dos2unix to do essentially those three commands. Is anyone actually still targeting FC3, or is there another reason for not using dos2unix? I think what I ask above covers it. I will post the new SRPM after I add the patch(es), but the same spec URL currently has the noted changes. Thanks for the detailed suggestions. -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=440 --- Comment #14 from Dave Straub <dave(a)is1337.net&gt; 2009-04-05 18:29:10 --- (In reply to comment #13) Probably, I'll use that instead of their project page. I asked upstream to consider supporting the BUILD_SHARED_LIBS flag properly or disable it by force. I have patches to do both, but I am including the one that disables it until they give a response, so as not to change the project's default behavior. The rawhide build is patched in the SRPM, and that is sent upstream as well. Spec: http://dave.is1337.net/sources/vbam.spec SRPM: http://dave.is1337.net/sources/vbam-1.8.0-0.5.20090404svn877.fc10.src.rpm -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=440 --- Comment #15 from Orcan Ogetbil <oget.fedora(a)gmail.com&gt; 2009-04-06 08:01:02 --- Actually, it should be enough to add -DBUILD_SHARED_LIBS:BOOL=OFF to %cmake . No need to add a patch for this purpose. Let's wait for the upstream's response (but it doesn't look like they intend to make these libraries shared). By the way, make sure that the Fedora specific optflags are passed. They are not honored in the above package either. -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=440 --- Comment #17 from Orcan Ogetbil <oget.fedora(a)gmail.com&gt; 2009-04-06 17:51:47 --- No, see: On my system rpm -E %optflags says: ------------------------------------------------------------------------- -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic ------------------------------------------------------------------------- On the other hand, I see this in the build log of vbam: ------------------------------------------------------------------------- DEBUG: /usr/bin/cmake -E cmake_progress_report /builddir/build/BUILD/vbam-1.8.0/CMakeFiles 32 DEBUG: [ 3%] Building C object CMakeFiles/vbamcore.dir/src/common/memgzio.o DEBUG: /usr/lib64/ccache/gcc -DHAVE_NETINET_IN_H -DHAVE_ARPA_INET_H -DHAVE_ZLIB_H -DFINAL_VERSION -DSDL -DUSE_OPENGL -DBKPT_SUPPORT -DC_CORE -O3 -Wall -I/usr/include/SDL -I/usr/include/glibmm-2.4 -I/usr/lib64/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib64/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/giomm-2.4 -I/usr/lib64/giomm-2.4/include -I/usr/include/gtkmm-2.4 -I/usr/lib64/gtkmm-2.4/include -I/usr/include/gdkmm-2.4 -I/usr/lib64/gdkmm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/include/atkmm-1.6 -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/cairomm-1.0 -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/atk-1.0 -I/usr/include/gtkglextmm-1.2 -I/usr/lib64/gtkglextmm-1.2/include -I/usr/include/gtkglext-1.0 -I/usr/lib64/gtkglext-1.0/include -I/usr/include/libglademm-2.4 -I/usr/lib64/libglademm-2.4/include -I/usr/include/libglade-2.0 -I/usr/include/libxml2 -DSYSCONFDIR='"/etc"' -DWITH_LIRC='0' -DVERSION='"1.8.0-SVN"' -DPKGDATADIR='"/usr/share/vbam"' -DPACKAGE='' -o CMakeFiles/vbamcore.dir/src/common/memgzio.o -c /builddir/build/BUILD/vbam-1.8.0/src/common/memgzio.c ------------------------------------------------------------------------- The above flags are not passed, except -Wall. The sed command I gave before fixes this issue. Note that %optflags should be passed on each usage of the C/C++/Fortran compilers. -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=440 --- Comment #19 from Orcan Ogetbil <oget.fedora(a)gmail.com&gt; 2009-04-08 20:42:54 --- Well, after the optflag issue is solved, the package is pretty much done. Now you need to get sponsored. For this purpose, you may want to do some unofficial reviews. Please check bug #2 for a list. -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=440 --- Comment #21 from Dave Straub <dave(a)is1337.net&gt; 2009-05-31 19:35:20 --- (In reply to comment #20) There have been no updates upstream since I last posted in this bug, and I don't think there was anything left to change in the spec. I am not sponsored in Fedora; VBA-M is the only package I submitted because I've been using it for a while, and I saw VBA is on the RPM Fusion wish list. If you want to see this bug resolved, someone who is already sponsored can feel free to use my spec as a starting point and take over the package request. I will leave the files hosted at their current location for as long as I have an account on that server. -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=440 --- Comment #23 from Dave Straub <dave(a)is1337.net&gt; 2009-05-31 20:53:48 --- (In reply to comment #22) I had every intention to keep this package patched and up to date if it was accepted, but I am not sponsored. It looks like submitters of pending packages all have people working with them, so I can't give many more suggestions that others haven't already said. I am not going to search for random projects I don't use to submit to Fedora in order to get sponsored, either. That version has been uploaded since April: http://dave.is1337.net/sources/vbam.spec Their configuration was overriding the flags set in the environment by %cmake. The flags they used would be covered by %optflags anyway, so I just removed the offending lines with: sed -i '/CMAKE_C.*_FLAGS/d' CMakeLists.txt -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=440 --- Comment #25 from Kevin Kofler <kevin.kofler(a)chello.at&gt; 2009-06-01 15:44:55 --- You don't have to contribute a random package to Fedora, you can be sponsored within RPM Fusion (for RPM Fusion only, i.e. if you later want to contribute to Fedora, you'll need to get sponsored separately there). -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.